At Blender Studio, we’re currently in the midst of producing our second interactive project — a video game with the working title Dog Walk. Many years ago, when Blender had a built-in game engine, the first video game made with Blender was Yo Frankie!. Since then, the studio has focused mostly on creating animated short films, leaving the interactive element out of the equation.

Over the years, many films with different techniques, approaches, and challenges have been produced. However, Blender is not used solely for movie animation. The game industry has adopted Blender in its workflows, and it is now heavily used by major game studios worldwide. Because Blender is so popular for creating game assets and plays a significant role in development pipelines, Julien Kaspar pitched the interactive project Dog Walk — an indie “feel-good” game where players are invited into a snowy park. In this world, the dog Chocomel and their buddy Pinda traverse the environment, searching for items to decorate a snowman. The two characters are directly and indirectly controlled by the player, each requiring their own set of animation loops. While Blender was used for most of the production, the open-source game engine Godot was chosen to build the game. But how did we approach the process of creating these animations for a game like this? And what challenges did we encounter along the way?

Enjoy the read!

Gameplay vs. Movie Animation

One of the most fundamental differences between game animation and movie animation is interactivity. In video games like DogWalk, animations must respond to player input in real time, adapting to actions such as running, jumping, or interacting with the environment. This makes game animation dynamic and unpredictable, as players can trigger animations in any order or at any time. Proper planning and “game logic” are essential to ensure these animations blend smoothly together. This doesn't mean it sacrifices storytelling. Both gameplay and cinematics can evoke great storytelling and can be neatly combined to create believable worlds and emotional stories. For game animation, the animator has to cooperate with game developers in order to deliver their animations successfully. For movies, animators often work on their own 'islands' even though they do need to communicate with other departments, their main workflow can happen more individually.

In contrast, animation for movies like Sprite Fright, Charge!, or Wing It! is more linear and non-interactive. Animators design performances with a specific narrative flow, which is predetermined in the storyboard and layout fase. Since the viewer has no control. Timing and choreography are intentionally planned to evoke emotion and create a believable, entertaining performance. This is also the case for game animation, but the process here is more complex due to the interactivity aspect. Animators need to be more aware of the transitions to cinematics and where gameplay animation needs to read from all angles. With movies, the camera is usually locked, which allows the animator to 'cheat' towards camera. Now for Dogwalk, we were allowed to cheat when animations were only oriented towards camera.

Animation Loops, Actions, and Cinematics

In video games, repetitive actions such as walking, running, or idling are created as looping animation cycles. These cycles can blend seamlessly when transitioning from one action to another, maintaining a natural and fluid appearance regardless of player input.

For Dog Walk, the animation style aims to evoke a “stop-motion” feel by animating the characters on 2s, 3s, or even 4s. This means that instead of moving every frame, the characters hold their poses for a few frames before transitioning to the next pose. This aesthetic allows us to 'snap' into different states and not worry about the blending too much. It makes the process more economical and easier to implement.

A crucial element to establish was the animation tree for both characters. Since they need to interact with each other, we had to develop clear “game logic.” Pinda (the kid) can experience different moods in the game, influencing how the player interacts with them — whether they continues to play along or simply sit down and start crying. One action leads to a reaction, and all of these interactions needed to be carefully mapped out to understand how the game functions overall and which animations are required for each character to create a believable dynamic.

Game Logic

Visualizing the game logic has served as a solid foundation for starting conversations, ensuring that everyone is aligned on the characters’ logic and expected behavior. While the game logic may still be adjusted based on playtesting, feedback, or bug fixes, it provides enough direction to begin creating the game’s core animations.

To differentiate the multiple states of animations, we categorized them in designated groups:

- Core gameplay loops (LOOP): These are the basic animations that are required to play the core gameplay. This includes, walking, running, idling and variations of these states. They are always loopable, which means they can play seamlessly and indefinitely.

- Actions (ACTN): These are animations that are triggered by the player at a specific time or place. Actions only play once at the time. For example picking up an item or falling in the snow.

- Cinematics (CINE): This category has been called for creating narrative driven animations for the intro and outro, as well as some moments during the game where the player is progressing the story by completing certain tasks. The player is allowed minimal interactions during cinematics so that it’s clear how the story progresses during the game. The main distinction here is that animations play out towards camera, to make sure they read well due to their importance for the story.

- Synchronized animations (SYNC): Some animations require both characters to be ‘in sync’ with each other. Both characters contain their own actions, but when the characters are hugging for example, they both need to play their own part of animation. It is important that these start at the exact same time to avoid time offset, causing in unwanted behavior.

These different categories are used as prefixes for the name of the actions that can be called and differentiated by the game engine’s code.

Cyclic vs. Linear Workflow

In movies, animations follow a linear timeline where the beats are already established in the storyboarding fase. Characters do not need to loop actions indefinitely, and transitions are carefully timed to fit the shot. This gives animators the freedom to fine-tune individual moments. Once a shot is approved, they can move on to the next one, making this a rather linear workflow. Where there's still feedback and retakes on certain shots before they get approved, the main beats are determined already in the storyboard or previs.

In contrast, the animation workflow for DogWalk follows a more cyclic process. When animators are assigned to create specific animations, they typically start with a rough blocking of the requested action. These blockings capture the main beats of motion and indicate the timing of the animation. Once completed, the animation is exported as a .gltf file and imported into the Godot game engine. Our pipeline have been set up by Simon so that files are exported so that Godot can automatically import and update the animation files for the game.

For the animator, this particular animation is then put “on hold” until its implementation in the game engine is successful and approved by the director. At this stage, feedback is still possible, allowing the animation to be polished while ensuring it works correctly in the game. This iterative workflow enables both the animator and the game developer to quickly adjust and implement animations, making the process more efficient for testing within the game.

Using Blender’s NLA (Non-Linear Animation Editor)

Animators are not entirely dependent on game developers when it comes to testing their animations. While modular animation cycles can be combined in Godot, Blender’s own Non-Linear Animation (NLA) editor also provides a powerful tool for previewing and blending animations.

The NLA allows animators to import different animations into a single Blender file and use NLA strips to blend between various states, with several parameters to adjust. This proved particularily useful in the early stages when the implementation pipeline for Godot and the import/export process had not yet been fully established. However, this didn't fully translate successfully to Godot initially. Bones where scaling incorrectly and the rigs had to be adjusted in Blender in order to export properly into Godot. This was an iterative process where issues were found out later on during playtesting.

Using the NLA as a preview tool was both efficient and easy to use. It enabled us to identify and resolve potential issues before starting the export process and involving other team members down the pipeline.

Technical Challenges

Since Dog Walk is our first game project using Godot and Blender together, we encountered several animation-related challenges early on. Exporting to the .gltf file format came with its own set of hurdles, but with Simon’s work in setting up the pipeline and collaboration with the Godot developers, we we've managed to improve and add some import/export features, while some issues still remain to be solved in the future.

Combining keyframed and procedural animation required the addition of extra bones to accommodate both techniques. For example, when the player uses the “bark” input, it should trigger the bark action. However, to ensure this worked seamlessly across all states of the dog (sitting, walking, running, etc.), we developed a system where separate bones were used to respect the unique poses of each state. This prevented the dog from snapping into a neutral pose when barking, instead overriding only the necessary bones to execute the bark animation. This solution was somewhat exceptional, as most animation loops could be achieved by blending the same bones across all states.

Another key challenge was ensuring a seamless transition between cinematics and interactive gameplay. How do we ensure that when a cinematic ends, the character becomes playable in the exact same spot and orientation? To address this, we created a list of positional bones located around the snowman, which dictate the start and end points of each cinematic for each character. For example, Pinda (the kid) always starts and ends in the same position, maintaining continuity between cinematic sequences and gameplay. The order of actions is as follows:

1. The player enters the area where a cinematic is triggered.

2. Pinda walks (in-game) toward the target position where the cinematic animation begins.

3. Once the cinematic ends, Pinda’s final position is handed back to the game, continuing the core gameplay loop.

In Dog Walk, finalizing animations is an iterative process that involves constant feedback, gameplay testing, and polishing. Animators work closely with Julien Kaspar (Director) and Simon Thommes (Pipeline TD), who are responsible for the technical implementation and ensuring that animations are both functional and visually cohesive in the game engine.

Conclusion

Creating animations for Dog Walk has been an exciting journey where we’ve learned a lot along the way. Our experience in filmmaking allowed us to bring something new to the table while also getting familiar with the workflow of game development.

When it comes to game animation, we feel like we’ve only just dipped our toes into this vast world. Even with a relatively simple game, Dog Walk presented plenty of challenges and puzzles to solve. Looking back, we see opportunities to optimize and improve parts of the workflow, making it more flexible and efficient in the future.

This project has been a great experiment so far, and we’re excited for you to play the final game soon! Stay tuned for more updates, news, and production logs at studio.blender.org/project-dogwalk/.