Author: by Jay Weston

If you're an artist or designer, you may find that your ability to code seems opposite to your main talents -- I have certainly found this myself! My main passion is game design, but without code, you can't make a game, right? With tools like Unity and Playmaker (a visual scripting system for Unity) this isn't necessarily the case.

After working part time on a couple of games, Zombie Outbreak Simulator and Class 3 Outbreak for a few years with Binary Space's programmer/CTO Saxon Druce, I was looking to add more titles to my game designer belt, but at the same time I wanted to keep things small-scale and achievable.

I had been playing a lot of iOS games while we ported Zombie Outbreak Simulator to iOS, and Tiny Wings in particular had me completely enthralled. From a gamer standpoint, I loved the feeling you got of being in the zone, getting perfect jump after perfect jump. From a business standpoint, I loved that it was essentially one level and extremely simple gameplay, hence quick development time.

After toying with a few ideas for games, I ultimately decided to try a version of Tiny Wings that was first person, in 3D. Using just Unity, I struggled through some basic physics code to get a ball rolling around on its terrain engine (I can hear you laughing) and after a week or so, I was quite happy with the result.

However, being the most hopeless coder of all time, progress was slow and infuriating. Not only was I trying to get my head around 3D physics and vectors, but also Unity itself, AND JavaScript! There are some creatives that can bash out some script without much problem, but I'm not one of them, and to learn this side of game development would set me back arguably years of study and practice, which at the ripe age of 32 I'm not willing to do!

Enter Playmaker

Somehow -- I think while looking through Unity's Asset Store -- I found Playmaker. Playmaker is a visual scripting system / state machine manager, which uses states (which house actions, each a snippet of pre-written code) and transitions to develop a game. A highly simplified example: You can attach a finite state machine, or "FSM", to a character with the states "fighting," "idle," and "walking."

Within each of these states, you can include animation actions, raycasting/shooting actions and movement actions. You transition between each state using events, i.e. within the idle state, you would add an action that waits for a left mouse click. This left mouse click triggers a transition event to the shooting state. Each action in a state is essentially a pre-made piece of code that you can tweak and fit together to create a state machine, and eventually an entire game.

Playmaker's Test Lab example scene, which controls simple opening/closing doors

You can see from the above image how, for the non-technical, these visual state machines are so powerful. When I look at a block of code, I see a wall of text, and try in vain to understand what it does, when it triggers, and what it's doing at any given point. With Playmaker, I can glance at an FSM and see what it does in almost an instant.

I can also see not only what it is doing in real time in the visual editor, but also in the game view, where each object will display which state it is in. I can't tell you how good this is for debugging and just general understanding of what your FSM and the game in general is doing. Add to this things like debug rays, break points, and more, and you get a very clear understanding of what's happening.

Using Playmaker, I've just completed my first (mostly solo) creation, Unknown Orbit, where you can float, jump and fly around a surreal, 3D planetary system as a comet. Part-time, this game has taken me about a year. Full-time, I imagine it would have taken six months, and now that I've learned Unity and Playmaker to a greater level, I think the game could be recreated in a few months if not less.

Unknown Orbit

Here's a quick example of an FSM for Unknown Orbit, where the player picks up snowballs. On the left are the states and transitions that control when we move between states. The middle pane is currently showing the actions inside the "destroy self" action. In this FSM, when the player flies into a snowball and picks it up, an event is broadcast called "Add snow".

The state machine attached to a snowball pickup in Unknown Orbit (click for larger version)

The comet object hears this broadcast via a "global transition", and enters a state that increases the radius of the comet's ice core.

The state machine attached to the ice/snow object in Unknown Orbit (click for larger version)

The Tradeoffs

So what are the tradeoffs, you may ask? Well, you will have some memory overhead loading everything in, and yes, there are some small performance hits in some areas because of all the extra unused capability in the system. Playmaker isn't optimized for any particular type of game, and neither is Unity. But today's hardware is so powerful that unless you are doing something pretty crazy, you probably won't hit the wall any sooner than you would using other approaches.

Another trade-off that I encountered was that due to a couple of levels of abstraction in the game-making process, you can sometimes feel helpless to fix problems. I would find a bug and spend days trying to fix it, and be clueless to the source of the problem. I imagine this is common to some extent in most games, especially where you use someone else's engine/code/API; however, when you are using an engine with a plugin to that engine, things can get tricky. Luckily both Unity and Playmaker have excellent support, and I further mitigated this by working directly with an expert in both Unity and Playmaker whenever I encountered problems I couldn't solve.

Also, while I have yet to encounter this, the more plugins you use with Unity, the higher your chances of conflicts, or of the creator disappearing/no longer providing support. If you are selecting plugin(s) to use with Unity, I suggest choosing ones that have been around for a while, receive frequent updates, and whose creators are active in their own forums. In my case, Playmaker actually supports my chosen interface plugin, which has also been around for some time, which was very handy.

The Advantages

In terms of game design, Unity and Playmaker are great in allowing you to focus almost entirely on building and testing ideas as quickly as possible. I'm personally focused on game design, so this allows me to create ideas and prove/disprove them quickly, getting in as much practice and experience as possible in a short time span. I jumped out of games into a business and back again a few years ago, so I feel like I'm getting to make up some lost ground now!

If you're a game designer at a typical large studio, you might be making "safe sequel number 9999," and while you may have some room to move, you can hardly flex your muscles and push yourself in terms of wildly different or unique designs. If for example you're a designer "stuck" making say, racing games (happily or otherwise) you could practice in other genres with relative ease and low time commitment.

I also believe that the fewer people you have on a project, the more unique and singular the design vision will be, creating more individual games. Using these tools almost puts you into a team that has created a graphics/physics/animation/etc. engine and lets you run wild with whatever design you like, with little in the way of restrictions.

The Lean Startup?

I'm also a big fan of lean startup principles, a concept that Eric Reis is famous for. Lean startup is mostly a business approach where companies attempt to prove product or service ideas prior to launch, then quickly develop a minimum viable product (MVP), iterate on it, and get customer feedback as quickly as possible. This is the opposite to how games are traditionally created, where you define the game first via a design document, make the game, then hope it will sell well.

For lean startup strategy, I think this combination of Unity and Playmaker is certainly something to consider for both large studios wanting to prototype ideas/MVPs quickly, or for solo/small teams, especially if you lack a coder and just want to dive in yourself! Throw in Kickstarter (a crowd funding solution), and you have a very nice lean startup strategy of game development where you can quickly create a prototype, develop a Kickstarter pitch, then prove whether people would pay for your game before you have heavily invested in it.

(If you'd like to know more, you can read Tyler York's Gamasutra article on lean startup for games.)

So how did I follow the lean startup approach, exactly? Well, I did and I didn't. Because this was my first Unity title, and I was going to be learning a lot, I picked and chose various concepts from lean methodology while I decided to play it safe and attempt a fairly proven game concept. I looked at Tiny Wings, Dino Run, Dolphin Olympics, and other games that were similar, and decided that because those games have had some success, that I was already aiming for a concept that would have a good enough chance of success. If you like, you can go the whole hog and try to prove whether your idea would be popular by creating banner adverts or text ads on Google or Facebook, and see what sort of clickthrough rate you receive.

I then chose an art style that I was familiar with -- I have 3D art/texturing as my background, with no animation required (I have no skills there), no AI, and just an extremely simple game mechanic that I could tune based on feel. My minimum viable product was done in days due to Unity's built-in physics; I showed some friends who approved, and I was then on to the finished product.

From my work on Zombie Outbreak Simulator, I was also familiar with freesound.org, where I sourced almost every sound in the game, quickly and free! For music, my friend Rhys Lindsay recorded me an awesome spaced-out track. This left me to concentrate entirely on the learning process and fine-tuning the game.

I would say that I followed lean startup mostly in respect to creating an MVP and final product with the minimum asset requirements, minimum spend, while iterating quickly and often. I honestly was a complete coward in terms of getting early feedback from anyone but friends, as I was genuinely scared that someone would steal my idea while I crept along at a snail's pace learning how to make it. I also just wanted to make something that was uniquely me, with little outside feedback. Funnily enough, towards the end of the project, I found it really helpful and great fun to work with testers and get their feedback. My apologies to them for not being able to add more planets! Perhaps in a future update!

Having now completed one Unity game using Playmaker on my own, I have the following advice for developers in a similar situation:

So yes, coders might still be required for some games, but proving that you can make/release a whole game on your own will prove to yourself, potential partners, funders, Kickstarter backers, etc. that you have a work ethic and can get things done.

As a further note, strangely enough I've found that using Playmaker has actually solidified my understanding of things like object oriented design and other programming/design concepts. So I think it can be helpful in learning these concepts as well!

If you're a creative or just really want to bang out a prototype with great speed, I highly recommend you try out this combo of Unity/Playmaker.

Here's the end result of a years worth of work (part time) on Unknown Orbit, by one guy with no programming experience, some 3D skills, and some game design background, made using the iOS version of Unity and Playmaker.

Unknown Orbit was developed by Jay Weston at Exbleative and is now on the App Store for iPhone and iPad. Unknown Orbit lets you float, jump and fly around a surreal, 3D planetary system as a comet. Find out more here.