Game development considerations

It’s been a while since the last article I published. I was busy wrapping up a project I’m working on currently, which, as most game development projects do, turned out to require a little more attention than was planned. The project I was working on was my first porting gig. As can be expected, this exposed me to a bunch of problems I never considered before. One of the tasks I was assigned was writing up a radial menu control, and that’s what I would like to write about today. Radial menu At its core, a radial menu is nothing more than a UI control that consists of a circular items layout and an optional direction indicator. Seems simple enough, right? Well, as it often is with simple concepts, there is a ton of things that go into writing a radial control that is responsive, easy to use and flexible enough. Initial guidelines Let’s start by quickly going over some of the initial discussions I had with people who had done this sort of work before. It’s very important to go thr...

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

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