Parade of Rain

Last week was a busy week as I spent most of it implementing and tweaking the really basic tutorial system I had in mind for Tilt To Live. From my gameplay experiences I feel tutorials have gotten pretty good at being integrated into the game themselves and not being ridiculously wordy/boring. I’m not sure if it’s that I tend to grok how most genre game mechanics work from many years of playing, or understand the basic ’standards’ across games in the same genre, or that the tutorials are really getting better. I tend to be optimistic about it though and hope we are progressing . When I was designing the tutorial system for Tilt To Live (which isn’t anything special, but I did sit down and give it a bit of thought) I started thinking from a more general game design perspective on what to consider in such a system:

How complex is thy game?

I generally pay attention for first few minutes of tutorials to learn the essential controls then I barrel forward into the game hoping for the best. Some tutorials overstay their welcome. It really comes down to distilling the core gameplay experience and then getting the user to run through those motions quickly and keeping it engaging. Of course it’s really hard to get around that if you’re game is as complex as say…Commandos 2.

Commandos 2 may be the most ferociously complicated game released yet for Xbox. – 1UP

Sometimes there just isn’t getting around that boring part of the tutorial if your game really IS complex and there are a lot of rules required to know before you can  make your first move. For sufficiently complex games, tutorials are a huge part of the game design problem. When I played commandos I pretty much lost interest after 15 minutes futzing around in the training missions. Another tale of a lost player due to a lengthy and uninteresting tutorial . And this was even with a friend of mine who was a huge fan of the game pretty much holding my hand through the first couple of missions. It just didn’t click with me, but I like to think that the ‘fun’ of the game was lost on me.

Yet, lengthy tutorials are common in non-video game settings. Take contract bridge for instance. I learned to play it with several co-workers and if you gave me a manual and several self-paced tutorials I probably would have never figured it out (particularly the bidding system). Call me dumb, but I like to think I’m just lazy .

The difference in me learning how to play bridge vs taking the time to play commandos 2 was that the “tutorial” was integrated into the very game itself in a way. I wasn’t playing “Tutorial: Bridge” like I was playing “Tutorial: Commandos 2″. I was playing full non-handicapped bridge and learning at the same time. It was a constant learning process. It was a fun process of discovery, which for some odd reason didn’t come across to me in Commandos 2. The rules of the game don’t spoon-feed you tactics and how to ‘win’ at bridge. Also the ‘engaging’ part was from talking to the other players in the game to learn more. Not many tutorial systems beat social interaction. I’m certainly not the only one that enjoys learning how to play a game through other enthusiasts. Juuso, of GameProducer.net recently had similar thoughts:

I like how Zombie Panic has no tutorial, nor much hints at all. Instead, players ask each other “how you rotate the board”. In Zombie Master (for some reason I’m getting zombie game examples here) it’s cool how players ask each other “what to do next?” – sometimes the reply is “n000b!” but often time other people tell what to do. I think that’s tutorials in its greatest form: community interaction where everybody helps each other. People can enjoy the game in many different levels.

In essence, the more complex your game rules are you may be more justified to put in a longer tutorial. But you need to ask yourself, particularly if you’re an indie focusing on smaller games, is your tutorial system teaching the player the game rules (Bridge) or is the tutorial holding their hand while they play a bunch of throw away levels (Commandos 2 and a lot of single player games)?

Who art THOU?

These days, no amount of tutorials will get a player who is casually interested in your game but doesn’t grok the necessary control schemes to talk in that game’s “language”. By language, I mean FPS, RTS, or RPG relevant control schemes. Each genre of games kind of have set standards on how to play that particular game. I’ve pretty much concluded that my mother, at her current age and interest level, will never be able to pick up Halo 3 and learn to play it competently. Not because I don’t believe she doesn’t have the ability (lol), but simply because she doesn’t care enough about it to invest the time and energy to become familiar with that system. Give her bejeweled 2 on the other hand and omg…we’ve lost contact…for hours. On the other hand, any hardcore gamer can take any FPS shooter, run through a brief tutorial on what is different about this shooter than others and proceed to play.

Casual games have picked up on that sensibility (for the most part), and keep tutorials pretty minimal but make very few assumptions about the player from what I recall. The good iPhone games tend to be doing a decent job at conveying play mechanics quickly and efficiently, because the audience is mobile. Some opt for a simply ‘how to play’ button but offer no in-game advice, while others do the opposite.

I chuckled to myself when I realized the brilliance of Doodle Jump’s aesthetic, intentional or not. They were able to literally pencil in the tutorial in the background as you play and not break the “mis-en-scene” (hah, how’s that for artsy?) of the game.

In Practice

So, when it came to implementing a tutorial system for Tilt To Live I had the answers to the above two questions along with some other notes:

1. How Complex is the game? Mechanically, it’s dead simple. Actual difficulty of getting a reasonably high score? Currently, results may vary. The resulting tutorial system should be either a)extremely minimal b) non-existent.
2. Who are YOU? While the game has obvious influences from more hardcore 360 shooters, I wanted to tone down the difficulty, give a more approachable aesthetic, and try to reach a less hardcore audience. The resulting tutorial system shouldn’t assume too much of the player’s previous gaming knowledge. This influences the terminology you use in tutorials and other text.
3. Appealing to the Core Ideas of the game: One of the core ideas of Tilt To Live is to keep it as minimal and simple as possible. Right down to the title, which serves almost as a tutorial in itself.

Adam and I kind of went back and forth on whether a game as simple as Tilt To Live really needed any explanation. I mean the title pretty much says it all for goodness sake. I persisted and decided even a brief explanation of at least one of the game rules (collecting pick ups to attack enemies) should get an explanation. We eventually came up with this (a work in progress video):

So the player on the first launch of the game is informed of the general rules of the game but control is never taken away from them as they can freely play the game. This gives the first time casual player some time to get acclimated to the game’s controls and then proceed as normal.

We’re still up in the air about a “How To Play” option that would give more detail on the power ups and mechanics. I figured no one would give a damn about the option, especially after seeing a few other iPhone games. It all points back to the complexity of the game. It doesn’t necessitate the explanation of all the power ups. Plus discovering what each one does is part of the fun . Additionally, I will cut anything from the main menu as long as it doesn’t make  it more difficult to get to information you want in order to keep in line with point #3 above. So I’m leaning towards removing it all together, but I’m not completely done iterating on it so it may change….

Tangible goals are key to any project. Without them I feel like I’m peddling up a steep hill just so I can peddle up some more. Scheduling and time logs showing time spent are great for statistical and historical purposes, but in the scheme of things can do little to save a project if you and your team lack that motivation needed to push the last mile. Countless indie games die from loss of interest. I’ve had several of my own projects fall by the wayside as other opportunities popped up that seemed more “fun”. As they say, the grass is greener on the other side . But I would argue the overall motivation for those failed projects didn’t dropped per-say. It was just that a particular type of motivation wasn’t effective at getting that project done, and that the person failed to cultivate the right type of motivation to see it through…

Short Term Vs. Long Term Goals

When it comes to goal setting I tend to write my short-term, concrete goals down in some form. That list takes the form of a weekly schedule and to-do list. The longer term goals, such as “Finish game X” or even loftier ones such as “become a full-time independent developer” or even “Travel…somewhere…anywhere” kind of stay in my head constantly nagging away at me . I find that when I’m not working directly on my game for a period of time the long term goals rear their head and eventually guide me back on course. But interestingly enough, the second I sit down in front of the computer to work my long term goals go out the window and short term goals kick in. This has had some pretty compelling implications on my work habits.

Some weeks I tend to faff about a good bit on YouTube, TED, RSS, IM, and other things throughout the work session. This happens even when I’m fully aware of the devil that is the internet. Now what happened between the time I was driving home from errands all hyped up about getting my game done and sitting down in front of my computer to make that dream a reality? I feel like my long term goals aren’t pushing me along anymore once I’m in a position to do actual work. What I’m finding is that I’m constantly looking at my to-do list and reminding myself how great it’ll be to finally have a a a good GUI system implemented this week to make the game hopefully look a little more…professional? I’m looking forward that following weekend to have a new build to push out to beta testers. I’m not looking forward to finishing game X on any given week, but finishing feature Y or bug Z. The important distinction here is that those short term goals have tangible results that are more easy to visualize while working.

Yes, I’m saying I have no idea how Tilt To Live will end up, I can only guess at that. I have a clearer image of how feature Y should work though. Maybe I should chalk this up to inexperience? It just seems so weird to me that there’s some sort of internal switch in my motivation based on the context of where I am at or doing at the moment that decides whether short term or long term goals will be the most effective. Realizing this will help push me more to create better weekly schedules so that my short-term goals are more tangible.

This seems obvious when you think about it, but I started thinking about how this applies to other things in life when I came across The Buried Life while listening to an Adam Corolla Podcast (doing laundry at the same time so not completely faffing about!). How many goals do people never see become a reality because they experienced my errand-to-computer dilemma? They got all hyped up about an idea, but when they were on that edge of opportunity they backed away not because they didn’t want to do it, but because they simply didn’t have any short term goals to push them over that edge? I’ll leave at that for now as it’s a bit heavier topic that I simply don’t have the time or qualifications to fully analyze at the moment. Back to my indie task at hand…

Work in Progress Screenshot of "Tilt To Live"

As I’m approaching the final legs of production (and starting to get my shit together for promotion and marketing) tangible goals are harder to find and smaller. In the beginning, having a playable mock up was a huge step forward that could be completed in a single week. Nowadays it’s about getting X animation doing Y exactly correct so it’s timed with the audio to give the best feedback for the user. The amount of effort for both tasks is about the same, but the return on investment for me as a programmer is much smaller when doing these polishing tasks. But I know polish on a good game is what pushes it past “ok” to “good” and gets people talking about it.

In a large project, such as indie game, having long term goals are essential to getting you and/or your team to jump on the project. Without those short-term goals feeding your long term motivation, your motivation eventually starves and the project slowly dies.

This week’s partial tangible goal list:

By Saturday that list will hopefully be empty, but it’s not the empty list I’m excited to see, but the fact that I’ll have a first pass of a tutorial system in the game by the end of the week . Looking at this list I can tell my “scheduling skills” were a bit lacking and I know most if not all of the priority #2 cases will be moved to the following week because this week’s goal is to implement and polish a tutorial system. Hopefully, this won’t translate to another hour long fall through the rabbit hole they call the internet .

Oh, and in case anyone is wondering what task management system I’m using, it is called FogBugz. It’s been a treat to be able to use such a robust system, even if I’m a single developer.

When it comes to gui coding I don't typically find it the most glamorous things to do. Particularly when dealing with games. You are left with writing a lot of boiler plate GUI code that is tightly integrated with your rendering pipeline. And even when I do find gui libraries for games they tend to try to emulate the OS in look and feel. When you want something lightweight and very interactive/animated you typically have to write it and integrate it yourself. If someone knows of a library for games that allows for versatile GUI development please leave a link in the comments . When left unchecked, GUI code can end up being:

1. messy and hard to maintain
2. difficult to change
3. rigid (basically just "functional" with very minimal style)

The GUI is one of the few remaining "big" items left on Tilt To Live's to-do list. When imagining the GUI I had all sorts of crazy ideas for animations, transitions, interactions. Despite it being a relatively minor part of the game's experience I still felt it important to really make it as polished as possible. Why? The GUI is the first thing a new user sees when launching a game (unless you're Jonathon Blow's Braid). It's important to grab the user's attention as soon as you can to make sure they give your game a fair shake.

Attention! Over Here! Look at Me!

In the mobile market you are fighting for pretty small attention spans. One of the design goals for Tilt To Live is to make it quick to play. Currently it takes one tap to start playing the game. I'm still working on reducing the initial load time. I even contemplated removing the requirement of 'one tap' to play, and to just drop the player into the game. When someone selects 'Tilt To Live' on the iPhone there's a large chance they are simply wanting to play a quick game of Tilt To Live. In fact, other games like Spider: The Secret of Bryce Manor do just that and it's actually quiet welcome. My only reservation is Tilt To Live may expand in the future to multiple game types so the 'play from launch' approach isn't ideal if the desired game mode isn't known with great certainty.

Either way, trying to get that good first impression on the user is very important. In addition to that, reducing the friction required to play your mobile game could possibly raise the game up beyond "I have nothing better to do" status and overtake other forms of gaming.

Ease-e-does-it

So back to GUI animations. Throughout the game I've used a hacked-together curve editing tool I wrote in Blitzmax to produce animations for items spawning, enemies popping up, etc. It works "well enough", but the barrier to creating a new 'curve' was still high and it added to the total filesize of the game and was another asset to add to the app. So I revisited easing functions. I use some throughout the GUI system, but they aren't very interesting. I started looking into alternatives and ended up with a rather nice solution.

Below is a work in progess video of the new easing functions in action on Tilt To Live's menu UI:

A couple of years ago, Shawn Hargreaves had a really nice article explaining curve functions and how to use them in the context of GUI transitions using the XNA framework. It was a really nice primer to getting your hands wet with polynomial functions. Fast forward to today, I still have the basic "exponential" and "sigmoid" functions, but they were pretty boring in the scheme of things. Tilt To Live's aesthetic is kind of cartoony so those functions weren't very lively.

Having worked with Flash many years ago I knew it's easing animation capabilities were very sophisticated, but I wanted to have some subset of that flexibility in my code as well, so off to Google I went. The best resource I found was Timothée Groleau's Easing Function Generator. Not only did it have a nice set of preset easing functions, it generated the code to produce those exact curves! Wow, this was a huge time saver! For anyone that wishes to use these functions as well, the variables used in the function probably require a quick explanation:

• t - the floating point time value from 0 to 1 (inclusive). If you want the position on the curve half way through the transition then you pass '0.5' through t.
• b - the starting position. In a one dimensional setting this is the value you would get if t = 0.
• c - the 'change' in position. So if you want to transition from 34 to 56 then c = (56-34) = 13. (more on this later)
• d - duration of the transition. If you want the transition to last, for example, 2 seconds then d= 2.

With that actionscript function generator it's pretty trivial to implement it in any other language (as in my case, C). Although my GUI transitions aren't based off of changes in position, but off of start and end positions. So my typical transition function signature looks like Transition(startPosition, endPosition, delta). Below is an example implementation in C:

The result:

• Much more interesting GUI transitions
• No extra assets as curves are procedural
• Can re-use curves in different types of animations (position, scaling, rotation, etc)

When I'm doing a polish phase on the GUI of a game or animations, sounds, etc I'm often reminded of the tidbit from Kyle Gabler's  Gamasutra article about prototyping: Make it Juicy. Using easing functions to add a bit of bounciness, juiciness, and overall personality to a game can really help make the game feel more alive...feel more...juicy.