Why did I make this?
This small game was made in ~7 days for The Very Serious Juniper Dev Game Jam.
The theme was spin to win.
A jam is a friendly competition between game developers who are tasked with creating a complete game, based on a set theme, and in a very short period of time.
This was the first game jam of youtuber Juniper Dev and its schedule allowed me to build a monthly game jam streak, following Colza Attack and preceding CriTickal Heat (an appropriate name after the hottest heatwave I ever went through…).
I’m starting to feel that this website is becoming a game jam devlogs’ library…and it’s completely okay because that’s my current obsession!
Before the jam
I assembled an A-team with two previous jammers: Willy (3D artist) and Itooh (fellow Godot dev and musician).
This was going to be a rough one, because during the week I would be able to work mostly on evenings, and Willy announced a few days before starting that it won’t be available at all.
Oh, and the thermometer would go haywire, wasn’t ready for this.
First evening
The jam began at 4pm on a Friday.
We started brainstorming 2h later, on the online whiteboard Excalidraw.
I found so many meanings for the word spin, and made a nice mindmap, but there still were no game ideas…
By switching to Jonas Tyroller’s technique, I had the absurd idea of a game where you make chaos in an office with a spinning fan.
The brainstorming mindmap (pardon my French)
We synced with Itooh. who had the idea of creating orbits.
Finally, we agreed on an incremental game where you accumulate more and more things in orbit around your character, but it’s also a skill-based game: if you stop moving (like a planet around the Sun), the objects crash on you and you lose health.
The progression was simple: in pure Katamari Damacy style, acquiring bigger objects will attract even bigger ones.
Itooh wanted to focus on finding assets and sound design, so I had to tackle the core mechanic of making things spin around the character in 3D.
This time, I won’t be able to lean on his great developer skills and this would be my first encounter with Godot 3D physics engine.
Choosing 2D would have been easier, but we knew the game would be better in 3D and that’s kind of a necessary step towards becoming a professional game developer, especially if I want to make 3D games.
Regardless, the game would be easy to make after tackling this challenge, as a good game jam concept must be.
Before going to bed, after a lot of trial and error and documentation reading, I was able to attract an object towards my player. Woo-hoo!
Second day
The plan was to take advantage of the weekend full days of work to make the core physics mechanic of the game.
I started this day a bit late because I went to the country in an attempt to flee the hellish forecasted temperatures.
My old physics classes reminded me that the Moon is orbiting Earth because of two perpendicular forces:
- an attraction force towards Earth (gravity)
- a forward force towards the black emptiness of space (fleeing the crazy monkeys who are shooting inhabited shells at them)
Unfortunately for the Moon (but luckily for us), the former is more powerful than the latter, so it is trapped inside Earth’s orbit.
Well, I’m not a physicist, but this quickly worked. Although I had to tinker with it a lot to create the crashing behaviour I wanted: the character’s attraction force is so strong that without movement, the orbiting object crashes on it.
I added a way to move in a basic 3D scene (Itooh created some ready-to-use objects from assets packs) and a level-per-object system to prevent breaking everything from the start.
The chaotic prototype
It was funny to wreak havoc, but I couldn’t see how the prototype was fitting with design intentions: everything was so chaotic!
I probably needed to better balance the level of objects and prevent them from bumping into each other.
Third day
That day was hard.
I tested a lot of things to balance the objects’ masses.
And I found out that my clunky dark magic physics system wasn’t suited for the basics of our idea: the player was supposed to prevent the spinning objects from touching them.
I was lost with the direction of the game.
There was a silver lining though: after seeing our exchanges with Itooh, it encouraged Willy to join us. He started thinking about art direction right away.
After a compulsory nap, I accepted the collectathon path proposed by Itooh: we will make a game like Donut County, in which you have to collect every object to continue to the next level; you move the mouse in a fixed zone and the camera zooms out when you enter the bigger objects’ league.
Itooh worked on a dynamic music, as usual.
I went out to relax. The sand on the beach was burning; I could enter the usually chilly water right away.
After thinking about the different levels (which were going to be scales here), I called it a day, relieved that we found a new clear direction.
Fourth evening
The week started, and after more dark magic (and some help from AI), I was able to track the mouse cursor position in a fixed 3D scene.
It started to be better, more user-friendly.
At that time, to make it fun, we had two branching paths:
- finding obstacles/puzzles to hinder progression
- or making a varied and smooth experience with a lot of assets.
We chose the latter, and Itooh had the idea to slow the gameplay by making the objects vibrate before picking them up in the chaotic tornado.
Finally, we discussed some lore and decided to go with a minimalist narrative exploring the classic metaphor of capitalism.
Fifth to Seventh evening
I worked a lot, despite outside temperatures reaching 43 °C (where I live, this is crazy).
Having a fan aimed at my legs wasn’t effective anymore.
Some improvements made the game less chaotic and more enjoyable, like freezing the objects not yet picked up, which prevented the tornado to throw everything on the floor.
In my cooked head, I thought we had to finish on the seventh day and started to panic in front of all the work left (which included all level design).
I integrated Itooh’s work: dynamic music, minimalist narrative UI and SFX.
That gave a lot of charm to the experience.
Willy modelled an entire open-space scene with a nice and colourful style.
I took a long time to tune each object level (which set the moment the player was able to pick it up), it was laborious but necessary.
On the sixth evening, Itooh made me realized that we had one more day left than I thought we had. And that would be a full day on the project for me.
From that moment, I knew we will have something good in the end. It was still 30 °C outside, at midnight.
Last day
I started by creating the page on itch.io (the same where you can play the game!) and pushing the first build.
Then I did tedious balancing and level design tasks, to propose the best experience.
With more than 300 flying objects at the same time in the fullscreen game, my laptop started to lag.
But we didn’t have enough time to optimize properly (and I never did that before).
Willy sprinted through two extra rooms for the last level, with a lot of specific props.
Then, for the final boss of this project, we had to tackle an annoying bug preventing some objects from being picked up.
Willy proposed to refactor the way we picked objects, because our pickup zone around the player was a vertical cylinder and it wasn’t catching the props along the walls.
His solution was using more dark magic for me: raycasts. Unfortunately, he knew how it worked in Unreal Engine, but not in Godot.
He tried his best to explain the logic for an hour long, but my boiled two left neurons weren’t able to understand.
I tried a lot of things, but it didn’t work.
Exhausted, I decided to circumvent this problem by lowering the floor number of props the player needed to collect, preventing them from being blocked if they didn’t get those uncooperative objects.
I pushed the last build at 1pm, a bit defeated…
But I’m stupid. So I tried an ultimate thing, actually proposed earlier by Itooh (rotating the pickup zone proportionally to the mouse coordinates, rather than using complex 3D dark magic). And…it worked!
Only two lines of code fixed the issue.
After more bug fixing and very basic optimization, we pushed the last build at 2pm.
My brain was fried.
And this one-week-long marathon was finished!
The final game
I was very happy with the result and thought we would get good ratings.
The experience was funny and smooth.
I was able to train my balancing and level design skills.
But it felt more like a toy than a game, there wasn’t a lot of challenge.
And one-week non-stop was too long, especially during France’s hottest week in recorded history.
Ratings
There were 3,511 entries.
I played 14 of them.
Overall, I played good and just okay games. The jam had a seriousness category, which I wasn’t sure how to rate when the game was not a parody.
For our game, even if Juniper played and liked it, we only got 18 ratings.
It was maybe because of its absurd long name and simple cover image.
Overall, we ranked #225 (which is great!) and notably:
- #86 in Visuals
- and #207 in Audio!
Which were the doings of my amazing teammates.
Top games were great, but often in a single category.
Key takeaways
- Working a day job while doing a week-long (including the weekend) jam is exhausting.
- Changing camera perspective can transform a chaotic experience into a crisper one.
- Even if it takes some time, simple optimisation can fix an unplayable physics-heavy web game.
After the jam
During the voting period, Willy carried out an optimisation pass on every 3D model.
I also think that trying to optimise the physics in this game will be a great exercise for me.
Now I need to find the time to do so!