Playniac's Rob Davis introduces the concept of 'wireframe narratives'
As an emerging expert in the world of racing rodents, I spoke recently at Develop and GDC Europe 2011 about Playniac's approach to preparing squirrels for international competition, and found that there was plenty of interest in the techniques we were developing.
We introduced what I call ‘interactive wireframes’ for International Racing Squirrels, a game commissioned by Channel 4 which launches in autumn 2011.
Other game designers are already talking about applying them, and students want to employ them in their coursework.
The interactive wireframe really helped the commissioning team at Channel 4 visualise and understand the game, the mechanic and the user journeys that Playniac was building.
Even at a very early stage, the broadcaster’s staff could take away a sense of how things would work once the game had been completed.
So what are interactive wireframes, how do they differ from previous ways of specifying games, and how can developers use them in ‘storytelling mode’ to do very early user testing?
We started off using use-cases and applied them in various productions including Lost Army of FuShi, an action puzzle game for BBC Bitesize; and Alien Farm, a multi-user, collaborative, alien herding game for CBBC.
For each element in the game, the use-case explains in writing a user’s intentions, the action they will take and the results.
Use-cases look like a handy tool for detailing game features, but we found that in practice they quickly became large documents that were difficult to maintain.
They are painstaking to write and, worst of all, no one really wants to read them. Though excellent at specifying functionality very precisely, they leave little room to manoeuvre in game implementation.
The main issue was that they didn’t give a sense of what the game was like to play or how the game’s graphical user interface (GUI) might be laid out, so we decided we needed to find a more visual technique.
Many readers will be familiar with wireframes, and we have used them for projects such as Journey to Fossil Island, an ecological adventure quiz game we created working with British Gas.
This was an episodic game, with missions for release over several weeks, and the wireframe diagrams above show the map view screen.
The game features six island locations that the player visits in turn, and this wireframe could be created before any of the locations had been designed or even named.
The wireframe makes the functionality clear and also hints at the possible layout of the information on the screen, without pinning it down.
In the previous image above you could see a static wireframe from Journey to Fossil Island, and below how the finished map screen appeared in the game.
Static wireframes give an immediate visual sense of the layout of game screens and their functionality. They also allow some GUI design to be done early in the project and in an abstract manner, and are very easy to understand for both technical and non-technical readers.
They are useful for communicating the game to everyone involved and the design and development teams will use them to take the game forward.
They are not intended, however, to convey any design for the finished screens, even if occasionally they do include some graphical elements for conciseness. Being diagrammatic, neither do they convey look and feel or colour schemes.
Overall we found that, although supporting user flow diagrams can help, the approach did not give a good sense of screen flow and user interaction.
For our next game we decided to take wireframes one step further.
International Racing Squirrels is a race team management simulation that has the player running a team of jet-setting squirrels.
They train their squirrels to boost their stats and upgrade them with accessories from a shop, before sending them to race up mountains, across deserts or through futuristic cityscapes.
Behind the gameplay, we’ve turned the finances found in games from Sim City to Game Dev Story up a notch, and incorporated a realistic model that simulates real-world consumer finances.
We decided to create an interactive wireframe where all the buttons on screen would be active, although none of the game functionality had been implemented.
We used Adobe Flash CS4, and switched to AS2 mode to enable us to work entirely on the tool’s linear timeline using basic instructions, rather than having to write any separate code.
Interactive wireframe screen layouts look quite similar to their static counterparts, but users can mouse over to reveal tooltips showing further information and they can click to advance to different sections of the game.
The interactive wireframe was created using Adobe Flash, and delivered to our team and client via a password-protected web page.
One of the main screens in International Racing Squirrels is the home screen, where the player gets an overview of their game and can manage their team.
They can buy and upgrade homes and training activities, view their stats, pay bills, go to races and more. There was a lot to fit on this screen and the interactive wireframe also shows onscreen items in various states.
Though not usually a feature at the wireframe stage, the diagram above does give a sense of the intended setting: the background image was added for this purpose.
The completed screen brings those features very much into the world of the game, featuring an up-tree urban training facility.
For the main race screen we decided early on that we would not create a first-person racing game but, as in management sims such as Championship Manager, we would allow players to set up their team and then watch them perform.
We provide some interaction during races in the form of a performance boosting mini-game and various power ups.
The wireframe shows the race position indicator, a loose tribute to Mario Kart, the overhead track overview, the ‘squirrel cam’ showing the team member front-on and the mini-game.
Taking us slightly closer to a working prototype, we were able to mock up several versions of the mini-game before deciding on the final form (below).
The finished game screen shows all of those features in place.
Interactive wireframes have all the benefits of their static predecessors and give a clear sense of screen flow. They also give some sense of the game dynamics.
They are extremely easy to understand and incredibly useful for the design and development teams as well as the client.
So many queries about the game can be resolved by referring to the interactive wireframe that in some senses it can seem as if the game is producing itself.
With some basic Flash knowledge, interactive wireframes are surprisingly easy to maintain once set up. They can also be easily delivered over the web.
Although Flash Professional is our preference, a variety of tools could be used including Flash Builder, OmniGraffle, PowerPoint or Keynote; even HTML or interactive PDFs.
There are also online offerings such as MockingBird. However in our view they are not as flexible or powerful as Flash for interactivity.
An additional benefit of interactive wireframes is that they can be used for live testing.We found this invaluable to get some sense of the game in action early on.
For the first time, we took the interactive wireframe into a very early user test in a London school, where players ran through the entire game and using all of its features.
Don't forget that this is a game that doesn’t exist yet.
The interactive wireframes were also very helpful for Channel 4 and Playniac’s school play-testing because, as we all know, showing people static wireframes just doesn’t cut it.
The game is being played in what I'd call ‘storytelling’ mode. Off camera a ‘games master’ is playing the part of the software, describing everything that is happening but not immediately viewable on the screen.
The session is videoed and we observe how screens and functionality are understood; and how well intended game mechanics work.
I was asked by a GDC delegate how this approach was useful if it can't convey the excitement or visual experience of playing the actual game, and so runs the risk of alienating the tester.
We are not, however, trying to create an entertainment experience at this stage. By asking the participant to suspend their disbelief, allow us to tell them a story and join us in imagining the result, we are simply trying to understand more about our game.