1 / 49

Seth Gibson Rapid Experience Development

Seth Gibson Rapid Experience Development. Build It On Stone. Begin At The Beginning. “Work Smarter, Not Harder”. Change Starts With Tech Art. Solid Infrastructure==Solid Productions. Improper Use Risks Slow Change. Stop Scripting, Start Programming. The Need For Tech Art Infrastructure.

sylvia
Download Presentation

Seth Gibson Rapid Experience Development

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. Seth GibsonRapid 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 OwnsThe 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/

  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 DoesThis 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

More Related