separate prototype, add generic softdev intro

.gitignore

@@ -99,4 +99,5 @@ ENV/
 
 # mypy
 .mypy_cache/
-getting_started/tiles/*
+
+software_engineering/tiles/*

index.rst

@@ -15,13 +15,22 @@ piece of software is more complex. You are facing questions like:
 Below you find development tools and techniques that help you to write
 programs that get the job done and don’t fall apart.
 
+Developing Software
+-------------------
+
+.. toctree::
+   :maxdepth: 1
+
+   software_engineering/README.rst
+   software_engineering/prototype.rst
+   software_engineering/code_review.rst
+
 Setting up a Python Project
 ---------------------------
 
 .. toctree::
    :maxdepth: 1
 
-   getting_started/prototype.rst
    getting_started/virtualenv.rst
    getting_started/git_repo.rst
    getting_started/structure.rst

software_engineering/README.rst

@@ -0,0 +1,99 @@
+
+The Dungeon Explorer Game
+=========================
+
+.. image:: title.png
+
+*image generated with dreamstudio*
+
+In the following chapters, we will write a small game called **Dungeon Explorer**.
+Writing a game is a great way to both become better at programming and to exemplify a systematic approach to programming.
+
+What Software Development is about
+----------------------------------
+
+.. image:: software_engineering.png
+
+Software development is more than writing code.
+While most courses and online resources focus very much on the process of writing code,
+it is easy to forget that several things that are necessary before the code can be written:
+
+* an **idea** that provides a reason for the program to exist (*"why"*)
+* **requirements** that describe what the program should do (*"what"*)
+* a **design** that describes core mechanics of the program (*"how"*)
+* the actual **implementation**
+
+When moving from the idea towards code, one gradually translates the informal, prose description of the problem into a *formal language*. Much of it requires gaining a deeper understanding of a task that is unknown at first. This is what much of a software developers work is really about.
+
+In a simple program, like many learning examples and coding challenges, the first three steps are nonexistent or at least very easy. 
+In any real-world software project, the first three steps are often more difficult than the implementation.
+When writing requirements or designing a program, the software developer does not only have to find a path that brings the original idea to life, but also anticipate what forces the software will have to adapt to in the future.
+
+Let's look at an example of how the first three steps would look for a **Dungeon Explorer** game:
+
+The Idea
+--------
+
+*"In the Dungeon Explorer game, an adventurer roams a dungeon, solves puzzles, avoids traps and finds treasures."*
+
+The Requirements
+----------------
+
+Here is a short example of how the idea could be fleshed out more:
+
+1. User Interface
+~~~~~~~~~~~~~~~~~
+
+=== ==============================================================
+#   description
+=== ==============================================================
+1.1 The dungeon is seen from the top as a 2D grid
+1.2 The dungeon is drawn from square graphic tiles
+1.3 The adventurer is controlled by the player by pressing keys
+=== ==============================================================
+
+2. Dungeon Elements
+~~~~~~~~~~~~~~~~~~~
+
+=== ==============================================================
+#   description
+=== ==============================================================
+2.1 There are walls that are impassable
+2.2 There is an exit square that leads to the next level
+2.3 There are keys that are needed to open doors
+=== ==============================================================
+
+3. Traps
+~~~~~~~~
+
+=== ==============================================================
+#   description
+=== ==============================================================
+3.1 There are pits. If the player falls into one, they die
+3.2 There is green slime where the player loses health
+3.3 There are fireballs that travel in straight lines
+=== ==============================================================
+
+The Design
+----------
+
+Two key elements of the game deserve to be described better.
+First, the grid that is used for the dungeon is based on *integer x/y coordinates*:
+
+.. image:: grid_model.png
+
+Second, the following **flowchart** describes how the program actually works:
+
+.. image:: flowchart.png
+
+.. note::
+
+   At this point, we have not decided what libraries or even what programming language to use. This is good, because the design makes the task more specific without constraining the developer.
+
+These are just two examples of design techniques.
+For a first implementation, see the next chapter.
+
+Reflection Questions
+--------------------
+
+- which of the in the software development diagram could be automated with the help of a Large Language Model (LLM)?

software_engineering/code_review.rst

@@ -0,0 +1,62 @@
+Code Reviews
+============
+
+A **Code review** means that another person reads your code. This could
+be:
+
+-  a senior engineer
+-  a programmer with similar experience
+-  a junior developer
+
+All three provide complementary feedback that is useful in many ways.
+Besides discovering bugs, they also expose general design weaknesses
+(that might become bugs in the future) or simply learn you
+alternative/better ways to solve the problem.
+
+Because of that, many engineers see code reviews as the 
+**number one technique to build high-quality software.**
+
+
+Exercise 1: Code Review
+-----------------------
+
+Inspect the Python code in :download:`prototype_opencv.py`.
+Answer the following questions:
+
+* What libraries does the program use?
+* What variables does the program define?
+* What do the functions do?
+* Which parts of the code correspond to the flowchart?
+* How are the grid coordinates represented?
+* What would you like to know more about?
+
+Exercise 2: Modify
+------------------
+
+Extend the code such that:
+
+* the player can be moved up and down.
+* the player stops at the border of the screen
+* the player respawns at the left if they leave the grid on the right side
+* there is a "teleport" key that jumps to a random grid point
+
+
+.. topic:: What to look for in a code review?
+
+   Here are a few things to pay attention to in a code review.
+   The list is by far not exhaustive:
+
+   -  Does the module header explain understandably what the code does?
+   -  Are constants listed right after the import statements?
+   -  Is the code sufficiently documented?
+   -  Are the functions understandable?
+   -  Are the variable names descriptive
+   -  Is the code formatted in a consistent way?
+   -  Are there code duplications?
+   -  Is there dead code that does nothing?
+   -  Are there code sections that are unnecessarily long?
+   -  Are there while loops that could run forever?
+   -  Are there deeply nested code sections?
+   -  Do all functions have exactly one way to return data (either by
+      return value OR by modifying an object, not both).
+