Saturday, July 17, 2010

R&D Optimization : Development Cycle & Rapid Prototyping

Today we had a very productive meeting with the Quebarium crew which consist of myself (@frederictessier), @fcycles and @tronicsynth.  And one of the main topic of our talking was about ways to optimize our R&D to develop more quickly and get something completed.  The main presentation we had and which ill be discussing in further detail below was about to rethink about our Development Cycle and do it via a Rapid Prototyping philosophy.

Why did we had to rethink our Development Cycle? Well as @fcycles so elegantly described in his slide : FRUSTRATION


Oh, you got scared by those French words, don't worry ill be translating our slides that explain our world domination plans which start first with...

Sorry to disappoint you, no world domination plan here, but the explanation of the reasons that have raise our personal frustration.

The first and most important point that is a fact for us :

Many ideas & interests = n projects, 0 release

Sadly this is the sad truth for us, if you look closely in the slide above the screen shots are from different game we've work on until various stage and that never got completed :-( (maybe we should really listen to Chris Hecker).

Which is often the results of one of the following or a combination of them :
  • Lack of time
  • Hardware that change quickly (looking at you iPhone/iPod touch)
  • Project too ambitious?
  • Idealist?
  • New ideas pushes the old ones
How can we resolve this problems? Well here is how we think we should change our Development Cycle that will fit with our vision and philosophy we have about our team (other developer might have different view and feel free to share it in the comment section).  Also for another take about rapid prototyping I would recommend that you also watch the presentation that @owengoss from Streaming Colour Studios did at 360iDev which is available here.


This new Development Cycle is the way we envision it and it will be in 2 main phases : Prototyping phase & Development phase.

PROTOTYPING

This would be one of most important phase as it is here that you will find out if your game is going to be fun, doable with your limited resources (time, budget, peoples), etc... and they are one important keyword to remember here and it is RAPID, since you need to know as soon as possible if its going to work or not.  If you spend months and months to work on a prototype and if in the end it doesn't work out, well you would had spent considerable amount of time and still need to redo it again.  And don't be sad if you throw away that prototype and make a new one, you will have only spent hopefully not too much energy on it and be ready to make a new one, this is an iterative phase after all.  The goal here is to go from an idea to a working prototype that will help set up the development phase.

Now we can divide that main phase in the following sub-phases :
  • Idea : This will be the starting point for everything that will follow, but here you shouldn't got too much in details, that means you just keep it simple with one sentence that tell your idea.  Think of it on how you could tell your family/friends in just one short sentence a game that sounds fun.  Example : When the cat is away the mice are dancing.
  • Description of the game : Now you can you go with a bit more detail in here, that will describe the core of the game (the mechanics and other elements), but once again try to keep it simple at this is still for a prototype and not the final development in which we will refine those grain of details.
  • Pre-prototyping : Before making the actual prototype it might still be useful/helpful to just verify some of the concept/ideas in a very simple form by just doing it on a paper, spreadsheet or anything that will let you do them very quickly.  This should help you define in which direction you should take the prototype.
  • Prototyping : Now its time to build the actual prototyping you have been waiting for, but remember one of the key element before reaching this step is to have a simple but efficient description of the core of the game.
 
Also they are still some little thing you should do before starting to work on the prototype, which might or not apply to you depending if you work in a team or not.  In our case since we are a 3 persons team we allocated 10% of our time for presenting the description of the core of the game & ideas to the other member of the team so they will know what to expect and what they will need to do (code, sounds, graphics, etc...).  Then its time to work on the different aspects of the game, whether it is the sketches (yes the graphics will be be kept simple, but not just square and colours, and in our case it won't be programmer arts... but musician arts for better or worst ;-p), the level design, game interaction, AI, physics, etc... This going to represent about 80% of the time spent on the prototyping, as once again since we are a team, we allocated another 10% for doing integration of the different parts together and have a complete prototype.
    • Validating the prototype : You've got a working prototype?  Now it's time to sit down and play it, this will be one of the most important time as this will determine the faith of your prototype.  Does it go to the next phase which is the Development or does it go back to another iteration of the prototype?  So you shouldn't rush this phase as it will have serious impact down the line.
    One of the key point to remember when validating the prototype is that is serve to validate the concept in one of the following ways :
      • Is  it doable?
      • Seems interesting?
      • What are its weakness, anything missing?
      • Is it the graphic style we have in mind?
    Its also the time to verify if they are some crucial elements that need to be rectify before going to the next phase that will be the most time consuming and where you will do most of the hard work.  Better do it right, so if in doubt maybe it might be wise to redo another iteration of the prototype. 
      You are satisfy with the prototype that you have in your hand? Then you are ready to pass to the next phase which is the Development itself.

      DEVELOPMENT

      The second main phase of this cycle where you are going to spend the bulk of your time, hopefully that will last just a few months, not years...  But as noted in our slide below, this phase is still currently in "beta" in a sense its still under development (oh the recursivity ;-)).  So we are still pondering what are the best way to approach this, as we are developing for several platforms and each have their own ways of doing thing (languages, SDK, hardware, etc...).  You could also bring the code that was done during the prototype into this phase, but I will leave it as open for debate.


      But they are still some sub-phases that should be followed once again in an iterative manner which are as follows :

      • Game description : You might think why I am not coding yet (be patient just a little longer) and that this is a repetition of the same sub-phase in the prototyping.  And its true, but this time you're finalizing what has been decided/written in the previous phase.  You're adding more precision to the game specification and filling the blanks that was left intentionally since it wasn't the actual core mechanics that needed to be tested in the prototyping phase.
      • Development : Yes its finally the time for some coding, coding and even more coding!  Be ready to spend long hours in your favorite IDE typing in the C, C++, Objective C or even Assembly language if you are hardcore.  Eventually what ratio we would like to achieve (hopeful dream) is to have a 75% of the time spent on designing audio+graphics and 25% in actual coding.  Is that even possible?  Well I would like to discuss further about this topic, but this will be for another time... still need to keep some trade secret (our secret sauce in the making as they say) can we? ;-p
      • Validating the game : Is it breakable? Is everything balance well? Testing, yes the most dreaded phase for developers, but still an important one as you want to make sure everything in the game just work.  And what do we do when we found out something is not right, well its time to do another iteration in the development and come here again to validate if it has solve the problems or not.  Once you think that you have a build of the game stable enough and that the game play & other elements are there, then its time to think about doing a beta.
      • Availability of beta version : You now have something that you aren't ashamed to show to the public (well a restricted public as normally you don't really want to manage an open beta and in certain case its not even possible).  Choosing the right beta tester will be very important, as you will want people that you can give you some objective and constructive comments which can help to improve the game or if you didn't catch them in the previous phase some bugs.
      • Beta tester comment : Take good notes as this probably going to be the last step that will bring your beta to an actual release.  This is the time where you collect the feedback from the people to whom you have sent the beta, but beware that it wont be easy to accept every beta tester comment, so try to repeat to yourself "don't take it too personally".  This is hard, but every comments deserved to be noted, as often they are some good ideas or even thing you knew yourself but tried to forget them.  If the suggestions are something that would bring some major changes those should be only considered for future update and/or another project.  If they are some bugs reported then you should go back to development phase to correct them, as you don't want to ship bugged game (maybe they are some case that it will be unfixable and/or not reproducible, but it should be bug free as much as possible).  If everything is good well you have reach the end of the Development Cycle and are ready for a release!

      Now since the development is over and that you have a release version (which has been ship and ready for distribution), it will be the time to think for your next project... What did you expect? This is not your last project ;-).  Yes this is a recursive function they are no way around it, so let go find more games ideas!

      1 comment:

      1. Nice read. Thanks

        Phuong - Enlevel Studio

        ReplyDelete