Now we arrive at the final piece of what I see as a grand solvable puzzle that is “What’s gone wrong with video games?” This is closely related to my last post about internal and external testing of games with Alphas and Betas. The development approach that a given team uses will adversely affect the usefulness of testing. The reason I think many game companies choose to simply launch broken and buggy games is simple: they are developing the game in a non-agile environment. I will, as an admitted software development laymen, attempt to lay out why agile development is the way forward for game companies large or small, and would work in tandem with a more robust and transparent approach to testing.
What is agile development?
Basically agile development is a philosophy and approach to software development that more and more companies are adopting. Traditional, or waterfall development, works very hard to have efficient vision transfer prior to creating anything. Imagine you want an app developed and you meet with a team who asks you lots of questions about what the app should do. Once they feel they have an adequate vision for what you want, they get to work, and eventually give you your first deliverable. They’ve now spent hundreds of hours building systems that talk to other systems and functions that call other functions and so forth. Setting aside the debate over whether this is the best approach for software stability and if they used test driven development to ensure the app actually works… Without fail most people will look at the delivered software and say, “It’s not quite what I had in mind, can you make these one hundred changes?” This is when developers pull their hair out, grind their teeth, manage a humble smile, and say, “Sure, can you pay us for the 100 hours we already worked?” Now begins the wonderfully frustrating tango between the unsatisfied customer and the irritated development staff, trying to find out where they went wrong and how they can put the humpty dumpty app back together again. Those changes from the customer are going to literally affect everything. The developers, in some sense, have to start over. This is where the term waterfall development comes from, because you build the entire thing, and then like a waterfall you just sort of dump all the work out at once.
If you are reading this and have almost no knowledge about software development, you are probably already seeing where this is going. Agile development allows for constant tweaking and fixing as the software is built. You take the MVP (Minimum Viable Product), and you build just that. You do this by asking, “What, at its core, do you need this software to do? What will be its most basic and necessary function?” Obviously this gets more complicated with a video game because just moving around in a 3D world requires an entire game engine to be built. However, the principle still applies. If you build in small pieces, and continue to iterate and test, you will end up with an incredibly stable and solid piece of software. Something else that happens when you do this is your developers become more adept at interacting with the systems and code within the game. This means that unforeseen problems or bugs that emerge down the road can be more quickly and efficiently addressed because your developers have already grown accustomed to getting down into the trenches of the games programming. When waterfall development is the approach, you end up with a game that is drug along kicking and screaming, scattering bugs and glitches throughout the entire game world. Some of the principles of agile development may need broken down and applied differently depending on the department or division of labor within the development team. But if a gaming company wants to survive the ever changing and fast pace technological world that they exist in, they must be able to adapt and improve their games instead of continuing to spit out games that make developers look sloppy (which they aren’t) and the gaming companies look incompetent (which they aren’t).
If you read nothing else, read this…
Adopting agile development as your philosophy and approach is not the silver bullet. None of the things I’ve written about are the golden ticket to a better developed, more polished, top quality game. All of them need to coexist in the same space and feed off one another. You need a sharp focus and priority placed on fun instead of pitting the game against the user to squeeze more money out of them. Player behavior needs to be considered and properly incentivized to ensure exploits, cheating, and negative experiences don’t continue to be the norm. Games need to be built in a way that makes adding good content easy and more content needs to be delivered in the initial launch. Creativity needs to be fostered and encouraged, with deadlines and corporate demands set on a shelf of understanding so games can be built at a more sensible pace. More testing and transparency with gamers will help the quality of games increase and the empowerment and connectedness of players and developers rise as well. And lastly, the development needs to under-gird and touch on all of these things. Agile development will allow for creative ideas to be tested out and implemented, it will make space for testing and polishing prior to launch, it will enable creative teams to craft more innovative and high quality content, it will fuel the vision and fun of the game, and it will allow for an adaptive approach to change the shape of the game as needed to improve player behavior. I’m not the expert, I’m just a guy with ideas, so I would love to hear feedback, criticism, or ideas from other people in the gaming community.
Agree, disagree, or have ideas of your own? Share in the comments below. If you enjoyed this entry please share it on facebook and twitter.