Buying a new computer, the Mood Flip origin story, and tutorial design

For a number of years now, I’ve been using a Mac.  While I’ve still been able to play some games on the Mac, it’s very limited in that regard, and my Steam account is full of awesome titles that I have not yet been able to play and have been stockpiling during sales in anticipation of my next real computer.  I’ve been okay with waiting until now, but with my Oculus Rift pre-ordered and soon to be on its way, it’s time to return to Windows and buy a new VR-ready gaming PC.  I’ll also be shifting my Unity game development over to the new rig, and afterwards just use the Mac for the Xcode build stage.  Anyway, this week I started the process of buying all the various bits and bobs needed to make this a (warning: bad pun alert) virtual reality.

When we first arrived in the UK back in 2012 and needed to buy a new PC, I recalled that in my previous job back in Australia one of my co-workers had been working in his spare time on an iOS game using Objective-C and Box2D.  This inspired me quite a bit, although the last time I’d done any games programming was back in the ’80s on the Commodore 64, tinkering with text adventures and making crude sprites move across the screen just to see if I could.  So we bought a Mac and I set about learning Unity and mobile games development in general.  After a number of months spent tackling the learning curve, going through tutorial after tutorial, and trying out increasingly more complex prototypes, I finally hit on the idea that would become the genesis of Mood Flip.

I’ve always loved seeing science pictures of gravity wells, such as this:

GPB_circling_earth

 

These spacetime bending diagrams are often accompanied with descriptions of space stretching “like a rubber sheet”, and this always used to make me think about that other property of rubber sheets: how they spring back when you stop stretching them.  And that in a nutshell is where the main prototype for Mood Flip’s central mechanic came from: I just plonked down a plane with a grid texture on it, and then wrote some code to calculate the manipulation of the plane’s vertices to stretch into the likeness of a gravity well.

That was in 2012.  Since then the idea has expanded considerably, of course, with the concept of Moodies living out there in space on that grid, and their state flips being the physical result of the user stretching the grid.  But the central idea of the gravity well is what started it all.  And sometimes, that’s all it takes – from one core idea, a whole creative foundation can be built.

Anyway, back to the new PC: I am typing this on my new WASD CODE keyboard, which arrived yesterday.  I’ve got an Acer G-Sync monitor and a Mionix mouse on order.  I still need to do some research on the main PC components, but I think I already know which company I’ll be buying it from, and am pretty close to finalising the specs I want.  Back in the old days, I used to build my own PCs, but it’s been so long now that my knowledge of the latest hardware is very much out of date, and I feel more comfortable paying a bit extra to have it done by professionals.  My wife wants to take a short holiday for the upcoming school term break, so I’ll hold off ordering the new rig until we get back so that there’s no delivery date clashes.  But hopefully before the end of the month, I’ll be gaming hard, uh I mean developing hard, on my new beast of a computer.

As far as development news, of late I’ve been tackling the refinement of my tutorial panels.  It’s hard work!  Trying to keep them as lean and minimalistic as possible, while still giving the user the right amount of information they need to understand the game mechanics, is really difficult.  So far, I’ve pared back the 12 panels I had before down to 5, chopping out a lot of superfluous explanations.  I think adding another 3 or 4 further panels to explain the concept of “crosshairs mode” should be enough.

My thinking is that most users will want to hurry through the tutorial and start playing “for real” as quickly as possible.  So the main concepts I need to get across are the ones which explain:

  • The main interactive objects/characters in the game – in this case, Moodies, which are basically personified emotions
  • The goal of the game – to flip all the Moodies to Happy
  • The primary user actions used to achieve the goal – in this case, taps and pushes
  • The most important secondary user actions – in other words, swipes, zooms, and crosshairs mode

And that’s it.  As tempting as it can be to over-explain every available function and give users every pro tip you can think of, it’s equally important to trust the user’s intelligence and not overtax their patience.  So what I’m trying to do is to keep the interactive tutorial as thin as possible, with only the absolute vital minimum info, and put everything else into a secondary “Advanced Tips” option on the menu.  For example, I used to have a tutorial panel which informed users that they can adjust the push speed in the Settings menu.  Then I thought: do I really need this?  On the one hand, it does let users know of an option available to them which can help customise their game experience for the better, that they might not otherwise discover on their own.  But on the other hand, all it would take for the user to discover that for themselves is one visit to the Settings menu of their own volition.  So the dilemma becomes: do I mention this in the tutorial and risk upsetting some users with yet another panel to wade through, or do I leave it as a discovery item and risk some users never becoming aware of it (and possibly churning, if they find the game too hard without it)?  Similarly, I could spend several panels teaching the user the intricacies of how to use the second finger pause trick, or I could defer most of those details over to the Advanced Tips section, since that’s an advanced technique that, while very helpful, isn’t strictly required to be able to play the game.  It’s balancing choices like this which are so tricky, especially when you consider the various user type scenarios that need to be considered:

  • Users who never read tutorials and just fast-click through them, and who will get frustrated and might churn if the tutorial goes on too long or can’t be skipped
  • Users who will go through the basic tutorial and then afterwards explore for themselves, and who won’t read the Advanced Tips.  The danger here is not providing enough information in the basic tutorial and possibly leaving these users without a core piece of game knowledge they might need to progress their skills
  • Users who rely on the visual explanation aspect of a tutorial only and not the descriptive text.  Young children, for example, are likely to learn from visual cues only and not read the text
  • Power users who want to pore through every possible bit of information available to help them master the game.  Even here, restraint still needs to be shown and there should be some elements of mystery left unexplained for loyal fans to discover on their own through experimentation

I’ve read a lot of advice about making tutorials integrate naturally into gameplay, and while I concur with this as a general rule, sometimes a game’s mechanics need a little more up-front explaining.  Anyone would be able to discover how a tap works in Mood Flip by just experimenting by themselves, for example, but the equally important push-and-hold mechanic isn’t so easy to discover organically.  Hence the forced tutorial the first time you play.  If a game is going to have a forced tutorial, however, it had better be short and sweet, and ideally optionally skippable.  These are the principles I’m trying my best to abide by.  Only time will tell, I guess, whether players feel I’ve struck the right balance.

In the meantime, I’ll be doing additional, uh, UX research when I get my new rig…

Leave a Reply