Agile Development: Towers, creeps, and many beeps

One could take a quick glance on GitHub issues and pull requests and immediately rule out the possibility of our group using a non-agile development process. Why? Well first of all, let me make it clear that it is almost impossible for a decent game to be developed with the traditional waterfall cycle.

Video game design requires originality, innovation, and adaptation. Change is good, and in fact the design phase of a good video game demands change. Change leads to diversity and diversity is the true seed of originality.

Agile methods in the video game industry allows developers and designers to be on pace with each other, allowing room for tweaking for the better or for the worse. Having experience scripting quests for MMORPG servers, the designers, storyboard writers, artists and testers have a whole arsenal of ideas and improvements every step of the way. Some ideas are great, some are on the other hand, downright terrible from a developer's perspective, but the key concept is that change can happen and it will happen.

In a traditional sturdy method of software development such as the waterfall lifecycle, developers and designers would be forced to agree upon one and only one implementation strategy by the end of the design phase. Risks which are unforeseen during this phase will result in massive setbacks and redesign phases which cost a lot of time (or money). In addition, many designers are not developers, and vice versa. The game mechanics and concept envisioned by the designer may be completely different from the resulting outcome of implementation by the developers. Of course, such problems can be avoided by clear software documentation which is why other software projects may yield great success with traditional waterfall methods.Video games, however, are a different story. They are designed for fun, and as I have discussed in previous blog posts, fun can neither be quantified nor predicted. Fun is hit and miss. Or in nerd terms, the realm of fun is to be explored in a stochastic domain and thus determining whether a video game is fun via the design step alone is like attempting to solve an NP-hard problem. This, in my opinion is the main reason why video games (fun ones) simply cannot be created through sturdy methods.

Change is constantly required as the developers need to communicate with designers, receive feedback constantly and determining the next direction the game should gear towards (nothing insane like changing game genres but mechanics and concept). This is why lean development is so important in video game development, it allows designers and developers to have an idea of what the product looks like and what needs to be improved. If a design flaw occurs, problems can be corrected quickly within a few iterations of the development cycle. This constant communication between the two core teams is vital to the success of the game itself. The idea of fun can be evaluated often and adjustments can be changed accordingly (it's like greedy exploit with random sampling in the search space of fun).