Mercedes
GoedWare Game Jam #14 (+ prizes 🏆) Devlog
Hello and welcome to my devlog. I will be sharing how Mercedes was created over the past 10 days for GoedWare Game Jam #14 (+ prizes 🏆). I will walk you through my process, the challenges I met and the choices I made while crafting Mercedes. I am also going to share some of my practices I have developed and grown used to and some tricks here and there.
My engine of choice is Unity so all examples will be based on that - many of the ideas here apply across game engines however so whether you're working in Godot, Unreal or something else, there may be something in for you too.
From feedback for previous games of mine I have taken away that possible aspects to improve on are simplicity for the player and liveliness. So those are the things I want to put special emphasis on in this jam.
Day 1
The theme has been announced - EVERYTHING IS A RESOURCE.
As expected, my head is completely blank. What should I create?
I begin by summarizing what the game should be. It should feel simple, it should feel alive and it should match the theme. I spend literal hours lying in bed, staring at the ceiling, hardly even blinking, while all sorts of thoughts run through my head. Now, the head is far from blank, but I still cannot find anything that satisfies me.
I decide to take a break and buy some groceries.
Strangely, some ideas start flowing in the moment I leave the house and change the scenery. Coincidentally, I remember most motivational gurus suggest taking a simple walk or something to fuel your creativity - it is said that Steve Jobs amongst others used to do this to generate ideas.
Regardless, I am not Steve Jobs and my ideas still aren't great or at the very least not refined yet - I have two interesting starting points now though that popped up during shopping - Alchemy and recycling. With the former, alchemy - at least the way I know it - you can convert everything into everything. This would make a great interpretation of the theme.
After a bit more thought I decide to not go for "classical" alchemy transmutation but rather go for a magic based story, where conversion magically happens within a single unit - a cauldron. In contrary to alchemy, this will provide more room for explaining supernatural aspects of the game and more freedom in designing and selecting visual and sound effects later. Fittingly, the main character will be a witch. There also needs to be some means of acquiring resources. This will be done by fairies, because fairies are cute and everybody loves them.
For the genre, I decide to go for an idle/incremental type game as it is very easy to keep things simple - one of my objectives - for the player. This comes at a great cost however - which is liveliness, my other objective. I decide to challenge myself to make the game feel lively regardless as I think it would be fun.
The idea is born! Time to cast this idea into a game.
Day 2
Time to bootstrap the project. Yesterday I have decided that I want to go with a witch that cooks resources in a cauldron. All of this has to happen in some sort of lab.
Often enough, the most overwhelming part of a new project can be the start. There are millions of ideas in your head, and you want to implement them all at once. The same was and is true for me, and right now I have an idea but no prioritization or sequence on any of the visuals, mechanics and features I would like to build. I have a full working game in my head, but I have no idea if I can achieve it or not.
This is where I recommend the Onion Model. It is very simple. You draw a circle on a sheet of paper, then draw another one around it, then another one and so on until you have got some layers. I usually draw like 4 layers only, but you can draw more. Then, start from the core layer and write down the one mechanic, that characterizes your game. Then, on the next layer, with the next most important features.
This is what it looks like for my game:
The first thing I want to start with is the core mechanic - the Collect&Cook mechanic. For this, I need
- An environment for the fairy to move around
- A resource
- A fairy that can move and collect resources
- A destination for the fairy to collect resources and an origin for it to return to to deliver resources
- To add some immersion, I also want the fairy to be visible at (almost) all times
- For this, I am going to add a window of some sort for the player to be able to view the fairy whenever they desire
I tend to start with the most complex mechanics as these have to be rock solid and potentially may take me a littile while. I can then gauge with more precision how much time I am going to require to finish the other parts of the project. I am likely not going to touch the core mechanics again once they are done. Or rather, I have to do my best to avoid this because everything is going to be built on top of it - changing these things later during the project can lead to many regressions. Sure, these can be avoided, but it is always time consuming - and time is very sparse in this time boxed event.
I start by sketching a very, very simple environment for my whole game to operate in. It looks like this now:
This does not look like much, but there is already more to it than what meets the eye.
The landscape image is set up as a projection from another coordinate in the world space - this is going to be a designated outdoor area with special scaling, movement speeds and possibly lighting and more if time allows, for the fairies to move and operate in. In reality, it looks like this:
As you can see, the main view - the one you see in the prior screenshot - is on the bottom right while its reflection is on the top left, outside of the player's viewport.
You can add a projection like this in the main view by placing a RenderTexture inside of the window frame and having a secondary camera's output point to that render texture. The secondary camera points to the outdoor view. In motion, it looks like this:
You can achieve an effect like I did, but you can also do things like a mirror, a surveillance camera or more if you ever need something like this for a different game.
Now that this is done, it's time for the next step. I decide to work on a fairy prototype along with its movement now, as I need to smoothly handle the teleportation between the indoor and outdoor areas. For this, I draft a very simple fairy sprite which takes me like 1 minute:
So pretty!Next, I need to make this fairy move to various locations that I am going to have. There will be
- a grass area
- a door that leads outside
- a stash to store resources in
- an (invisible) door from outside to inside
After a bit of effort and trial&error, I manage to make the movement work. One thing to keep in mind here is to wrap the movement around a state handler because that will serve as a foundation later to identify which animation to play amongst others. But none of this is visible as of yet.
I test this out with some debug buttons. Below is state of the progress:
Day 3
Yesterday I have built a very simple world with a projected window and a fairy that can move to designated areas by button clicks. As of the plan, today I need to add a resource system along with one resource for the fairy to be able to collect and take to the stash. This may sound simple, but it needs to be solid, versatile and extensible as this is going to be the very heart of the game. It needs to be versatile and extensible especially due to the game jam's time constraints - I need to be able to add and alter an arbitrary number of resources dynamically later to be able to extend and balance the game freely. At the same time, I must never be forced to touch this system again, because if I spot something in a late phase of the jam and am forced to change it, there is a very high risk of breaking something because there are so many connecting lines.
We are only going to have one fairy for today of course, and only one resource. But I know that there will be more. And I have to design the system around this.
That's all great, but how do I approach this?
The answer is that I have three techniques for building versatile and scalable environments.
Firstly, get a cup of coffee ☕
Secondly, bootstrap the project with singleton managers/services
All of my projects have a bunch of singleton services which mostly have three purposes:
- Broadcast events to interested game objects (more on this in the next section)
- Keep singular state. In my case for example, there is going to be a CookingService that will
- Broadcast cooking events, for example cooking progress, when cooking starts or stops or when a recipe is changed
- Keep state of cooking
- Sequencing events (not so common)
Most people would call these Managers but I am used to call them Service due to some naming conflicts with the term Manager with inbuilt classes. For example, Unity has an inbuilt class named SceneManager, and if I want to have a singleton class what manages scenes, I need to find a different name. SceneService works though, and I never get any name conflicts using that term.
I suggest setting up all your services (or managers) to initialize shortly before the default initialization time. In Unity, you can achieve this by going to Edit -> Project Settings -> Script Execution Order and then setting your services to something lower than 0, like -10. There is also a trick to not have to do this for every new service you create - by having a BootstrapService! You would then go and set up that service to start slightly earlier than the others with the aforementioned method, and the BootstrapService's responsibility would be to start up all other services that you have in a desired sequence. Here's a fast-forward screenshot of the service list that I have at the end of the jam, along with the Script Execution Order section:
As you can see, I have set the BootstrapService execution sequence priority to -10, so that it would execute earlier than the default scripts. On the right hand side you can then see that the BootstrapService is enabled, with all other services being disabled at the start of the runtime. At the time BootstrapService is enabled then (which will be earlier than default) all services within its list will get enabled as well, in the order specified in the BootstrapService.
This is great for controlling the service startup time and managing dependencies between services! In my example, there is a dependency between LabEventService and CookingService - the former requires the latter to be running. The bootstrapping method ensures that this is always the case.
Thirdly, build an event-driven architecture
An event-driven architecture is key to a scalable game. Imagine below scenario:
You have a game scene with a player character and an enemy unit. The player can damage and destroy the enemy unit. When an enemy is destroyed, various things should happen:
- the player's level should increase
- a new enemy should spawn
- an enemy-destroyed counter should increment
At first glance, the most straightforward way would seem to be handling this in the enemy itself, so when an enemy is destroyed, the enemy will call methods on the player object, on the enemy spawner object and on the UI object to increment the enemy-destroyed count.
There are however various problems with this:
- The enemy unit cannot exist without the player unit, as it will not be able to increase the player's level if it does not exist
- The enemy unit cannot exist without the enemy spawner unit, as it will not be able to spawn a new enemy if the spawner is not there
- The enemy unit cannot exist without the enemy-destroyed counter, as it will not be able to increment the counter if it is not there
- This tight coupling also adds unintuitive logic - the enemy unit is suddenly directly responsible for altering the player level, new enemies spawning and even changing the UI?
The code will not inherently fail, and at a certain scale it is fine and okay to do these things (hint: I am guilty of these too, especially when I am in time constraints), but skipping on modular, scalable design at the very core of the game is mostly not a good idea, especially if you plan to extend it. You will quickly get overwhelmed and the cross-dependencies will become unmanagable. Fixing one thing will break 5 other things.
Instead of this, broadcast the events, such as an EnemyDestroyed event to a singleton service (as described in the previous section). All game objects that are interested in enemy destructions would then subscribe to the EnemyDestroyed event and do whatever they should. The Enemy unit itself would know nothing of its "consumers", because it does not need to! If you are unfamiliar with this, it might sound a bit scary and overcomplicated at first, but trust me, it is not!
Diving deeper would kind of break the scope of this devlog - in a nutshell, to get started
- Create a singleton service
- Add something like this to it:
public Action<Enemy> OnEnemyDestroyed = delegate { }; - Invoke the action from the enemy whenever an enemy is destroyed
- In the game objects that are interested in it, subscribe to the event and handle it individually per case
So, I grab a big mug of coffee, keep all that in mind and transcend into a state of deep programming trance...
...and after I awake, I have below result:
This does not look like much difference at first glance. There is now a cauldron draft, there is some different UI element on the top and some particles.
But under the surface, there have been numerous changes, and I have implemented a solid resource gathering and cooking system.
Right now there is only one resource - grass - and one type of fairy in place that collects grass, as well as one recipe, the grass fairy. With the system that I have built however I can now easily extend this to any scale.
I figure that working with multiple resources is impractical at the moment because there is no UI for me to work with. The core mechanic - the deepest layer of the onion - is now complete. Taking a look at the second layer, I am supposed to be able to select ingredients. Therefore, I will continue working on a UI prototype next.
Day 4
As decided at the end of day 3, it is time to design a UI for selecting resources so that I can extend the system that I have built. For the most part, this is just grunt work. So I am grabbing another mug of coffee and sinking myself into deep programming delirium...
In the past I have had some issues with scalability of my UIs across different screen types. I am not an expert on this, but what seems to have worked for me is to use anchors for scaling my UI elements instead of absolute widths and heights. So I will go with that for this project until I know better... below is what it looks like and how it scales right now:
As you can see though, the UI is pretty empty. I therefore take some time to populate those according to my imagination, and present to you below result:
I've also taken the liberty to add some new resources and recipes as you can see to see the UI doing its thing, and I think it looks really nice already! At the very least with this I will be able to continue to scale the game with more resources and recipes and test whether everything works.
As I am quite burnt out from heavy programming the past two days, I decide to exert the other, create half of my brain for the rest of the day and work on some visuals for the remainder of the day.
Day 5
Today, I am replacing most of the provisional art assets with real ones. I am adding:
- a fairy sprite
- a witch sprite
- a stash sprite
- a door sprite (which I changed later by the way...)
- texture to the lab background
- a fitting landscape
For pixel art, I use Aseprite exclusively. For inspiration, simple icon assets and inspiration I use ChatGPT. (Update: These have been replaced in the meanwhile. This was initially done as the game was originally made for a game jam with strict time constraints)
Using AI to generate art (in 2025) can be great to kick off a piece of art or to get inspiration, but there are some things that AI is particularly bad at:
- Pixel art at a low resolution
- Limiting colors
- Coherency
Generally, AI tends to do "too much", as in adding too many details, too much resolution and too much color. Also, it cannot create the same thing twice, meaning coherent animations are pretty much impossible (at least I could not get it done).
I definitely recommend using AI to get a template or something, but whatever it creates needs to be rescaled, recolered and potentially animated. None of those things work well with AI as of now from my experience. For static images that you can scale down, like icons, it kind of works though.
Here is the result:
Day 6
Today, I am going to finish the main gameplay loop, from cooking the first to cooking the final item - the third layer of the onion. This is for the very most part playtesting and balancing the game, and adding, removing and altering recipes. Thanks to my prior work I can do this very easily and dynamically. My system manages this solely by Scriptable Objects which I can easily create, update and delete. It looks like this:
I am also having some of my friends playtest the game to tell me what feels good and what does not. Based on this, I design a 30 to 45 minutes progression that feels not too fast and not too slow.
Once this is done, I am focussing on an intro and outro now. This is for the most part a chore as well without any remarkable technical depth, amongst others it involves
- building speech bubbles
- small intro and outro scenes
- some dialogue
- playing through them again and again to see if the timings will right
Day 7
I think I am pretty good on time, and the gameplay feels a bit shallow still - hence I decide to introduce a recipe based upgrade system. Currently, there are two types of recipes - resource recipes and fairy recipes. I am adding a third type, the upgrade recipe.
Even more luckily, this is easier to implement than I had initially feared, so I complete this in a relatively short amount time and have some time remaining today. I decide that it is now time for polish to make the game feel better to play. I am going to spend today and tomorrow doing this. There are three main points I am going to focus on:
- Responsive UI
- Reactive ingame units
- Visual effects
For achieving a responsive UI, as well as for reactive ingame units I have two main tools of choice - Feel by MoreMountains and LeanTween.
Note: I am not sponsored by Feel or LeanTween in any way - I am simply sharing my experiences
Generally, there are many problems that you may encounter that someone else might have solved already. The more common your problem is, the more likely it is that someone else has encountered it before. Consequently, the chances are also higher that someone has tried and fixed the problem already.
In these cases, I recommend taking some time to investigate if anyone has solved the particular problem you are encountering right now before. Some of these assets cost money, but it may be worth considering.
Improving User Experience may be such a problem - virtually every game has to deal with this problem. The solutions to these problems for me are Feel and LeanTween. I use LeanTween for very light user feedbacks, like button hover effects or sliding UI panels, and Feel for more heavy stuff, like combining multiple effects. I would probably use Feel for everything if I was more proficient in its usage though.
Feel costs some money, but LeanTween is free and open source! And it is very powerful.
I am adding things like
- UI elements popping up instead of "just being there"
- Cauldron bubbling
- Cauldron bump effect when it's cooking and when the mouse is hovering
- Button hover effect
- UI panel sliding effect
- Fairy, item and upgrade cooking effects
- Some more stuff probably, that I cannot recall right now...
Day 8:
It is time to integrate some sounds and music!
My process for selecting sound effects is rather simple - I listen to sound effects that I own and then select those which might be suitable for a particular effect... Generally, I think it is a good idea to add as many sound effects as possible, because humans are used to EVERYTHING making a sound. One exception is sounds that may get too annoying - mostly sounds that I expect to occur very frequently. In my game, an example of this would be the fairies' collection of resources - I tried it and found it to be quite annoying, and considering it is implied that they are somewhere far away adding no sound to that seemed reasonable.
Concerning music, I have spent the last few days on music for a tiny bit, but not for long. I use FL Studio for creating music. I was hoping I could come up with something, and I came up with a few sounds, but this needs a lot of refinement.
For the intro and outro, I am going with a classic "witchy" sound, but I figured that the main gameplay theme has to be something chill and wavey for easy listening, because the player will be there for the longest time.
Now, I don't really have a great sophisticated process for coming up with music... It is mostly playing with chords, turning some knobs and filters and taking inspiration from songs that I know. I have taken inspiration from Yume 2kki's soundtrack, if you are interested.
Day 9:
Most of the work is done and I am already content with the result. I am going to do some further minor polish and try out some things.
One thing I could try is to make the landscape a bit more vibrant by adding some ray effects and clouds that procedurally change over time - like real clouds basically. I also want to layer the mountains, so that part of the clouds fades behind them. Also, a water effect for the lake would be nice.
I have a live phone wallpaper project that I have built once to create some vibrant backgrounds for my phone, and I am intending to reuse those scripts to generate procedural clouds and a water ripple effect in the lake.
I go and import them, and do some tweaks. Below is the result:
Look at those procedural clouds moving and shaping!
Unfortunately though, I have to notice that there's a large performance drop with this approach. Not noticable, but significant. The framerate on my computer dropped from about 300 frames per second to 80 frames per second. Not every human notices this, but a computer definitely does and there was something going on in the background, and it feels wrong to go forward to this.
Besides, would you have noticed that there was a ripple effect in the water if I hadn't told you now?
This performance drop very likely stems from the fact that I am rendering the changes of the shapes in CPU by actually changing the shape of the very texture - this is very inefficient. For doing this once for recording a GIF (like I did in my phone live wallpaper app) that is completely fine, but for a realtime render like a game it is not.
The proper way to deal with this would be to write a shader, but considering I have very little proficiency in that area and also in light of this being the last day before the submission deadline I decide to scrap the transforming clouds and the water ripples.
I decide to stick with the static, moving clouds and the light rays as they have no performance impact, and that looks almost equally as good.
Done!
The work is done!
I am really looking forward to playing some of the other entries now...
Thanks for sticking around and reading the devlog. I hope you were able to take away some things for your future projects and I hope to see you in a future jam!
Comments
Log in with itch.io to leave a comment.
You did a great job on this devlog. Silly question. You said at the beginning "liveliness" was a concern and that you were disappointed you may not be able to have it in this game. What do you mean by "liveliness"? I've not heard the term applied to games before.
Hey, thank you! Maybe the term is not very fitting... what I meant was a game that feels "alive". I was a bit concerned that it could be challenging in an idle-incremental type of game with essentially just one control at this time. I tried to achieve some "liveliness" (not sure if theres a better term for this) by providing the intro and some interactive dialogue amongst others, but other types of games have more interactive movement which is missing in this game, so I thought that this makes the game feeling alive challenging
There definitely was a lot going on - caldron bubbling, fairies outside gathering, could blowing by. I think just having some part of your game moving (the player stretching up and down or blinking, stars twinkling, etc.) can add that feeling of the game being a living world as opposed to a static image.