Awakening was our first casual adventure game, and quick and dirty prototyping helped a lot in finalizing our design, art style, and tools. The project started as a one-level demo, which we built in about three weeks; it consisted of the Garden room with complete objects, subgames, and effects, and one Hidden Object scene.
Since the point of the demo was to find a publisher, this was the only time we broke the "keep things ugly" rule -- the Garden demo was very pretty, with an 80 percent level of quality and functionality when compared to the final version of Awakening. Building a complete vertical slice in a short amount of time also helped us gauge the capabilities of the team, if we could actually build the game we were pitching to make.
Once we were signed, the full development took about 10 months, with most art staying placeholder until near Alpha. We first built the entire castle in black-and-white sketches, then in about 50% art quality (as Rough Playable), and then getting to 80% in Alpha. We added the visual effects, sound, and cutscenes last.
By keeping things flexible until the last second, we were able to make changes in the last few months of development that really helped with the overall playability of the game.
Daily prototyping freed us from a lot of "asset guilt", and we scrapped or changed major parts of the game, which were all good moves. Awakening became #1 on Big Fish Games for almost three weeks, and I believe the flexibility of a quick and dirty prototyping method contributed to this success.
Granted, the whole point of a "quick and dirty" method is there are no hard and fast rules; we tweaked processes as we went along, to fit what was best for our team. If I had any generic wisdom to impart for other studios, it would be:
1) Train your team to think in terms of prototypes. Encourage them to experiment, and to accept when their ideas fail. Encourage artists to create and submit works in progress and leave perfection for when ideas are final. Train everyone to be technically proficient in tools so they can prototype and test their ideas themselves.
1) Train your publisher. Explain which parts are works in progress, and pull (absolutely pull) them for feedback early in the process. Encourage them to be involved, but also let them know when a change is unreasonable. Just because the team can change things quickly doesn't mean these changes don't add up and take actual time.
1) Learn when to stop revising. Assume that milestone dates don't change, and put your foot down when a feature or asset is approved. Just because you can change your mind everyday doesn't mean you should. Aim to get things right each time.
If you are interested in quick and dirty prototyping or you have your own method that works for you, drop us a line -- we are interested to see how this works in other studios!