So same as @Insality here I’m writing a post-mortem style blog post about my journey this time with the next game jam.
It wasn’t my first jam, I participated now in many of them, even in the GamedevJS Jam with L45ER B0T, so my itch page is full of those short games: https://paweljarosz.itch.io/
The Idea
I thought I’m well prepared, I even wrote some tips for other participants. But there’s always surprise and this time it was the theme… Usually, there is at least some first spark - a mechanic, a visual, an idea around which I’d like to build up, anything. This time the theme was Machines, and for quite a while I just staring at it and couldn’t come up with a nice, fitting idea. It is one of those themes that can go in a hundred directions, which is both good and terrible.
I knew I wanted to make something in 3D in Defold. That part I was sure about. In the previous Tiny World challenge I built a small town scene with lights, shadows, skybox and a curved world shader, and I really liked the atmosphere of that kind of presentation. So I started with this and some remnants of that approach are actually still in this repo, if someone looks around carefully.
I started searching for 3D assets, maybe from visuals I could come up with something. And that was a good idea. I searched through Kay’s assets and looking at the space bits I thought - maybe a space base building? In the end - it’s all about machines. I quickly come up with an idea of just building the base, but then also thought of what buildings serve what purpose and trying to keep it as minimal as possible, I assigned 1 “resource” to 1 “building” first and come up with an idea of building and maintaining a space base.
That’s all! Everything from this point was just downhill racing and iterating over this idea. I’ll add day/night, so that solar panels won’t work at night, so I need to add something to compensate - so I added wind turbines, but I didn’t want the wind to blow all night, so I made it random and this started breaking my power resource management, so I needed further balancing and so the play started 
But that’s for a later part of the story, for now let’s get back to visual for one last moment:
The visuals
At first I thought I would continue in the same art direction as my Tiny World challenge entry and make another “small world” kind of game, maybe something compact, curved, toy-like. But after some tinkering I gave up on that. The more I tested it, the more I felt that in this case a flat area worked better, because I wanted the planet to feel huge, uncharted, a little bit scary, and base small, helpless. The whole point of the game slowly shifted toward maintaining a remote base on a hostile planet, and once I flattened the terrain, it suddenly started to feel like the place extended far beyond what the player could see. The base looked smaller, more lonely, more exposed. Instead of feeling like a diorama, it felt like a tiny patch of survival on a huge empty world. That was much better for the kind of game this was becoming.
I also spent some time experimenting with skyboxes. There are remnants of that in the repo too. I tried different backgrounds, different moods, different ways to make the planet feel bigger and more interesting. But I was never really happy with the result. I could not quite match the textures to the models, and I also did not have a satisfying idea for transitioning between day and night. I did not want some awkward sudden lighting swap, and I did not want to spend half the jam trying to solve just the sky.
P.S. I created an issue for easier cubemap setup: Highlight a selected texture when editing a cubemap · Issue #12248 · defold/defold · GitHub
So I simplified it. I dropped the skyboxes and ended up with fog and a clear sky. In the end I actually think that was the right call. It made the world feel more intimate, easier to read, and somehow more alien at the same time. I also pushed the color palette toward a Mars-like feeling, but I never mentioned anywhere it’s Mars - just a planet, as it doesn’t matter for the gameplay. It also let me spend much more time where I actually needed it most: coding and balancing…
Because this game turned out to be mostly about systems.
The systems
Once I stopped thinking in terms of visuals and started thinking in terms of systems, the game clicked, but also started to be more complex than I though, even though, through this whole time I tried to keep it as simple as possible.
I made a whole base that is really just a network of machines pretending to be a society. That became the foundation of the game:
- machines/buildings produced resources,
- other buildings and crew members “consume” them,
- the crew depends on all of the base - they need oxygen, food, and waste recycling
- the crew, in return, produces intelligence and can gather minerals - all that you can exchange for credits to build new buildings, so the loop is closed
- everything slowly breaks (this was added a little bit later), so you have to also spend credits on fixes
- and the player’s job is to keep the whole thing from collapsing.
That sounded simple enough at first. It never was 
I started by designing the core resource flow and the relations between systems. Which building produces what, which one consumes what, what depends on what, where the bottlenecks are, how failure should spread. I tried to map everything out almost like a little economy graph. If I remember correctly, a lot of that early thinking that happened with pencil sketches full of arrows going in every direction, trying to make the loop interesting but not impossible, ended up being a little bit unmatched to reality, but it wasn’t so bad, so I’m happy I’m maybe getting better at the difficult art of game design
That was probably the most important part of the whole project, because once the visuals are stripped away, this game is really just a set of equations and dependencies.
The Code
Writing first prototype was very easy, because everything seemed simple and small enough to code it in a short time. Once the systems started working, I started playing and balancing, fine tuning the numbers each play, starting again. The first step were meant to be easy for players. So I added tutorial tasks to guide players, in which order to build what buildings, where to spend money first. There were changes to this, even after I published it
I also started adding a (not so) smart system for dynamic balance - the events. More of them being positive appear, when stats are bad, and more negative, when stats are good to keep the game going and challenging. I wanted it to be challenging so I didn’t nerf the stats much, I tried to keep it a little bit difficult even for me, so that only good strategist can plan a good, well-working base. In a retrospective, I think I need to balance the further gameplay more, as it becomes really difficult in the later stages, because all buildings start to fell apart almost in the same or similar time and repairs, even though not so costly, become pain in the 
.
A lot of the early implementation was built around very simple math and structured Lua modules. I used DefMath for almost all math operations, which was very convenient and honestly made the code nicer to work with. Huge credit to @Pkeod for that, and also for DefString, which I used too.
And a huge credit goes also to @Insality - I used Druid UI Framework, Defold Event and Defold Saver. I also planned to use Token and Quest, but I need to become more familiar with those still. Once I added saver and started to save my progress on the game it started to feel like a real game. It was really important here to design the data in such a way that saves are not an obstacle during the development. I didn’t have any problems with re-opening the game on the same local save even though the code changed. I could re-open the project and continue playing.
The balance
There is always this funny moment in management games where you stop “building the game” and start “arguing with the game”. It starts resisting you. You increase one value and it reacts somewhere else. You try to help the player and accidentally remove all tension. You make things harder and suddenly no one survives past day three
That happened here constantly. And because I wanted to spend more time on coding and systems than on fighting presentation problems, I am glad I simplified the visuals when I did. This is for a later part, when I will really add a falling meteor! 
The architecture
Even though it is a jam project, it is not a complete mess. Maybe a little bit There is though still a visible structure in the source. The game is built around a simulation layer that manages resources, building state, crew, and economy progression and general rules. On top of that sits the visual (view) layer that manages buildings, handles interactions, updates the UI and lets the player place and manage modules.
So if someone wants to browse the source, I would roughly describe it like this:
Core simulation
This is the heart of the game. Resource flow, buildings, production, consumption, repairs, price changes, condition and progression live here. If you want to understand why the game behaves the way it does, this is the most important part. Most of the code sits in sim.lua. The catalog.lua is on the other hand the “data” part describing most of the stats and constants I was balancing.
Building logic
Each building type exists because it plays a role in the network. This is actually where the “Machines” theme became real for me - not one machine, but a whole ecosystem of semi-dependent machines that constantly threaten to fail in interesting ways.
UI/gameplay layer
Selection, buttons, displays, warnings, interactions, feedback. This part grew a lot during the jam, but was pretty easy to maintain thanks to powerful Druid framework 
Most of the code sits in presentation folder, but there are also useful grid.lua and pick.lua modules for grid and building placement related code.
Assets and experiments
And, of course, there are leftovers and the mess. Old experiments, attempts, and remnants, things I tried and abandoned. Some are left, because I wasn’t sure what can I safely remove. I actually like that those things are still there. They tell part of the story too!
The lessons
Few of them are mentioned above - like trying to keep things as simple as possible and re-use your previous experience + mix it up with some new challenges and disovering.
Design simple data first. You don’t need dozens of stats, reduce it to the minimum, especially for strategy/base building games. I spent my childhood playing Europa Universalis, Industry Giant or Footbal Manager, so I’m somehow a spreadsheet masochist. Even my dream game - Witchcrafter is now an RPG with dozens of statistics, even for NPCs, becoming more like an immersive sim. I’m a fan of data oriented design, and though this game jam is not a proof of that, as it was done in just less than 2 weeks and is a mess tbh, I try to define data first and make it as reasonable and flexible as possible. I start thinking with data, then the implementation - because implementation can really be brought to simple math equations - what matter are those variables only and their menaning.
Don’t spend more than 10-20% of the jam time on designing. Cut it off after this time. If it’s taking longer, you’re not going to make it a reality. I barely fit it in, but it’s mostly because I did some jams before and was using familar tools and libraries.
The hard part, in my case, was all the behavior around the relations and balancing. It is not enough to know that a farm consumes power and produces food. You also have to decide:
- what happens when it only has half or less of the required power,
- how the UI explains that,
- how its state interacts with damage/condition,
- how it influences the crew (should not be abrupt, but gradual),
- whether and how the player can recover from it,
- and whether all this still feels fair after long time.
That is the part I underestimated. I thought I was implementing a resource graph, but I was actually implementing many layers of exceptions around the resource graph
And that is a useful lesson, because I think this happens a lot in simulation and management games. The first system diagram can make the game look almost solved. But the actual game lives in the transitions, the failure states, the priorities, the unclear situations, and the ways players misunderstand what is happening.
I still think starting from clear equations was the right move. I would not abandon that approach. But in hindsight, I would structure it differently to avoid the growing pile of weird ifs.
The wins
The biggest win is simple: I finished it! 
I think this project taught me something useful about simulation game development. It turned out pretty nice. I like playing this game, it can be played on mobile, so I also played it outside a lot. It starts to get good feedback, so maybe it will motivate me to continue on this!
I also wrote a guide on deploying a Defold game to Wavedash, because that turned out to be a nice extra outcome of the jam. Once the setup is done, the pipeline is actually pretty pleasant, and it was fun to document that for others too! 
Defold itself was great for this kind of work. It let me move fast, prototype systems in Lua, assemble the project from libraries and assets, and still keep enough control to finish! 
(I know I’m biased here, because I’m part of the Defold team now, but some of you that know me, know that I wasn’t always part of Defold team, and was still using it and promoting it for years now with much joy!)
Thank you for reaching the end of this long post, hope you find something useful for you here and had some fun! See you at the next jam - maybe - our Defold jam! 