Presentation is loading. Please wait.

Presentation is loading. Please wait.

Multimedia Games Development COM429M2 Week 4 Game Development Process.

Similar presentations


Presentation on theme: "Multimedia Games Development COM429M2 Week 4 Game Development Process."— Presentation transcript:

1 Multimedia Games Development COM429M2 Week 4 Game Development Process

2 Learning outcomes Understand the game development process Understand steps from initial idea/proposal to working prototype to full game development Extension to earlier lecture, Early game development

3 Preproduction process Next stage in process after initial game idea/proposal has being approved Preproduction process involves initial development of the game Objective is to complete game design process Produce documentation Create working prototype to prove technical and commercial feasibility of concept

4 Documentation Requires production of range of documentation Documentation pads out/structures initial idea Formalizes concepts Provides game blueprint

5 Documentation includes Game design document Game production path Art bible Technical design document Project plan (Timescale/deliverables)

6 Game Design Document End of preproduction process results in game design document Document details all aspects of game e.g. levels, storyline, game play Similar to software requirements/design document Iterative process, constantly evolving document

7 Game Design Document Reference document (Bible) during development Should be easy to read Concise, written in a factual style Use standard company/industry template Include comprehensive and detailed table of contents for easy navigation Include one page summary at start

8 Design Document Summary Summary should include Central game concept or focus Concise summary of story (paragraph) Highlight important game play features/aspects Conclude with game innovations

9 Design Document Storyline Needs to include an easy to read narrative of events in the game. These should include Game setting Plot elements (standard structure) Back story Characters (Playable) Characters (Non playable) e.g. player supporting/player opposing, neutral

10 Design Document Storyline This is fleshed out version of story summary Helps presentation of story Includes storyboards showing key moments in the game/plot elements and cut scenes Includes dialogue

11 Game play mechanics Essential and most important part of document Expanded version of section from game proposal Needs to be very detailed, without assumptions Covers all aspect of game

12 Game play mechanics Describes player interaction with the game world Details possible player actions and results Discusses what the player does in the game and how they do it Serves as a starting point for user manual

13 Game play mechanics Should include game genre and any extensions/variations from expected norms Details players capabilities/skills and how these are done Covers user interface and interaction modes Discusses game start-up process and player options (customise character) Highlights requirements for character maintenance and development

14 World Behavior Documents changes to game world in response to players actions Complements section on mechanics to give complete coverage of how player and world/NPC’s interact Describes NPC features and skills, context sensitive behaviour and triggering actions Covers interaction between NPC’s Covers actions of NPC’s when not interacting with player Covers behaviour of non character elements of world More detail = less unpredicted behaviour = less QA problems

15 Game Elements Game elements include Characters (non player controlled elements) Items utilized/wielded by the player/NPC’s Any other game objects or mechanisms and their possible combinations e.g. puzzles, door locks Be as detailed as possible

16 Game Elements Be well organized Arrange elements in groups/sub groups or classes Include a physical description of each element Include a description of each elements operation/behavior Show relationships between elements Include concept art if possible End objective is to ensure that there is enough detail for an artist to create good artwork or a programmer to code up the element.

17 Game Progression Progression described in events/player experiences/levels Shows evolution over time Complements storyline development Usually done on a per level basis where appropriate or on a stage by stage basis

18 Game Progression Should include detail on each stage/level of game Structure and organization Aesthetics,look/feel Major obstacles/puzzles/challenges encountered by player Level/stage and relationship with storyline Player experience, level of difficulty, emotional involved, skills developed

19 System Menus Description of menus/option screens outside of main game play Extra to game design, warrants own section Describe functionality/features of menus /screens, their interaction and place/functionality in the game List user interaction with menus and outcomes Again be as detailed as possible

20 Common Mistakes Document not sufficiently detailed Poor structure, hard to use. Excessive focus on storyline to the detriment of other essential elements Blue sky document with unfeasible functionality Dated or poorly maintained scripts

21 Art Bible During preproduction phrase it is essential to establish game look and style Can take the form of pencil sketches but the more detail shown the better Should be complimented by notes and annotations with description of artistic style, direction and instructions Should be the starting point for story boards/concept art included in the design document

22 Production Path Production path details all stages of game development from concept to working prototype Includes the art, modeling, rendering, level editors, sound etc…tools to use Need to ensure cross compatibility of tools used Helps determine timescale for implementation and project costs

23 Spore development

24 Technical Design Document Complements game design document from earlier Game design document describes how the game will function Technical design document describes how that functionality is implemented Includes description of software design and code structure, artificial intelligence, graphics animation, sound, networking etc..

25 Project Plan The project plan is the roadmap describing the milestones in game development States tasks to be completed and any pre-requisites or dependencies and manpower costs Helps in development of project schedule Usually includes resource management plan, project budget, schedule/milestones Typically needs major revisions and updating as project progresses

26 Constraint Triangle Trade off between time/cost and quality Balance between 3 elements Increase staff, project delivered in less time but more money Decrease staff, reduce quality/functionality

27 Production stage Production stage follows preproduction Full development of the game based on feedback from preproduction Involves extensive game testing Release to manufacturer Ongoing maintenance following release (patches and upgrades)

28 Game prototyping The physical outcome at the end to the preproduction process is the game prototype Working demo which captures game essence Essential to highlight game novelty and strengths Hard to do well as all technology/content is not available Large parts of the game are simulated Critical to proceeding to full scale development

29 Development process Development process long and involved Typically lasts 6 months - 2 years Less than 6 months unrealistic More than 2 years increases risk of being obsolete

30 Development process Good time management essential Tasks always take longer than expected Create small manageable tasks with clear deliverables and allocation of responsibilities Essential to track and ensure progress

31 Development process Iterative process be prepared for changes Ensure documentation is current Typically use a software development model to structure project (Waterfall model)

32 Development process Essential to maintain good communication across development team Expect problems Have road plan of functionality and features with ability to discard elements if required

33 Development process: Testing Testing is important for game development. Includes validation and verification testing Validation testing looks at game and game play design and whether the right game is being created. Verification testing looks more at functionality and focuses on removing imbalances and eliminating bugs Testing is an iterative process and should occur frequently

34 Types of Testing Unit testing involves testing individual elements of the game e.g. networking module System testing checks the interaction between modules Acceptance testing is where the “complete” game is checked before publishing

35 Types of Testing Alpha testing Internal testing where the game is mostly playable from start to finish. Some content and and gameplay maybe absent, but the engine, interface etc are complete Involves focus shift from construction to completion (polishing of product)

36 Types of Testing Beta testing Internal or external testing, all elements are integrated into final game Objective is bug elimination If possible do public beta testing Last part of beta testing is “Crunch time” where the only objective is game testing

37 Testing: Warning Signs During testing there are a number of possible indicators of poor game design If addressed early these can be rectified before release If missed or ignored then the game could be seriously comprised

38 Testing: Warning Signs Development team constantly needs to help players in using controls, user interface or game objectives Provision of natural level of information is expected for game play but excessive manuals or help tutorials may be indication of deeper problems Game should be self contained and provide any required guidance Players should easily become familiar with game and move on quickly

39 Testing: Excessive loading/saving Excessive loading and saving of a game may indicate high level of game difficulty Major concern if across large player group Problem resolution involves identifying location of excessive loading and saving Will help identify problem area Problem area should be lessened or removed

40 Game imbalance Players consistently select the same character/ weapons/units/strategies maybe sign of sign of game imbalance Similarly if players consistently ignore something Imbalance can be detected by tracking player preferences and analyzing statistics

41 Excessive offensive behaviour Players ignore defensive tactics or strategies Indicates either defense is poor/ineffective or there is limited risk in pure aggression E.g. poor weapon balance, excessive power ups or availability of health Requires game tuning to rectify

42 Constant control reconfiguration Most games offer flexibility to reconfigure game controls However if majority of players reconfigure default controls then it may be an indication of a problem Ideally controls should require minor tuning Adhere to genre conventions e.g. Doom WASD

43 Constant viewpoint reconfiguration Player’s viewpoint should be adjusted automatically to complement game action Optional manual tuning should be available but should not be a requirement Excessive viewpoint reconfiguration is an indicator of poor game implementation

44 Player balance Players should always hover between victory and disaster Both should be a constant presence/possibility Excessive strength or weakness leads to lack of balance in game play

45 Showcases Avoid games that solely showcase technology Fundamentals still essential regardless of technological novelities

46 Meeting deadlines If possible do not release a poor game due to time constraints Harms long term viability of product

47 Testing: Code freeze Code freeze occurs many times during game development Prevent changes that could cause significant problems and delays Allows developers to integrate modules without coming across unexpected changes Prevents feature/funcationality creep late into development process Late in Beta allows only critical bug fixing

48 Testing summary Test extensively Listen to tester feedback and address concerns Fix problems early, more costly in the long term

49 Going Gold Game released to manufacturer Game thoroughly tested For console games, this will involve approval of the console manufacturer

50 Maintenance phrase Following release there are often smaller updates Patches to fix bugs/hardware incompatibilities discovered after release Upgrades and updates are typically additional content which enhances original game e.g. new levels

51 Development problems Always plan for things to go wrong Particular problems will constantly arise during development process Impossible to prevent but contingency planning will help to minimize impact

52 Typical problems Over optimistic timescales Feature creep/game bloat Staff motivation Inadequate staff skills Disruptive staff Poor working conditions Unreliable external contractors Over ambitious objectives Poor management

53 Typical problems Inadequate level of detail in task definition Misunderstood objectives Diversely located staff/poor communication Inflexible planning Poor response time in bug fixing

54 Poor strategic planning Plan to catch up later Impose mandatory overtime Throw more resources at the problem Hold more meetings

55 Good strategic planning Most effective way to reduce workload is to reduce project scope Complete critical tasks first/prioritize wish list Create essential content first/ first/prioritize wish list Keep staff motivated

56 Summary Large number of steps in game production Early concept to game design document and project planning Involves high level of planning and attention to detail Plan for problems

57 Examples GDC 2007 Spore: Preproduction Through Prototyping Eric Todd Overview: This session explains how prototyping can be the heart of a virtuous cycle during preproduction. The cycle is illustrated with concrete examples and numerous prototypes from Spore’s preproduction phase. Potential pitfalls are highlighted. Spore: Preproduction through Prototyping

58 Examples GDC 2007 From Design to Product: A Model for Independent Game Production Nick Soutter Overview: So you've got an idea? Congratulations! Now what? This lecture will focus on how to turn your idea into reality, with practical examples and concrete methods drawing from an experienced developer. Learn how to start a small game company and leverage limited resources ($10K or less) to get your game developed into a commercial product. From Design to Product: A Model for Independent Game Production

59 Examples GDC 2007 Play Early, Play Often: Prototyping Sid Meier’s Civilization IV Dorian Newcomb, Soren Johnson Overview: This session gives a look at the first few builds of the development of CIVILIZATION IV. It demonstrates how games are prototyped at a studio where design rules, and offers unique approaches to get the most out of ideas earlier, rather than later. Play often Play Early

60 Multimedia Games Development COM429M2 Week 4 Game Development Process


Download ppt "Multimedia Games Development COM429M2 Week 4 Game Development Process."

Similar presentations


Ads by Google