A tutorial on Game development models would be nice.

There are a lot of game development or software development models available over the internet in therorical format. It would be really helpful for us if someone did a tutorial on how to use those models practically in unity. Would really make the game development process very easy for a lot of developers out there including me.
Thanks in advance.

 

Like blender?

 

I think he's referring to asset pipelines and game theory. Something on designing games, not just the technical details behind developing them.

 

Kannan, can you be a bit more specific with your question? What kind of information are you looking for? And what size teams do you have in mind? Are you thinking production process (agile, XP, CI, etc) or content pipelines or scheduling or just some best practices for actually making a commercial product?

 

I meant like there are certains methods in the development of an application like waterfall model for instance. What types of software development model can we use and can i get a tutorial on that? Would really help new developers who just enter into game programming who know only programming and nothing about the other processes like s/w development model.

 

There's no canonical Right Way To Make Games(TM), but many developers are now using agile/scrum style methods. Clinton Keith has written a lot about this topic, and if you check out the production track in the GDC vault from the last few years you'll find a lot more examples. You can also check out great books like The Mythical Man Month or People Ware for some general software dev process wisdom.

Most experienced game devs use a hybrid of waterfall and agile: waterfall for the big picture and agile for the day-to-day basis. At a high level, games tend to waterfall by the major phases (concept/prototype, pre-production, production, alpha, beta, etc). Between these phases most devs have milestones 1-2 months long, with some idea of what should be done at each milestone (i.e. level 5 complete, 50% of enemies implemented, whatever). Within a milestone, many teams use some kind of agile process, which tries to focus on flexibility in the face of what is often a complex, difficult to predict creative process.

It can be helpful to understand the weaknesses of both approaches, too. Detailed waterfall scheduling is extremely time consuming to do, and has a very hard time dealing with uncertainty, especially compounded over many months and years into the future. I've seen teams try to figure out which sub system a programmer will be working on years into the future, which is really just an exercise in futility. On the other hand, agile methods do very well with the day to day but don't tell you much about how you are doing relative to your overall goals, schedule, budget, etc. I've seen teams be so agile that they forget to ask basic questions like "ok it's June, we said we'd be 50% done now. are we there?" Theoretically agile methods mean that you can ship at the end of each iteration. While this might be possible for a hypothetical web page or a word processor, it's rarely realistic for an entertainment product like a game.

Lastly, I'm personally a big believer in the value of a very early, very focused, concept/prototype phase at the beginning. You can skip this if you are doing a sequel or copying another game, but if you are doing something original usually you have a ton of uncertainty about what you're making and how. This prototype phase can be a few days (like a game jam) or a few weeks (like Double Fine's amneisa fortnight). The product can be a video or art work but a playable prototype is the gold standard. By hook or by crook, the goal of the prototype is to make something tangible that captures the essential creative spirit of what you are making and can serve as a guide to the planning and development that is to come.

I hope that helps!

 

I should also mention that often different approaches work better for different teams and different parts of the project. Content creation is, in general, more amenable to waterfall scheduling and is often most efficient when planned this way. Programming is generally much less predictable, and favors agile methodologies. Early on when there are many unknowns, the whole team may want to be agile. Later on, when you're just fixing bugs before ship, maybe even the programmers want to use a more formal methodology, like bug triage/burndown.