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

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

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

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

So, What Is This "Tech Art Infrastructure"?

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

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

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

And Who Owns The Product?

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

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

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

Building Blocks

Always Use Protection

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

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

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

“Don’t Let It Go To The Judges”

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

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

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:

Choose Your Weapon

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

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

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

Laying The Foundation

So How Does This All Work?

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

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

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

How Do I Know It Will Work?

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

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

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!

What Happens When It Doesn't Work?

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

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

Case Study: 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

“Work Smarter, Not Harder”

Change Starts With Tech Art

Begin At The Beginning

Questions? linkedin.com/in/sethgibsontd facebook.com/djTomServo twitter.com/voMethod