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