Game development considerations

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...

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 desi...