Dealing With Rapid Changes as a Game Engineer
By: Andrew Ching
Tags: Communication, Teamwork, Planning, Coding, Game Development

Imagine this: You and your colleagues have looked at the design for a new feature for your game, and you, the engineer, have given a time estimate of a few days since the feature looks simple. Of course, nothing is ever that simple, and as modifications to the original design start to come in, you’re left scrambling to incorporate last-minute changes into your code. In the end, what was supposed to be a magnificent skyscraper is instead a log cabin held together by duct tape. The foundation below still looks fantastic, but now it may never see the light of day.

“The best laid plans of mice and men oft go awry”

How can you avoid this?

Don’t let your code look like this! (Photo by Zaimful on Pixabay)

The Importance of Process & Communication

Let’s rewind to right after the feature was mooted, when you and your colleagues had just begun to discuss it.

At Mighty Bear Games, the game designers start things off by writing a preliminary design document for the feature. This document will serve as the main reference for the conversations between disciplines on the implementation of the feature.

Notice I said conversations. There should be a lot of back-and-forth communication between the designers, artists, UI, and engineers on deciding what’s best for the feature and the players. Sometimes, this means simplifying the feature to make things easier to understand for the players; other times, it might be about making it easier for the team to implement, at least for the first version of the feature. At Mighty Bear these conversations involve everyone, in order to eliminate as many blind spots at this stage as we can — and we haven’t even started any of the implementation yet! The earlier the team starts talking and reasoning about the details of a feature, the better the chances of that feature turning out great.

Photo by Scott Graham on Unsplash

After the design document has undergone multiple revisions, we have one final kickoff meeting where we go through the document together before beginning work on the implementation. This kickoff serves to align everyone’s expectations for the feature as well as iron out any more kinks that might have arisen.

The conversation doesn’t just end once people start to go off and do their own thing. Often, the devil is in the detail, and some issues will surface as you dive into development. Further decisions will have to be made here, and not just by you. It’s therefore important to continue to communicate the problems you’re facing so that everyone is aware of what’s going on and can react accordingly. Additionally, while it’s intuitive to only involve those who are needed (e.g. the designers for a design issue, or artists for a problem with the model setup), keep the conversation public so that others have a chance to chime in if they have an insight. Sometimes, contributions from other disciplines may surprise you.

Lastly, don’t be afraid to ask questions, even if you think you may look silly. Better to be a fool now than later. Just kidding — there are really no bad questions as, above all, there’s no room for uncertainty during this process. Ask away!