How to efficiently create a winning demo

A working demo allows you to test out gameplay mechanics and get a feel for how a finished game will play, far more so than any game design document or mock-up ever could. It's both a useful internal tool for testing a concept before going into full production, and often a necessary step towards getting client approval or landing potential investors.

Over the past decade, Art Of Play produced over 70 games and more than 150 demos, and along the way we've found what does and does not work largely through trial and error. In this article, we will share with you some tips and tricks that will help you build a solid demo quickly and efficiently, and also highlight some of the pitfalls to avoid along the way.

The first step of course is to come up with a concept. Ideas can come from anywhere, such as post mortems on past projects. Ask yourself what worked, what you wished there was more or less of, what would be more fun if it was changed? Ideas can also come from playing other games, or other media (books, movies), or just life in general.

A working demo allows you to get a feel for how a finished game will play far more than any game design document

Lemmings, for example, started as a cute little pixel art animation that one of the founders of DMA design had created in an effort to learn Deluxe Paint on the Amiga with no game in mind. Once the animation came together he started to envision how that character might work in a game, and the rest as they say, is history.

Ideas can sometimes sound great on paper or in a meeting, but it's often not until you create a small prototype that you solidify that idea. Sometimes you strike gold, more often you find some things don't work or you may have overlooked a problem that needs to be solved. Either way, it's an important step in the game development process, and turning that initial concept into a working and useful demo is both a science and an art.

The science: the technical side of things

• Know your tools

Game developers often like to talk about the toolchains they use for creating games -- the latest and greatest framework, plugins, or shaders. But just as important (arguably more so) are the tools and systems you put in place for communication, both within the studio and externally with clients, publishers, and investors.

Most of us have worked in studios in the past where time was sucked up by endless and sometimes seemingly unnecessary meetings. Modern software and tools mean that whether your whole team is in the same room or you are spread over different continents, staying in constant communication and doing so effectively and efficiently has never been easier.

Think of the tools at your disposal (technical game creation tools, team management and communication tools) as all being part of the same toolbox. It's essential that you and your team decide early on which tools and channels you will use and stick to them, learning to operate them inside out.

If your focus is split between Slack, Basecamp, Discord and email, things will get lost in the mix. You'll get duplicate messages and you won't remember where information was when you first saw or posted it. Set up a single channel for each type of communication and stick to it.

It doesn't take many distractions to slow things down, so give your team the space they need to work effectively

If you are working across multiple time zones, it is essential to plan meetings as and when they are necessary. When real-time isn't needed, stick to your preferred communication tool such as Basecamp or Discord where messages can be posted and reviewed when it's convenient to each team member. Even if you're all in the same time zone or even in the same physical location, avoiding the need for excessive real time communication can help keep things moving.

Every programmer knows the feeling of holding a complex process in their head as they are working on it, only to be interrupted, and then taking ten minutes to get back into the "zone". It doesn't take many distractions each day to really slow things down, so give your team the space and tools they need to work and communicate effectively.

• Reduce, reuse, recycle

We can reduce the amount of time and effort required to produce assets early on by avoiding perfection and keeping to placeholders as much as possible. However, when it comes to reducing or reusing your team's work, keeping assets to a minimum is only one area to focus on. Over time, you'll build up a library of content and experience. With every project you create, whether it's a fully fleshed out and released game or a small prototype that you decide not to move forward with, you'll have learned something new, and probably created some assets and written some new code which may be of use down the line.

It's a good idea, after every project no matter how small, to dissect it and discuss it with your team. Find out what worked and what didn't, and that becomes part of your collective "library of experience". You can use those experiences as shorthand when discussing future projects to help speed things up: "Hey, why don't we do this like ABC that we did in XYZ project?" The more projects you work on, the more often you'll be able to point back at something from a previous project to use as an example, and to pull ideas from.

Do the same with your code and assets. If you developed any new code which might be of use in another project, consider putting it into a library or module that can become part of your framework or toolset moving forward. There's no point reinventing the wheel over and over again. Every time you reuse code from a previous project (if it was well written, and efficiently rolled into the new project) you're increasing your efficiency, and reducing the time required to build that next demo or reach that next milestone.

There's no point reinventing the wheel over and over again

Same goes for assets. While you usually won't be able to reuse final assets from a game (unless you're making a sequel, or another game with the same IP) it is often possible to reuse placeholders, at least for the early stages of demo development, which can be swapped out later.

It's possible to use up a huge amount of time creating placeholder graphics and audio, or even just trawling through stock libraries. If you can build up an internal library (and keep it well organised) you'll find that you can grab what you need quickly, and just start building a lot faster.

• Perfect is the enemy of good

A demo is not a game; it's not intended for release, and as such it doesn't need to be highly polished. The temptation is often to make things pretty, and to add features and flourishes to impress your client/investor, but the focus should generally be on getting to a point where a mechanic, level, or system works well enough to test as quickly as possible.

A demo is not intended for release, and as such it doesn't need to be highly polished

If something doesn't work, you want to find out early on so that you can either change it or drop it, and pivot on to a different idea; in startup jargon you want to "fail fast." If you're striving for perfection at every stage, you're putting too much time and resources into those early builds which are wasted once you do pivot. There's a time for striving for perfection, and that time is after you have a solid demo which you've refined and tested, one that you are confident can be turned into a winning game.

In the same way that avoiding red tape and keeping communications streamlined means you conserve resources and stay focused, actively avoiding any attempt towards perfection will keep your team agile and moving towards your goal.

Simple placeholder assets, basic level layouts, boilerplate text: all of these things are quick and easy to produce, and mean you can focus on the primary task of getting the demo built and tested. Once you have ideas locked down in a working demo, you can change focus and begin perfecting each area.

The art: the client and the team side of things

• Creative thinking

Game development really is the epitome of a marriage between technology and art. No matter how strong your technology skill set, you also need to encourage and nurture creative thinking within your team.

How much creative rope you have can vary wildly from project to project. If you're developing a game as work-for-hire to deliver to a client's specifications, they may well have given you very specific details in a game design document. At the other end of the scale, if you're developing a game based on your own IP and the demo is a tool to attract investors or a publisher, you'll have all the creative freedom in the world. More than likely, you'll fall somewhere in the middle.

It doesn't matter if your team is just you and a partner, or offices full of staff in multiple locations -- encouraging innovation, supporting creative thinking and enabling your entire team to come up with ideas and test them out is vital.

It's easy to pigeon hole. "Jack is a designer.", "Sally is a coder", but the best ideas often come when people think outside of the box, and that means outside of their bubble or area of expertise. Whether it's a broad stroke concept for a game or an idea for a small sub-mechanic, level design or feature, enabling the entire team to put their ideas forward means you're drawing on a wider range of experience and ultimately have more chance of finding the best solutions.

Once you have that core idea, it's the team who will turn it from a concept into a demo. To do that, it's vital that the studio setup allows for fast iteration, and an agile working environment. That means going back to your tool set, ensuring you have the right assets and enabling your team to do their work without being bogged down with red tape and approval processes.

• Minimise red tape, keep it small

Red tape, internal politics and the requiring of approval at every step is a death sentence to building a demo fast. While a certain amount of bureaucracy is usually required (especially if you're working based on a client brief), keeping it to a minimum means everyone can get on with their job and keep things moving.

Internal politics and the requiring of approval at every step is a death sentence to building a demo fast

This is where a small team generally has an advantage over a larger team. A small team of fewer than ten or so people, whether physically working in the same space or distributed, makes it relatively easy for everyone to be on the same page, know what the others are doing, and be in constant communication with each other.

Over time, you get to know everyone on the team personally and learn their strengths and weaknesses. The better you know the other members of your team and how they like to work, the less time needs to be spent in meetings and the faster you can move.

Larger teams can still be agile, but by their very nature more time and effort will be spent managing the team, assigning roles and keeping everyone on the same page. That's where communications systems, tools, and structure that were all mentioned earlier become even more important.

Another advantage of smaller teams is that by its very nature a small team requires each person to wear multiple hats, which can reduce the amount of back and forth on a project. In a larger studio where coders are coders and artists are artists, a coder might put in a request for an asset and have to wait for that asset to be created and delivered by the art team.

In a smaller studio, that coder probably has some art skills (and the artists probably have some rudimentary code skills) which is normally more than enough to at least create placeholder assets or make small code tweaks to keep things moving. No matter what studio you find yourself in, consider broadening your skill set. Having the ability to wear multiple hats and enabling your team to do the same puts you in a much stronger position and helps keep the wheels turning.

• Great client expectations

Whether it's 30 days or three months, having a deadline to work towards helps keep a project on track and prevents feature creep and bloat. Work of any nature has a sneaky habit of expanding to fill whatever time you assign to it, and it's easy to keep adding new features and more polish in this line of work. But it can result in a project never quite reaching the finish line. If you want your game to avoid becoming the next Duke Nukem Forever and actually seeing the light of day in a reasonable time frame, working towards deadlines is a necessary part of the process.

Once you have a deadline, you need to be cognisant that you are restricted and there are limits on what you can achieve. That means that your client (and we use that term in the broadest possible sense -- your "client" could be potential investors, or even just you and your team) needs to be made aware that a demo is just a demo, not a finished game.

That means first making tough decisions on what to include -- and by extension what not to include -- in the demo, and then clearly communicating what the difference between your demo and your completed game will be.

Once you have a deadline, you need to be cognisant that you are restricted and there are limits on what you can achieve

A demo has multiple roles to fill. First and foremost, it allows you to test whether or not your concept is fun, but it's also a communication tool. Since you're limited to a subset of your final games features, you should focus the demo on the core of what is unique to your game. Do you have a unique game mechanic, or a new control system? Is it your art style that makes you stand out from the crowd? Do your level designs elevate your game above others in the genre?

If your demo is focussed on the unique aspects of the game, you can use other communication tools to tell the rest of the story. Let your client know from the start what will/won't be in the demo, and consider supplementary content to fill in the gaps. Depending on the type and scope of the game, that could be storyboards, concept art, a mock-up video or something else.

Whatever the medium, taking the time to plan your strategy and deciding how you will ensure that everyone is on the same page from the start will keep the engine well oiled, and ensure that you stay on track to deliver a demo that does exactly what you set out to do.

Conclusion

Building a demo fast and efficiently essentially boils down to three things: an experienced team who are enabled to work independently but can communicate and collaborate well together, the right set of tools (both for development, and communication) and the correct mindset and habits.

With these three things in place the whole team can stay on track, minimise unnecessary red tape and stay focussed on the big picture of creating a winning demo, not the minutiae of attempting to perfect and polish at every step along the way.

The more prototypes and demos you can build, the more experience you'll develop but also the greater the chance you'll have of "striking gold." Angry Birds was the 52nd game developed by Rovio. Those first 51 games weren't "failures" but they certainly weren't the runaway success that Angry Birds was, and yet I suspect that each of those 51 games built their experience and systems to a point where Angry Birds was possible.

Whether you're building a demo to a deadline to show to a client/investor, or are developing your own IP as Rovio was back in 2013, getting from concept to demo as quickly and efficiently as possible means you can repeat that process until you arrive at a winning formula. Once you do have a winning demo which is fun to play even with placeholder graphics and a lack of polish, you'll know you're ready to turn it into a full game and let those birds fly!