After deciding to make games, we spent a lot of time thinking about the type of game, a fancy idea, and a thrilling story. But in a rush of wisdom we decided to go with a very simple game: a zombie shooter. The main reason being not getting lost in needless complexity and first and foremost learning the basics.

After evaluating a few game engines, we chose Unity as our main tool. We also discussed going with a more open engine that would enable us to be more flexible. As a computer scientist, there is always the haunting need to be able to turn every last little screw in a system. Also, there is the nagging ambition to solve problems by oneself and not to use tools out of the shelf (which can feel a bit like cheating). But in the end, we turned that option down, because we wanted to focus on designing gameplay. Of course you can write your own text parser, of course you can write your own scene editor, but that will take up months of your time. Time that will be lost for designing the real features of your game. And to be honest: In nearly every language or engine you will end up using a few premade libraries. Who wants to punish oneself by writing a fully featured FBX importer on their own?

The next step was organizing our team. Not comprising the classic combo of programmer and artist, there surely was going to be an overlap in our tasks. In addition to that, we are working in different locations. Hence we needed a tool which allowed us to centralize our code and assets, version and occasionally merge them. Based on our experience from our jobs, we gave BitBucket a try. Using this tool gives you an online repository for your files and also a small task manager for team members. Accessing the repository is possible via a client, in our case we use SourceTree from the same company. That combination allows us to work on our local computers, versioning our work from time to time and later update the files in the online repository. After that, every other team member can download the newest version of the project and continue working. This has been working well for us so far, even though a little bit of communication is needed. With two team member working on the same file simultaneously, there is always the possibility that both updates cannot be merged. Plus this mechanism is only available for text based files, meaning it wouldn’t be possible for two members working on the same 3D model, for example. In Unity, it is possible to tweak the settings in a way that project and scene files will be saved text based, clearly the best option with using a repository setup.

Our initial goal was getting to know each and every step of the production. Well… the first steps were skipped immediately. Neither did we create a concept nor design a style guide. Instead we just tried out Unity, learning the features and making up the concept on the fly. In hindsight, maybe this isn’t as bad as it may sound. In this manner, we were able to learn using Unity “by example”, our example, and using every new feature in context of our game. To be clear, it didn’t quite happen this way: We decide we need ragdoll physics, let’s see what Unity has to offer. It was more like that: Oh, Unity has ragdoll physics, how can we put that cool thingy in our game. Of course we didn’t do it by hook or crook. We could have used the cool wheel colliders and put driving vehicles into the game but we decided that would have been too much work with too little gain. In my experience, learning that way is far superior to watching endless tutorials on YouTube without ever getting your hands dirty. Of course these tutorials are super helpful either as an inspiration or as a solution to a problem you may stumble over (I’d like to mention one channel that got me really up to speed with Unity: quill18creates).

Our next project surely will follow the established production pipeline and a design document will exist… possibly ;). Little by little, our first test level started to grow. We modelled items for the level, textured them (UVs are great… but you have to understand them first 🙂 ), wrote some C# scripts, tried to animate the main character, learned about physics and ragdolls (yay!) and implemented more and more ideas. Needless to say, the downside of this approach became clear to us, especially when the scripts had to be restructured various times and grew into a wild mess. Separation of concerns? Next time… when we have a concept that lists all of our actual concerns :). Also, the later scripts were written a bit differently than the earlier ones due to our then gained knowledge. They work, but are a bit inconsistent (e. g. using Awake() or Start()? Get components during runtime via GetComponent() or hardwire them in the editor?). Surely this can cause a lot more work and a bit of frustration, but on the other hand, it let us progress rapidly, keeping us motivated. The whole project is far from being neat, but being just our first project, we can sweep all of that under the carpet with a clean conscience.

To sum up, using Unity, choosing a simple theme and setting, and especially not being too concerned about the “right” way of doing things, we were able to start quickly. For the beginning, this is a beautiful thing, but you have to keep in mind that this first project won’t be the next big thing. This is almost never the case. With that in mind, you can freely experiment and learn for the next project. So don’t waste your long, nourished dream on your first try.