Friday, December 30, 2016

New Year Studio Resolutions to Try

This time of year is awash with suggestions for New Year's resolutions.  So here are a few more for game developers for 2017.  If nothing else, they might keep your mind off of politics a bit.

Always be learning - Teach yourself new techniques.  Expose yourself to different ways of thinking.  It doesn’t have to be about games either.  An artist I know learned how to build Arduino electronics and started joining us programmers for lunch to ask great questions.  He invited us to join the artist's weekly nude drawing class (but I’m not sure any of us took him up on it).

Pace yourself - Crunch is inevitable, but lots of research has shown that beyond several weeks, productivity can drop below that of normal hours.  It can take courage to shut down the studio for a weekend after several weeks of crunch, but it is worth it.

Micromanage less - Coach and encourage your developers to solve problems on their own.  When they come to you with a problem, ask “what have you tried” instead of providing the solution.  When you see a problem they don’t, ask them if they see the problem instead of telling them what to fix.

Grow cross-discipline communication - Problem solve across disciplines instead of handing off design docs.  Find ways to communicate more.  Steve Jobs famously designed the Pixar building to “force more interactions” between disciplines.  Look at ways of generating conversations through cross-discipline brown bag lunch sessions or even trying different seating arrangements.

Play your own games often and early - Many mechanics that make games great didn’t appear in the original design document, but emerged mid-development from the team.  Many of my best memories of game development come from end of day sessions playing our game and talking about improvements over a beer.  The earlier you can enjoy even a core mechanic or two, running with placeholder assets, the more engaged the team will be with the game.

Invest in people - Game development is craftsmanship, not mass production.  Traditional craftsmanship requires years of apprenticeship before an effective level of skill is reached.  Assume people are at different levels of skill and help them grow where they need to.  Sure, they might take their new skills you invested in and go someplace else, but a studio that respects people enough to invest in them usually has great retention rates.

Enjoy each other - Do things outside of work.  Don't let the schedule and stress kill relationships.  Decades from now, when you are reflecting on your career, you’ll remember the people you worked with more than the games you made.

Thursday, December 22, 2016

AGD Practice - The Silent Count

Daily Stand-ups have a frequent problem: the talkative coach (or Scrum Master).  There's nothing wrong with their speaking during the meeting, but if we want the team to take ownership of the work, the developers need to do most of the talking.

Coaches usually mean well, but they often come from a management background in an organization where work is assigned to developers and answers mainly come from management.  This creates a pattern of developers expecting problems to be solved by management.  We want to create a new pattern, where they solve most of the problems on their own.

Coaches need to coach developers through these pattern changes.  This requires emboldening them and sometimes creating a void that they must fill themselves.

A good practice for coaches is to ask questions - even questions they might know the answer to - and to wait for the answer.  The practice is to silently count to 10 seconds after you ask the question.  Don't be surprised if it takes 6-7 seconds before someone speaks up...long silences can be uncomfortable for a developer who knows the answer, but is a bit shy in speaking up.  If you get to 10 seconds and no one has spoken up, ask a bridge question; a question that is easier to answer and gets you halfway there.


Coach: "Are we on track to hit our sprint goal this week?"

Silent count to 10.

Coach: "OK, are there any things that you might be worried about?"

After a few seconds a developer speaks up: "I'm not sure I'm creating the right animations for the melee".

Another developer speaks up: "I can sit with you after the meeting and go over what we need".


Creating a pattern of solving problems among developers, without direct management supervision will give you one of the greatest benefits of self-organization.  Having eight people solving 90% of the problems is a lot more efficient and effective than you being the bottleneck.

Tuesday, December 20, 2016

What we need is better planning, not better plans

"Plans are worthless, but planning is everything" - General Dwight D. Eisenhower

On June 6th 1944, D-Day, the largest seaborne invasion in history began the liberation of German-occupied northwestern Europe.  156,000 soldiers landed on the beaches of Normandy or were air-dropped behind German lines.  The battle could not have been won without extensive planning, but the it did not go according to plan.  Many paratroopers landed far from their targets as did landing craft.  German defenses were stronger in some areas forecasted and weaker in others.

What made the battle successful was not the plan, but a combination of the knowledge gained in planning, plus the initiative taken by soldiers and units to adjust as reality emerged.  This is captured in Eisenhower's quote above.

What we need is better planning, not better plans
I'm often asked "how much should we plan?".  The answer is always necessarily vague.  We plan differently for things that are certain and for things that are uncertain.  Planning for things that are certain ensures that we are focused on a shared goal.  Planning for uncertainty results in a prioritized list of experiments that will remove uncertainty so we can make better decisions in the future.

Examples of decisions best made earlier:
- Deciding the genre of game.
- Deciding what engine to use.
- Knowing what constraints a franchise has.

Examples of decisions best made later:
- Deciding how many bullets each weapon carries in a magazine.
- Deciding how many NPCs are in each view.

Deciding earlier or later depends on the cost of making that decision.  The phrase "deciding at the last possible moment" applies.  You shouldn't decide how many NPCs should be in view until your graphics engine is running well enough to tell you how much it can draw at 30 FPS.  Conversely, you don't want to decide which engine to use a month before you release your game.

An illustration
I'm a fan of Donal Reinertsen's work.  One of the tools he applies is called the u-curve.  The u-curve illustrates the tradeoff between two opposing factors, such as the cost of planning too little vs. planning too much as a sum of those costs:

The graph shows the cost of planning based on how much of it we do (the red curve).  This curve is based on two components: How much planning we do on uncertain things and how much planning we do for things we are certain about.

The green curve shows the cost of planning away uncertainty with detailed design up-front. As we do more up-front planning--making more and more decisions about the details of our game--the cost of those early decisions adds up.  For example, when we've designed and built numerous gameplay missions based on speculated numbers and behaviors of NPCs, the cost of reversing those decisions late in development increases.

The blue curve shows the the costs of planning things we are (or become) certain about.  If we don't make decisions about the engine, game genre or even what programming language to use, the cost of making those decisions later will impact us more.  We can make lots of decisions early:  NFL games have 32 teams and stadiums.  FPS games have online multiplayer.  Mobile games should at least run on iOS and/or Android.

The red curve is the sum of those cost curves and the sweet spot is where the cost is lowest.  So, getting back to the "how much should we plan?" question, the answer is "where the cost between planning and iteration is lowest".  This depends on the uncertainty of various parts of the game and the cost curve is different.  Determining that starts with an honest assessment of the risks and uncertainty of your game and a willingness to take steps into the unknown in places you may have only felt comfortable trying to plan-away in the past.

Tuesday, December 13, 2016

Define Done and Avoid Death Marches

How often do you reach an alpha milestone on schedule only to have post-alpha work bite you?  Extended crunch, cut features and assets result in burn-out and a game’s quality damaged by last-minute compromises to get it out-the-door. The culprit is usually “debt”.  Debt is that extra work which takes a feature from "works on my PC" to a feature that a player who buys the game could use. Like financial debt, development debt has an interest rate; the longer you hold onto the debt, the more expensive it becomes to eliminate. It's also not just technical debt.  Art and design debt exists as well.

What does “done” mean at your studio?  When I ask this question onsite, I often hear some anecdotes and definitions such as:   
•    “It compiles on my machine.”   
•    “I’ll know it when I see it.”   
•    “It’s 90% complete”   
•    “It’s coded” (or “it compiles”).   
•    “It's done, but it needs final assets.”   
•    “It’s first pass” (out of an undetermined number of passes)

Usually there is no agreed-upon definition.  This is a big warning sign on the road to death-march-ville.

One of the initial challenges in adopting agile is defining a more frequent and universal definition of done (DoD).  As with all agile practices, it’s emergent; Teams inspect and adapt the game and their work and continually improve the DoD.

For Scrum every sprint must meet this definition of done before being accepted as done by the product owner.  For Kanban, a work item cannot be pulled into the next stage until it meets the definition of done in it's current stage.  For example, a rigged model cannot be pulled into animation unless all the naming conventions for the skeleton are met.
Non-functional Requirements

A DoD is derived from a set of non-functional requirements.  These are attributes of the game that apply universally to all work , such as:   
•    The game runs at a smooth, playable frame-rate   
•    The game runs on all target platforms   
•    The game streams off disc cleanly   
•    The game meets all Facebook API standards   
•    The code meets the coding standards of the studio   
•    The assets are appropriately named and fit within budgets   
•    All asset changes must be “hot-loadable” into the running game   
•    …and so on Non-functional requirements are never done.

Any feature added or tuned can impact frame-rate, so by the end of a sprint we must ensure that any work added does not slow frame-rate below a minimum standard.  If it does, it's not considered done.

Multiple Definitions of Done

Because potentially shippable doesn’t always mean shippable, there often needs to be more than one DoD,  I’ve seen teams create up four DoDs, which cover anything from “prototype done” to “demo-able done” to “shippable done”.  These identify the quality and content stages that large features, which take longer than one sprint to be viable (called epics), must go through.  Keep in mind, that these definitions shouldn't allow the team to "waterfall" the work.  Even if you have a set of cubes flying around for targets, before animating creatures are ready, those cubes can't crash the game or impact frame-rate too much.  If cubes are killing your frame-rate, you have more important things to address before adding animating creatures!

Starting Out

The best implementations of DoDs start small and grow (that can be said of a lot of good practices).  Start by identifying a few of your larger areas of debt in a retrospective and pick some low hanging fruit DoDs.  For example, if basic stability is an issue, a definition such as "the game can't crash while using the feature" is a good starting place.  Don't be surprised if this definition impacts how much the team can commit to every sprint: quality costs...but that cost will be recouped with interest over time as practices are improved.

What Post-Alpha looks like with a Good Definition of Done

When we started using agile, I’d hoped we could do away with the alpha and beta stages of game development.  In practice, for major initial release of a game, we still needed time after feature-complete to balance the game.  What we did lose were the death marches and compromises.