1: My situation before Slime

I've worked on Slime for almost one and a half years now. That's the longest I've ever worked on a game. The decisions I made for Slime were heavily influenced by what little experience I had as a game developer when starting the project, some of which have probably saved this project from being discontinued early. You see, the goal - for me at least - is to work on something I can finish and enjoy working on, which is easier said than done. At first, when I started to learn how to make games with Unity in late 2017, simple ideas would come to my head, but as I continued to think about them, many more ideas came up adding to the original idea. They were exciting to think about but what I didn't realize then was that these ideas were also complex and time consuming things to actually implement. Somewhat predictably, my early projects ended up barely finished and I ended up unmotivated.

Slime started as a quick drawing of a small, simple game idea I had at the time: You - a vaguely oval-shaped slime - can throw yourself in a direction of your choosing and then you find yourself being either stuck to another wall and jumping once more, or dead because you threw yourself into a spike. It was supposed to be a kind of puzzle game because you had a limited amount of jumps.

And I for myself decided: A project doesn't have to be finished, if you decide that it is not worth it. Just take whatever new knowledge or experience you can get from it and move on. This really helped me because wasting my time in particular was the biggest part of my doubts about what I was doing at that time. My mistake was to focus too much on what game I'd like to make instead of thinking about the game I was making (and could reasonably accomplish). And this decision allowed me to just move on from projects without feeling bad or being disappointed of myself when I felt they had arrived at their potential given my still developing skills, but on the other hand I also gained experience from them regardless. At this stage, this freedom was more important to me than properly finishing something. In some cases just dropping the project might even be the responsible thing to do. Long therm projects, espeically early on, tend to be inappropriate for your learning curve at that time.

2: A small afternoon project

I finally started work on some afternoon in December of 2018 when I decided I would just try out this idea and see how it worked out because something this simple would surely only take a very small amount of time to finish. I also tried not to have a real vision for this project to not overload myself with stuff to do again. As opposed to most previous projects, I started by quickly drawing some textures and then implemented basic player behavior, like jumping and dying. Even having only crappy and rough graphics motivated me a lot. I spent days looking at placeholders like clean-cut white cubes for ages in other prototypes which really drained the fantasy of the game and having any kind of graphics in place already prevented the dread of creating polished once down the road, since i already had designs to base them off of, as well as that kind of feeling of a cohesive style for the game.

I instantly decided it was more fun to just have the health count down over time, since it allowed for errors if you made up for the time loss by being faster elsewhere. The following day I decided there should be a string of levels to complete, so I quickly threw together 4 levels and a game manager that would just load the next scene and finally a sort of sandbox level at the end. At this point the game looked something like this and it already had bouncers (although the direction they'd throw you in was unpredictable to say the least):

The second version added buttons, working doors, jump orbs and levels to introduce them. I felt like buttons were a good way to make the player take a detour - no matter how small - to make the levels feel less like a single long path and more like a complex path. I mean, they are still pretty linear by design, but their shape provides the levels with enough fidelity to stay interesting gameplay wise. At this point, the game was going to have more things like timed buttons and small puzzles, but I felt - since i could look at the existing prototype for reference - that it didn't really fit in with the instant death spikes and time constraining health systems. This was one of the times were having no vision helped me just look at the game as it existed currently and see what it needed and what it didn't need. Eventually a vision of sorts materialized from the game, but the special thing about it was that it stemmed from the game and grew with it. It slowly built itself, step by step, only building on stuff that I already implemented, preventing me from dreaming too much. It made me think more critically about what to put in the game next, because I didn't have plans with eventual "good ideas" that were dependant on other ideas (crappy or complicated ones in particular), many of which would not even fit the game in hindsight and have certainly been its doom.

I sent version 0.5 (which added one new level and the timer) to a friend and watched him play it because I was curious how it would play and also because I needed motivation. I learned a few things that day. First, playtesting is really interesting, especially first experiences with the game. And it's really really motivating. If you can slap the most basic of things together and call it playable, start testing it. Secondly, my game was pretty hard, mostly due to the player controlling horribly sometimes and the levels getting harder pretty quickly. Lastly, the game concept itself was fun. All of these things were enough to motivate me to continue working.

3: From prototype to game

In 0.9, I finally had the concept of level packs - 9 levels, I don't remember why - and a level select screen, basic pausing, F1 to return to level select, a main menu, the first options menu entry - music volume - and progress saving (times and deaths). The game was actually enjoyable at this stage, since I had balanced the levels over multiple versions with the help of playtesting and there were also a lot of improvements to the handling of the slime, which now felt much better to play, like boucing being based on a circular collider around the player's center instead of the actual weird collision shape. I also added discord integration, which was one of the things I did randomly because I felt like trying them out.

A friend I often talked about games and game development to sometimes made music tracks in his free time, first on a free sequencer app on his old phone and then, more recently, on his PC as well using Bosca Ceoil. We agreed that he could make some tracks for the game, the first of which were introduced in this version. I thought it would be cool to have the music progress as you complete more levels - an idea I held on to, but reimplemented quite a few times. At first the tracks all had the same length and when entering level with index x, the track would be swapped, but the position in the track would be kept. It was kind of hard to really progress a song with this configuration and it also sounded a bit strange, so in the next implementation, it would just move from loop to loop when a level with index x was reached and the old loop had finished playing. I later added support for transitions (tracks played only once between loops) to cope with parts in songs that couldn't be looped.

He later remade the soundtrack with his recently acquired version of FL Studio, but having music in the game early on and knowing that somebody else also worked on the game was also a great motivation and made the game feel better from the start. I really admire his and other's music, especially since I know how useless I am at making music on my own.

At some point I thought about making a level editor, and at that time my friend was also talking about user level support and kind of convinced me to actually do it, even though I said that it was going to be way to much work. Since the editor is designed for 2d and the game specifically many things are easier, like rotation and placing tiles and objects. I also wanted to be able to directly transition into a "level test state", which proved to be difficult at first and very useful at last. All in all I got it done faster than expected.

I had already written a level loader/saver in the past, which I slightly readjusted to fit this project. (This is a bit technical, just skip to the next paragraph if you aren't interested in the inner workings of saves) I basically save an array of ObjectSave structs (along TileSave, ConnectionSave and some level specific info, like start health). They contain the id of the object they represent and an array of ComponentSave structs. This array contains at least an TransformComponentSave that inherits from ComponentSave (which in itself is an empty base struct used only for Polymorphism (c# language feature)) and saves position and rotation of the object. If, on the object i want to save, I find a component I can save, the according ComponentSave struct for it is also added to that array (pretty much all objects that are editable in the ingame editor have such a special component), for example when saving a door, the Door component is found and since there is a DoorComponentSave, the relevant values are copied and the save struct is added to the ComponentSave array of the door's ObjectSave struct (which in this case means that I've implemented a special case for it. I would probably try to make it check for that and copy the values dynamically next time). Tile saving works in much of the same way, except there are no components and I only save tile map position and tile type. When loading the object is created according to the saved id and all the saved component values are passed into the components of the newly spawned object.

Besides adding the level editor and rewriting the game manager to load levels from files, I added more level packs, each focused primarily on one mechanic, with some other mechanics introduced on the side. In the first level pack, you learn how to control the slime and how levels work and are completed, which is the main focus of the pack, but it also introduces mechanics that players get used to faster, like spikes and health blobs. The second level pack mainly introduces buttons and doors, but also bouncers. The third pack is focused on jump orbs, but also contains falling spike balls. The secondary mechanics in a pack are often less interesting on their own (falling spike balls, health blobs) or can only be used in more specific circumstances (bouncers), so I put them in the pack in which I thought they'd fit the most thematically.

4: The biggest scrapped feature

You may have noticed that multiplayer was a planned feature for quite some time before it was scrapped. Originally there were going to be coop packs - variants of the single player packs for coop mode - which would require two players. It's just that I never really had ideas for it and after some time I decided that it was also not really fitting for a speed focused game. Consequently, I was playing around with the idea of online multiplayer. I kind of knew that this would be a great chunk of work and I had never done anything networking related. The plan was to just sync the other player's positions for everyone, but there would be no interactions between them. You would see the players in the same level as you and it would essentially be some kind of race through the built-in level packs (or custom ones, though sending a level pack file to all players and then playing it already sounds like a lot more work). I did some work on it and got it to sync two players in a lobby level, but wasn't really motivated to continue and it was also harder to test if something worked - or why it didn't. Theoretically, the code for it is still in the game, but I don't think I'll continue it at this point.

5: Finishing it

As the game developed further, I became increasingly less satisfied with the graphics. I hadn't touched most of them since I drew them at the beginning of the project. I wanted to do slime spatter for quite some time, but decided I needed to redo all object line-art first, which took some time since I rarely worked on it. But now I finally got myself to do it. I think that because the slime splatters all over the place when dying, I can get away with the gray, plain graphics and they fit in better, but some of it still didn't look good.

Since all the line-art was now final, I took the opportunity to give all the objects a solid color as well. One for environmental objects, one for stuff that kills you and one for gameplay elements.

At some point I was just doing slight adjustments or small fixes to stuff and felt like I was running out of things to do. Well, at that time I had forgotten that I still had to make a bunch of levels, but I also happened to have a lot of free time. That's when I thought about the scrapped online mode again. There would be no interactions between the players, it was at most good for laughing at your friends while showing off your skill in a race. It was just displaying many independent runs. I still thought that making an online mode for those reasons was a bit much work for so little and I remembered that, if you think about an online mode like that, a much simpler solution, a compromise, would be to just build an online leaderboard. So I went with that. As leaderboards are pretty much optional to the experience, I accepted that they would only work when starting the game through the itch app, as it lets you use their API  very easily. Your scores are saved with your itch user id, which can be converted back to a name.

With that working, I added some polish here and there, fixed or changed some small things that still bothered me and finally, I remembered that there still were levels to be built. These wouldn't introduce any new mechanics and just explore the existing mechanics and combinations of them more, serving as a final challenge and combination of all game mechanics to capture some more potential.

Still, it turns out that that takes quite some time. Maybe I'm not used to extensive level design, but I rarely did more than one level per day, if any. Sometimes I had good ideas or my experiments worked out and sometimes nothing ever came together and the level was discarded. It was such a lengthy process, that I ended up implementing new features on the side just for the sake of change, for example the two speedrun skins and the assist mode, which was heavily inspired from Celeste's.

The remaining development was spent on implementing sounds and adding final touches like screen shake and usability improvements. Even though these changes were fairly small, they really added to the game, which at that point I was ready to call "finished".

I've worked a lot on this game, which I really wasn't expecting then, so I wanted to make an overview of the development thus far, as I really like to read those for myself and writing this also helps me to reflect on what has happened so far. This project has really taught me a lot about scope and long-therm-ish game development, and finishing a game.

Thanks for reading.