Outside Video Games: Agile vs Waterfall Development

Software CodeNow 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.

Advertisements

7 thoughts on “Outside Video Games: Agile vs Waterfall Development

  1. Pingback: What’s gone wrong with video games? | Say No To Rage

  2. This actually sounds like a fantastic development model coming from someone who aspires to get into the game development scene. However, I think the biggest problem with the disconnect between devs and investors is this (looking at you, Nintendo): people with money don’t want to hear the word ‘risk’. The idea of having to invest further or even lose the investment entirely is paralyzing, so they set premature dates and force devs to design in a doubly hostile environment – where devs are the redshirts, and the investors and frustrated gamers dog pile them into oblivion. If gaming is ever going to truly recover, investors and big companies need to start realizing that like with any form of art, risk is almost literally the name of the game. Nothing is for sure, and I feel like definitely the first step is investors letting up on their iron grip on the devs. Thry need to understand that it takes time (which you touched on) to make a good game, and hopefully it will give them time to see that gamers are very loyal customers that you don’t need to bully and deceive them to earn their money.

    Like

  3. We need some persuasive people to talk about risk to the guys throwing all the money in, they shouldn’t have gone to video games if they wanted safe money granted but still.

    Like

    • I totally agree! I’m hoping some of my entries this coming week about risk and AAA titles not generating very much profit will put me on the radar of some people that need to hear what I have to say.

      Like

  4. Pingback: AAA Video Games Aren’t Profitable and How to Change That | Say No To Rage

  5. Pingback: | Video games suck, and players are part of the problem

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s