Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Lecture8 - Game Development Process (continued)
Transcript of Lecture8 - Game Development Process (continued)
Overall game development is not suited for typical software life cycle methods, such as the waterfall model The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.
One method employed for game development is agile development. It is based on iterative prototyping, a subset of software prototyping. Agile development depends on feedback and refinement of game's iterations with gradually increasing feature set. This method is effective because most projects do not start with a clear requirement outline. A popular method of agile software development is Scrum.
Another successful method is Personal Software Process (PSP) requiring additional training for staff to increase awareness of project's planning. This method is more expensive and requires commitment of team members. PSP can be extended to Team Software Process, where the whole team is self-directing.
Game development usually involves an overlap of these methods. For example, asset creation may be done via waterfall model, because requirements and specification are clear, but gameplay design might be done using iterative prototyping.
Development of a commercial game usually includes the following stages:
Pre-production or design phase is a planning phase of the project focused on idea and concept development and production of initial design documents. The goal of concept development is to produce clear and easy to understand documentation, which describes all the tasks, schedules and estimates for the development team. The suite of documents produced in this phase is called production plan. This phase is usually not funded by a publisher, however good publishers may require developers to produce plans during pre-production.
The concept documentation can be separated into three stages or documents—high concept, pitch and concept; however, there is no industry standard naming convention.
The late stage of pre-production may also be referred to as proof of concept, or technical review when more detailed game documents are produced.
Publishers have started to expect broader game proposals even featuring playable prototypes.
Lecturer Zaid Bawab
Game Development Process (continued)
Development Process - Pre-production
High concept is a brief description of a game.
A pitch, concept document, proposal document, or game proposal is a short summary document intended to present the game's selling points and detail why the game would be profitable to develop.
Verbal pitches may be made to management within the developer company, and then presented to publishers. A written document may need to be shown to publishers before funding is approved. A game proposal may undergo one to several green-light meetings with publisher executives who determine if the game is to be developed. The presentation of the project is often given by the game designers. Demos may be created for the pitch; however may be unnecessary for established developers with good track records.
If the developer acts as its own publisher, or both companies are subsidiaries of a single company, then only the upper management needs to give approval.
Concept document, game proposal, or game plan is a more detailed document than the pitch document. This includes all the information produced about the game. This includes the high concept, game's genre, gameplay description, features, setting, story, target audience, hardware platforms, estimated schedule, marketing analysis, team requirements, and risk analysis
Before an approved design is completed, a skeleton crew of programmers and artists usually begins work. Programmers may develop quick-and-dirty prototypes showcasing one or more features that stakeholders would like to see incorporated in the final product. Artists may develop concept art and asset sketches as a springboard for developing real game assets. Producers may work part-time on the game at this point, scaling up for full-time commitment as development progresses. Game producers work during pre-production is related to planning the schedule, budget and estimating tasks with the team. The producer aims to create a solid production plan so that no delays are experienced at the start of the production.
Game design document
Before a full-scale production can begin, the development team produces the first version of a game design document incorporating all or most of the material from the initial pitch. The design document describes the game's concept and major gameplay elements in detail. It may also include preliminary sketches of various aspects of the game. Design document is sometimes accompanied by functional prototypes of some sections of the game. Design document remains a living document throughout the development—often changed weekly or even daily.
Compiling a list of game's needs is called "requirement capture".
Writing prototypes of gameplay ideas and features is an important activity that allows programmers and game designers to experiment with different algorithms and usability scenarios for a game. A great deal of prototyping may take place during pre-production before the design document is complete and may, in fact, help determine what features the design specifies. Prototyping may also take place during active development to test new ideas as the game emerges.
Prototypes are often meant only to act as a proof of concept or to test ideas, by adding, modifying or removing some of the features. Most algorithms and features debuted in a prototype may be ported to the game once they have been completed.
Often prototypes need to be developed quickly with very little time for up-front design. Therefore usually very prolific programmers are called upon to quickly code these testbed tools.
A successful development model is iterative prototyping, where design is refined based on current progress.
Game audio may be separated into three categories—sound effects, music, and voice-over.
Sound effect production is the production of sounds by either tweaking a sample to a desired effect or replicating it with real objects. Sound effects are important and impact the game's delivery.
Music may be synthesized or performed live.
There are several ways in which music is presented in a game.
Music may be ambient, especially for slow periods of game, where the music aims to reinforce the aesthetic mood and game setting.
Music may be triggered by in-game events. For example, in such games as Pac-man or Mario, player picking up power-ups triggered respective musical scores.
Action music, such as chase, battle or hunting sequences is fast-paced, hard-changing score.
Menu music, similar to credits music, creates aural impact while relatively little action is taking place.
A game title with 20 hours of single-player gameplay may feature around 60 minutes of music.
Voice-overs and voice acting creates character gameplay interactivity. Voice acting adds personality to the game's characters.
At the end of the project, quality assurance plays a significant role. Testers start work once anything is playable. This may be one level or subset of the game software that can be used to any reasonable extent. Early on, testing a game occupies a relatively small amount of time. Testers may work on several games at once. As development draws to a close, a single game usually employs many testers full-time (and often with overtime). They strive to test new features and regression test existing ones. Testing is vital for modern, complex games as single changes may lead to catastrophic consequences.
At this time features and levels are being finished at the highest rate and there is more new material to be tested than during any other time in the project. Testers need to carry out regression testing to make sure that features that have been in place for months still operate correctly. Regression testing is one of the vital tasks required for effective software development. As new features are added, subtle changes to the codebase can produce unexpected changes in different portions of the game. This task is often overlooked, for several reasons. Sometimes, when a feature is implemented and tested, it is considered "working" for the rest of the project and little attention is given to repeated testing. Also, features that are added late in development are prioritized and existing features often receive insufficient testing time. Proper regression testing is also increasingly expensive as the number of features increases and is often not scheduled correctly.
Despite the dangers of overlooking regression testing, some game developers and publishers fail to test the full feature suite of the game and ship a game with bugs. This can result in customers dissatisfaction and failure to meet sales goals. When this does happen, most developers and publishers quickly release patches that fix the bugs and make the game fully playable again.
Commercial game development projects may be required to meet milestones set by publisher. Milestones mark major events during game development and are used to track game's progress. Such milestones may be, for example, first playable alpha, or beta game versions. Project milestones depend on the developer schedules.
There is no industry standard for defining milestones, and such vary depending on publisher, year, or project. Some common milestones for two-year development cycle are as follows:
The first playable is the game version containing representative gameplay and assets, this is the first version with functional major gameplay elements. It is often based on the prototype created in pre-production. Alpha and first playable are sometimes used to refer to a single milestone, however large projects require first playable before feature complete alpha. First playable occurs 12 to 18 months before code release. It is sometimes referred to as the "Pre-Alpha" stage.
Alpha is the stage when key gameplay functionality is implemented, and assets are partially finished. A game in alpha is feature complete, that is, game is playable and contains all the major features. These features may be further revised based on testing and feedback. Additional small, new features may be added, similarly planned, but unimplemented features may be dropped. Programmers focus mainly on finishing the codebase, rather than implementing additions. Alpha occurs eight to ten months before code release.
Code freeze is the stage when new code is no longer added to the game and only bugs are being corrected. Code freeze occurs three to four months before code release.
Beta is feature and asset complete version of the game, when only bugs are being fixed. This version contains no bugs that prevent the game from being shippable. No changes are made to the game features, assets, or code. Beta occurs two to three months before code release.
Code release is the stage when all bugs are fixed and game is ready to be shipped or submitted for console manufacturer review. This version is tested against QA test plan. First code release candidate is usually ready three to four weeks before code release.
Gold master is the final game's build that is used as a master for production of the game.
Overtime is expected in the games industry. Particularly, crunch time or crunch mode is unpaid overtime requested by many companies to meet project deadlines and milestones that negatively affects game developers. A team missing a deadline risks the danger of having the project canceled or employees being laid off. Although many companies are reducing the amount of crunch time, it is still prominent in smaller companies.
Many companies offer time-off, called comp time or extra paid time off after product ships to compensate for crunch time's negative effects. Some companies offer bonuses and financial rewards for successful milestone reach. Sometimes on-site crunch meals are offered and delivered to the team during crunch time.
After the game goes gold and ships, some developers will give team members comp time (perhaps up to a week or two) to compensate for the overtime put in to complete the game, though this compensation is not standard.
Once a game ships, the maintenance phase for the video game begins.
Games developed for video game consoles have had almost no maintenance period in the past. The shipped game would forever house as many bugs and features as when released. This was the norm for consoles since all consoles had identical or nearly identical hardware and incompatibility—the cause of many bugs—was a non-issue. In this case, maintenance would only occur in the case of a port, sequel, or enhanced remake that reuses a large portion of the engine and assets.
In recent times popularity of online console games has grown, and online capable video game consoles and online services such as Xbox Live for the Xbox have developed. Developers can maintain their software through downloadable patches. These changes would not have been possible in the past without the widespread availability of the Internet.
PC development is different. Game developers try to account for majority of configurations and hardware. However, the number of possible configurations of hardware and software inevitably leads to discovery of game-breaking circumstances that the programmers and testers didn't account for.
Programmers wait for a period to get as many bug reports as possible. Once the developer thinks they've obtained enough feedback, the programmers start working on a patch. The patch may take weeks or months to develop, but it's intended to fix most accounted bugs and problems with the game that were overlooked past code release, or in rare cases, fix unintended problems caused by previous patches. Occasionally a patch may include extra features or content or may even alter gameplay.
In the case of a massively multiplayer online game (MMOG), such as a MMORPG or MMORTS, the shipment of the game is the starting phase of maintenance. Such online games are in continuous maintenance as the gameworld is continuously changed and iterated and new features are added. The maintenance staff for a popular MMOG can number in the dozens, sometimes including members of the original programming team.
Production is the main stage of development, when assets and source code for the game are produced
Mainstream production is usually defined as the period of time when the project is fully staffed. Programmers write new source code, artists develop game assets, such as, sprites or 3D models. Sound engineers develop sound effects and composers develop music for the game. Level designers create levels, and writers write dialogue for cutscenes and NPC(Non Player Character)s. Game designers continue to develop the game's design throughout production.
Game design is an essential and collaborative process of designing the content and rules of a game, requiring artistic and technical competence as well as writing skills.
During development, the game designer implements and modifies the game design to reflect the current vision of the game. Features and levels are often removed or added. The art treatment may evolve and the backstory may change. A new platform may be targeted as well as a new demographic. All these changes need to be documented and disseminated to the rest of the team. Most changes occur as updates to the design document.
The programming of the game is handled by one or more game programmers. They develop prototypes to test ideas, many of which may never make it into the final game. The programmers incorporate new features demanded by the game design and fix any bugs introduced during the development process. Even if an off-the-shelf game engine is used, a great deal of programming is required to customize almost every game.
From a time standpoint, the game's first level takes the longest to develop. As level designers and artists use the tools for level building, they request features and changes to the in-house tools that allow for quicker and higher quality development. Newly introduced features may cause old levels to become obsolete, so the levels developed early on may be repeatedly developed and discarded. Because of the dynamic environment of game development, the design of early levels may also change over time. It is not uncommon to spend upwards of twelve months on one level of a game developed over the course of three years. Later levels can be developed much more quickly as the feature set is more complete and the game vision is clearer and more stable.