Game Development, Unity, C#

How I developed my first Video Game

My first video game

How I developed my first game Cable Clutter and my key takeaways

Roughly one year ago I had an idea for a video game when I walked by an installation in a science museum and ended up developing a video game for a bit more than a year. Here is the entire journey of how I went through the process and what I have learned from it.

Table of Content

• Disclaimers
• How to fail at Game Development
• Inspiration Strikes
• Developing a Music Game?
• Identifying Problems
• Fun with Cables
• Uncharted Territory
• More Content and Performance Improvements
• Getting Feedback and implementing a Level Editor
• Level Progression
• Release on Steam
• Final Thoughts

Disclaimers

There are a few things that you should consider when reading this article. Mainly what the position was from which I started developing the game.

1. I work as a software developer. Even though I don’t use C# at work, it made at least the programming part in Unity a lot easier. Sure, I still have to learn how the engine and its APIs work , but most programming languages are similar enough that you can pick them up relatively quickly if you already know at least one language.
2. I have a math degree. While this is usually not directly useful, it helps a lot when it comes to analysing and solving problems.
   Also, it helps quite a lot when it comes down to reading mathematical notation. For example, at some point in development I wanted to use Bézier curves and I had to read up how to implement them.
3. This is not my first attempt. I tried to develop a video game a few times before and always failed. This was maybe my fifth attempt.

Don’t be discouraged if you don’t start from the same position as me. There is a lot more to game development that programming and maths. Recognize your strengths and weaknesses and adapt to them.
Also, it is totally fine to fail, as long as you learn from your mistakes. I have learned a lot from my failed attempts and everything that I have learned before flowed into Cable Clutter.

How to fail at Game Development

Cable Clutter was certainly not the first game that I tried to develop. I have started multiple projects that have failed. Failing is normal and you usually learn important lessons. Also, you will never create something new if you are afraid to fail. Here are some of the key reasons for my failures that I have identified.

1. Writing my own engine
   There is nothing wrong with writing your own engine and there are legitimate reasons why you might want to do so. I have a few smaller projects where I did write my own renderers in OpenGL or SFML and I am thinking about learning Vulkan.
   It is good to know how engines work and writing your own engine is an excellent way to learn about something like Phong shading or ambient occlusion. If your main goal is to create a game though, in most cases it is enough to use an engine that already exists, like Unity, Unreal Engine or Godot.
2. Taking on too much
   If you are a solo developer or a small team, there is only a limited amount of time that you can put into a project. In my case, I have a full time job and all the game development happens in my spare time. That means that I can roughly put in 1–2 hours of work every day on average (you might be able to put in more) and that means that I probably won’t be able to develop something like an MMORPG.
   Furthermore, there are a number of skills that go into a video game. You probably need to be able to program, draw to some extend, if your game is in 3D you need to be able to do 3D modelling, somehow you need to get music into your game, sadly you have to deal with marketing, and last but not least, you need to know how to actually develop video games. In my opinion, it is almost impossible to be an amazing programmer, artist, 3D modeler, musician and a marketing specialist at the same time. Each of these skills can take years to even get to a decent level. You will have to compromise somewhere.
3. Doing too much manually
   Because I work alone, I have to reduce the amount of work required. So I try to automate everything I can. If you are using Unity and you repeat certain tasks over and over, you probably want to write some editor scripts.
   If you have to do something over and over, you probably want to write a shell script for it. For Example, I wrote a script that builds the game in Unity and uploads the build to Steam.
   Make your code modular and reusable. If your code base is good, you can reuse it in future games. You really don’t want to solve the same problem multiple times just because your code base is bad or because you are not using the engine as intended. Monobehaviours in Unity, for example, are supposed to do one thing and one thing only. If your Monobehaviour does 2 or 3 things, you probably want to refactor your code.
4. Not removing or reworking features
   It hurts to kill your babies, but if you realise that something doesn’t work, you have to fix it or in some cases it is best to just remove it. Game development is a creative process, there is a high chance that what you start with will be nothing like what you actually end up with.
   Some of my projects I never finished because I added features that I never got to work. I just ended up being blocked and abandoning the project.
5. Not using Version Control
   I highly recommend using a form of version control. I would never have been able to get anywhere without Git. Version control allows to continuously save your progress and roll back changes in case you have to. Therefore, you can just try something new without being worried about breaking your existing work.
   Before I used Git I was often worried about refactoring my code or adding new features because I was worried that I might break something. Git takes this feat completely away. Nowadays I use some sort of version control for almost everything.
6. Being afraid to learn something new
   I used to be really afraid to get into game development because I was afraid that programming or 3D modelling would be too hard. Or I felt unconfident about my drawing skills.
   There is no reason to be afraid of these things. Granted, none of these things are trivial, but you do not need to be an expert in any of these things.
   While it is useful if you are good at programming, you do not have to be the best programmer in the world to develop a video game. It is enough if you are decent.
   Same with drawing skills… You don’t need to be able to create amazing art works. Of course it is great if you can, but it is sufficient if you draw well enough to get your ideas down on a piece of paper. Your drawings don’t need to look good. Furthermore, if you need good art or good 3D models you can always hire an artist.

Inspiration Strikes

I had the main inspiration for my game when I visited Technorama, the Swiss Science Center in Winterthur, with a friend. They have really cool exhibitions and labs where you can experience science. Amazing place to visit with your kids and I even enjoy going there as an adult.
It was there, where I saw an installation that gave me the main inspiration for my game, namely a wall where you can play music by placing xylophones on a wall and then drop a ball on them. The ball will then bounce around on the xylophones and play music.
I thought it would be cool to implement something similar it in Unity. Also… I thought that it wouldn’t be too hard. Thus, I started right away when I got back home.

The Programmers’ Credo:
We do these things not because they are easy, but because we thought they were going to be easy.

Problem:
While I know how to program and I kind of know how to use Unity, I have to admit that I don’t know anything about music. And if I wanted to create these xylophones, I will have to learn how to implement them in Unity. Luckily I found VSCO 2 Comunity Edition. It essentially contains a bunch of sound files and an SFZ file with instructions on how to but them together. Essentially, you have multiple sound files for each instrument and the SFZ file will then tell you with which pitches you have to use for each file to get to the complete range of sounds. Eventually I got the hang of it and put it all together in a C# class. Then I read on Wikipedia how the notation works and created an Editor Script in Unity that would allow me to control what sound each of the xylophones would make.

So I put everything together, created a simple scene and this is how my first implementation looked like

First implementation

While I admit that it does look very simple, it does exactly what it is supposed to. The balls hit the xylophones and they play the sounds.
As a next step I wanted to add more controls to the game. The entire thing should be interactive. Also, I played with the idea of making the game Christmas-themed and added a Christmas-HDRI from Poly Haven for the background.

Slightly more controls

Developing a Music Game?

At this point of development I was convinced that in the end it will be a game where people will play music in some way. To either put together an orchestra of different instruments that play a song by using the physics system or maybe it will be a puzzle game where you have to play a given melody.
Anyway, I found that everything looked very clunky and all the objects get into each others way. It was very hard to come up with something that actually played something that sounds like music. So I sat down, opened Blender, and tried to come up with a design that was more lean and easier to use. Also, I wanted to add more controls to the xylophones.

Here is how the updated version looked like:

Improved Models and Controls

Now, it is great that you can play around and play some sounds. But if this is going to be a video game, it needs to have an objective, some sort of goal that the player has to achieve. I thought that it might be cool if you have a sheet of music with a melody that you then have to play by using the physics and the ball. Because I don’t know how to play music I also didn’t know how to read music sheets. So I spend some time to read up on how they work. In case you are interested, here is a decent explanation.
Essentially, there are two clefs (maybe there are more? I don’t know), the Treble Clef and the Bass Clef. They will tell you what sound each of the notes are supposed to be. You just have to remember it somehow.
There is a bit more to it. But I decided to start with a very basic implementation where you just have to play the melody in correct order to complete a level.

Remark:
I find the notation in music to be random and overcomplicated. Whoever came up with it put a lot of effort in making it unintuitive and unreadable. Definitely not made by a Mathematician!

Here is what I came up with:

Identifying Problems

It was at this point where some problems with the game started to show up. First of all, configurations of the xylophones that played the melody were often very random and it didn't feel like you're actually solving a problem, it felt more as if you were just trying random stuff that accidentally worked. I really didn't like that. Everything was way too fuzzy.
The rules of the game should appear clearly to the player. In other words, it should be clear in what space the solutions lie. And so I thought that the puzzles would improve if everything was more discrete. For example, if the xylophones would move on a grid it would be clear where they could be in a solution. Similarly, their rotations should only be discrete and angles, incremented by a fixed degree.
Also, I ran into some problems with the physics system in Unity that I was not able to fix. So I made it that gravity and physics would no longer apply to the ball. Now the ball now just goes straight. This way it became a lot easier to control where the ball was going.
Another change I added in this iteration was the addition of path finding. The Xylophones could now only move on a grid on a board. To generate these boards I added an editor script that would programmatically create them.
All of these changes made the game’s rules and the solutions to the puzzles more clear and I think it was the right direction to move into.

Everything is more discrete

At this point the game kind of works like this: You have a given melody that you have to play with the xylophones. You play the melody by reflecting the ball between them in the correct order and pass the level. This was now better because you have to think about what you are doing and the levels are more clear.

Fun with Cables

One evening when showing the game to a friend he had an amazing idea. It would be cool it you could connect the xylophones through cables and send signals to each other. Meaning that if a xylophone was hit, it would send a signal to connected xylophones which would then rotate or move them. I really liked the idea and immediately sat down to implement a prototype.
I added sockets and cables. Each cable has two plugs and the plugs could connect to sockets. Each socket is then connected to an action. The respective action could be any method of a Monobehaviour. In the video below is an example where the action is a rotation.

Fun with Cables

I absolutely loved how it behaved and it opened up a lot of new possibilities. It was at this point where I then made a critical decision. I decided to not make a music game, but to make a puzzle game with automation.
Making the game about music caused some problems. If players were not able to read music sheets, they would just randomly try stuff until they passed the level and I couldn’t find a way to make it more clear to them what they are supposed to do.
Furthermore, having to play the melody really limited what players are allowed to do. This had the effect that I was only able to come up with 5–6 levels and that was it. If I wanted to make a proper game, it needed more levels than that.
At this point I really wasn’t sure if it was the correct decision to make, but looking back it definitely was. Moving away from music and going into automation opened up a lot of cool possibilities for new game elements and puzzles. So I decided to remove the music sheets and added a simple goal that the ball has to reach.
So I sat down again in Blender and started redesigning some game objects and added some new ones. I created a button that you can press and then sends out a signal through the cable. I also created a cannon, which could spawn a ball. The xylophones as well as the cannons could be controlled through the sockets. The sockets could mainly control their position and rotation and for the cannons they can also shoot the ball. Together with the buttons I thought this could create interesting interactions. For example, you could now control the movement of the xylophones with WASD, which is just standard input in pretty much any video game.
At this point I got really excited. Everything started to look a lot more like a video game.

Updated Game with new Objects

Uncharted Territory

I have started a lot of small projects, but never got to the point where I was actually developing a video game. So far I mainly had a bunch of game mechanics, but now it had to come together to create a complete product.
I had more and more ideas about how the different elements could interact with each other and I tried to create levels that would use the different game mechanics. This is the phase in development which is the most fun in my opinion. Where you can just be creative and play with what you came up with, essentially, discovering what your game actually is and what it is capable of. It was very cool to watch the game grow day by day.

Sadly, there are some things that you have to implement which are not that much fun, like the user interface or saving the game states.
I've created user interfaces before with SFML and ImGui but I've never done so in Unity. I know that you can create UIs with the 2D but simply because I have never used it, I decided to implement the entire UI in 3D. Looking back, this was probably a dumb decision. I did it not because it was better, but simply because I'm used to working in 3D. Beware the law of the instrument.

Law of the instrument
If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail

I finally did get the UI to work, but it did take a lot more time than it was supposed to. I highly recommend looking into the 2D API if you want to create a user interface for your game.

For saving the game state I just used the JsonUtility. You can find it in the unity documentation. It did work out of the box and I didn't have any issues with it. I also did some tests and it seems to work at least on both Windows and Linux. Somehow test it on a Mac, but that’s another issue.

More Content and Performance Improvements

I sat down and added new types of cables, cables that could only be used once, cables that would lock when the start button is pressed and cables that can be reused. I also added some pipes through which the balls can travel and reworked how the boards look like. In general, I just tried to find new elements that I can add to the game that would be interesting.
At this point I also invested a little time in improving performance. I mainly found two useful resources for doing so. This Unity article here about performance and optimization and the C# recommendations for Unity from Microsoft. This helped me to find two or three bottlenecks that really did improve in performance quite a lot.
Furthermore, they are not lying there. Empty callback functions in Monobehaviours really do create performance issues and calling GetComponent() is very expensive. For me they were mainly two key takeaways, A) remove empty callback functions and B) try to stash everything that you would get with a GetComponent(). Ideally you only wanna call GetComponent() once, i.e. in the Awake callback function.

Getting Feedback and implementing a Level Editor

I now had the game in a state where I thought it would be a good idea to ask people for feedback. So I gave the game to some friends to playtest the game. Getting feedback from people is extremely useful and I'm glad that I did so. When you have worked on a project for multiple months, you start to get tunnel vision and it becomes hard to see what is good and what is not. A pair of fresh eyes might discover issues that you are blind to. They gave me a large list of things that I could change and improve and that kept me busy for a while.

Another feature that I started to think about was a level editor. In my opinion, one of the most fun things to do is to interact with the different game objects and come up with new puzzles. That is why I thought that it would be great to include something like a level editor or a playground in the game. Sadly, it is not in the game in its current state, because it proved to be harder to implement than I initially thought.
When I designed the objects and the set up the code I didn’t have a level editor in mind. Adding the functionality required fairly large code changes. At this point I am just not that happy with how it is implemented and that is why I have left it out of the final build.
There is another issue. I spent some to find a way to work around this. But apparently in Unity you have to write the serialisation and deserialization of game objects yourself. Sadly my code is totally not set up for that. That means that, if I want players to be able save their own levels I have to implement the serialisation and deserialisation for every single game object, which would take a larger refactoring.
That is why I decided to focus on the rest of the game for now and maybe implement the level editor in the future. I mean I can always publish an update for the game in the future.

Level Progression and Music for the Game

Initially, I just implemented a simple linear progression. After a level is finished the screen fades to black and the game loads the next level. This was achieved with a small animation on a canvas with a black texture. It was simple to implement and at the beginning of development I really didn’t need anything more fancy. But now some problems started to show up with the linear progression. I just couldn’t figure out how to fit everything together smoothly. Sometimes very easy levels that just introduced a new element would be followed by very hard ones. Also, if the player wasn’t able to solve a level he would just get stuck there. In the end I simply couldn’t figure out how to fit everything together.
I then looked at other puzzle games and how they solve this issue. I really liked how the problem is solved in Baba is You, you unlock new levels in the vicinity of a level you just solved. I thought that something similar would fit my game as well. So I sat down and completely reworked the progression and made it non-linear to allow for more flexibility. I was now able create categories of levels. Meaning that I can introduce a new game object and then bundle consecutive levels with increased difficulty that use said game object.

One thing that was missing up to this point was the music. I can program, I can kind of 3D model, but one thing that I cannot do, until now at least, is creating sound effects and music. That is why I either looked for royalty free music and sound effects or just payed for them (there is no harm in supporting artists).
For the sound effects I mainly used the Universal Sound FX asset from the Unity Asset store. I already bought it a few years ago for another project and ended up using it in Cable Clutter.
For the music I spent a few days just listening to tracks on different sites that host music that you can use in a video game. The one I ended up using was ccMixter. Especially the music by airtone. Literally every single track in the game is by airtone. I find that airtone’s work fits quite well to the overall tone of the game and I really enjoy the tracks.

Release on Steam

Now I was at the point where I have a video game in its beta state and I had to figure out how to actually release a video game. I decided to release it on Steam. Mainly because it is the platform that I use most, and also because the entire process is quite well documented.
First of all you have to create a Steamworks account. Then you have to pay the Steam Direct Fee to get an AppID . It works like this: You have to pay a $100 fee for each app that you want to put on Steam. You can’t get that money back, but when your game makes $1,000 you can get a new AppID without paying the fee.
Once you have an AppID you can then use it to upload builds of your game to Steam. For building and uploading the game I just wrote a small shell script that takes care of everything because it is really boring to do everything manually.
To release the game on Steam you have to go through the release process. You need to have a build and you need to have a store page. For both you will have two checklists in Steam. Just go through each of the points. Be prepared to upload a lot of screenshots. Once you are finished, you can mark your game ready for review. It takes a few days and if everything is ok, you will receive an email that your game is ready for release.
It sounds like less work than it actually is. This took me several days to be honest.

I also continued to work on the game. I further improved progression, fixed a lot of bugs and tried to migrate my game to URP. When I started working on the game I created an HDRP just to play around with. At that point I didn’t know that it will turn into a full game. I chose HDRP because I wanted to learn how it works. Somehow I ended up developing an entire game in a Unity project that I initially created just to play around.
HDRP as of now can neither do an Android nor an iOS build. I didn’t know this until I tried to do an Android build half a year into development. It makes a lot of sense to make your game accessible on as many platforms as possible. So naturally I wanted to migrate the project to URP because it would allow to build the game for mobile platforms. After a week of trying to migrate the project, I sadly had to admit defeat. Migrating a project from one render pipeline to another is hell in Unity. At this point I just have to wait until they release a version where you can create mobile builds with HDRP.

But otherwise that is pretty much it. I went through the entire development process. I spent a lot of evenings programming and working on my game. I figured out how you actually release a game on Steam. All that would be left now would be the marketing (I have no idea how to do the marketing).
I talked to a friend who is a game dev and he recommended contacting streamers and giving them some beta keys. I personally think that it is great advice and it seems to be the way that people usually market their games nowadays. Sadly, I am too introverted to contact streamers :D

Final Thoughts

I wanted to mention a few key takeaways that I have learned from the entire process.

• It would have been a good idea to keep serialisation and deserialisation in mind from the beginning. In the future, I will structure my code to make this a lot easier.
• Having everything modular and reusable saved me a lot of time. I was often just able to recombine some existing Monobehaviours to create new game objects.
• I should have definitely put more time and thought into marketing. It is the least fun of the things that you have to do when developing a video game, but it seems to be essential for its success.
• It doesn’t make sense to plan out your game too much in advance. The entire thing seems to be a creative process and what you start with might not even be close to what you end up with. I started by developing a music application and ended up with a puzzle game where you try to get a ball into a goal. (I still think there is a great music app hidden somewhere in there)
• It would have been a good idea to keep older builds of the game around. Sadly I didn’t do that until maybe the midpoint of development.

In case you are still around, thanks for listening to my journey. It was a lot of fun to develop Cable Clutter. The game is available on Steam feel free to check it out. Also, feedback is always welcome. I hope that some people will enjoy it and I can’t wait to start my next project.

And last but not least, here is the trailer for the final game: