As a new player, I want to see the initial game board with all important items so that I can get a first idea what the game is about without reading anything.

[suchja]

Notes

• some people might not know the game. So it should be very easy for them to find out what to do! - relates to NFR-1 - Ease of use
• Project structure and class design needs to consider NFR-3 - Extensibility (UI) as well as NFR-4 - Modular Design
• Here we will go with an initial fixed size GameBoard (20x20). In #6 we will change this, but until then it is fixed.
• It's okay when Snake appears at the same position with each start.
• Food should be randomly placed at different positions with each start.

Acceptance criteria

• [x] At startup the GameBoard with Snake (head and one tail item) and first Food is shown
• [x] Hint is shown that arrow keys will start the game
• [x] Application can be closed

[suchja]

Adding this to milestone 0.1 as it relates to the core game.

[suchja]

Design

What is the easiest implementation of this that would align with acceptance criteria and NFRs?

• MainWindow - part of widgetapp Qt6 Widget project
  • visualizes hint from GameViewModel.
  • shows GameBoardView inside QGraphicsView as CentralWidget
  • should be fixed size and ensure that there is enough space for the GameBoardView to show 20x20 grid with a tile size of 20 pixels
  • doesn't need any menus or similar
  • Needs to provide normal close functionality
• GameModel - part of snakecore library project
  • stores dimensions of board (e.g 20x20)
  • provides access to SnakeModel
  • provides access to getPositionOfFood() : QPointF
• SnakeModel - part of snakecore library project
  • knows board dimensions
  • starts with a provided position on the board
  • getBody() : std::deque<QPoint> provides all body elements of the snake
• GameViewModel - part of widgetapp Qt6 Widget project
  • gets pointer to GameModel when it is created
  • provides required Dimensions for drawing the board background
  • provides a "hint" indicating how game can be started
• GameBoardView : QGraphicsScene? - part of widgetapp Qt6 Widget project
  • setViewModel -> triggers the first drawing!
  • draws grid background
  • draws snake
  • draws food

Tasks (Implementation)

• [x] Create test-project for widget-app to test GameViewModel
• [x] Create unit test for GameViewModel::getBoardDimensions() : QRect. -> Should use info from Game and multiply with Tile-Size.
• [x] Create GameBoardView, add it to MainWindow and let it draw Background based on info from GameViewModel (no tests required here!)
• [x] Draw snake on GameBoardView
  • [x] Add Snake to model,
  • [x] add test that start position of head is in the center and implement snake accordingly
  • [x] add test that body of snake has one item and that it is connected to head and implement snake accordingly
  • [x] Let Game provide const access to Snake (requires unit test) -> changed to only provide position of Snake
  • [x] Let GameViewModel provide info about snake`s position (not sure how exactly)
  • [x] Let GameBoardView draw snake

[suchja]

Design Decisions

snakecore does depend on Qt Core

The core library (now called snake-core) providing the game logic will be based on Qt Core. Although I usually try to fully separate the model (business logic) from technology as good as possible, I prefer to use signals/slots and also the provided "garbage collection".

Dedicated setViewModel method instead of constructor injection

Generally speaking I like dependency injection via the constructor. However, here I'm using a dedicated method on the GameBoardView to inject the dependency to the GameViewModel. Here I currently see the following benefits:

1. Flexibility in Initialization: By using a setter method (setViewModel), you decouple the instantiation of the GameViewModel from the GameView itself. This separation allows you to initialize and set the GameViewModel independently of creating the GameView.
2. Late Binding: The setViewModel method supports late binding, meaning you can change the GameViewModel instance associated with a GameView dynamically at runtime if required. - Although I'm not sure whether this is required here at all.
3. Separation of Concerns: The constructor of GameView should ideally focus on initializing its own internal components and setting up basic functionality. Handling the GameViewModel assignment through a setter method keeps the constructor cleaner.

As I'm not that familiar with this way of injection, it is more like a try. I'll need to come back later on and see whether this really holds true and improves the overall design.

QList vs std::vector (or similar)

For this design it is necessary to pass around lists of points for the snake's tail. Generally speaking this involves usually a maximum of 10-15 objects. Therefore performance consideration isn't that big of a problem. However, as my goal is also to learn about Qt and current versions of C++, I'm deciding to use QList. Although I usually avoid relying on a framework or technology in core libraries, I already decided to use Qt::Core for snakecore. Therefore this isn't as much an issue. Then it seems that especially in Qt6 the QList has been optimized for better memory management. The core feature I see for this scenario is implicit sharing (copy on write). This means an QList instance is only copied, if an element is added. For the snake game an element is only added to the body, if the snake eats a food. Therefore this happens not that often.

[suchja]

Tasks (Implementation) - continued

• [x] Draw food on GameBoardView
  • [x] Add FoodGenerator to generate random QPoint within the game board dimensions (requires tests!)
  • [x] Let Game provide provide access to QPoint as food
  • [x] Enhance GameViewModel and GameBoardView to draw food from Game.

Open Issues

Testing FoodGenerator (random positions)

As the FoodGenerator uses QRandomGenerator it is difficult to apply automated tests. Problem is that although two consecutive calls shouldn't result in the same position there is a slight probability that it will. If two consecutive calls result in the position, this is not an error per se. It only is an error, if it happens all the time or if the sequence of the created random positions is always the same.

Adding tests on the output of QRandomGenerator seems to be a bad idea. As there is always a slight chance that due to the randomness the tests will fail. In this case I will go without tests, because to me a test that wrongly fails is a real anti pattern. Thus I provide the tests, let them execute and verify the results manually. Then I mark them to be skipped (QSKIP) in the future. Once I have an idea how to properly test this, they should be updated accordingly.

Testing GameViewModel::getFoodPosition()

Generally speaking testing the GameViewModel::getFoodPosition() involves similar problems (regarding randomness) as described in the previous section. Additionally this should test that the coordinates are in the correct coordinates system. Unfortunately some coordinates overlap between the row/column based system applied by the snakecore and the GraphicsScene related system applied by the widgetapp. Therefore I skip these tests as well. Somehow I need to provide a better way of testing this.

[suchja]

Tasks (Implementation) - continued

• [x] Show hin to user on MainWindow
  • [x] Enhance GameViewModel to "trigger" UserMessages (requires tests!)
  • [x] Show a matching string on MainWindow

Although I'm not sure about the user experience of this, I'll show the hint in the StatusBar of the MainWindow.