1 / 39

Chapter 3.1 Teams and Processes

Chapter 3.1 Teams and Processes. Programming Teams. In the 1980s programmers developed the whole game (and did the art and sounds too!) Now programmers write code to support designers and artists (who are the real content creators). Programming Areas. Game code

lukas
Download Presentation

Chapter 3.1 Teams and Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 3.1Teams and Processes

  2. Programming Teams • In the 1980s programmers developed the whole game (and did the art and sounds too!) • Now programmers write code to support designers and artists (who are the real content creators) CS 4455

  3. Programming Areas • Game code • Anything related directly to the game • Game engine • Any code that can be reused between different games • Tools • In house tools • Plug-ins for off-the-shelf tools CS 4455

  4. Team Organization • Programmers often have a background in Computer Science or sciences • They usually specialize in some area (AI, graphics, networking) but know about all other areas • Teams usually have a lead programmer • They sometimes have a lead for each of the major areas CS 4455

  5. Skills and Personalities • Successful teams have a mix of personalities and skills: • Experience vs. new ideas • Methodical vs. visionary CS 4455

  6. Methodologies • A methodology describes the procedures followed during development to create a game • Every company has a methodology (way of doing things), even if they don't explicitly think about it CS 4455

  7. Methodologies: Code and Fix • Unfortunately very common • Little or no planning • Always reacting to events • Poor quality and unreliability of finished product • “Crunch” time normal CS 4455

  8. Methodologies: Waterfall • Very well-defined steps in development • Lots of planning ahead of time • Great for creating a detailed milestone schedule • Doesn't react well to changes • Game development is too unpredictable for this approach CS 4455

  9. Methodologies: Iterative • Multiple development cycles during a single project • Each delivering a new set of functionality • The game could ship at any moment • Allows for planning but also for changes CS 4455

  10. Methodologies: Agile Methods • Deal with the unexpected • Very short iterations • 2-3 weeks • Iterate based on feedback of what was learned so far • Very good visibility of state of game • Difficult for publishers or even developers to adopt because it's relatively new CS 4455

  11. Common Practices • Version control • Database with all the files and history. • Only way to work properly with a team. • Branching and merging can be very useful. • Used for source code as well as game assets. CS 4455

  12. Common Practices • Coding standards • Set of coding rules for the whole team to follow • Improves readability and maintainability of the code • Easier to work with other people's code • They vary a lot from place to place • Get used to different styles CS 4455

  13. Common Practices • Automated builds • Dedicated build server builds the game from scratch • Takes the source code and creates an executable • Also takes assets and builds them into game-specific format • Build must never break CS 4455

  14. Quality • Code reviews • Another programmer reads over some code and tries to find problems • Sometimes done before code is committed to version control • Can be beneficial if done correctly CS 4455

  15. Quality • Asserts and crashes • Use asserts anytime the game could crash or something could go very wrong • An assert is a controlled crash • Much easier to debug and fix • Happens right where the problem occurred • Don't use them for things that a user could do • Open a non-existing file • Press the wrong button CS 4455

  16. Quality • Unit tests • With very large codebases, it's difficult to make changes without breaking features • Unit tests make sure nothing changes • Test very small bits of functionality in isolation • Build them and run them frequently • Good test harness is essential CS 4455

  17. Quality • Acceptance test (or functional tests) • High level tests that exercise lots of functionality • They usually run the whole game checking for specific features • Having them automated means they can run very frequently (with every build) CS 4455

  18. Quality • Bug database • Keep a list of all bugs, a description, their status, and priority • Team uses it to know what to fix next • Gives an idea of how far the game is from shipping • Doesn't prevent bugs, just helps fix them more efficiently CS 4455

  19. Leveraging Existing Code • A lot of code that games use is the same • It's a total waste of time to write it over and over • Instead, spend your time in what's going to make your game unique • Avoid Not Invented Here (NIH) syndrome! CS 4455

  20. Leveraging Existing Code • Reuse code from previous project • Easier in a large company if you have an engine and tools group • Use freeware code and tools • No support • Make sure license allows it CS 4455

  21. Leveraging Existing Code • Middleware • Companies provide with components used in game development • physics, animation, graphics, etc • Commercial game engines • You can license the whole engine and tools and a single package • Good if you're doing exactly that type of game CS 4455

  22. Platforms • PCs • Includes Windows, Linux, and Macs • Can have very powerful hardware • Easier to patch and allow for user content • Need to support a wide range of hardware and drivers • Games need to play nice with other programs and the operating system CS 4455

  23. Platforms • Game consoles • Current generation • PS2, Xbox, GameCube • Fixed set of hardware – never changes • Usually use custom APIs – not very mature • They have very limited resources • Currently much better sales than PC games (although that changes over time) CS 4455

  24. Platforms • Handhelds and mobiles • Extremely limited hardware (although rapidly improving) • Programming often done in lower-level languages (C or even assembly) • However, DS and PSP in C++ • Much smaller projects, teams, and budgets • Emerging market CS 4455

  25. Platforms • Browser and downloadable games • Small games – mostly 2D • Need to be downloaded quickly • Run on the PC itself (on any browser usually) CS 4455

  26. Platforms • Multiplatform development • The closer the platforms, the easier the development • Use abstraction layers to hide platform-specific code • Choice • Target the minimum common denominator for platforms (easy, cheap), vs. do the best you can in each platform (more expensive and time consuming) CS 4455

  27. Chapter 7.1Game Productionand Management

  28. Concept Phase • Where concepts come from • Sequels • Film licenses • Technology re-use • Occasionally, original concepts get greenlit • Producing the conceptual design • Green light CS 4455

  29. Milestones • Highly detailed, specific • Quantifiable, measurable • Due dates • Avoid terms like “alpha” and “beta” unless clearly defined • Milestone approval cycles CS 4455

  30. The TechnicalDesign Document • GDD is a statement of the problem; TDD is a statement of the solution • Foundation for the programming work • Identify technical challenges • Plan for technical solutions • Set forth asset format guidelines CS 4455

  31. Scheduling • Generate task lists from GDD & TDD • Plan everything • Programming • Assets • Demos • Approvals • Green lights • Vacations, holidays • QA • Work backwards from completion CS 4455

  32. The Golden Spike • May 10, 1869 – Promontory, Utah • Start at both ends, work towards the middle (alpha and/or beta) • The back end cannot be compressed • Determine target beta date to achieve desired ship date • Can game achieve beta by target date? CS 4455

  33. Adjusting the Schedule • Add people to reduce development time? • Deliver assets on time • Don’t make programmers wait for assets • Prioritize feature set • Lower priority features to be done later if possible • Look for bottlenecks • (feature-technology interdependencies) CS 4455

  34. Production Phase • Programming now underway • Kicking off tasks – art creation • Art lists • Art asset file naming conventions • Art asset tracking • Art asset approval cycles • Art asset delivery formats CS 4455

  35. Red Flag Spotting • The usual causes of red flags: • Team conflicts • Personnel issues • Design problems • Money troubles • Technical glitches • Change requests • Schedule delays • Take immediate action CS 4455

  36. Kicking Off Tasks - Audio • Sound list • Music specification • Story text • Voice-over script • Creation of sounds • Creation or licensing of music • Recording of voice-overs CS 4455

  37. First Playable – Proof of Concept • Keeping everyone on board • Licensor(s) • Platform holder(s) • Executives • The Team • The Cerny method (google it!) • Keeping the momentum going CS 4455

  38. The Multitasking Producer • Time management • Managing mid-production • Expecting the unexpected • Red flags in mid-production • Design by committee = consensus? • Late production CS 4455

  39. Quality Assurance • Test plan • The QA database • QA – the view from inside • The QA-producer relationship CS 4455

More Related