Part 6: Why agile is great, and where we failed
|
The second day of GGC has just ended and I need to ventilate regarding the biggest failure of this project. Failing to work in an agile environment. What is great with working agile is that you during sprint reviews take a step back after adding a feature, evaluating its design and intent. As we started working on Rune Mages this was indeed planned. However, something happened early on in the project which today can be seen in the game. Most of the game’s systems were added slowly but securely. The programmers explained that if the backend of the game’s systems would be well written, changes to game balance and what not would be much easier later in the project. I understand this philosophy, but I also think it is what made the final product subpar. What happened was that after every week, some systems were not implemented because of their complex and well made structure. The implemented systems could be tested, but these systems did not result in any meaningful gameplay to test. At GGC the game suffers from a huge lack of feedback, UX issues and AI hard crashes. If the game would have been extensively tested every week I think that these issues could have been resolved.
Agile is primarily to test design and if it works as intended. In our case, agile would not only have helped us discover bugs, but it would also have helped us finding the ”fun” in the game. What happened in this project is that we built the game with the waterfall model, where pre-production goes into production which then produces a result. This is hit and miss, as it is difficult to predict how the user will play with the design. I believe we were comfortable with our pre production and thus stuck with it. A big mistake in my opinion. With agile we could have discovered a new area of play that has not been seen before. As it stands, the game is conceived by some users as generic, non unique. Thus, just as unsafe sex, always test!
 |