1. Seth Gibson Rapid Experience Development Build It On Stone

2. Begin At The Beginning

3. “Work Smarter, Not Harder”

4. Change Starts With Tech Art

5. Solid Infrastructure==Solid Productions

6. Improper Use Risks Slow Change

7. Stop Scripting, Start Programming

8. The Need For Tech Art Infrastructure

9. Bad Infrastructure Creates Bad Tools One-off tools and scripts can often obfuscate both the pipeline and content.

10. Bad Tools Create Bad Pipelines Poor pipelines increase complexity while reducing flexibility and scalability

11. Bad Pipelines Create Bad Content At worst, we end up with bad content at both ends of the pipe

12. So, What Is This "Tech Art Infrastructure"?

13. Good Infrastructure Begets Good Pre-Pro Good infrastructure creates a good GAME

14. Good Pre-Pro Begets Good Production Proper pre-pro means we’ve answered our production questions

15. Good Production Begets STFG Good production means we finish strong and start again stronger

16. And Who Owns The Product?

17. “But Mom, Technical Art Director IS A Real Job…” We should really be managing ourselves, just like every other discipline.

18. The Tech Art Director Is Not… …Just More Experienced …Just A “Bigger Hammer” …A Job For Engineering Leads

19. The Tech Art Director Is… …Part Production Artist, Part Software Engineer …A Peer To The Art And Engineering Directors …Focused On The Needs Of The Production Before The Needs Of The Art Team

20. Building Blocks

21. Always Use Protection

22. Keep Proper Filters In Place… “Sandboxing” provides a secure means for Tech Artists to iterate “off-line”

23. …And Open The Valve Slowly We can also control who gets what changes when

24. Case Study: DVCS And Symlinks Use A Branching Scheme To Develop And Test Features In Isolation Symlink Individual Artists To These Changes For Test Use Hooks (if supported) To Manage Distribution

25. “Don’t Let It Go To The Judges”

26. Don’t Reinvent The Wheel… Tech Art should focus on solving the problems that HAVEN’T been solved yet

27. …Build A Better Car Instead “Softwarehousing” gives us a solid base to build our own foundation

28. Case Study: Orendorff’s path path is a simple module that’s no longer actively supported but provides some powerful path manipulation tools. Grab it from github and modify it to your needs For more on path, see Jason Parks’ post on ArtOfTech: http://www.jason-parks.com/artoftech/ http://www.jason-parks.com/artoftech/

29. Choose Your Weapon

30. Use The Right Tools… notepad is only useful because it’s simple and you already know how to use it

31. …To Get The Job Done Right A proper IDE lets us shorten our code iteration cycle and do away with extra tools

32. Case Study: IDE Features (Wing) Sharing Project Files Source Control Integration Unittesting Documentation Builds

33. Laying The Foundation

34. So How Does This All Work?

35. Teach Yourself… Writing documents can often show you gaps in your own knowledge

36. …As You Teach Your Team Proper documentation makes all the difference in adoption and shaping opinion.

37. Case Study: Sphinx Fully customizable rST based, minimal coding required Supported by many IDEs If you’ve seen the python docs, you’ve seen Sphinx in action

38. How Do I Know It Will Work?

39. Catch Bugs In Your Design… By testing simple code units, we squash bugs when they’re small

40. …And You’ll Have Fewer Bugs In Your Tools Unittesting gives us the opportunity to design the bugs out of our code

41. Case Study: Unittest Content Leverage your DCC app’s ability to access scene objects and files through Python Build a “known good” set of content and pull it into your TestCases Come to my poster session and I’ll tell you more!

42. What Happens When It Doesn't Work?

43. Keep Your Error Logs Close… Custom error handling goes a long way to removing ambiguity in debug

44. …And Make Debugging Easier For EVERYONE Knowing what we’re handling makes for easier debugging

45. Case Study: Email On Exception Setup custom logging levels Customize distribution lists and message content based on each level Creep artists out when you show up at their desks unannounced right after they error

46. “Work Smarter, Not Harder”

47. Change Starts With Tech Art

48. Begin At The Beginning

49. Questions? seth.gibson1@gmail.com linkedin.com/in/sethgibsontd facebook.com/djTomServo twitter.com/voMethod