Introduction to Prototyping with PlayMaker

Hullo, Nate here.

We started full-time development of Rocket Rumble in November of 2015. After a couple weeks of paper prototyping (read about that here) we moved on to prototyping on actual computers.

So when we kicked off, as a team we knew that there were some essential systems that we needed to get into place. You know, all the really important back-end stuff that actually makes the game work. So as designers, Ben and I had to be pretty much self-sufficient so that Vicky and George (our coders!) could get down to business. We had all manner of prototypes we wanted to build, and we needed to be able to do that without relying on our coders. We can both sort of code in C# [Are you sure? -Ed.], but it’s not our forte, so we decided to investigate visual scripting tools. Enter PlayMaker.

Playmaker by Hutong Games

PlayMaker is a visual finite state machine (FSM) editor that integrates seamlessly with Unity. It requires no coding ability, though you’ll need to be somewhat familiar with Unity. Essentially, an FSM is a collection of states, and only one can be active at a time. Within each state, you perform a series of actions (spawn an object, spin something around, add some numbers together). Then, events can be triggered that allow the FSM to transition into a new state, where you can perform some new actions. It’s largely drag-and-drop, with a huge (expandable) library of possible actions to chose from. What you build ends up looking like a flowchart (as seen below), so it’s easy to understand and visualise what you’re building, and once you’re familiar with it it becomes a really quick way of working.

We use PlayMaker for prototyping, but we also integrate it with our active development. In fact, one of the great things about it is that we can explore game feel and juiciness in our prototypes, and then slice out the good stuff and insert it into the proper game. I’ll talk more about that in a later blog post.

The evolution of a prototype in Rocket Rumble. 

As designers, Ben and I use PlayMaker extensively for prototyping, to explore and experiment with ideas, and to communicate our ideas to our coders, who will then build proper systems based on these prototypes. We prototype just about everything. Rather than obsess over game design documents, we tend to just build what we’re thinking about so we can actually interact with it.

For instance, we have a map exploration element to the game, which functions as a sort of overworld that ties together our battles and other encounters. We had some general ideas about how we wanted this to work, but we didn’t have it all worked out to begin with. So to start with we made a series of paper prototypes consisting of drawings of rudimentary maps, with dots joined by lines, little paper cutouts of rocket ships and event pop-ups and so on. Paper prototyping is super useful, but it only gets you so far. We needed to get these ideas into Unity where we could actually interact with them, review them, and then iterate on them.

Early paper prototypes for Rocket Rumble's map system. 

I used PlayMaker to build a procedurally generated star system, with nodes connected in 3D space, random events such as battles and rewards, and even a little spaceship that travels from node to node. Building this prototype raised some interesting questions, and some interesting mechanics started emerging very quickly. So then we were able to expand on the idea, try out new mechanics and approaches, add cool bits in, take rubbish bits out, refining it into something close to what we wanted in the game.

The map generation graph.

We’re a small team, and our coders are super busy building the robust systems that will underpin the entire game, so they don’t have time to code every half-baked idea Ben and I have, only for us to see it and say ‘Oh, well that doesn’t really work after all. Can you change it so that…’. So PlayMaker empowers us to build basic, though functional versions of these ideas, without getting bogged down worrying about performance, stability and so forth. Of course we have detailed, written game design documents, but it’s often much more effective to present Vicky and George with the prototype and let them play with it, than to attempt to communicate some of the more esoteric concepts in a game design document.

In future posts we’ll talk more about how we use PlayMaker for prototyping and beyond, as well as breaking down some of those prototypes in more detail, so stay tuned!