The Aware Game Engineer 0
Introduction - what game development is about?
🗓️
I can't count the hours I've wasted on building useless internal tools, endless refactors, and micro-optimizing code that was already 'good enough'. At first glance, these tasks feel like 'Must-Haves', but in reality, they lead to burning budgets, delayed releases, and crunch. "The Aware Game Engineer" is a deep-dive series on how to stop wasting budget on things players don't care about. I'm gonna share the mistakes I made and explain where they came from, so you can save time and your production budget. Each article is a tool you can use to increase the production speed of your game.
1. Why do we care?
Computer games are just a new generation of toy products. Toys were invented to play, just as we do with games. The act of playing means arousing emotions. A sense of fun, chill, thrill, nostalgia, amazement, or fear is the real reason we interact with computer games. We look for adventure, temporarily escaping from reality or just fulfilling some power fantasy.
The static scene comes from the No Rest for the Wicked game I developed with Moon Studios. It illustrates a cozy Sacrament house interior and a resting, wonder-filled Cerim who warms himself by the fireplace. The scene, despite being static, is playful (arouses emotions). Personally, it brings me back to that one Christmas Eve when I was just lying on a couch, waiting for dinner to end so I could unpack gifts and wonder what the rest of my life would look like. Pure nostalgia.
I will take this thought further: if the toy is good, it will sell just as well. The developer's goal is to produce the best possible toy in the shortest possible period of time. Anything that pushes us away from that goal is bad.
2. What does being an Aware Game Engineer mean?
At the beginning was chaos ... or a freshly opened editor.
Game development is complex. Perfectly executed game production doesn’t exist. Even the most experienced developer makes mistakes. That’s the part of the process. Consciously choosing the right mistakes to make is the thing.
Often, our good intentions lead us in a not-so-profitable way. Here are some of the most common mistakes I see during development:
Spending a couple of days optimizing wrongly recognized bottlenecks
Over-engineering some low-dependency systems.
Deciding to refactor a system without any serious reason.
Spending months implementing useless internal tools.
Coming up with a feature that isn't a must-have yet, but it will be one day. It will, trust me.
Allowing the use of AI in the wrong places so it becomes a tech-debt factory.
Giving the design team too much control over systems.
… The list can keep going.
3. Wanderer Equipment
In this series, we're gonna dive deeper into specific development problems that occurred during the production of large-scale live products. We're gonna consider whether they must have happened and what price production paid for them.
Each article of the series provides a specific solution and practical tools for usually abstract problems.
This series is an attempt to pack the experience and observations I've collected over the last 8 years and organize them into one cohesive toolkit.
