Game development considerations

My CD Projekt RED story, part 3 We are now 2 years into my CD Projekt RED adventure and so far, it’s been mostly smooth sailing. I got promoted to a QA Analyst position, an equivalent of a specialist position for developers. I was earning around 2600zł or $650 per month, which would sometimes go as high as 3500zł with additional crunch pay. At this point I felt fairly rewarded for my efforts and could even start planning my wedding. I also received the first bonus for my participation in the creation of both Witcher 3 expansions. This amounted to roughly 13.000zł or $4250, which was an amount of money I had a hard time wrapping my head around. I still lived in a single room in an apartment I shared with other people, but at this point it was mostly my own choice. I’ve had my own wedding on the horizon so I needed every coin I could save for the occasion. Getting out of QA It was during that time that I decided I want to transition away from doing QA work. I approached the audio te...

There are many courses and materials available about the object oriented programming (OOP). Although many of them are very solid and accurate, in my opinion most of them fail to catch the meritum of this programming paradigm. As opposed to other materials, which focus mainly on object relationships, like ‘has-a’ or ‘is-a’, or go into great lengths about code encapsulation, I would like to offer a learning perspective focusing on polymorphism. Once we establish a solid understanding of polymorphism, we’ll see how this paradigm can also be applied to code-free designs and what benefits it can have. This article is a little bit more code-heavy, but hopefully my descriptions and explanations will help you go through it even if code is not your thing. The common knowledge When we look at courses explaining what OOP is, they usually put the most emphasis on the structural framework that the paradigm is built upon. We learn about classes that can be instantiated to create objects. We’r...

At one point, I was tasked to create a system, that would allow sound designers to stop currently playing sound or sounds whenever another sound is triggered. Since our engine already supported custom sound properties, I knew the most appropriate way to expose this functionality would be to introduce a new list property to each sound entry in the sound config. Thus, sound designers could tweak the functionality as they saw fit using the flow they were accustomed to already. So far, so good. However, it was the next step I wanted to take when my reasoning stood against the open-closed principle, so let’s explore that case together and see what lessons can be learned from my mistake. One disclaimer before we dive in. Since most of my career working with sound involved using Audiokinetic’s Wwise audio middleware, I will refer to each sound as a sound event throughout the article. A sound event in Wwise is a call the middleware expects to receive from the game engine whenever an acti...

One condition to break it all Let’s assume we’re working on a quest. Throughout it, we trigger a gameplay event whenever a certain condition is met. To make it less abstract, let’s say we’re registering an in-game clue as found whenever the player character is 1 meter away from it. Since the scene investigation is one of the core gameplay loop mechanics, we do this a lot, in many different places. After many months of work, we ask first playtesters for feedback, and the most common point raised in the surveys is that finding clues just doesn’t feel right. The required distance between the PC and a clue is too short, forcing players to squeeze into some weird nooks and crannies, exposing a multitude of locomotion issues that would be too costly to fix at this point. The decision is made to increase the clue-registering distance, because surely it’s simpler and cheaper to make small numerical tweaks, than it is to rework all the environments or to fix the animations system that’s ...

As many programmers like to joke, there is nothing worse than reading somebody else’s code. From my experience, debugging somebody else’s visual scripts or designs can be as daring an experience, if not worse at times. Many developers feel at home only within the confines of their own designs. Whenever we have to pick up unfinished work of any of our peers, or debug the bugs in their designs, it very often means we’ll have to work extremely hard to wrap our heads around those unknown environments. Lacking the mental shortcuts the original author had in mind more often than not leads to lots of frustration, experimentation and trial-and-error guesswork development. If only each one of us would invest the time to make our work more readable to others… In programming, most of our daily work is dealing on somebody else’s codebase. Although this too can be quite a daring experience at times, it generally doesn’t have as much of a negative impact on our morale and sanity. In today’s artic...