Reflections

Wow.  That was a particularly extended hiatus from posting, huh?  Simply put, I haven't felt like writing for a while and I didn't have a lot that I wanted to share.  However, that's going to change in these last few months before the end of the year.

With, TITAN officially cancelled:

And with OVERWATCH officially announced:

I feel like I can now write about my experiences at Blizzard.  For the record, I left Blizzard earlier this month to pursue new opportunities.  Regardless, I am still bound by my NDA and so what I plan to share in the near future will be focused more on lessons learned and personal observations.

If you come here expecting juicy gossip or spoilers, you've come to the wrong place.  However, if you come here to read about industry leadership, then "stay awhile and listen" (read, actually).

 

More to come soon.

GDC 2014 - Day 3 - Artists

The third and final day of the Art Leadership Roundtable was intended for Artists.  By the last day of GDC, people tend to be tired and a bit less-likely to speak up.  As such, I've learned to permit the topics to run a bit longer and on less-dramatic topics.  Given that the day's topics were intended to be Artist-centric, I wanted to provide a chance for mentorship -- a chance for art leaders to answer the questions that artists might have.

There are many art leaders in this room.  But we didn't start out as art leaders.  We started out as artists.  Then we found ourselves in leadership positions and we stumbled and failed and learned and became better leaders with time.  This session is about giving back to the artists -- to the next generation.  What questions do artists have about leadership or direction?  What insight can we provide into how projects and teams are managed?

The session got off to a rocky start.  If I recall correctly, the first person asked how to get artists to relinquish the rights to their artwork for use in mobile applications.  Interesting question, but completely unrelated to the topic that was proposed.  One person responded with "talk to a lawyer" and then we quickly redirected away.

The second attendee to respond presented a much more relevant issue.  I can't remember exactly how the question was phrased, but the key concern was getting artists to do what tech art is telling them to do.  The speaker expressed frustration in working with artists who only care about the visuals and don't want to understand how the pipeline works or care about technical limitations.  What I wrote on the notepad was:  Tech Art vs. Art.  FIGHT!  However, this is a very real concern that exists at the intersection between visual goals and the medium (technical limitations) within which we work.

Given the way the question was phrased, attendees were asked what techniques they used to engage artists in the pipeline and technical processes early in development.  Here are the suggestions that were offered:

• Work with a select group of artists (role models) to create benchmark visuals which lead the content creators to the pipeline.  Show them the results first, then the tools that achieve those results (rather than the reverse).  In short, make the tools part of the art style.
• When it comes to tools development, involve artists in the mockups of interactivity.  Encourage them to think about user experience.  How the tool functions is just as important as what it does.
• Active technical mentorship.  Weekly discussions or informal "brown bag" lunches where pipelines and tools are open to discussion and dissection.
• In the cases of student projects (where some students create content and others create rigs), implement a clear mediator (faculty) to resolve conflict.
• Develop visual documentation.  Documenting tools is an important component, but artists tend not to read long-winded instruction docs.  Image-heavy documentation is more likely to be read and understood.
• When creating new tools, ensure you're focusing first on the big problems.  Leave the micro-details for later.  Over-engineering is the Achilles' heel of tech art, and artist-involvement can help to avoid that scenario.
• When new pipelines are implemented, make sure artists are actively using them from that first day.  Don't roll out a new tool that artists aren't planning to use until 2 months later.  Coordinate development to happen concurrently so that the tool evolves with the art staff.

We also talked about why this type of issue arises.  What causes fractures to erupt between the tools group and content group?

• Authoring tools without input from the users.  In this scenario, artists are less likely to use a tool if they felt it was created without their opinions given reasonable consideration.
• No clear value.  People are inherently suspicious of change and new tool deployments are no exception.  Artists won't embrace a tool that is rolled out without a sense of investment or especially if they fail to understand the benefit.

Last, we talked about how to keep a fracture from forming when tool deployments fail or the unexpected happens (as it often does).

• When things go wrong, involve the artists proactively.  Postmortem new tools quickly and be clear about what next steps will be taken (and which won't be taken).  The whole purpose should be to define and redefine the goals.
• Encourage artists to question the workflow/pipeline.  Just like games, rarely are tools perfect on their first iteration.  Artists need to be open to the iterative process, but they will only engage in that process if they feel encouraged to engage and see the results of their feedback take shape in future iterations.

There were a handful of other comments offered, but all of these represent the most significant components.  Artists need to be involved in tools development.  And tech artists need to engage them.  This is about the craft of what we do.  The final result will amount to shockingly little if people refuse to pursue the craft, but the responsibility belongs to both parties.  Exploration and iteration are cultural components of learning.  Learning is how we progress.  If we fail in that charge, we fail to advance our discipline and our industry.

As the topic was drifting to an end at this point, I asked the attendees if there were any more questions from artists that people in leaderships could respond to.  One student attendee was bold enough to raise her hand and ask the following.

Why aren't more studios hiring for entry-level positions?  How are students expected to get into the industry in the current workforce climate?

• As to the why, the first response highlighted the cost in mentorship and training.  Much has already been written and discussed about the competitiveness about the job market.  However, the additional reality is that it requires a lot of effort to "train up" new hires with little experience.
• As to the how, another attendee responded that students need to be prepared to do literally anything to get that first industry position.  If they are still students, they should be applying for internships.  If they've completed school, then they need to look for tangential entry-points such as QA.  In fact, this comment was repeated multiple times in many ways, the culmination being to just "get through the door."
• At this time, the counterpoint was offered that QA Leads and Managers hate losing good people to development teams.  It is frustrating to train people into a position where they have impact and then lose them once they've built up a breadth of knowledge.  When pressed for how to successfully initiate such a transition, it was suggested that those entering QA speak to their long term plan but also be dedicated to the QA role for which they are applying.
• Another responder commented that their studio is more isolated from the industry, and so they make more of a concentrated effort to draw hires directly from the schools.  The implied suggestion here was that students should explore studios that aren't already in dense, competitive market locations.
• The comment was offered that too many students or recent graduates are expecting to just land in a AAA studio right out of the gate.  This person strongly suggested that job seekers have more realistic expectations.  Given their overall lack of experience, it was suggested that they tap into the indie development community, where they might be able to explore contract opportunities that could afford some early experience.  They should also actively pursue contributing to a mod, a gamejam, a hackathon or whatever else might build upon their experience and expand their network.
• Wisely, another attendee suggested that students really need to solicit and collect personalized portfolio feedback.  Many schools are cranking out students whose portfolios are largely interchangeable and fail to highlight the students' individual strengths or area of interest.  I can agree that I've seen way too many of these as well.  In order to combat the pool of portfolio mediocrity, students need to network with the intent of soliciting feedback.  When you get out of school, you have a job -- that job is to replace everything in portfolio with a stronger piece.
• Although I don't recall the context, the book Mastery by Robert Greene was recommended.  LINK
• Another attendee lamented that students miss out on opportunities from poor philosophical instruction in school.  Students become so focused on creating the "cool piece" that they fail to grasp the context.  They don't think about how the content is part of the product.  In order to combat this problem, it was suggested that students build a "visual experience" instead of just things and then actively share their work with the greater artistic community to get feedback.
• On a related note, it was also strongly suggested that students and new developers become more visible in the development community.  They should be participating on forums and in art challenges.  This was coupled with the feedback that it is no longer sufficient to simply submit a resume and a cover letter.
• The final (and frequently heard) comment was that new artists need to cater their portfolio to the prospective employer.  They must also be willing to build long-term relationships and not become bitter if it takes a long time to land your "dream job."

Although there was only time for two topics, the day ended on a high note.  Once more, I would like to thank everyone who attended.  Below you will find the unedited feedback from the session.  My comments, if warranted, were added in orange.

Art Leadership Roundtable: Artists

Friday, March 21 from 2:30 PM to 3:30 PM

Room 112, North Hall

Total Headcount: 82

Percentage of Evaluations Returned: 42.68%

Percentile in Visual Arts Track: 35th

Percentile in Overall GDC Main Sessions: 37th

Session Totals (This Session)			All Main Sessions	Visual Arts Track
Response	Count	Percentage of Responses	Average Percentage of Responses	Average Percentage of Responses
Excellent	22	62.86%	62.42%	57.67%
Good	8	22.86%	31.02%	34.84%
Poor	4	11.43%	5.61%	6.59%
Terrible	1	2.86%	0.95%	0.91%

Comments

Very insightful and helped to network quite a bit. Surrounded by the people you want to work with and having them help me get started in the industry is just wonderful.

This was a leadership round table and we talked way too much about how to get a job as a student which we aren't anymore.
While I understand the sentiment, the simple fact is that there are MANY students in attendance at GDC every year.  The idea that their questions should be ignored is unwise and, in my opinion, an example of poor leadership

The third session was dedicated to artists but focused on new artists entering the industry. That should've been done in a careers roundtable versus an art leadership roundtable. He should've focused on the art leadership and art management. I waited in the first two sessions and did not get in. Was looking forward to a revamp of the things they discussed in those meetings at this one. Will try again next year.
I regret that you were unable to attend the previous sessions.  I hope that you are able to learn from the notes from those dates.

This was pretty great. Answered a lot of questions.

I was very very disappointed in this session. I think that the type of artists to attend this suggestion should have been defined as technical artists.  This clearly was not for artists who deal with mobile devices. I was very disappointed that my question on licensing art was clearly told that it would be discussed if needed after this session. What is the audience you expected to come to this session? Perhaps there needs to be a session for casual gaming or casual gaming art.  Artists are used in this format as well considering this is a GDC not just in the XBOX or playstation platforms.
I'm sorry you felt this way.  However, I fail to see how an exploration of the question of tech art / tools or gaining entrance to the industry is exclusionary towards mobile development.  Given the fact that your question about licensing art received silence and blank stares from the room, I think it was reasonable to redirect rather than to force a topic without traction.

This was my first roundtable.  Keith was great at leading the discussion and keeping the room on topic.  I primarily attended this one despite some others I was interested in because it was not recorded for the Vault.  It was interesting, but I think I may stick to the regular talks in the future.

Keith has a good command of the room, although I was a little disappointed in what we discussed in the roundtable. A lot of it seemed like rehashing of information about how to break into game art that I've seen plastered all over the internet.

great information and topics discussed for new and old art directors.

Keith did a nice job moderating this roundtable. The group did not have a great number of ideas they wanted to discuss at first, so he goosed the conversation. It flowed nicely from there. His follow-up promise of notes from the roundtable sessions are also greatly appreciated for those of us that could not make earlier ones.

Good discussion.

again iT NEEDS TO BE LONGER!!!!!!!!!!!!!

Best part of GDC for me.

Always a good dicussion

Talk was ok, a bit too much focus on "How do i get a job as a student"

Keith is a fantastic moderator - best of all the roundtables I have attended at GDC.  Please bring him back for future sessions.

 

GDC 2014 - Day 2 - Art Leads

The second day of the Art Leadership Roundtable was intended for Lead Artists.  This ended up being re-translated in the announcement to Art Leaders.  This wasn't a major problem other than the fact that it may have set different expectations.  I tried to reset this direction at the beginning of the session.  Ultimately, it just meant we had a large population of attendees -- something that continues to amaze me each year.

Art Leads are often put into their leadership positions without a great deal of leadership training or guidance.  Given that, we should discuss our own leadership challenges.  Where did we (collectively) fail?  How did we resolve the problem?  What did we learn?

 

Lesson 1: External Development

This was a pretty big question and received a fair amount of silence in response.  One bold attendee was the first to raise his hand and talk about working with contractors.  In his particular example, the Lead was challenged with working with an outsourcing team to develop content for his area.  When pressed for the specifics of the problem, the attendee spoke about a "lack of vision" for the project.

When talking about "lack of vision" relative to an outsourcing effort, this can manifest in more than one way.  For one, the external developers (the outsourcing team) may lack the vision.  They may not understand the style.  They may not know the purpose (or the gameplay) behind the content they are generating.  Either way, the Lead is tasked with making sure that the assets being created are consistent and meet the needs of the project.

The other area where "lack of vision" manifests is from the internal team.  The team may fail to understand the vision of how outsourcers are part of the development effort.  They may see external development as the "enemy" and seek out opportunities to point out the failings.

Outsourcing has certainly been a topic of past roundtables, and I won't go into the full breadth of it here.  However, regardless of which "lack of vision" scenario you may be facing, the Lead is going to find themselves in a position of micromanaging the relationship.  First, the Lead will have to micromanage the content being created externally.  Furthermore, this antagonism towards the external team may motivate the Lead to micromanage the internal team to the same degree (out of a sense of fairness, out of a sense of needing to maintain close contact with the onsite team, or out of a perceived need to keep the groups separated).

In this particular case, the attendee spoke of artists being unable to see the fight.  They weren't exposed to the Lead's struggles.  This may have been the fight to bring the external development team in line.  This may have been the struggle with the project directors to get others to see how external development impacting the team.  Regardless, what the team did see was that the Lead's time was being invested more heavily in the external team than the internal team.  This perception led to a growing loss of trust.

How was this resolved?

In this particular story, the problem was resolved by bringing a new Lead into the picture.  Although a change-up in leadership is rarely desirable (and always difficult), sometimes it is necessary in order to reset expectations.  The new Lead then set up regular one-on-one's with each member of the team to 1.) preserve the vision of the project and the understanding of outsourcing's place in the development goals and 2.) ensure that regular contact between the Lead and the internal team members was happening.

Lesson 2: Student Project

The next attendee to speak up was a Lead on a student project.  Rather than immediately dismiss the student project as "not real game development," I wanted to hear more.  I suspected there was something to be learned in this example, and so I encouraged the participant to share more of the experience.

The basic description was that, as a student project, it was relatively small with limited resources.  However, there were a lot of unmet expectations from the various team members and the project ended up a mess in the end.  The attendee was looking for direction from the audience on how to address these types of projects in the future.

So, how do try to resolve this type of scenario?

Several suggestions were offered.  For one, build a scalable project with clear "kill gates" when you start missing deadlines.  More importantly, establish more frequent check-ins between all team members (especially in the early stages of development).  The check-ins should be focused on priorities and current status as well as an opportunity to reinforce expectations.

In addition, despite being a smaller student project, it was suggested that clear milestones be partnered with an asset tracker.  "Done" can mean different things to different individuals, and so an asset tracker could help ground progress in reality and the milestones can be tied to the specific kill gates as that second layer of reinforcement.

Another attendee suggested that students not jump straight into trying to create the final project.  Rather, attempt some smaller and time-boxed projects.  Spend ~1 week doing a demo (or vertical slice, or core combat, etc.).  These will accomplish two things.  One, it will prove out the technical feasibility as well as scope of the overall project.  Two, it will teach the team how to work together or prove out which members of the team aren't a fit.

It was also suggested that the team formalize its structure.  Even a small team should have clear areas of authority and responsibility.  However, in the case of any student project, this MUST be supported by the instructor or faculty.  Failure to meet your responsibilities must have real consequences -- just like the real world.  The problem with student projects is that technically everyone is a peer.  Formalizing your structure (with faculty support) will break through any perceived ambivalence or half-assed contribution.

Lastly, student groups should investigate how successful mod communities organize themselves.  There are groups who have figured out how to operate in similar situations.  There's no upside to figuring it out on your own when others have already learned the hard lessons.

Lesson 3: Inexperienced Authority

This is a tough one.  The next participant to share with the roundtable spoke about their experiences working with an outside party.  This individual(s) had a great deal of authority over the project, but not much experience working with the actual development team.  This is an extremely common thread, and it is one that persists in relationships where the development team is independent of the publisher.

Regardless of the specifics of the scenario, it doesn't take much effort to see how the relationship can potentially go badly.  I can speak from personal experience when saying that this type of scenario spins out of control from a lack of respect or consideration between the two entities (developer & publisher).  In this particular tale, the attendee spoke about a growing lack of trust and the diminishing sense of ownership.  Ultimately, the issue did not get resolved and the project died.

How do you resolve this type of situation in the future?

There was a variety of advice offered for when the relationship starts to sour.  To start off, you should make it your responsibility to be the first to involve the other entity in your work.  Maybe you setup regular checkpoints.  Maybe you establish monthly milestone reviews.  Moreover, you make sure that the other group feels like they are part of your group (rather than being separate).  If possible, make them feel part of the creative process.  The whole goal is to engender trust -- with the realization that this also takes time (and consistency).

Someone pointed out an interesting perception while on this topic:  Too many artists don't care about the business of making games.  While I am not going to claim to know the overall trend of artists across our entire industry, I can say that I have certainly spoken with a lot of artists who are reinforcing this perception.  The only counter to this limited mindset is through educating younger (and sometimes seasoned-yet-myopic) developers in the business of game development.  This is difficult as there has generally been a "behind the curtain" approach to the business of development for years.  This is something I feel needs to be stripped away.  I could probably write a separate blog post about this topic alone.

However, in the short term, it is for this reason that I elect to refer to our profession as game developers rather than artists, designers, engineers, producers, etc.  The latter are our roles in development.  But we are all developers.  The adherence to the role or the title does more to separate than it does to unite.  It is also for this reason that I changed the name of the roundtable from the Art Director & Lead Artist Roundtable to the Art Leadership Roundtable.

Lesson 3.1:  Catharsis

In response to the previous topic, one attendee shared a story about about a publisher (who is no longer in business) who was only interested in copying another publisher's game and just giving it a different title.  We see a lot of this in our industry, but this particular tale was exacerbated by the fact that the publisher's desired source kept changing based on whatever new best-selling game had come out the previous quarter.

There was no resolution to this problem.  It was purely catharsis.  And yet, a small lesson can be found.  Some problems can't be fixed.  Sometimes leadership lands in the hands of the ill-prepared.  Sometimes you are required to follow direction, even if you don't agree.  And sometimes things fail, despite everyone's best intentions.

Catharsis can be closure.  However, I will also caution that catharsis should never be used an excuse not to think about (and learn from) past experiences.

Lesson 4: How I Killed a Project

Candidly, I didn't take very good notes as the next attendee shared his personal story.  The short version, as I recall it, was that he was the new Lead on a small team with a rather extensive (and unrealistic) scope.  As the Lead, he felt compelled to constantly make sure the team was doing what he wanted them to do, to work himself as hard as possible and maintain control over the whole development cycle.  He felt responsible for creating the best work in the game and also for fixing the work of others that didn't meet his expectations.  The attendee spoke openly about the frustration he felt from the team, of the ridiculous hours he worked and of his own waning health during the worst of the development cycle.

He then told everyone that the project was completed.  The previous paragraph doesn't do his tale justice.  As such, I should point out that no one in the room expected the project (as he described it) to have been completed successfully.

How did he resolve the situation?

When pressed for details on how the project recovered, the attendee admitted that he couldn't accurately recall that development cycle.  The long hours and high stress had robbed him of the memories of the experience (kinda like child birth, I guess?).  I seem to recall this was also his last development cycle and that he had since moved on to academic and a teaching position.

Given that, I pressed him for any lessons he feel like he learned going through the experience.  First and foremost, he talked about realizing that the leader can't always be "on the front line" themselves.  The lead has to learn to delegate and entrust responsibility to others.  Moreover, he talked about setting realistic expectations.  The team was small and the scope of the project was already unrealistic.  This created an environment whereupon more unrealistic expectations could be heaped.  As such, he set unrealistic expectations for himself, for the new hires to the team, for the quality of the work and for the scope of the project.  Ultimately, the most significant unrealistic expectation he set was for himself -- and yet the project was completed.

I feel confident assuming that there are some of you reading this right now who are reflecting back on your own experiences in our industry.  Reflecting on your own unrealistic expectations.  How did that work out for you?  Was it a better project in the end?  Were you a better developer?  Or did the cost prove too high?  Did you learn something from it?

Practical Resources in Leadership

For the last 10 minutes of the roundtable, I asked the attendees to shout out key philosophies as well as resources (books, videos, training, etc.) that had helped them become better leaders.

I've already collected that list in a separate blog post.  If you haven't read it yet, check it out here:
http://hyphenatedkeith.blogspot.com/2014/05/gdc2014-become-better-leader.html

 

Speaker Evaluation

As before, I wanted to do something new with the write-up this year.  Here is the raw, unedited report from the day's roundtable.  If I felt a comment warranted a response, I added it below in orange text.

Art Leadership Roundtable: Art Leaders

Thursday, March 20 from 4:00 PM to 5:00 PM

Room 112, North Hall

Total Headcount: 82

Percentage of Evaluations Returned: 42.68%

Percentile in Visual Arts Track: 91st

Percentile in Overall GDC Main Sessions: 86th

Session Totals (This Session)			All Main Sessions	Visual Arts Track
Response	Count	Percentage of Responses	Average Percentage of Responses	Average Percentage of Responses
Excellent	27	77.14%	62.42%	57.67%
Good	7	20.00%	31.02%	34.84%
Poor	1	2.86%	5.61%	6.59%
Terrible	0	0.00%	0.95%	0.91%

Comments

First of all, thank you also for all of the kind words written below.  I appreciate that people are willing to invest their time attending these sessions.  I hope that others are learning from the roundtable and building long-term relationships across the industry. 

 Best round table of the conference, Keith is amazing as a moderator and a leader

Very good learning lessons and experiences

A little scattered, ended well

This was my very favorite pannel, learned a lot

This was awesome!

As long as the "horror stories" are followed up by times of learning, analysis, and review, it's even better.  Keith does a good job of leading the roundtable, making sure it proves challenging instead of just a swapping stories sessions.  A larger room would be better as a lot of people wanted to get into the roundtable, but could not.
I concur.  Sharing failures is only valuable if we share what was learned or how to react when faced with a similar challenge.  Unfortunately, I disagree with the larger room.  We've tried that in years past and I feel that it does more to hinder interaction than encourage discussion.  However, I agree with the sentiment that it is unfortunate that not everyone can attend.  I hope some of those who don't make it through the door at least get something from these posts.

Content was relevant and the roundtable was run in an efficient, focused way. 90 minute session would be more productive.
I've asked for a 90-minute session.  We'll see if that ever happens. :)

This is the most valuable aspect of GDC by far. I just wish they weren't becoming so crowded!

great panel.

I normally love this session. This particular one seemed like it lacked focus, and was geared towards bitching about problems.
I apologize if the discussion seemed to come across as "bitching."  The intent was sharing and learning.  I agree that there is a fine line and I will try in future sessions to make sure we're on the correct side of it as much as possible.

Very honest feedback and discussions! Would love to see moderated so others can speak as a few select contributors dominated the floor time. 
Good feedback.  Thank you.

 NEEDED MORE TIME!!!!!!!!!!

Best sessions of GDC

It was an alright round table. I feel like not much came from the discussion though. I feel like more topics could have been covered.
This is a perpetual struggle.  More depth or more breadth?  I do try to find the right balance or "judge the room" for when a topic has momentum or needs to be shifted.

 

GDC 2014: Day 1 - Art Directors

As the first day of the roundtable was dedicated to art directors, I opted to start with an important, but otherwise easy topic:

How do you communicate vision to a team?

• The first attendee to respond spoke of "town hall" meetings.  The purpose of these was to gather the team to ensure alignment.  This type of meeting helped to maintain momentum and provide context behind the decisions which were being made.  Later on, this idea was further reinforced as "weekly share sessions" where various workgroups regularly demo their own progress (successes and failures alike).
• Another participant advocated the establishment of "core pillars."  These would become the central tenets for decisions.  Core pillars also served to establish "confidence" within the team insofar as granting artists the ability to make their own decisions.  When pressed for how the core pillars were transmitted, the participant offered the ideas of posters (visual reinforcement) as well as frequent dialog (both individual and team)
• It was also suggested that monthly milestone reviews were part of communicating vision.  While I agree, I think it is worth noting that milestone reviews are reactive and the most successful vision setting is actually proactive and comes at the front of a milestone rather than the end.
• Communicating vision was also accomplished through paintovers of prototypes.  Again, I think you risk becoming entrenched in reactive direction with this example.  Paintovers can be incredibly helpful in "fine tuning" the direction, but run the risk of wasted effort if they rely too heavily on throwaway prototypes.  Paintovers also need context, so regular interactions and context is equally important in this example.  However, developing concept paintovers from real gameplay is sometimes more effective than just a "beauty shot" which may not relate to the game itself.
• Another suggestion was to storyboard the game.  I've certainly heard of similar cinematic approaches to art direction for games.  Personally, I feel that this becomes more problematic relative to the scale and scope of the game.  Storyboards can infer a certain amount of rigidity and therefore run cross-purpose to the iterative nature of interactive development.
• Yet another example was the creation of key references or touchstones for direction.  In these cases, being able to refer to other media (film, artwork, other games, etc.) helps people to understand the vision more quickly than long design documents.  At the same time, I've also seen the collection of references cause inconsistent vision.  Thorough context must be given for why the reference is appropriate.  In the example of using a character from a film, should the reference be looked at for overall mood?  For materials?  For color?  Reference can be interpreted in lots of ways and most are incorrectly.  The AD must ensure that the reference is interpreted properly.
• Wisely, another participant commented that the technique used to communicate the vision is not the most important.  Rather, the director must ensure that he or she is "passing the bus test."  Vision must be appropriately delegated out to the team, whether that be through a formal leadership structure or informal ownership.  This goes hand-in-hand with the comment above about confidence building.  The director cannot (and should not) be on hand to answer every possible question.
• One new option I heard this year was the creation of screen recordings.  Using Camtasia, the director/lead would record a voice-over as they reviewed some aspect of the game.  They could then show specific examples of where direction or content was most successful.  These were then uploaded to a communal dropbox where all team members had access.  Moreover, the videos could then be watched by new hires as part of their onboarding process.  My only concern for this technique is the amount of up front time this may require from the leadership group.  However, if they are consistent in execution, then I would expect the cost to drop off significantly over time as the value increased as the team grew.
• Another attendee mentioned the sizzle reel.  This one comes up frequently.  For those who may be unaware, this is a video version of the reference/keystone option listed above.  The biggest upside to this option is that it can potentially generate much more team excitement; however, it is also subject to the same drawbacks if viewed without context and detail.
• Rather than spending so much time on collecting reference or concept art, another person suggested the focus be spent on developing real-time prototypes.  The downside to a lot of sizzle reels, paintovers and vertical slice demos is that they are often tightly scripted, hacked together and/or don't represent an accurate picture of what is reasonable.  The suggestion here was to, instead, focus on developing a real prototype and then find the style within the emerging technical limits.
• Another example was Workshops or Live Brainstorms.  Ultimately, this sounds problematic to me.  Direction by committee is rarely effective except potentially within very small teams.  Otherwise, I still advise for a central vision holder.  That individual can still use these types of meetings to solicit input from other members of the team, but the final decision making authority should still rest with him or her.
• Lastly, and most importantly, it was suggested that PLAYING THE GAME is the most effective way to communicate vision.  Obviously, this is more practical in full production than pre-production (when you are still building the core game).  Regardless, this should still be reinforced.  I've seen teams late in the production cycle still rely too heavily on broad concept artwork rather than directing the game itself and allowing that to naturally influence the rest of the team.

For the second half of the session, I wanted to try something a bit different this year.  It required a bit of openness as well as the desire to share hard-learned lessons.

Tell us about your failures.  Tell us about "unintended consequences."  Also, what did you learn as an art leader that you wish you had known before you started?

• One attendee spoke about creating detailed asset spec sheets when they were new to the lead position.  Unfortunately, as time and asset volume increased, these sheets grew into unmanageable excel lists.
•  Yet another person agreed to having a similar problem with a OneNote document growing to similar unmanageable extremes
• One AD admitted to the mistake of trying to solve too many things in concept art.  At some point, you have to abandon the concepts and start building to find out what works and what won't.
• Another interesting example came from someone who directed the creation of a large animated sequence.  Unfortunately, the sequence was designed and created without soliciting team input or buy-in.  The end result was a finished sequence, but one in which very few team members were invested or excited about continuing.
• One amusing failure involved the creation of a number of character concepts.  Unfortunately, these were all generated from the wrong point of view and didn't communicate the right information.  In this situation, you can imagine that either the content creators had to infer a great deal or the concepts had to be re-created with the gameplay POV in mind.
• One common thread to almost all AD discussion was the focus on content over the game.  This year was no different, and at least one AD admitted to becoming too obsessed with details and thus missing the big picture.
• At the other end of the spectrum, a director pushed the concept group to really explore exaggerated character silhouettes.  Unfortunately, the game had a more realistic (rather than stylistic) setting, so the character ended up being messy, blobby and lacked readability relative to other elements
• Similarly, another AD lamented not finding the "signature elements" until well into production.  However, I don't have the sense that this was by intent.  Sometimes a style takes time to develop.  Ideally, this is something that needs to happen sooner -- and it shouldn't be delayed by the failure to just make a decision.  Regardless, a delay in defining the signature style will result in a delay caused by iterating on all of those assets that had been developed prior to that point.
• One participant admitted to spending too long trying to fix the broken parts of the game.  This is not a failure in defining a style, but sometimes the style may not work in certain situations.  Rather than admitting this limitation and moving on, an AD may feel motivated to force the solution.  Sometimes it's easier to just kill these things rather than let them consume your time.
• By comparison, sometimes you also need to know when to do a "deep dive" on a good idea.  It's a balancing act, either way.  This is why I advise time boxing your prototypes -- there has to be some point at the future where you walk away if it still isn't working.
• One AD admitting to the frustration of working with artists who just want to do art rather than be game developers.  I'm sure many of us have worked with this stereotype.  I know that different ADs have different opinions on the pure artist vs. developer.  I know I have mine.  Rather than advocate one position over another, I suggest instead that you define which is important for your studio/project/team and allow that to guide your actions.
• As much as I said that artists are this way, sometimes the AD falls into a similar conflict.  One participant admitted to making the mistake of expecting every asset to be great.  The byproduct of this expectation is that it slows down the development process and frequently requires a large external team to support the internal team.
• Unsurprisingly, one leader admitted to micromanaging creativity.  That's a common topic and a mistake that new leaders are prone to making.
• Another participant pointed out the lesson that the art leader's responsibility is to make sure their team's work looks good.  However, more importantly, they must ensure that the visuals properly communicate.  In order to do that, the lead must ensure that clarity of vision is found and maintained.
• Another attendee admitted to sometimes being too accommodating.  The intent here being to isolate the team from distractions or keep the conflict out of the bullpen.  I understand the desire to minimize distractions, but the risk to the team in this instance is the appearance of changes being erratic and lacking context.  Accommodation is certainly one path to resolving conflict, but as another participant pointed out, you also have to learn when to say no.
• Lastly, there were a couple of over-arching key notes on how to effectively manage a team.  Ideas which most of the attendees seemed to support and espouse
• Fail quickly.  Try lots of things, but don't be afraid to walk away from the bad ideas.
• Help artists to find the answer instead of outright telling them the answer.
• Make your decisions about the game.  Let the art reinforce the intent of the game.
• Share the vision.  Allow others to mentor and own elements of the game.

Speaker Evaluation

Lastly, I wanted to do something new with the write-up this year.  Here is the raw, unedited report from the day's roundtable.  If I felt a comment warranted a response, I added it below in orange text.

Art Leadership Roundtable: Art Directors

Wednesday, March 19 from 3:30 PM to 4:30 PM

Room 112, North Hall

Total Headcount: 87

Percentage of Evaluations Returned: 34.48%

Percentile in Visual Arts Track: 85th

Percentile in Overall GDC Main Sessions: 77th

Session Totals (This Session)			All Main Sessions	Visual Arts Track
Response	Count	Percentage of Responses	Average Percentage of Responses	Average Percentage of Responses
Excellent	23	76.67%	62.42%	57.67%
Good	7	23.33%	31.02%	34.84%
Poor	1	3.33%	5.61%	6.59%
Terrible	0	0.00%	0.95%	0.91%

Comments

Not enough time. great insights and enthusiasm about helping each other and up and coming leaders of the art world.

 Got quicker into discussion than previous round table years so a positive improvement. Still too big to be a real round table of huge value.

 More time for discussion would be better, with some more explicit control and guidance about the topics covered so it doesn't bounce inbetween just the usual complaints or concerns. 

 Excellent discussion, ambient noise was a bit distracting.

 Round tables are GDC's best invention. These also happen to be very well moderated!

Overly gabby participants stole the conversation and steered it into irrelevant territory. Questions were great. It would be nice if there was a little focus on soft skills.

 By far some of the best and most informative time spent at GDC. Keith was a great mediator and always kept the flow of the discussion moving.

Keith did a great job with this roundtable. I think the discussions went really well and moved at a great pace.

These round tables were the best thing about my trip to GDC! Please keep doing them.

These roundtables need better hosting. They quickly devolve into a single topic discussion. It might be better to pick three topics chosen by the group and spend 20 minutes on each.

Unfortunately, I tried that one year and it went VERY POORLY.  I'm not sure how to get a group that large to reach anything close to consensus on only 3 topics.  Ultimately, I've decided to control the topics myself and shift as I perceive the audience shifting.

Would be a good thing to make these larger rooms as I reslly wanted to attend this session but cciuldn't

I'm sorry you couldn't attend.  The rooms have been filling up at an astonishing speed in recent years.  However, I'm concerned about the rooms becoming so big as to discourage interaction (which is at the core of roundtable design)

Invaluable for people involved with Art Leadership