Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
October 30, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Developing by Demo: How Demo Creation Can Help Rather Than Hurt
by Harvard Bonin on 04/24/14 04:01:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


One of the most polarizing discussions on game teams often occurs around the hated, cursed Demo.  Every year, right around February/March teams start kicking it into high gear in preparation for the center of the universe in gaming – the Electronic Entertainment Expo (E3).  Occurring in June, E3 is the North American equivalent of The Great Migration.  Developers, publishers, journos, movie stars, sports stars and any number of random hanger-ons descend on the Los Angeles Staples Center trade show floor to see the latest and greatest new and upcoming video games.  There are huge presentations, props and parties all attended by the best and the brightest in our business.  And we all dread it.

We dread it because we know months ahead that we’re going to have pass something off as “finished” waaaaay before the development schedule allows.  It usually turns into a big crunch for teams as they struggle to implement finished systems and assets earlier than the natural course of development says they ought to be included.  On paper its sounds crazy.  What exec ever mandated some arbitrary date for the dev team having no knowledge about the sacredness and fragility of the development cycle? Madness.  But there is a method to this madness and in this article I’ll attempt to break down the key reasons why these demos and all others are actually good for development. In fact, I’ll advocate for more demos. Please save your slings and arrows till the end.


A demo is (obviously) a demonstration. It’s real software that will either be presented or even played.  If it’s consumer facing through the press, a kiosk or a download, it’s got to be pretty damn close to the final version in the quality department. To show anything less than great would hurt the game’s chances for success rather than help it. 

There are lots of demos that a team has to create.  Internal milestone presentations to stakeholders, press junkets, trade shows, etc.  They seem to come from all directions and, all too often, seemingly out of nowhere.  Teams get frustrated thinking marketing doesn’t understand development.  Marketing thinks development teams don’t appreciate the marketing needs. 

Demos must be crafted experiences in order to represent themselves well.  The poor man’s demo is typically making the first couple of levels the software.  This isn’t the ideal since demos must be designed to show off the best parts of the game.  Too often the beginning of games tend to be laborious but necessary tutorials and those aren’t generally the best at showing the game potential.


Now that we’ve established the many forms of a demo, you may be wondering why I view them positively rather than negatively.  Everything written prior to this point certainly doesn’t paint a nice picture.   There are lots of reasons the benefits outweigh the costs.  Here are a few benefits that I’ve pointed out but I welcome contributions from readers.

Create Transparent, Shared Goals: The value of a team having a collective goal cannot be under emphasized.  Both Agile and Traditional project management approaches espouse the benefits of having a single endpoint that is communicated clearly to the team.  If you choose to Google the topic you’ll find a number of studies regarding their importance in social and team psychological behavior.  Demos provide a single, demonstrable goal and once that the team knows will be evaluated on a variety of criteria depending on its purpose. They are a catalyst.  A rally point.  I’ve implied that demos only happen on special occasions but this doesn’t have to be the case.  The end goal may simply be the end of the sprint.  To quote a well-regarded Agile Coach and friend, Clinton Keith, “Teams should treat sprints as demos.”  His point is that demos bring together the team around a common effort and by treating every sprint as a demo the team will train itself into producing work they know will be reviewed within that constraint.  This forces teams to focus and helps mitigate the risk of items running past the current sprint and into the next.  You can find his very interesting article relevant to this topic here.

Define Done: Aside from communication issues I place the challenge of “defining done” at the top of historical team problems.  Both are often discussed in project post mortems or retrospectives.  Many times I’ve taken a look at work from team members or external developers and wondered whether they were serious or not.  Did they really think this item or feature was good? Do they think this is done? In retrospect I place all the blame for this confusion on myself.  In my earlier years I should have worked with each team or individual and collaborated with them to define the definition of done.  This would have set the proper expectations and the quality bar required.  Producers need to work with their stakeholders and teams to make sure that everyone is aligned with what done means on a particular deliverable.   Done is also relative. It doesn’t always mean that the feature is ready for final ship.  Some work takes many weeks and, if the team member delivers work in progress at the end of sprint but it’s not final, that’s OK– as long as the expectations for the end of the sprint were set prior to delivery.  Frequent face to face check-ins during a sprint also help keep features on course. If this analysis and discussion is not performed there will be guaranteed problems and stress on any project, regardless of product size.  This principle covers the smallest indie games all the way up to the largest AAA console or PC titles. 

Practice Closing: Some teams are great at wrapping up projects.  Some, not so much.  Often, I’ve found it comes down to the project management, leads and production team to set the right cadence and priorities.  This comes up often at the end of projects when team members may not be focused on higher value features or bugs and, instead, focus on their pet tasks.  When this happens the work is not aligned with the overall project strategy.  The producer must be very aware of what the team is focused on and what their bug closure rate is.  Demos, in this case, allow a team and producer to practice finishing the project.  If each sprint is treated like a demo a team can get very good and lean when closing the title.  Real, official demos (like for E3) simulate the finaling process to an even greater degree.

Iterate on Polish:  While some demos arise due to surprise opportunities most do not.  The trade show dates are usually set a year in advance, the general ship date is known, etc.  Producers need to work with marketing to evaluate possible opportunities that may arise so that proper risk management can be performed.   There is simply no excuse for a producer to not plan for demos in the schedule.  I do not advocate “padding”, however.  This is generally frowned upon all the way around.  If the producer and team understand the scope of the demo(s) then some planning can be done around their creation.

Engage Stakeholders:  Stakeholders are any people who will be affected in some way by the project…and there are a lot of them.  Usually, when it’s used in conversation it is referring to executives, studio directors, etc.  However they can also be the team members, customers, governmental agencies, etc.  It’s up to the producer to make sure the stakeholders that can have direct impact on the development process are regularly engaged.  Demos provide a way to show work in progress to these people.  In my younger days Bing Gordon, a founder of Electronic Arts, would harass me during meetings for me to stop using “weasel words”.  He was referring to my (previous) tendency to add a lot of qualifiers when showing off software.  He was a believer that the software should speak for itself and not require a lot of excuses like “that’s not done” or “we’re going to improve that”.  I’ve come to realize that weasel words actually hurt the feedback loop.  It’s important to not censor feedback and comments by preemptively cutting off potential critiques. Demos of working software allow this feedback to be honest.


Target dates are inherently a constraint, for demos or otherwise. In fact, the end goal of a project might be the biggest and most powerful constraint there is.  In the book Scarcity: Why Having Too Little Means So Much by Professors Sendhil Mullainathan and Eldar Shafir  the value of constraints is explored. They argue that the brain handles scarcity of food, money, etc. sometimes illogically and at the expense of the long term welfare.  It’s interesting to this discussion because our scarcity is “time”.  In other words, the lack of time leading up toward a deadline tends to focus people on the highest priority work alone.  If not managed correctly these deadlines can affect the long term success of the title.  This is why I agree with Clinton Keith about treating the sprint deliverable as a demo.  The regular time pressure cadence can help teams to focus on the work.  Too often teams lose focus and momentum when the project has years till the final date.  Sprints allow teams to create a sense of urgency that is sustainable and help alleviate panic as deadlines draw near. How often have you reflected back on your own projects and wish you had spent the time in the initial phases more wisely?

Constraints help projects focus and find creative solutions around a problem.  Many times I’ve had similar discussions with artists, designers, programmers, etc. and all generally agree that constraints help them be more creative when implementing a feature.  Constraints force out of the box, creative thinking.  They also help to eliminate waste.  In this case, the time constraint of the deadline forces team members into efficiency since they will need to be finished soon. 

Constraints can backfire, however.  If they exist but are unknown to the team then they can’t be managed properly and can lead to a very broken project.  In almost all cases, communication transparency is king.


In the end, if managed correctly I truly believe demos can have a net positive effect on the success of a title.  I’m sure many readers may feel otherwise as this can be an emotional topic.  As always, I welcome feedback and I’d like to hear about other experiences as well.

Related Jobs

Intel — Folsom, California, United States

Senior Graphics Software Engineer
Pocket Gems
Pocket Gems — San Francisco, California, United States

Software Engineer - Mobile, Backend & Tools
Grover Gaming
Grover Gaming — Greenville, North Carolina, United States

3D Generalist / Artist
CCP — Newcastle, England, United Kingdom

Senior Backend Programmer


James Dunne
profile image
Hi Harvard,

Great points here and covering an area that I often find myself explaining to others outside the industry. Specifically the overall dread that Devs seem to feel when faced with having to create a demo.

Do you think that the audience response to demos can serve to motivate or demoralize a team? If the demo "shows badly" does that become damage control for the team's morale or is it something that they can ignore when necessary?

I ask because this whole act of creation, whether it be game, or book or movie can be incredibly tenuous at times and one little roadblock or criticism can shake a person's confidence in the work they are doing and possibly result in a person just wanting to quit. (Perhaps also why some of the people who show demos fall back on, as you say, "weasel words" in order to defend the project and the team behind it.)

Great articles, I've enjoyed reading them all and I hope to see more!

Harvard Bonin
profile image
Hi James,

Thanks for the kind words. I'm enjoying writing them.

I think the audience response can do both either way. If its received well it can motivate a team and help solidify their belief in "what works" in a game. It also might incentivize a team to coast, though this seems unlikely. Positive reinforcement seems to be a good thing for teams. If received poorly it can be demoralizing and have the opposite affect. That said, even if not received well it might identify unknown problems for the team and provide insight to fix them.


Clinton Keith
profile image
Yes, a great article! Harvard, you're really writing some gems.

In Ed Catmull's book "Creativity Inc." about Pixar, he says one of the elements of their success is their "candor" with one another. It's assumed that every movie they make will be bad early. The bad news *has* to be openly discussed. The trick is do create an environment where this is safe.

When "one little roadblock or criticism can shake a person's confidence in the work they are doing", it's an issue with the culture and needs to be addressed to get to the issue and allow good people to remain strongly motivated.

Harvard Bonin
profile image
Hi Clint,

Thanks very much! I just started reading that per Rory's suggestion. Looks like you rubbed off on him.

Harvard Bonin
profile image
I finished Creativity, Inc. It's amazing how much it maps to agile methods. Truly a great read. It made me want to reach through the book and make him understand that his methods already exist. His charisma, experience and talent lead him to the same principles. Great book.

profile image
Hello again Harvard.
Once again a very well thought out article.
All those are great for internal focus and chemistry - but it over looks the severe downside of Demos that are put out in the wild. (Not the E3 or internal ones - those can be mitigated and their impact is more easily controlled)
I have seen Demos ravage sales.
The best selling games do not release Demos, LoU, Halo even CoD waits until long after the package games sales curve is over.
here is Jessie Schell discussing the issue.

Luis Guimaraes
profile image
Didn't the CoD4:MW demo come before or with the title's launch? As I remember it was the demo that made everyone hooked in the game, after the CoD3 fiasco.

Harvard Bonin
profile image
We are in agreement Nick. This article is focused on the value of demos for development. The market value is another beast and one that may be even more contested.