Technical preproduction (for a new IP)

2. Technical preproduction(for a new IP) Stefan Posthuma Technical Director Electronic Arts Canada

3. 1984

5. 1998

7. 1998 - AI programmer1999 - Lead programmer2003 - Systems Architect2004 - Product Manager2005 - CTO Sports2007 - TD, new IP

8. Can`t spend any money! Multi-million seller! New team! New technology! 100% new IP! AAA title!

10. To do list • Early prototype • Pick technology • Set up infrastructure • More prototyping • (Survive all exec reviews)

11. Early prototyping • Goals: • Prove core game features • Experiment with the IP • Establish the rules • (survive first exec review)

12. How? Improvise!

13. Use what is at hand • Readily available • Easy to use • In working order • Local knowledge of the system • Somewhat genre specific • Doesn’t have to be pretty!

14. Align expectations • Prototype just to prove core game play • Not VTAR by any stretch of the imagination • Use deliberately low-fi models and textures • All work done should be considered throw-away • Knowledge gained far outweighs any code written

15. Review time... • Clear explanation of what the rules are • No VTAR, not on target platform, etc. • Get creative • Multiplayer mode to mimic AI • Went over well, got point across • Survived first exec review!

17. Pick technology • AAA title, 30 months to ship • Forget about writing your own engine • Need existing solution • Something that will be competitive 2 years from now

18. Let’s go shopping!

19. Shopping list • Genre specific • Scalable and extensible • Needs to compete late in console life cycle • Provide mature asset pipeline • Rapid prototyping needed! • Data driven run-time • Engineers can focus on infrastructure while designers build prototypes

20. Options • In-house • Luxury of large company, lots of choices • Godfather, Harry Potter, Battlefield, Medal of Honour, Skate, Need for Speed, the list goes on • 3rd party • A few obvious contenders • Unreal • Gamebryo • Others...

21. Narrow it down • Spent about a week looking at high level specifications of available engines • Applied criteria in shopping list • Ended up with 2 contenders

22. Next up

23. Taking a very, very close look • Make first contact with the provider • Talk about evaluation licensing if applicable • Explain intentions • Get a copy of the technology and have engineers take a look • Give it a good poking and prodding • Build a test level or example • Get it running • Try to modify some assets • Play with the editor and pipeline • And so on

24. Get up close and personal • Go visit the provider • Easy when internal • Not so easy perhaps when they are busy • 3rd parties like to visit you • Or...find someone friendly who is using the technology and visit them instead • That is what we did

25. Planning your visit • Take it very seriously • Expensive • Need to get the most of it • Have a detailed evaluation plan • Clear expectations of outcome • Send the right people and take your time! • 1 week with 4-5 people minimum • Make a detailed itinerary • Day to day schedule for every participant

26. Remember to socialize • Having beers with the team is incredibly valuable

27. Kick the tires • Bring some assets along, try to pull them through the pipe • Build very simple prototypes • Get a feel for the main workflows • Take copious notes

28. Make a report card • List the major areas of the engine and rate them on how well they apply to the project • Put them side by side and compare • Use this to help pick a winner

29. Decision time... • Scalability and long term potential were big factors • We picked the more risky engine because of this • It was written from the ground up for NG • Architected for multi-core systems • Very scalable • Highly data driven

30. Evaluation process took 2 months

31. Meanwhile... • A small team continued prototyping using the previous engine • This so production and design could continue their work

32. Learning • Document! • A team Wiki where learning was documented • Careful on boarding of new team members using the Wiki • They improved it as they used it • Process • Code Collaborator • Excellent learning tool • Knowledge sharing big part of team culture • Put it in people’s objectives • Nobody is an expert, regardless of seniority

33. Re-implement • Duplicate original award-winning prototype • Bring over existing assets • Uncover a few things we missed

34. Dive not deep enough?

35. The animation system... • Needed to do major upgrade of animation system • Physics was handled with interface that we could ‘simply implement’ • Assumptions were made... • Physics layer took order of magnitude longer to implement • Seriously impeded game feature implementation

36. How did we fix this? • Collaboration! • Visited engine tech provider to come up with a plan • Worked closely with animation technology provider (internal group) • People from the 3 teams working together on-site • Hard push to come to a solution • We now have ground breaking animation technology in our game 

37. Review time again In the middle of the animation crisis!

38. Showing a hybrid • Two demos: • Critical animation features in animation prototyping tool • Game play features in new game engine • Survived another review!

39. Moving on... • Prototyping vs. Feature building VS

40. Agile to the rescue • Scrums focus on specific features • More importantly the term ‘technical debt’ exists! • Clearly defined quality of implementation • First look, Functional, Presentable, Shippable • Put this on every user story • This helped align expectations • Agile also helps with daily communication and sharing progress with the team • Scotty and Kirk at peace once again

41. Infrastructure • Don’t forget about this! • Provide basic technical infrastructure early on • Build system • Deployment system • Stability and ‘always on’ were top priorities • Production always able to play the game • Wandering execs can get ad-hoc demos • Content providers always productive

42. Keeping in touch • Remember those beers you had with the people who wrote your engine? • Foster those relationships • Join forums, know the right people, keep in touch • For us, EA team so mutual show and tell is possible • Both sides stoked about each other’s work

43. Progress! • Animation physics problems solved • All critical features now living happily together • Team velocity really picking up • Survived another review!

44. The team • Keep it small, resist the urge to grow! • Can’t spend any money remember? • Get the most senior people with broad experience • Time to roll up those sleeves and jump in wherever it is necessary • Agile helps, scrum teams are peer based • Don’t forget about team building and culture • Just as important as the game

45. What lies ahead • When will we be production ready? • Some simple tools • Questions to ask

46. Lightweight review • Find a friendly TD or other senior technical person • Have them go around the team, asking questions • No documents, long sessions or other painful things • Focus on technical risks, things that may have been overlooked • Write up a summary, discuss, action • Very helpful!

47. Workflows • Content providers need to be 110% efficient • Examine workflows in detail • Start with behavioural – who does what, in what order and why? • Drill down into physical – too many button presses? Asset export too slow? • Not production ready until all issues have been addressed

48. Be honest • Capacity • No ‘To Be Hired’ bodies on the schedule! • Technical risk • Usual suspects (frame rate, budgets) • Specific game feature related • Forward looking • What will online feature set look like in 2011? • Post ship technology demands

49. TD’s clipboard • Checklist • Risks assessed, communicated, mitigated • Capacity agreed on • Core feature set prototyped and functional • Scope, scope, scope • All asset pipelines functional and mass production ready • Scalable from 1 off example to 300 needed for ship • Metrics!

50. Summary • Prototype like MacGyver • One goal: prove core game features • Invest in technology evaluation • Dive as deep as you can • Balance prototyping vs game building • Introduce the Technical Debt concept • Be ready for reviews and demos • Always on, have the infrastructure to support this • Ask the right questions • Ready to go into production?