Here’s the second round of GDC Notes, typed up as my computer chugs through physics sims.  I’ll probably only be getting to Rob’s talk tonight, as I’m bouncing between tasks.  I also want to mull over the talk a bit, because it was one of the most important and thoughtful talks I saw the whole week.  Not as flashy or exciting as the visuals talks, and not as cut and dried as the debugging or database talks, but very well thought out and important.  I realize, after looking over my notes, that he’s describing a system and a culture very much like the one in which I did my internship, an experience for which I am very grateful.

My thoughts, where I decide to include them, will be in italics.

The slides and Rob’s (very dense) notes are available here.

Tuesday (Tech Artist Bootcamp) (continued):

Rob Galanakis – Bioware Austin, Ending the Culture War

  • “You have crappy tools because you have a crappy tools culture”
  • I had never thought of “tools culture” before, but that’s definitely what we had at Volition, what made it so possible for me to be effective even as a beginning intern.
  • Can you share resources and tools between teams?
  • You cannot have good tools and bad culture
  • Changing culture is hard
  • The Defining feature of a great TA is their impact on studio culture.
    • Streamlined workflow
    • strong communication
    • good code
    • This is one of the areas where I see the biggest need for/advantage of having a forked tech art discipline built in to a strong art program.
  • Good pipelines take a decade to build
  • Three Strategies
    • Figure out what Tech Artists and Engineering teams are good at
      • play to the strengths of engineering and technical art teams
        • Engineering teams are set up to build and maintain large systems
          • Engineering teams have more build, testing, and deployment infrastructure
          • More management means deliberate and manageable rate of change
        • TAs are good at working directly with content developers
          • TAs often start as content developers
        • TA teams are smaller and less managed than engineers
        • TA reports to, is taksed by, and is paid by content
          • Not engineering
        • Boyd’s Law – Speed of iteration beats quality of iteration
      • Engineers provide a solid foundation
        • TAs can/will not create a solid large system
        • TAs should iterate using the large systems as a base
    • 2. Replace adversarial relationships with positive structures
  • Programming, art, and design hate each other because they compete for the same resources (programming time)
    • Create mechanisms to share resources and share people
  • If you can’t trust the people who wrote the tech, you can’t trust the tech
  • content creation’s tools budget is self-sufficient and sacrosanct.  Don’t steal resources from other areas
  • Often, the poorest schedules are rewarded with the most resources, resources and people are shifted from functioning areas to the most mismanaged areas
  • Don’t use tools budget to patch holes in bad scheduling
    • Probably painful at first, if the studio is used to depending on this, but seems like it would lead to great advances
  • Content should control content’s budget.
    • they choose whether to spend budget on content or tools
  • Let Engineering control the tech
  • TAs can keep content developers away from bugs and issues in teh code
  • Tools Vision is powered by TA

That’s it for the evening.  I may at a later date go through and write more of my personal thoughts, but for now, labs are closing soon, and I have other work to do.  Hope  you took something away from this.