Why did I make this?

This small game was made in ~2 days for the Scientific Game Jam 26.

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 one had an interesting plot: there was no theme, but three PhD students presenting their work, which should inspire our games.
I want to create games with a real world feeling, anchored in everyday life, so creating from science was enticing!

First evening

The PhD students presented three very distinct theses :

• Archaeology: using top-down views of landscapes and 3d modelling to spot faint traces of Neolithic homes.
• Fluid mechanics: how the gigantic valleys of Mars were created.
• Ecology: why a deadly rapeseed parasite was found in some fields but not in others.

After hearing them, I knew I wouldn’t choose the second one, because fluid mechanics means very complex maths for my programmer’s mind.
On the contrary, I quickly got detective game ideas for the others two.

In particular, I envisioned a concept where the player uses a set of measuring tools in various fields and should connect the dots to understand the conditions that led to the rapeseed parasite infection.
The main design goal was to reproduce the researcher work: theorize, conduct experiments, and draw conclusions.

Orobanche Ramosa, the sneaky rapeseed parasite

This was an in-person jam, and the only guy I knew was already part of a big team, so the first step was teammate shopping by pitching and discussing my ideas.
At the end, we were a small group of no-team people endlessly talking about gameplay aspects, whereas we should have at-first decided with who we would be making these games.
Finally, I found another Godot (my game engine of choice) developer Ginahe and Willy, a professional 3D artist.

I wasn’t planning to have 3D graphics, because I wrongly thought 3D games were overly complex for game jams. However, as you can see, it went well on that side.

We brainstormed on my rapeseed detective concept and came up with more experimental ideas, where you change the physical properties of the fields to find clues.
Willy had the idea of a minesweeper with a moving mine.
We plugged the previous idea in it and were left with a turn-based strategy game where you have to understand how the parasite moves to kill it, by using tools to modify the physical properties of any square of the field.

We decided on three properties: soil, sunshine, and humidity.

I called it a night after that, exhausted but happy to have found a simple yet strong basis that could be easily expanded by experimenting with the player’s tools.

Second day

We started the day by deciding on a minimal scope for the prototype and created the todo list to make it.
While my teammates were writing the first lines of code and sculpting the first polygons, I took some time to test the gameplay on a whiteboard.

Testing the gameplay on whiteboard

Although this was a very basic walkthrough of the game loop, it allowed us to spot problems in the game mechanics and correct course before building anything in the engine.

Our goal was to have something playable at 5pm.

To make it in time, we scraped two tools (planting trees to create shade and adding fertilizer to change soil state) and balanced the odds of the parasite cornering itself by keeping only one random property (soil state) for each square.
However, we encountered difficulties with Ginahe to code the main systems and weren’t able to go further until they were done (to avoid code conflicts), so it took 3 more hours.

Unlike us, the art part was a breeze for Willy who made all the assets very quickly, even if he was discovering the game engine.
Therefore, we put an already good-looking prototype (which is usually a sign that it came too late) in the hands of playtesters, who praised the graphics but were a bit lost to understand how to win without our help.

We pushed a lot of quick wins and uploaded a first build on Itch.io.

When playing the game on the site, we immediately found it way darker than in the game engine, switching from a cozy to a gloomy vibe.

Despite that, I went to bed relieved.

Last day

The last sprint was a short one: deadline was at 2pm, and we still had a lot of polish to do.

Willy tackled the sound: finding a nature ambient background track and sounds effects for each action in the game.
He also made keyart and the Itch.io page content.

I integrated the menus, sound and quickly fixed a lot of bugs thanks to an overall good code architecture.

Willy and Ginahe tried hard to fix the darker assets bug when playing in the browser. Sadly, the only way they found was to redo the assets with a different way of coding colors.

The music settings menu was a last-minute speedrun. I realized at that time that I was remaking the same things (title screen, sound players, settings…) I already made (or should have) for my previous jams.
I should start the future ones with premade bricks to go faster in the last crucial hours.

And we were done, on time!

The final game

I was really happy of our achievement, considering at which point we were 24h ago. However, I felt a bit half in earnest on the design part: the detective aspect I wanted was only hurting the comprehension of the rules and the magnifying glass item lost its purpose.

Exhibition

All the games were displayed to the public on large screens. This was very rewarding for us, but also the opportunity to see a diverse audience playing the game.
Unsurprisingly, children had difficulties with our approach of giving no clear rules, and quickly lost interest.

I also noted that I had to tell people to look at their score to make them realize it existed. I was able to play the others teams’ entries, and all turned out fun and interesting.

Key takeaways

• A 3D game is not overly complicated if you have a 3D artist in the team and no character movement
• Having a second programmer allowed me practising Game Design a lot more
• Testing the gameplay on whiteboard is very helpful, even for a jam
• The core mechanics work should be split between programmers to avoid blocking progress, even if there’s an higher chance of conflicts
• Starting from a template with basic things (e.g.: title screen) might save time for polishing the game’s core

After the jam

For the first time, I felt compelled to go back to the code and do some improvements.
I updated all the UI to use the same style and emphasized the score during gameplay and at game over, to make clear that saving the most rapeseed was the goal.

I also extracted some code to make a template that will serve for future jams, available here.

I might come back to try adding the tools and properties we were not able to fit.