The humble beginnings

Hello, world!

My name is Adrian and I’ve worked on games for the past 4 years. I broke into gamedev by composing music for indies while simultaneously doing QA at QLOC studio in Warsaw, Poland. After 9 months there, I got a job at CD Projekt RED, where at first I continued my QA career, but then moved on to audio programming through embedded audio QA duties and some technical sound design and implementation assistance. I've recently parted with RED and joined an enthusiastic team of Crunching Koalas where I code in C++.
Over these past 3 years I've subjected myself to a pretty hardcore wholistic learning routine which blurred the lines between various different fields of software development for me. Although my primary education is in music performance and composition, I've invested a lot of personal time and resources in learning how to code. Throughout my career at RED, I dubbed in JavaScript, Python, C# and finally C++, but I've also spent a lot of time on design related tasks, including scripting (both visual and code), technical sound implementation, quest, animation and behavior graphs debugging and asset management. In this blog I intend to write about how it all went for me, including my programming self-education experience, my being thrown into deep waters of RED Editor with no prior experience with any other game engine, and how my dreams of working on the most well known games have been confronted with a surprising reality.

Design like a programmer

I intend to start this blog off with a series of articles called “Design like a programmer”.  This series is aimed mostly at designers working on games. If you are a designer, be it of quest, game, gameplay, progression or other aspects of a game, I will share with you some principles that should help you improve your design process and make your designs easier to maintain and/or expand in the future. If you are not a designer, don’t be discouraged from following, as I believe some of the ideas and observations I’m going to share could easily be applied to many other fields of game development.
Throughout the “Design like a programmer” series I will explore numerous principles that programmers learn both at university and at work and try to explain them using visual scripting, code samples and real life examples. Each code sample I’ll use will be clearly described so that you could follow along even if you don’t code yourself.
Let me explain a bit more what problems this first series of articles will tackle and why I’ve chosen to call it “Design like a programmer”.
When the field of game development had started to become an actual business, most of the developers where programmers. Even though the programming languages of yore were quite different from the standards we know today, certain programming principles have been established back then and have not changed since. This is very well reflected by programming literature, which core canon entries still comprise of publications published 10 or 15 years ago. As gamedev has started growing and the complexity of games increased, more specialized positions have started to appear. Artists, sound designers, UX and UI designers, gameplay, RPG and progression designers - all of them take care of very specific aspects of a game. This is understandable considering the scale of the games we are used to these days, but it also brings additional problems that can take heavy toll on a game’s production cycle and final quality.
Since the audio is my main field of expertise, let me explain further using sound design as an example. Sound designers’ skill set comprises mostly of authoring sound effects using self-recorded or library assets, implementing them into the game and mixing them before release. Those tasks demand that a sound designer knows about:

• the physics of sound propagation
• recording gear and how to use it effectively
• using digital audio workstations and an endless array of sound processing effects
• the workflow of audio implementation in the engine they use
• the audio middleware they use

Each of the points listed above could be focused on solely to build an entire career around it. This is in fact what happens in bigger audio teams, where some people take care of foley recordings, some of ambience and/or field recording, some of technical implementation and so on. Unfortunately, this very often leads to many of those highly specialized individuals being unaware of what place does their work fit in the huge jigsaw of the game they are building. This means they often perform their tasks without understanding the context, which can in turn place additional burden of work on anybody else that will have to process the assets on their way to the final build. But what does any of this have to do with thinking like a programmer or game and quest design? Glad you asked!
Both my personal observations and the numerous discussions I’ve had with fellow developers seem to suggest, that this specialization has lead to people being able to pursue any of those highly specialized careers without having the skills that were considered basic and common knowledge so many years ago. There are many people who have started their careers in the field of design (or transitioned to design from QA), and many more dreaming of doing so. Many of those people have never coded in their lives, which means they are not and likely will never become aware of certain principles and design approaches their colleagues from the code department have learnt. And that’s a shame, because there are numerous tips coders have passed from one to another that eventually became a standard that drastically improves not only the quality of code, but more importantly addresses many of the hardships associated with modern game development.
It is my opinion that among numerous causes of troubled game development nowadays, the fact that those solid principles that used to be universally known all these years ago but are not that common anymore is somewhere at the top of the list.
Game development is a very iterative process, which very often leads to tough crunch and lots of work being thrown away multiple times throughout a development cycle of a game. Luckily, iteration is something that’s basically synonymous with programming and there are numerous programming principles that can easily be applied to other fields of game development to make the process less painful. This series of articles will explore those principles in detail one at a time and hopefully show how they can be applied in other fields.
I hope that as you follow along, you will get ideas on how your work could be made easier to maintain and expand. As we explore various different maintainability and expandability principles together, I hope that the iterative process of game development will become easier to handle and allow you to spend your crunch time at home, crunching together on tasty food with your family and friends.

--- Adrian