Dealing with Rapid Changes as a Game Engineer
Dealing With Rapid Changes as a Game Engineer
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?
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.
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!
The Importance of Documentation
Have you ever looked at code you’ve written and wondered: “Why did I write it this way?” You’re not alone. We can only remember so many things at once, which is why it’s also important to document your own decisions.
A myriad of decisions will be taken throughout the development of a feature –both unilaterally and collectively following discussion. These discussions can occur online, e.g. over Slack, or in person. While analog conversations can sometimes work better, there’s no “message history” to rely on so you should write down any new takeaways, however small.
These decision points should be fed back into the design document so it continues to stay up-to-date as the source of truth for the feature. Anytime you have a question about the feature, the design document should be the first thing you check!
Managing Complexity and Dealing with Changes
Maybe you’ve noticed I haven’t even gone into any software engineering-specific tips yet. That’s the message: Taking the time to plan together and communicate effectively will itself eliminate all the biggest possible pitfalls during implementation.
Of course, there will likely still be issues that slip through the cracks. So, what are some things you can do as an engineer to cut down the number of changes you’ll have to make to code that’s already in development?
- Plan! So, the feature has been kicked off. Now you should be thinking about the code implementation plan. Break the feature down into smaller coding tasks and make sure that the timeline remains realistic. Document this stage-by-stage plan and (again) share it with others to make sure it’s a good one. Having another engineer take a second look at it is also a good idea.
- Code flexibly! If the designers have asked that the feature be able to handle 3 types of customizations, why stop there? If it’s not much more trouble to make it work with any number of customizations, you should do that. Your future self may thank you.
- Refactor and simplify your code! There’s never a good time to do this, but once in a while the engineers should think about which parts of the codebase are confusing or difficult to use, and spend some time to improve things.
- Test! Adopting a TDD will help make sure that any modifications to the code will not break existing features, and will also help you track which changes caused the test failures.
- Push back against unrealistic timelines! Never be afraid to ask to scale things back if the feature is particularly complex or wades into unknown territory. At the very least, it’s your duty to inform everyone of the risks involved in going with the current timeline. A side note: As a project’s complexity grows, the time taken to implement a feature will slowly increase as there are more interconnected systems to think about.
At the end of the day, dealing with unforeseen changes is always painful, but you can take steps to make sure it doesn’t have to be excruciating.
Conclusion
By communicating early, often, and as a team, you will only improve the quality of your project. One final thing I’d like to point out is that everything is a tradeoff. Spending more time to plan and prepare will usually pay off in the future, but you don’t always have the luxury of time. Don’t be dogmatic about your process as a team. React and adjust along the way. Strike a balance — and while the iron’s hot!
Dealing with Rapid Changes as a Game Engineer was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
