Hello fellow iDevelopers. This week-end the crew of Quebarium had our meeting and we had some lengthy discussion of what we think should be our new development cycle that will be more oriented toward rapid prototyping. You can read about it on our blog here : http://www.quebarium.com/2010/07/r-optimization-development-cycle-rapid.html I was wondering about the rest of you how do you approach your development cycle for developing a new game. Do you go with a more traditional approach like waterfall or do it more in agile/iterative approach? The problems for us is that we were more using the traditional ways, but it always become heavy/long and in the end we don't bring our project to fruition :-(. Which has often bring us a lot of frustration. We hope by first doing a very quick prototyping phase, that we can nail the core of the game we want to do, then only once we have a successful prototype that we will go into the development phase. Which we will also be split in smaller chunk/iteration so we can get something completed and not be discourage. I know many of us in here as being indie, are sometime doing this on the side in the evening/week-end (well its for us, as we have regular jobs to pay for our living for now) so we think its important to improve our development cycle and not get stuck in those never ending project :-(. Looking forward for your comments/opinions.
I had some thoughts about that as well for my upcoming project (i'm an indie and sort of newbie too). First, i ask myself, what's going to make my game special, where do i want to leave the paths of known sucesfull concepts? That's where i'm going to focus on while prototyping. Oh, first ask yourself, which games similiar to the one we're going to make or in which games are concept used similiar to the ones we're planing to use. Then go and play a couple of those games, and then discuss what you liked, what could be better etc. If they have community forums go and read there, you'll learn alot and avoid a lot of mistakes. For actual developing and prototyping i plan the following: -Programming a rough version of special key elements, test them, are they fun? -Engine/Infrastructure: parallel to the task above i'm planing to work on the engine/infrastructure i'm going to need for my game, starting with the most general purpose code. That's work that will be usefull later anyway. I can either use the engine as a basis for a rough prototype or for the full version. From my point of view this has the advantage that i'll get familiar with things and even if i decide to stop the project because the game is no fun, i still get a lot of experience, usable code out of it. -> no total frustration -> next prototype game is programmed faster. Don't forget to show your prototyp to some people outside, some actual gamers of your target group, that helps alot. Of course there are a lot of books, ideas and more professional approaches out there, but for myself as an indie this seems the best way to go for a start. If you're planing to develop for different plattforms this might be harder as several sdk's etc are used. My suggestion here is: one plattform for the start. If you have made 10 sucesfull ios games then it's time to look for android.
Thanks for posting. Always interesting to read about other developer's processes. I've fallen into the release early, release often philosophy. The problem is the consumers essentially become testers. But the App Store being what it is, has a lot of devs doing continued updates to their apps from user feedback so it might not be so bad after all. Even Super Monkey Ball from the Post-Mortem thread admits that they released an unfinished game, but wanted to get it in front of players ASAP instead of spending a few more months finishing it up.
We are applying the RAD methodology to our current dev. cycle. As a small team with limited resources, I think it suites us well so far. It's important to identify eventual risks (technical, conceptual, etc.) early in the development cycle. This way you will be able to focus on your identified risks and tackle them at an early stage which makes them less prone to become showstoppers further on up the road. Keeping things simple is also a good idea. If you plan and structure your design carefully, before starting the prototyping, you can identify your "must-have" and your "nice-to-have" features. If you have a history of unreleased projects, this might be a good way to keep the project managable. You may need to kill som darlings, or at least put them to rest until you have something releasable, but I think it's a small price to pay to be able to actually finish something. You always have opportunities to patch.
