How is it possible to maintain game development at break neck speed? The answer lies in ultimate flexibility. Find out how to keep your game development in shape!
Tesla Leads The Way To Development
Elon Musk recently gave us a peek into the incredible speed of development at Tesla. On December 11th, Musk received a tweet from a Tesla user complaining about other owners parking in charging places even after they were fully charged. On December 17th, just six days later, a software release to the cars made it possible for Tesla to monitor time spent at a charging station and implement a small fee for cars overstaying their welcome. It’s a simple idea to address the issue, but the speed at which the change was made is incredible, especially for a company of Tesla’s size. The only way development can happen at this speed is by keeping the product and service provision flexible.
Game Development And Code Flexibility: The Recipe For Success
Game developers are constantly adding new functionality and rolling with product-wide changes. The faster they can iterate, the more competitive their games remain in the market. In order to move fast and enjoy a accelerated development speed, it needs to be easy for developers to understand existing code and make changes without fear of breaking things. Enter code flexibility. But creating a change resilient system is time consuming and, well… hard. Balancing the need for flexibility in game development with the need to ship quickly is a constant juggling act. In this article, we look at how the importance of flexibility changes over the lifecycle of a game, and how game developers can incorporate more flexibility into development.
There’s no point optimizing a system that never sees daylight. Every great idea starts with a hack job prototype to make sure it’s a viable idea. At the prototype stage, we aren’t aiming for flexibility - we’re building so quickly, we don’t need the ability to bring in changes later.
The most important thing about prototyping is that everyone needs to know it’s not the final result. Bob Nystrom emphasizes this in his book Game Programming Patterns: “You need to make sure the people using the throwaway code understand that even though it kind of looks like it works, it cannot be maintained and must be rewritten.” When constructing the building, we don’t take the architect’s model and continue on from there. That would be absurd.
Build quick and don’t worry too much about creating abstractions to keep flexible at the early stages. Your goal is to get to a functional place to validate design decisions. Once the project has gotten the green light, you’ll need to dispense with the throwaway code and begin again with the long term in mind.
Abstractions, Architecture and the A Game
Once we’re working with the real deal, it’s time to build in flexibility. Bob Nystrom explains why working with flexibility early helps develop better games: "It’s easier to make a fun game fast than it is to make a fast game fun. One compromise is to keep the code flexible until the design settles down and then tear out some of the abstraction later to improve your performance."
While things are up in the air, abstracting layers will pay off. You’ll be adaptable and able to make changes quickly. Because the game isn’t yet live, there’s time to optimize performance later. Instead of a finely tuned, quick game that isn’t fun to play, build to 80% completion and then refactor for speed once you’re confident in the design. No one creates the perfect game on the first try - every designer will go through experiments to determine the perfect player experience.
There’s two ways you can build in flexibility into your architecture:
Flexibility By Disposability
The ability to rip out and rewrite large chunks of code in order to achieve change. This works best early in the development process where things are up in the air.
Flexibility By Modularity
Packaging code together in modules or microservices to reduce dependencies and increase speed of understanding. This works better later in the process as certain ideas become set in stone or you can be more confident about certain elements.
Depending on how much the game continues to change design ideas, you might find one method of flexibility more suited to your style of iteration than the other.
Launch Day Lock-In
Once you’ve got actual humans gaming, your ability to rip apart architecture and make big changes greatly diminishes. Any refactoring will need to be isolated and go through multiple levels of QA (hopefully) before becoming incorporated in the live environment.
What this means is that you need to be confident in your ability to iterate post launch. While you might not have everything completely finished, a roadmap to new functionality and potential changes should be laid out. For example - imagine you launch as a single player game (think Pokemon Go) but know that in the future you want to offer multi-player networking. A change of this magnitude requires the groundwork to be completed before launch - otherwise you risk having to rebuild the product completely behind the scenes as players are using it.
Locking in the game architecture for launch will keep you moving quickly because it ensures better stability. Flexibility is less important once you’re on the market. The key is making sure the system is fault tolerant and resilient so you can continue to iterate without fear of epic downtime or bugs.
Depending on the type of games you work on, you might move onto the next big thing quickly, or stay with your current project to develop it further. If you’re continuing to iterate, it’s time to consider some code refactoring. You’re at a stable point where changes won’t be made quickly, and stability and performance is much more important. You’ve got fans, you’ve got revenue, now you need to keep them as you continue to grow. This is where you take your fun game, and make it fast. Having a clean and structured development environment also means that if you do need to build in something quickly - like a feature request from VIP gamer - you can react much faster.
Breakout essential parts into microservices (if you haven’t already) and optimize. Simplify and find your elegant solutions. Build something new and innovative. Once you’ve got the project out the door, you can devote your time and effort into creating something (close to) perfect.
Build It, Ship It, Keep It Flexible
Ongoing agile development is only possible with flexible code. In order to drive change effectively, you need to have a system that is easy to understand, unravel and update without fear of breaking everything. At the same time, knowing where you are in the development process will keep your architecture efforts focussed on the right task for the right phase. In the crazy fast world of game development, the winners will be the teams who can iterate and experiment ruthlessly.