Game development considerations

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