As a player, I want to control the snake in all four directions (up, down, left and right) so that I can play the game.

[suchja]

Notes

• Project structure and class design needs to consider NFR-3 - Extensibility (UI) as well as NFR-4 - Modular Design

Acceptance Criteria

• [x] The snake responds to the arrow keys for movement.
• [x] The head draws an imaginary path when directions are changed quickly and the body follows
• [x] Moving in the opposite direction is not possible (hint is shown until next key press)
• [x] The snake changes direction smoothly without stopping.
• [x] The snake can collide/cross itself as that will be changed as part of #11
• Quick key presses between 2 movements will override each other (the last one wins!)
• [x] Between two movements of the snake only the first arrow key press will be accepted! (hint is shown until the next key press)

Last Acceptance criteria replaced (initial version kept for traceability), because it contradicted with the "opposite direction" criteria

[suchja]

Adding it to milestone 0.1 as it is core gaming logic

[suchja]

What is required for the whole story?

• Behavior
  • The following assumes the snake is moving. If not, #3 should apply
  • As long as the user does not press any arrow key the snake constantly moves into its current direction
  • If the user presses another key than an arrow key, a hint is shown "Key is not supported!". It will disappear with the next key press (if that is valid).
  • User presses the exact contrary arrow key to the direction the snake is currently moving (e.g. snake moves to left and user presses right arrow key) -> add as acceptance criteria!
  • Snake does not change direction (move is ignored)
  • A hint is shown to the user "Not possible to immediately go to opposite direction!"
  • hint disappears with next "correct" arrow key
  • User presses an arrow key (e.g. down) while snake is moving in another direction (e.g. right)
  • at next move the head moves one tile into the direction while the remaining body still moves one tile into the previous direction
  • one additional move and the head follows its "new" direction, the first element of the body follows this direction while the remaining part of the body moves still one tile into the "old" direction.
  • ...
  • User presses two different arrow keys before the next move -> add as acceptance criteria!
  • Snake moves into direction of the last pressed arrow key (keys override as long as next move is not executed)
  • snake behaves the same as defined in previous scenario
  • User presses one arrow key, head moves one tile into the direction, user presses another arrow key
  • basically the same as in the previous two scenarios except that now 2 direction changes are "active".
  • snake's head draws an "imaginary" path based on several direction changes and the complete body follows
  • Tests
  • [x] With each movement the Snake (head & body) advances one step into the set movement direction.
    • Is this already tested by #3?
  • [x] User presses "return" or "W" key,
    • [x] Snake keeps moving into the previously set direction and
    • [x] Hint "Key is not supported!" is shown in the statusbar
    • [x] Hint stays with every press of an unsupported key
    • [x] Hint disappears with next supported key!
  • [x] Snake currently moves up and user presses arrow up key -> nothing changes!
  • [x] Snake currently moves up and user presses arrow down key
    • [x] Snake does not change direction (move is ignored)
    • [x] A hint is shown to the user "Not possible to immediately go to opposite direction!"
    • [x] hint disappears with next "correct" arrow key
  • [x] Snake (head & 1 body element) currently moves to the left and user presses arrow up key.
    • [x] at next move the head moves one tile up while the remaining body still moves one tile to the left
    • [x] one additional move and the head moves still up, the element of the body now follows up.
  • Snake moves down and user presses (between 2 moves) arrow left key and arrow right key immediately after another. (left is overridden by right)
    • at next move the head moves one tile right while the remaining body still moves one tile down
    • one additional move and the head moves still to the right, the element of the body now follows to the right.
    • Replaced as defined here
  • [x] Snake (head & 1 body element) currently moves to the left and user presses arrow up key, Snake moves and user presses arrow right key.
    • [x] at move after the arrow up key, the head moves one tile up while the remaining body still moves one tile to the left
    • [x] at the first move after the arrow right key the head moves to the right, the element of the body moves up.
    • [x] with the next move, the head proceeds to the right and the body now follows to the right.
• Retrospective
  • Although tests are quite similar to the behavior, previously defined, I came across a few points I missed before. Therefore it seems to make sense to do both even if it takes some time (writing down both took around 45 Minutes).

[suchja]

Starting with the first test:

• User presses "return" or "W" key,
  • Snake keeps moving into the previously set direction and
  • Hint "Key is not supported!" is shown in the statusbar

• Interface
  • Here it seems we should come back to one of the todos from #9
  • GameViewModel::processKeyboardAction knows whether it is a supported key. Thus it could raise the GameViewModel::userMessageUpdated signal and directly provide the updated user message with it. Thus we could separate the user message from the gameStarted signal.
• Implementation / Tests
  • I'm not totally clear on whether it is enough to test for the userMessageUpdated signal on the GameViewModel
  • Additionally I could try to add a test that an unsupported key does not trigger Game::setMoveDirection. This would either require a more complex test or adding a mocking library to the mix. Currently I consider both as too complex. therefore I go ahead without such a test. However, I added at least on the todo list to check this later on.
  • This gets more difficult than initially assumed. Problem is that the handling of the user message interferes with #3 .
  • [x] UserMessages::StartGame stays until an arrow key is pressed even if an unsupported key is pressed.
  • [x] userMessageChanged is emitted with UserMessages::None when the game is properly started
  • [x] userMesaageChanged is emitted with UserMessages::KeyNotSupported when a unsupported key is pressed after the game is started
  • [x] userMessageChanged is emitted with UserMessages::None with next supported key, after GameViewModel::m_current_message was set to UserMessages::KeyNotSupported.
• Refactoring
  • Separated the UserMessages handling from gameStarted signal. (update #9 accordingly) -> Improves Separation of Concerns
  • Improved UserMessages to only emit a signal when it really changes. At least in MVVM for .NET this is best practice and should improve performance here as well.
• Retrospective
  • Although it seemed to be a pretty easy functionality, it took quite some time (around 2h).
  • I changed the unit tests (especially for GameViewModel) several times until they made sense.
  • It is still not clear to me how classes under test are put into the state required to start the test. Currently I call the available interface, but to me this seems to add a lot of knowledge about the behavior of the class into those tests. Thus changing tests later on probably becomes much more difficult.

[suchja]

Proceeding with next test:

Snake currently moves up and user presses arrow down key:

• Snake does not change direction (move is ignored)
• A hint is shown to the user "Not possible to immediately go to opposite direction!"
• hint disappears with next "correct" arrow key

• Interface
  • setMoveDirection on Snake and Game will return a bool indicating whether the direction was accepted.
  • GameViewModel::userMessageChanged will transfer the added UserMessages::WrongDirection
• Implementation
  • Snake should get the business logic ensuring that opposite direction is not possible.
• Retrospective
  • I changed some of the unit tests for the snake from beginning with the "key method name" in the test name to "should...". Generally speaking this seems to make sense as it shows what behavior is tested. However, this is only the right direction, when these tests are focused on behavior and NOT on single method invocation.
  • Using more integration like unit tests like test_GameViewModel::processKeyboardInput_shouldSignalUserMessageUpdated_whenOppositeDirectionIsPressed() isn't that good. On that specific test I wondered why it stills fails and it was of the preconditions that I forgot to set in the test. Here something like mock object would have helped.

[suchja]

Here we go with the next test:

Snake (head & 1 body element) currently moves to the left and user presses arrow up key.

• at next move the head moves one tile up while the remaining body still moves one tile to the left
• one additional move and the head moves still up, the element of the body now follows up.

• Interface
  • Looks like there is no change required.
• Implementation / Tests
  • Although the test states head & 1 body element it would be good to see 2 or even 3 elements so the movement of the snake can be verified. This adds some issues
  • [x] there are some tests that specifically test for one body element. Those need to be updated
  • [x] the order of the elements within Snake::m_body is important (last element is assumed to be first element in QList). This probably needs to be checked with a test!
• Retrospective
  • I thought it would be easy to simply increase the size of the snake's body. So I did that without any tests and also without running the existing tests afterwards. Unfortunately I added the elements of the body in wrong order which showed a wired behavior when the snake started. Additionally several tests went from green to red, because they only assumed a single element in the body. So now I have to fix that as well.
  • Therefore I should always go with the tests first as suggested by TDD.

[suchja]

Now let's move to the final test:

Important: Behavior / Test changed as it was inconsistent in its original version!

Snake moves down and user presses (between 2 moves)

• arrow left key and arrow right key (immediately one after another)
  • This would result in the the opposite direction handling as covered by previous test, but
  • To have a consistent behavior only the first key press will be accepted. Once an arrow key is pressed, the snake needs to move first, before another arrow key press is accepted.
• arrow left key and arrow up key (immediately one after another)
  • Only the first key press will be accepted. Once an arrow key is pressed, the snake needs to move first, before another arrow key press is accepted.
  • This case would otherwise imply an implicit move to the opposite direction!
• If one of these cases is detected, the message "Only one direction change per move is allowed" should appear.

• Interface
  • Now Snake (as well as GameViewModel) need to transfer 2 different errors. Therefore the Snake::setMoveDirection needs to be changed. I decided to go for an enum instead of exception for returning the different errors.
• Implementation / Tests
  • Although I see benefits in using exception for returning the errors from Snake::setMoveDirection, I decided against it, because
  • currently there is no long call chain. The only class that is affected by this change and has no stack in it, is Game. As it only forwards the information the change should be really small.
  • After I learned about noexcept I would go (for the moment) with the probably minor performance improvement.
• Retrospective
  • Already while implementing the test, it occurred to me that this specific test doesn't fit with the other requirements (especially with moving into the opposite direction). Therefore the test needed to be changed.