This in no way means my intentions are to limit the project from day one- rejecting the many ideas the team may have for the sake of a smaller and possibly easier game. In fact, the many ideas are precisely the reason why I would prefer to set limits early. I think the team would be better off if we fail early and often. If we’re able to do so without wasting too many valuable resources we will be better off. For example, if members of the art team have a particular idea that they feel would really push the “look and feel” of the game we are building, it would serve us best if we try out the idea as early in development as possible. The artist could compile some concepts and present them to the team. We would then make a decision early on if the ideas were usable. This is a good way to encourage communication and respect among the team as well. Everyone’s ideas will be heard and tried then as a team we will decide what stays and what is cut.
This style I’ve learned is called agile development. This excerpt from the supplied handout Development Lifecycle sums up it’s meaning.
Agile development is characterized by modularity and a frequent review of the state of the project, hence giving the team "agility" to easily and quickly change direction if something isn't working. At the same time, it provides product owners with the information they need and the ability to see progress as it's being made. (Slyke, 2009, para. 20).
“Frequent review of the state of the project” stands out most to me. Frequent review insinuates that it happens often, the earlier the better.
Setting limits to the scope early includes: building prototypes of an idea or set of ideas and testing them to see if they fit. If they work, we keep it and move on to the next. If they don’t we scrap it and move on. This will also ensure that the team’s time and resources and being spent efficiently. For instance, a certain prototype is built for a level and the team feels that it’s a good fit, but also thinks it should be tweaked a bit so the gameplay matches the look. We can move on from that point, integrating the new elements and iterating the previous steps to ensure it all works together. I think this is a lot less of a gamble than building large portions of a game with hundreds of lines of code; hundreds of hours spent on concept art, etc before finally playtesting it and finding that none of it helps to create the product with the highest quality. That would mean back to square one.
I am completely aware that many teams may choose to focus on scope towards the end of development. I am also aware that this may be their preference. However, I feel that in the best interest of the team and the project, making use of agile development is the best way to ensure the maximum game quality is attained and that is to set limitations early.
GamerBloodline was here.
Slyke, B.V (2009). How a Game Gets Made: A Game's Journey from Concept to Store Shelves. Retrieved on 7/5/2011 from http://www.gamecareerguide.com/features/745/features/745/how_a_game_gets_made_a_games_.php
Schell, J (2008). The Art of Game Design: A Book of Lenses. Massachusetts: Morgan Kaufmann Publishers.
Waters, K (2007). All About Agile: 10 Key Principles of Agile Development. Retrieved on 7/5/2011 from http://www.allaboutagile.com/10-key-principles-of-agile-software-development/
Waters, K (2007). All About Agile. Retrieved on 7/5/2011 from http://www.allaboutagile.com/agile-principle-10-no-place-for-snipers/