Game Development product is for entertainment to engage people to have fun, learn and spend good time. Hence the product will require an idea, story, innovation, creativity, writing skills, and technical expertise. However, during the real game development practice, simply adopting the software development life cycle (SDLC) is not enough, as the developers face several challenges during its life cycle. Software development life cycle (SDLC), also known as software process models, is a development strategy that encompasses the process, methods, and tools which are used to do the software development.
To address the problem, game development uses a kind of specific approach called game development life cycle (GDLC) to direct the game development. GDLC focuses on the standard streamlined engineering principles to build a robust software architecture for your game on all the platforms. The game development process is a highly complex process and it will always require a collaborative multiple skilled/talented team to build the product for various platforms. The process is inclusive of game producers, game/art directors, technical team, game designers, game artwork team, game quality team, game programming team, game testing team, and game marketing (Post-Production) team.
The model of GDLC follows a few fundamental steps of seven stages.
1. Idea: The very first stage of the game is where the developers decide which type of game they are going to produce like target audience or players, the kind of game, the hero, the protagonist of the game, the theme of the game, etc. The story of the product is written in the Game Concept Document. In the first stage, checking as many requirements as possible with the product owner and team members is a sure path to success. The designer must convey their idea to the rest of the team, a team filled with people who will also have many different ideas regarding what is and is not feasible within the given scope of the project.
2. Game Design: UI, Environment, Characters, Levels, Missions, Audio, and storyboard of the product are written in the Game Design Document. Designing of a game as a software product is one of the most creative, innovative, complex processes and requires critical iterative thinking, understanding, implementing of the design.
3. Technical Requirement Analysis: In this stage, the main target is to analyze the Framework, Plugins, Data, Scripts, Scene Management, Software Pattern, Object Pooling, and UI Development as Architecture for prototyping of the product written in the Technical Specification Document. Programming of a game as a software product is one of the most complex programming system development and requires critical thinking on its game software architecture.
4. Programming: The next stage is the programming stage which is written in the Technical Design Document. Lead Programmer at this stage should make a checklist of how the data is going to get executed using the software architecture.
5. Testing: Testing the written app is a crucial stage in GDLC, which is written in Test Cases and Test Plans. At this stage, the flow analysis and bugs have to be tracked by the QA under Bugs Tracker Report and Testing team must work on two documents Test Cases and Test Plans.
6. Deployment: At the deployment stage, prepare a short video (like a trailer) and some screenshots (like Flashbacks), then finally hit publish and make it live.
There are a lot of proposed software/game development lifecycle models which follow a specific life cycle during the process of development. These models are also termed as Process & Development Models. The list of some of the popular development models is:
· Waterfall Model: It is the oldest and most frequently used model and follows simple and straight-forward methodologies – according to which first complete one phase, then move on to the next phase (no going backward). Every stage of waterfall model depends on the information passed on from the previous stage. It is easier to understand and to manage effectively. This model was very popular during early game developments when the requirements were constant through the development. But these days, requirements change every day, hence following this model is not a good choice. It can be used for small game projects.
· Spiral Model: This one is a flexible model. The spiral model has a repetitive approach, going forward in a circular manner where the project passes through four phases over and over in the form of a spiral, until it reaches the completion, hence allowing several rounds of refinement.
In-Game development, the typical steps in a Spiral Lifecycle Model are:
- Design and Planning
- Implement the plan or in other words, code the Game.
- Play Test: This involves playing the game and analyzing it for improvements, looking for bugs/issues, etc.
- Evaluation of the current progress. Understanding what we did right, what we did wrong, and with a new point of observations, move back to step 1.
· Iterative Model: Here instead of beginning with fully known requirements, you can also start implementing a set of software requirements, testing, evaluating and plug-in further requirements after an iteration. During each iteration, a new version of the game gets produced. This rinsing and repetition go on until the complete project is ready.
· V-Shaped Model: This model is also called the Verification and Validation model and this model was born out of the Waterfall model and has the characteristics of a parallel running testing activity during each of its development stages. Like the waterfall model, each stage of the V-shaped model is dependent on its previous stage. This model plays its role perfectly when all the requirements are clear beforehand, as it’s very difficult to have a backward movement for making any changes.
· Big Bang Model: It doesn’t totally follow the SDLC methodologies or in other words, this model does not follow any specific process, and very small amount of time is spent on planning and designing this model at the time of game development. A bulk amount of resources is focused on development. This is one of the uncommon methodologies normally used for small projects where only two to three developers are working for developing a game.
· Agile Model: In this model, the product is broken down into a set of features, and hence it is used for quickly delivering a working product and so considered as a very rational development method. This model generates ongoing releases of your project, each having small and incremental changes updated from the previously released version. At each cycle, the project is tested and then released.