A real-time game from scratch - Motivation [0]

Introduction

In my day to day work, the software I write and architect consists of the standard stateless request & response web server kind. Not particularly exciting or complicated in terms of fundamental structure, although it presents various challenges when running at a certain scale.

In the interest of continued professional development, I have started on the path to writing a real-time game from scratch.

Motivation - Why?

I have been writing programs in Go for a few years now. I love the language and its simplicity, however the applications I have used it for are also quite simplistic - typically REST APIs, small CLI tools and a web scraper. There have been little to no opportunities to use the more sophisticated features of Go, such as its first class concurrency: Go routines and channels, particularly because I aim to pick the simplest tools for the job and the majority APIs I have written have never needed any complex concurrency requirements.

Along with Go, this would also challenge me on my Front-end skills. Most of the FE work that I do is within the context of a framework (typically React) or some minor vanilla JS to add some dynamic interaction to a server side generated web page. A real time game however would require a completely different approach, using tools such as WASM, Canvas or possibly even WebGL to ensure that the refresh rate of the game is as fast as possible.

Another reason is that the more time I spend at my full time job thinking at an architectural level of abstraction, the more I realise the importance of choosing the correct data structures and how to process them, a concern which is less important when you are knee deep in the code. My main concerns are typically how can we reduce the coupling within these two services to avoid development time slowing down or what is the ideal way to upgrade this legacy method of service communication to keep up with our load demand?. These concerns are very different from how do I ensure that, despite unexpected latency from some clients, the game can still run its core loop without blocking all the other clients’ inputs?.

One more reason is that I want to learn how to model systems that are beyond the standard CRUD plus some validation / business logic. A real-time game needs to take several inputs at the same time, ensure that the input is valid, update the game state, synchronise it to all clients and do so fast enough that the game actually feels realtime, despite varying latency, computational power, network availability, etc, all this within a stateful manner.

Finally, I have always found games to be a great entertainment and education tool. Ever since I became a father, being able to sit down for a 3 hour stretch of gaming has become a once in a blue moon treat, causing me to prefer games I can quickly jump into and out of whenever I get a 20 minute window whilst the baby is asleep and all the chores have been finished and I have already spent quality time with my family.

In summary:

1. Improving my knowledge of Go and its concurrency features
2. Challenging myself to learn a method of Front-end Development that takes real-time into consideration
3. Improving my understand of low-level performance and optimisation
4. Being able to architect a stateful, real-time system which caters for multiple clients
5. Creating a game that has a short play time and is easy to pick up and drop out of

The Approach - How?

I could plausibly hop onto YouTube or Udemy, follow a game development course and simply copy paste my way to a finished game. Whilst that was a very valid way for me to learn when I did not fully understand what was going on at a code level and allowed me to bootstrap my software career, my aim now is to improve my existing skills, not only in writing the code but also understanding what that code is doing under the hood. Often enough I have spent my time learning the theory, only to come to apply it and get stuck.

Over time I have come to believe that the theory and practice of a topic cannot be divorced from each other, and at least personally, my learning style prefers to start from the practice, learning bits of theory on the way, getting something working, then investing time to seeing whether knowing the full theoretical story could have produced something more practical. In a way, I am taking the agile approach to learning - knowing just enough to get something working, then iterating on that. Adding onto this - I could use tests to confirm my understanding of the theory. If I write a calculation for acceleration on paper, does my answer return the same when I write it a test for the function?

In summary:

1. Use my existing knowledge to create something working
2. Document the process, outcomes, areas of improvement
3. Investigate whether there exist patterns that can improve on the bottlenecks / issues
4. Refactor existing code to adapt to new found understanding
5. Repeat until the game can be considered complete

What kind of game?

I have always been an avid fan of Elite Dangerous and space games in general (such as KSP). Inspired by Elite Dangerous Arena, I will be creating a 2D space game, where the aim is to compete in some sort of Deathmatch / Team deathmatch / CTF setup.

This type of game is also interesting as it can involve a simple physics model - namely frictionless movement within a vacuum without gravity, at least initially. It could be interesting to involve elements such as gravitational pulls of objects within the arena, which also affect projectiles. Areas of concern in terms of design would include edges of maps - should they wrap around? Or somehow penalise players who exit the arena bounds?

Conclusion

I do not expect progress to be fast, especially given my packed schedule, but it should be a great learning experience, both for myself and any of my readers who have never delved into games development before, especially if they are coming from a more standard/corporate software development background rather than a pure game development background.

Any and all code I write will be made open-source, under the GPLv3 licence at https://github.com/simonamdev/cabin-fever

Next Entry

• 1 - Initial Setup