Fox in a Jam: How a game was made in one week with O3DE
Written by André L. Alvares, O3DE community member and Developer of Fox in a Jam
Every year since 2009, the Global Game Jam takes place all over the world, including Brazil, where I live, and in this 2025 edition I participated with the goal of creating a game in O3DE, which I succeeded in doing with the release of “Fox in a Jam“, and now I’m going to share with you how it was made, and which tools of O3DE were used!
What is a Game Jam?
First, let’s talk about how a game jam works:
A game jam is an event about making games in a short period of time, like two days, a week, a month, etc., and it’s not necessarily a competition. The event begins with the announcement of a vague theme that all developers are expected to follow with their own interpretation. Teams are usually formed at the beginning of the event, which is a great way to meet new developers. There are many game jams that are remote, others that are in-person events, and others that are a hybrid of the two, which was the case with my GGJ site. The theme of this edition of the Global Game Jam edition was: Bubble!
About O3DE
I became aware of O3DE when it was announced in 2021, but it wasn’t until 2023 that I began to study it in depth. What makes O3DE interesting is that it is an open source engine with a strong focus on tooling with well-established technologies for 3D games, the use of composition for gameplay implementation, and a scene editor with a familiar workflow, among other things. In summary, it’s an engine with a familiar workflow that I can be productive with, and a game jam it’s the perfect place to try making a complete little game quickly.
The idea
The first step is to define what the game will be. This game jam has a development time of one week, and while this is a generous interval compared to the traditional weekend, it’s still a very short time to make a game. As such, this game (like any game jam game) needs to be strategically simple, so it’s developed quickly, allowing some time to properly rest and add the final polish.
In other words, one of the secrets of a good game is scope control: a complex game may sound cool, but it will take a lot of development time and may end up being rushed to meet the deadline, whereas a simple game can be made with care and improved later, but hopefully not boring to play.
Controlling scope can sometimes be the most difficult challenge in game development, because adding new things is the easiest answer to a problem: how to make an interesting “core gameplay loop” and “game progression”. However, increasing the scope can make development more complex, and can make your game confusing.
As mentioned before, the theme is “bubble”, and there are many interpretations of this theme: economic bubble, social bubble, or just a soap bubble. At first, I thought about making a racing game with a character in a bubble, but that would require AI coding for the opponents, which I wasn’t willing to do, so I gave that up. However, a character on a slippery bubble trying to get through a path full of obstacles could be an interesting game and easy to make, so the concept of Fox is a Jam was born.
“A character balancing on a slippery bubble, dodging thorny obstacles on an inconveniently narrow path.”
The core loop is dodging the obstacles to get far on the level, and the progression is done by making the level harder with more obstacles in the later parts.
Gameplay Prototype
When you create a project in O3DE, you have some assets available that are quite useful for prototyping. With the default shader ball and sphere models, it was already possible to create working code for movement and collision handling with a box. I personally recommend enabling the “Dev Textures” gem, this gem contains some textures that are very useful for the prototyping stage, one of them was used to make the rotation speed of the sphere clearer.
On O3DE you can program your game in C++, Lua or Script Canvas. In my case I used Script Canvas because it has types.
Another basic feature of O3DE are prefabs and they were used on the box (and later on the spikes). This way, changes to the box prefab are propagated to all boxes at once.
The 3D assets and the low poly style
The gameplay was done, so the next step would be to stop using prototype assets and use the game assets instead, and for that I decided to use free assets with permissive licenses for this game: Hooded Fox by Tibo and Prototype Bits by Kay.
I particularly like low poly 3D assets without textures, as they are easy to customize and create new assets if needed, while maintaining style consistency. Placing the scenery assets was easy. Remember that the box was a prefab? When the model was added to the box prefab, all the boxes on the level were updated at once.
Later I placed the walls and floors on the background, hiding the skybox. For the spikes I had to create the model in Blender, but thanks to the low poly style it was easy to create and maintain consistency. Finally I added the fox model, but there’s an extra step for that.
The fox model and animations
The difference between all the other assets and the fox asset is just one: animations that react to gameplay.
Given the gameplay so far, the fox should run or stay idle, so we would need to apply these animations, and fortunately the fox model already has them!
To apply animations to our game, we need to use one of O3DE’s main tools: EMotionFX. EMotionFX Gem allows you to create “Motion Sets” (a set of animations) and an animation state machine called Animation Graph, which manages which animation state should be active. So we can add the “run” and “idle” animations to a motion set, and create the animation graph with them as the “Idle” and “Run” states, linked with two transitions (from Idle to Run and vice versa) controlled by an “IsRunning” parameter.
But there’s a catch: The fox is holding a sword, which like the spikes, is a thorny object.
Why would the character use such a dangerous object for no reason? Since the fox uses a “No Derivative” term, I would have to adjust the game design to fit the sword, first by introducing an attack. Fortunately, the fox asset also has an attack animation, so we add an “Attack” state and an “IsAttacking” parameter, just like Idle and Run, but there’s another interesting detail worth mentioning: The state machine enters the Attack state as soon as IsAttacking becomes true, but it shouldn’t loop, instead it should return to either the Run or Idle state while setting IsAttacking back to false.
This is solved by adding a “Parameter Action” to the transitions that sets IsAttacking to false on transition enter.
Finally, by simply controlling both the IsRunning and IsAttacking parameters in the gameplay code, EMotionFX does all the animation handling for us!
Adding a new unexpected mechanic from a great suggestion
The sword was unexpected and adding an attack animation isn’t enough if there’s no mechanic attached to it, and I didn’t have any good ideas on what to do, just some object that could maybe slow down the movement. It was already Saturday and the in-person event was happening, so I went.
Why? Because that’s the best part of game jams: meeting new people, talking to developers, interacting with other teams by getting help and helping out, sharing experiences, and most importantly, making new friends!
At some point, I was talking to my friend Alyson while he was working on his game’s art, and he suggested an idea that would solve the whole sword problem: cutting grass! Grass with a slowing down effect has been a very common concept in video games for decades, and cutting it with a sword attack makes perfect sense! So the model was modeled and the implementation was done.
To make the character send this “cut” event to the grass, I used another feature of O3DE: Script Events.
Script Events allow us to send events to another entity (including the sending entity itself), this feature was also used on the box to trigger the “hit” animation that happens on collision.
After that, the gameplay was essentially done, with some visual tweaks like the spinning spike and changing the skylight to make the game more colorful.
Adding Audio
The audio was still missing, but fortunately, I met two audio specialists: Rubens Stephan and DanFloyd. Rubens Stephan did the music, while DanFloyd worked on the sound effects, including pitch variation. O3DE has a complex audio system that includes Wwise support, but also a simpler alternative called MiniAudio Gem based on the MiniAudio library. The MiniAudio system was used because it allowed me to quickly add the in-game audio created by my teammates.
After that, the game had music and sound effects!
The final step
The last step was to add an ending to the game, which is getting the coin, using the concepts presented so far (I even reused the spike script just to make the coin spin). With that, the game was finished! If you want to study the final implementation, including some post-jam work, you can check out the source code.
Conclusion
Making this game with O3DE was an incredible learning experience, especially with the audio and animation as it was my first time doing it in the engine.
I’m not used to 3D games to be honest, and I was afraid I wouldn’t be able to finish it in time, but although I had some problems along the way, everything worked out and the project was successfully delivered in the end! Like any software, O3DE can always be improved, but since it’s open source, it’s also possible to directly contribute to the development of the engine and engage with the community! Watch the video:
I’m looking forward to the next projects of the community, thank you for your time and have a nice day!
Open 3D Engine resources:
- Connect with us on LinkedIn
- Subscribe to our new quarterly newsletter
- Follow us on WeChat
- Watch our videos on YouTube
