1 / 25

Making a Schedule You Can Believe In

Making a Schedule You Can Believe In. Korean Games Conference Tom Sloper October 16, 2004. © 2004 Tom Sloper. May not be published or reprinted without the express written permission of the author. © 2004 Tom Sloper.

tamasine
Télécharger la présentation

Making a Schedule You Can Believe In

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. Making a ScheduleYou Can Believe In Korean Games Conference Tom Sloper October 16, 2004

  2. © 2004 Tom Sloper • May not be published or reprinted without the express written permission of the author.

  3. © 2004 Tom Sloper • May not be published or reprinted without the express written permission of the author.

  4. Last year, I spoke on the importance of planning.I stressed that in order to make a budget and schedule, the game must be designed in detail before work begins.

  5. I was brilliant. I quoted famous people. I compared different production approaches.But then I flubbed it during the Q&A session afterwards.I can’t believe I was asked back!

  6. Someone asked me,“But when you make a schedule, how do you believe in it?”I hadn’t been prepared for that question then. But now I am.

  7. The Question Has 2 Parts • How do you make a schedule? • How do you believe in the schedule you made? The answer to #2 is contained in the answer to #1.

  8. How to Make a Schedule • Start with a detailed GDD (Game Design Document) and TDD (Tech. DD) • Generate lists from the GDD • Task list for programming • Art list • Sound list • Story text, dialogue, V.O. • Music list/specifications

  9. Break down the project into its component parts. Shell, config., save, load... U.I. input U.I. display World Characters A.I. Collision detection Event handling Scoring EOG Player matching Etc. Assign tasks to team members as needed Staffer make estimate Manager make estimate Compare estimates and discuss Note dependencies (esp. art, sound) Prioritize features Programming Task List

  10. Art List • Go through GDD with a fine-toothed comb • Identify every screen, icon, character, item, location, animation. • Make an estimate for each one. • Determine number of artists needed. • Set schedule based on programmers’ needs. • Art starts after programming starts, finishes before programming ends (concurrent).

  11. Sound List • Go through GDD with a fine-toothed comb • Identify every sound effect. There should be a sound for every action the player can make, and for every action the game makes. • Make an estimate for each sound. • Set schedule based on programmers’ needs. • Sound starts after art, finishes before art.

  12. Starting from the GDD, determine where each line of text or spoken dialogue is needed. Screenwriter makes estimate. Working backwards from when programming team needs dialogue, determine voice schedule. Contact actors’ agents Provide role descriptions, desired number of actors Get audition tapes (demo reels) Select actors Schedule studio time Recording sessions Process audio files Story Text & Dialogue

  13. Music Specifications • Starting from GDD, determine location of each music cue in game. • Determine length of each tune. • Composer make estimate • Schedule it in so music is delivered when team needs it.

  14. Programming Is Key • It’s important to have a schedule for the art, sound, voice, and music • But it is the programming time alone that determines the project time. • Knowing when the team will need art, sound, voice, and music enables on-time delivery of those assets. • Don’t make programmers wait for assets.

  15. Believing in the Task Schedule • If the people estimating the tasks are experienced at doing their jobs, their time estimates are trustworthy. • If the people are young, with less experience, or are doing something new and untried, then that’s different. • Either way, the cautious manager or producer can always apply a safety cushion.

  16. Padding the Cushion • One classic rule of thumb is “up the time increment and multiply.” Minutes  Hours  Days  Weeks  Months  Years • So if a contractor says “I can create that algorithm in 3 days,” you change “days” to “weeks” and you multiply. Some say “double it” (the more cautious say “triple it”). 3 days  3 weeks  6 weeks • In the schedule, you don’t put 3 days - you put 6 weeks (or 9 weeks). • That’s probably too much caution, so...

  17. A More Reasonable Cushion • Vary the scheduled time according to the trustworthiness (experience level) of the estimator. • Rather than “upping the time increment and multiplying,” just apply a percentage. • If estimator says “I can create your memory manager in 6 weeks,” put 8 weeks in the schedule. That’s a 33% cushion (adding 2 weeks to the estimate).

  18. Other Production Methods • The technique I’ve described assumes that you write a thorough GDD before beginning production. Not everyone works that way. • The Cerny “iterative prototypes” method recognizes that sometimes a feature that sounded good on paper just doesn’t work as envisioned. • It is still possible to schedule using this method.

  19. Iterative Scheduling • Starting with the desired publication date, first work backwards to determine the drop-dead Beta date. The processes that must occur after Beta cannot be shortened. • Working forward towards Beta, plan for a series of prototypes. Determine the features that need to be prototyped. Create a schedule and deadline for each prototype. • Upon reaching a deadline, re-evaluate the overall schedule. • The goal is to drive in a “Golden Spike” on the Beta date.

  20. “Golden Spike”? • In 1869, two east-west railroads were joined in Utah to create a single railroad that crossed the entire North American continent. • They didn’t start at one side and work to the other side. The started at both ends and joined in the middle. • This is an important aspect of game project scheduling as well.

  21. Build In Re-Eval Nodes • At key junctures in the project (or once each month), re-evaluate the progress and the schedule. • Is the schedule working? • Is the game working? • Is the team working? • Can we hit the Golden Spike? • If it’s working, you’re on schedule. • If it isn’t, redo the schedule.

  22. Danger Signs • There are several kinds of things that warn of danger to the project (and thus the schedule). • A late milestone • A feature missing from a milestone • A morale problem • The game isn’t fun • These things are interwoven – one can affect or infect the other. Any can impact the schedule. • The wise producer never ignores a danger sign but takes action immediately.

  23. When A Surprise Occurs • Sometimes something bad happens, without a warning sign being seen beforehand. • Immediately determine the impact on the schedule. • Consider options: • Feature tradeoffs? • Extend schedule? • It depends on the priorities. Which is most important? Fast? Cheap? Or good? • Re-examine priorities when re-examining schedule.

  24. Believability Comes From Experience • Constantly re-examining the schedule makes the team better at making more believable schedules the next time. • Experience teaches us to temper our optimism with a realistic view of the world. • By not ignoring danger signs, by not letting surprises disrupt progress, we gain confidence. • People believe in leaders who exhibit wisdom and confidence.

  25. Thank You Questions? ... Tom Sloper Sloperama Productions Los Angeles, California USA http://www.sloperama.com (310) 915-9945 tom@sloperama.com

More Related