Animating Snake Movement

Using FillPercent

Let's add the FillPercent floating point member to our class:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  float FillPercent{0};
8  // ...
9};

When our game starts or restarts, we'll initialize FillPercent to 0, except for the two cells that contain our initial snake segments:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void Initialize() {
8    CellState = Empty;
9    SnakeRect = BackgroundRect;
10    SnakeColor = Config::SNAKE_COLOR;
11    SnakeDuration = 0;
12    FillPercent = 0.0;
13
14    int StartRow{Config::GRID_ROWS / 2};
15    if (Row == StartRow && Column == 2) {
16      CellState = Snake;
17      SnakeDuration = 1;
18      FillPercent = 1.0;
19    } else if (Row == StartRow && Column ==3) {
20      CellState = Snake;
21      SnakeDuration = 2;
22      FillPercent = 1.0;
23    } else if (
24      Row == StartRow &&
25      Column == 11
26    ) {
27      CellState = Apple;
28    }
29  }
30  // ...
31};

Currently, our Render() function checks if CellState == Snake to decide if it needs to render the snake in our cell. We'll update this to check if FillPercent > 0 instead:

1// Cell.h
2// ...
3
4class Cell {
5public:
6  void Render(SDL_Surface* Surface) {
7    SDL_FillRect(Surface, &BackgroundRect,
8      SDL_MapRGB(
9        Surface->format,
10        BackgroundColor.r,
11        BackgroundColor.g,
12        BackgroundColor.b
13      )
14    );
15
16    if (CellState == Apple) {
17      Assets.Apple.Render(
18        Surface, &BackgroundRect);
19    } else if (FillPercent > 0) {
20      SDL_FillRect(Surface, &SnakeRect,
21        SDL_MapRGB(
22          Surface->format,
23          SnakeColor.r,
24          SnakeColor.g,
25          SnakeColor.b
26        )
27      );
28    }
29  }
30  // ...
31};

Using FillDirection

We'll also need a FillDirection value representing which direction we need to fill our cell. For example, if the snake is entering the cell from the left, the cell should be filled with the snake color from left to right.

For example, if on a given frame, FillPercent is 0.5 and FillDirection is Right, that corresponds to the left half of the cell containing the snake color, and the right half of the cell containing the background color.

Let's add FillDirection to our class, using the MovementDirection type we have already declared:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  MovementDirection FillDirection{Right};
8  // ...
9};

We'll initialize it to Right for all cells, as our snake always starts by moving right:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void Initialize() {
8    FillDirection = Right;
9    // ...
10  }
11  // ...
12};

However, when a snake visits a cell, we'll update that cell's FillDirection to keep track of which direction the snake entered the cell from. We'll also set FillPercent to 0 when the snake head first enters, and we'll animate this value from 0 to 1 in the next section:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void Advance(SDL_UserEvent& E) {
8    SnakeData* Data{
9      static_cast<SnakeData*>(E.data1)};
10
11    bool isThisCell{
12      Data->HeadRow == Row &&
13      Data->HeadCol == Column
14    };
15
16    if (isThisCell) {
17      if (CellState == Snake) {
18        SDL_Event Event{UserEvents::GAME_LOST};
19        SDL_PushEvent(&Event);
20        return;
21      }
22      if (CellState == Apple) {
23        SDL_Event Event{
24          UserEvents::APPLE_EATEN};
25        SDL_PushEvent(&Event);
26      }
27      CellState = Snake;
28      SnakeDuration = Data->Length;
29      FillDirection = Data->Direction;
30      FillPercent = 0;
31    } else if (CellState == Snake) {
32      if (SnakeDuration == Data->Length) {
33        FillDirection = Data->Direction;
34      }
35      SnakeDuration--;
36      if (SnakeDuration <= 0) {
37        CellState = Empty;
38      }
39    }
40  }
41  // ...
42};

To give our snake's head the illusion of sliding into the cell, we'll update our SnakeRect variable to gradually increase how much of the cell is filled with our snake color. Our FillPercent should start at 0.0 when the snake first enters the cell and, by the time the snake is ready to advance to the next cell, FillPercent should be at 1.0.

As we want our animation to update every frame, we'll use the Tick() function to implement this. We know our cell has animation work to do if its CellState is Snake, but its FillPercent hasn't yet reached 1.0. In that case, we'll call a new private GrowHead() function:

1// Cell.h
2// ...
3
4class Cell {
5public:
6  void Tick(Uint32 DeltaTime) {
7    if (CellState == Snake && FillPercent < 1) {
8      GrowHead(DeltaTime);
9    }
10  }
11  // ...
12
13private:
14  void GrowHead(float DeltaTime) {
15    // TODO: Grow Head
16  }
17  // ...
18};

Note that the GrowHead() invocation is converting the DeltaTime from a Uint32 to a float. This is important, as we want to use floating point calculations in GrowHead().

Within successive invocations of GrowHead(), we want to increase our FillPercent such that it reaches 1.0 by the time our snake is ready to advance to the next cell. For example, if our Config::ADVANCE_INTERVAL is set to 200, our snake advances every 200 milliseconds, so we want our fill percent to increase from 0 to 1 over that interval.

For example, if DeltaTime is 20, that means 20 milliseconds have passed since the previous frame. We'd want our fill percent to increase by 0.1, as the 20 milliseconds delta time is 10% of the 200-millisecond interval time.

So, in general, we increase our FillPercent by DeltaTime divided by ADVANCE_INTERVAL. We also don't want FillPercent to go above 1.0, so if this calculation increases it beyond that, we reduce it back down:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void GrowHead(float DeltaTime) {
8    using namespace Config;
9    FillPercent += DeltaTime / ADVANCE_INTERVAL;
10    if (FillPercent > 1) FillPercent = 1;
11
12    // TODO: Grow Head
13  }
14};

We now use this FillPercent value in combination with our FillDirection to modify the size or position of our SnakeRect.

Our SnakeRect value should have the same x, y, w, and h values as our BackgroundRect, with the exception of one property. The property we need to change depends on our FillDirection, and what its new value should be depends on our FullPercent.

• To fill the cell from left to right, we scale the width (w) of the snake rectangle by our FillPercent
• To fill the cell from top to bottom, we scale the height (h) of the snake rectangle based on our FillPercent
• To fill the cell from right to left, we move the horizontal position (x) of our snake rectangle. Since x represents the left edge of the rectangle, we need to start it at the right edge of the cell and move it leftwards. We calculate the starting x position by adding BackgroundRect.x (the left edge of the cell) to the remaining portion of the cell width, which is CELL_SIZE * (1 - FillPercent).
• To fill the cell from bottom to top, we move the vertical position (y) of our snake rectangle. Since y represents the top edge of the rectangle, we need to start it at the bottom edge of the cell and move it upwards. We calculate the starting y position by adding BackgroundRect.y (the top edge of the cell) to the remaining portion of the cell height, which is CELL_SIZE * (1 - FillPercent).

Putting all this logic together, we have the following. Note that we're using Config::CELL_SIZE to retrieve the width or height of each cell. We could alternatively have used BackgroundRect.w or BackgroundRect.h - they all have the same value:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void GrowHead(float DeltaTime) {
8    using namespace Config;
9    FillPercent += DeltaTime / ADVANCE_INTERVAL;
10    if (FillPercent > 1) FillPercent = 1;
11
12    SnakeRect = BackgroundRect;
13    if (FillDirection == Right) {
14      SnakeRect.w = CELL_SIZE * FillPercent;
15    } else if (FillDirection == Down) {
16      SnakeRect.h = CELL_SIZE * FillPercent;
17    } else if (FillDirection == Left) {
18      SnakeRect.x = BackgroundRect.x +
19        CELL_SIZE * (1 - FillPercent);
20    } else if (FillDirection == Up) {
21      SnakeRect.y = BackgroundRect.y +
22        CELL_SIZE * (1 - FillPercent);
23    }
24  }
25  // ...
26};

Running our game, we should now see our snake's head animating smoothly. However, our other snake segments remain on screen even after the snake has left those cells. Let's apply similar logic in reverse to animate the snake's tail leaving cells it no longer occupies.

We can animate the snake's tail leaving a cell in much the same way we animated the head entering. First, we need to update the FillDirection variable with the direction that the snake's head leaves our cell - that is, the turn after the snake entered the cell.

We can determine this from the UserEvents::ADVANCE event that comes after the ADVANCE event where the snake entered our cell. There are many ways we could detect this - we could add a new variable to our Cell class for example.

In our setup, we can also infer this by comparing the snake's current length to the SnakeDuration remaining on our Cell, before we decrement it. If those values are the same, that means the snake's head entered our cell on the previous turn, and is leaving our cell on this turn.

As such, its Direction is the direction that it is leaving our cell, and we can set FillDirection accordingly:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void Advance(SDL_UserEvent& E) {
8    SnakeData* Data{
9      static_cast<SnakeData*>(
10        E.data1)};
11
12    bool isThisCell{
13      Data->HeadRow == Row &&
14      Data->HeadCol == Column
15    };
16
17    if (isThisCell) {
18      // ...
19    } else if (CellState == Snake) {
20      if (SnakeDuration == Data->Length) {
21        FillDirection = Data->Direction;
22      }
23      SnakeDuration--;
24      if (SnakeDuration <= 0) {
25        CellState = Empty;
26      }
27    }
28  }
29  // ...
30};

Updating Tick()

In our Tick() function, we know that we need to animate the snake out of our cell if its CellState is not Snake, but it is still rendering some part of the snake segment, that is, its FillPercent is greater than 0. We'll create a new ShrinkTail() private method to handle this animation:

1// Cell.h
2// ...
3
4class Cell {
5public:
6  void Tick(Uint32 DeltaTime) {
7    if (CellState == Snake && FillPercent < 1) {
8      GrowHead(DeltaTime);
9    } else if (CellState != Snake && FillPercent > 0) {
10      ShrinkTail(DeltaTime);
11    }
12  }
13  // ...
14private:
15  // ...
16  void ShrinkTail(float DeltaTime) {
17     // TODO: Shrink Tail
18  }
19  // ...
20};

The logic we need for ShrinkTail() will effectively be the inverse of what we had in GrowHead(). Therefore, we update FillPercent and SnakeRect in the opposite way we did within GrowHead():

• We use the DeltaTime and ADVANCE_INTERVAL to decrease the FillPercent
• If this causes the FillPercent to fall below 0, we increase it back to 0.

Our SnakeRect calculations are the same as they were in GrowHead(), but in the opposite direction:

• The FillDirection == Right logic in ShrinkTail() is the same as the FillDirection == Left logic in GrowHead()
• The FillDirection == Left logic in ShrinkTail() is the same as the FillDirection == Right logic in GrowHead()
• The FillDirection == Top logic in ShrinkTail() is the same as the FillDirection == Bottom logic in GrowHead()
• The FillDirection == Bottom logic in ShrinkTail() is the same as the FillDirection == Top logic in GrowHead()

Our complete ShrinkTail() function looks like this:

1// Cell.h
2// ...
3
4class Cell {
5  // ...
6private:
7  void ShrinkTail(float DeltaTime) {
8    using namespace Config;
9    FillPercent -= DeltaTime / ADVANCE_INTERVAL;
10    if (FillPercent < 0) FillPercent = 0;
11
12    if (FillDirection == Right) {
13      SnakeRect.x = BackgroundRect.x +
14        CELL_SIZE * (1 - FillPercent);
15    } else if (FillDirection == Left) {
16      SnakeRect.w = CELL_SIZE * FillPercent;
17    } else if (FillDirection == Up) {
18      SnakeRect.h = CELL_SIZE * FillPercent;
19    } else if (FillDirection == Down) {
20      SnakeRect.y = BackgroundRect.y +
21        CELL_SIZE * (1 - FillPercent);
22    }
23  }
24  // ...
25};

Our final Cell.h code is available below:

The remaining project files (which were not changed in this section) are available here:

• Rubik-SemiBold.tff from Google Fonts
• apple.png by AomAm on IconFinder

Congratulations on building your working Snake game! You've learned a lot about SDL2, game loops, event handling, and animation. However, the learning process doesn't stop here.

A crucial part of becoming a better programmer is to experiment, iterate, and improve upon your creations. By taking on self-directed challenges, you solidify your understanding and develop problem-solving skills.

Now that you have a functional base, consider exploring some of the following improvements. These will not only enhance your game but also deepen your understanding of C++ and game development principles. Think of these as opportunities to apply what you've learned and push your abilities further.

User-Defined Game Settings

Currently, many of the game's core parameters, like grid size (GRID_ROWS, GRID_COLUMNS) and the snake's movement speed (ADVANCE_INTERVAL), are hardcoded as constants. A more flexible and user-friendly approach would be to allow the player to customize these settings.

Consider adding a simple menu system, perhaps accessible at the start of the game or through a pause screen. This menu could present options to:

• Adjust Grid Size: Let the player choose between different grid dimensions (e.g., small, medium, large). This will affect the game's difficulty and play area.
• Change Snake Speed: Offer options to control how quickly the snake moves (e.g., slow, normal, fast). This can significantly alter the game's challenge.
• Customize Colors: Allow the player to personalize the snake's color, the background, or the cell colors.

Implementing these features will require you to:

• Create UI elements to represent the settings.
• Handle user input to change the settings.
• Store the selected settings (perhaps in a separate GameSettings class).
• Modify your game logic to use these settings instead of hardcoded values.

Input Queue

Currently, every time our game advances, only the most recent keyboard input is used to determine how the snake turns (GameState::NextDirection). This can make our game effectively ignore some inputs if the user provides an additional input before the next Advance().

This behavior is sometimes fine, but many games use an input queue to allow all inputs provided in quick succession to be acted upon.

This involves creating a data structure (like a std::vector or std::queue) that stores a sequence of player inputs. Then, in your game's update loop, you would process all of the inputs from the queue in a way that feels better for the type of game you're making.

Reducing Event Traffic

To keep things simple, our project routed pretty much every event through to every relevant object in our game. This results in a lot of excess traffic, where the object's HandleEvent() functions are invoked with an event the object has no interest in.

Every function call that results in no effect has an unnecessary performance cost. An obvious way to reduce this traffic is having each parent check an event is relevant to its children before forwarding it:

1void HandleEvent(const SDL_Event& E){
2  if (isRelevantToChildren(E.type) {
3    for (auto& Child : Children) {
4      Child.HandleEvent(E);
5    }
6  }
7};

However, this limits flexibility. When creating a parent class, we often won't know what type of children we'll eventually be managing.

Even if we did know exactly what event types the children are interested in, declaring that within the parent would typically be a bad design.

To keep our code well organized and understandable, the event types that a class is interested in should be managed within that same class. For example, the event types that Cell objects are interested in should be declared in the Cell class.

Objects can then provide that list to their parent, or to some object that is managing event traffic. For example:

1class Child: public EventReceiver {
2  // Subscribe to event types from constructor
3  Child(EventReceiver* Parent) {
4    Parent->SubscribeToEventTypes({
5      UserEvents::GAME_START,
6      UserEvents::GAME_END,
7      // ...
8    })
9  }
10  
11  // ...
12}

This system can become increasingly elaborate - for example, objects may subscribe or unsubscribe from events at different points during their lifecycle:

1class Child: public EventReceiver {
2  // ...
3  void SetIsDisabled() {
4    // No longer interested in mouse events
5    Parent->UnsubscribeToEventTypes({
6      SDL_MOUSEMOTION,
7      SDL_MOUSEBUTTON
8    })
9  }
10  
11  // ...
12}

This situation is one example of a problem that can be solved by concepts like function pointers, delegates, and observers that we covered earlier in the course.

Refactoring

Now that you have a complete game, it's a good time to revisit your code and look for areas to improve its structure, readability, and maintainability.

If a class or system doesn't make sense or is difficult to follow, that's a good indicator that it could use some refactoring. Here are some examples that might be worth considering:

GameState and GameUI Interaction: Consider separating game logic from UI updates more cleanly. GameState could focus solely on the game's internal state, and GameUI (and its children) could observe changes in GameState.

This can perhaps be through the observer pattern, or implementing logic in the Tick() function that queries the GameState for information that is relevant to what needs to be displayed on the GameUI.

Cell Responsibilities: The Cell class currently handles a lot of different tasks: rendering, animation, collision detection, and even some game logic (like pushing APPLE_EATEN events). You might consider breaking down Cell into smaller, more specialized classes or components. For example, you could have a separate SnakeSegment class to handle the snake-specific logic and animation, and Cell could focus on representing the grid cell itself.

Adding const

To keep our lessons as simple as possible, we restrict the syntax as much as possible to keep the focus on the core concepts. However, there are some more advanced C++ features that you may want to add if you're more comfortable.

One such example is the const keyword, which we covered in more detail here:

The most useful place where we can apply const to our game is when our functions are receiving arguments by reference or pointer. If the function is not going to modify that argument, we should mark it as const. This applies to all of our HandleEvent() functions, for example:

1// ScoreCounter.h
2// ...
3
4class ScoreCounter {
5public:
6  void HandleEvent(const SDL_Event& E) {
7    // ...
8  }
9  // ...
10};

When a class method does not modify any of the class members, it is also useful to mark that method as const. For example:

1// ScoreCounter.h
2// ...
3
4class ScoreCounter {
5  // ...
6private:
7  std::string GetScoreString() const {
8    return std::to_string(CurrentScore) + "/"
9      + std::to_string(MaxScore);
10  }
11  // ...
12};

Adding static and inline

More keywords we should consider deploying are static and inline. We cover these keywords in more detail here in our advanced course:

An example that can be made static and inline in our snake game is the SnakeColor, as this variable has the same value in every Cell instance:

1// ScoreCounter.h
2// ...
3
4class Cell {
5  // ...
6private:
7  inline static SDL_Color SnakeColor;
8  // ...
9};

Friends and private Constructors

Finally, we should consider how our objects can be constructed. Currently, all of our classes have public constructors, meaning they can be created by any other class.

However, this may not align with our designs. For example, Asset objects are intended to only be constructed by GameUI objects, so we may want to make that constraint official.

To do this, we can make the Asset constructor private, and give GameUI access to this constructor by declaring it to be a friend:

1#pragma once
2#include "GameConfig.h"
3#include "Engine/Image.h"
4
5struct Assets {
6  Image Apple{Config::APPLE_IMAGE};
7
8private:
9  friend class GameUI;
10  Assets() = default;
11};

We cover the friend keyword in more detail here:

This lesson focused on implementing a visual improvement: animating the snake's movement across the grid. We replaced the instantaneous cell-to-cell jumps with a smooth sliding effect. This was done with the following components:

• FillPercent (0.0 to 1.0) controls how much of a cell is filled by the snake.
• FillDirection indicates the direction of snake movement within a cell.
• SnakeRect is dynamically resized and repositioned in each frame to create the animation.
• GrowHead() handles the animation of the snake entering a cell.
• ShrinkTail() handles the animation of the snake leaving a cell.