Tutorials – Instructing the User

While building the tutorial level for SpringFling, I started thinking about how different games choose to teach the user the basic mechanics of a game. I’m not talking about a beginning cutscene that sets up the backstory or character development, but the presentation of the controls and navigation through the game world. Some games choose to present the user with a linear sequence of static screens that present text instructions, possibly with visual diagrams to assist in comprehension. This seems all well and good but if one thing’s for sure, it’s that users rarely read text that is presented to them, especially if it stands in the way of completing a goal or getting to the ‘interesting’ part of something. Users end up skimming or blindly skipping through instructions, with a higher chance of doing so if the instructions last for more than three pages. Also, some instructions go so far past the Powerpoint 8×8 rule (8 bullets per slide, 8 words per bullet) that a wall of text is thrown at the user, forcing them to bear through the reading or skip ahead and hope they don’t get stuck.

For this reason I chose to do things a bit differently for the tutorial level of SpringFling. The plan is to create an interactive tutorial where the player never loses input control and is presented with both snippets of information (tips) and direct instruction (tasks). For example, the first step will be to instruct the user how to move their finger on the screen to compress the spring and aim in the proper direction to land in a certain designated destination. The level will then allow the player to try as many times as necessary to complete this task and upon completion, display positive feedback of the task completion and move onto the next task. This can be easily accomplished by using trigger volumes to detect the spring’s location and whether the user has completed the task. This interactive tutorial idea isn’t exactly new but especially on the iPhone, I’ve seen far too many games present game mechanics in a less than optimal way or in no way at all.

One other requirement is to be able to revisit the instructions or tutorial at any time without having to restart your game progress completely. Keeping this in mind, the tutorial level in SpringFling will be easily available from the level select menu in case the player wishes to run through it a second time to refresh their memory or remember how to, for example, apply jetpack boost to the player. The tutorial will be exitable at all times and quick to complete for someone well versed in the game, but with enough depth to properly show a beginner player how to navigate the game properly.

I’m always interested by games that present information in the game world without having to use a UI element or HUD element to display the information. An example of this is Rolando’s unique ‘hey finger’ method of addressing the user, without completely breaking the fourth wall and staying in character. You Have To Burn The Rope also displays its hilariously obvious game information on the ground and walls as you walk through the initial stages of the game. Many other games use the signpost method of showing information, although that usually triggers a UI popup to properly display the text without losing legibility by presenting it solely on a 3d sign. Edge for the iPhone also uses the very intuitive method of showing a phantom cube playing out a looping action to show the player the intended path or move to complete. It seems that in-game tutorials have really picked up in the recent past as developers realize the multitude of options that are available from interactively educating the player. (Thanks to Josh Dick for helping to come up with these examples.)

Mike Minotti seems to disagree with all of this. In a blogpost entitled I Hate Tutorials, Mike talks about why he dislikes many aspects of tutorials. He makes some valid points that ‘expert’ players are sometimes treated condescendingly in tutorials, but to say that all tutorials should be skipped because he ‘can figure out any control scheme in no time’ doesn’t mean that the rest of us wouldn’t like to progress through an intelligent well-made tutorial that quickly gets across the main ideas without boring or overworking the player with unneeded drills. He goes on to say “Whatever you do, don’t make me go through a tutorial level”. I agree that gamers have been burned in the past with some tutorials that take up too much of the players time or catering to the less experienced player but a viable solution would be to make the system adapt to how well you are completing the goals. This should keep players of all levels happy and what I plan on doing for the iPhone game.

What do you think about in-game tutorials and instructions? Should they be banned and burned at the stake? Should they be optional, manditory, adaptive, linear, static, or filled with silly hats? Voice your opinion.

Big SpringFling Content Update

That’s right. A bunch more content to whet your SpringFling appetite. I’ve put together 5 new screenshots, complete with new level art. Check em out below.

In addition, I have a rough video showing gameplay. I’ll put together a proper trailer in the next few days, but for now you can just check out this quicktime video:
http://gtproductions.net/projects/springFling/springfling_beta4.mov

These screenshots can also be found on the Unity forums in the showcase thread. And now, without further ado, the screenshots.

Max vs Maya – The war rages on

History:
Max represents history in their Modifier Stack paradigm. Deformers, unwraps, and other modifiers can be stacked on top of each other and are easily viewable in a simple table. Maya on the other hand uses the node structure to represent dependencies and related modifiers for a certain object. The clear cut winner in my mind, as far as simplicity and user interface is Max. Just look at the screenshot. Maya’s highlighted arrow doesn’t even tell you where you’re going to to end up when you click it. It’s like a mystery wheel! Or you can brave the depths of the hypergraph to see your node graph. Eww.
Winner: Max

Material Editor:
Maya has a well laid out material editor called the Hypershade. Create a new blinn, assign some properties. It’s very simple to use and you can see all of your materials at a glance. One downfall is that the default way to assign a material to an object is to middle click drag the material into the scene. This is far from the best approach. I am aware of the right click -> Assign material to selection but it should be much simpler. Another problem with Maya’s material editor stems back to the original node based decision for the whole basis of the program. In order to, for example, delete a file node that is linked in your bump channel, you cannot just hit delete or unassign a texture. It seems that the quickest way is to go into the hypergraph view and delete the actual file node that was created when you assigned a texture to that slot. Messy. On the other hand, Max’s material editor uses a confusing slot system that to me seems counterintuitive. When I look at a material editor, I feel like I should be able to see all of the materials in a list. Max instead chooses to represent materials on arbitrary material slot nodes, so if you see 4 textured preview spheres, it does not mean that there are 4 materials in the scene, but that you have created pointers to four existing materials and there may be more or less. You can even clear out all of the material slots and then are forced to use the eyedropper tool to load a material into the slot. Horrible.
Winner: Maya

Interface:
Both Max and Maya have highly customizable interfaces with great context sensitive radial right click menus (or quad menus as Max calls them and marking menus as Maya calls them), customizable top menus, toolbars, custom actions or script buttons, etc etc. Both have more than adequate modeling tools, especially with Max2010′s graphite modeling suite, there’s a plethora of modeling tools available to use for any task. Max still hasn’t moved from the separate Editable Mesh / Editable Poly paradigm, which i feel is a weakness from a scripting and usability standpoint. At some point you need to ditch the backwards compatibility and put the best tools into one combined mesh interface. Max fails miserably at alphabetizing their modifier list, and that list has gotten WAY too long to keep in a linear pulldown menu. Shame on you Max. Then again, Maya’s interface looks like a bad Java app or a linux GUI… so there’s not much beauty to go around in this fight.


Winner: Tie

Scripting:
Despite what pretty much everyone else says, Maxscript seems equally as powerful as Mel so far, as I haven’t come across many things you can’t do in Maxscript, yet. That yet is a pretty big yet, and as time goes on and I develop more and more Maxscripts, I might need to revisit this section, possibly with a deep hatred for Maxscript. One thing to point out is that all of Maya’s commands are completely written in MEL and are available to browse, so ANYTHING can be scripted in Maya. Plus the addition of Python seems pretty huge for both Max and Maya, so there’s also no clear winner in this category.
Winner: Tie

Other:
Maya is cross platform. This is a huge plus for Maya that pretty much pushes it into the ‘extreme win’ category for me and thousands of other Linux and Mac users. Even though Autodesk owns both, I can say with reasonable confidence that Max will NEVER be ported to any other platforms. Also, the community is huge for both Max and Maya, and fanboys will continue to strangle each other over their favorite DCC app. One thing I would love to see to unify Max and Maya (come on Autodesk!) would be to help ease the pain of switching between Maya and Max. This could be helped by combining the documentation in a way that search terms for one app’s features will show up in the equivalent function of the other app. For example, a search for merge vertices will bring you to the editable poly/mesh docs for Max and show you the Max equivalent weld verts command. This type of guide already exists for Maxscript/MEL, located here.

Final Verdict:

SpringFling – Menus and Updates

Here’s the menu I’ve come up with for SpringFling. I’m using simple planes and lerps to do all of the animation. The spring’s eye movement and sun movement is all programmatic. I initially tried animating nodes in Maya but the performance hit was a bit too much for the iPhone.

As you can see from the credits screen, my good friends Josh and Brad will be composing *custom* music for the entire game! This should really add to the professionalism and quality of the overall product.

In addition, you can see that player progress is being properly tracked, as seen by the locking status in the level select menu. This is accomplished through the PlayerPrefs functionality in Unity. They make it extremely simple to save data to the phone/computer by using the following code:


//Once a level has been completed, store the level
PlayerPrefs.SetInt("Level", 2);

Anywho, check out the video of the menu system in action. Any suggestions?

And of course the Quicktime version: Menu video

SpringFling – Main Menu UI Mockup

A quick mockup of the UI. Grass and sky were painted in Photoshop. I plan on having the sun come up over the gray UI element as a subtle tip of the hat to the geniuses at Popcap.

I’ve been using the name ‘SpringFling’ as one word throughout development but people frequently put the space after spring so I don’t feel too bad wrapping the name on two lines in the main menu.

Wrangling GUIs with Unity iPhone

Dealing with GUI creation is both a rewarding and frustrating venture. While working on my iPhone game SpringFling, I’ve come across some GUI conundrums. I wanted to achieve a UI effect like this:

The height bar would dynamically fill up based on the y-height of the player. It seemed simple to do, as I would just modify the scale attribute of an overlaid half transparent plane that would represent the filled portion of the bar. I could then rotate the bar slightly to match the 10 degree angle on which the ruler is set and all would be well. That doesn’t quite work out as simply though. When you’re working with GUI in Unity, it is a special graphics layer that is rendered last. That means that no 3d elements can ever go in front of your UI. I knew of this limitation and thought that I would just use two GUITextures and scale the red bar dynamically. Unfortunately, you are not able to rotate GUITextures so I first moved to a much more dynamic solution: Render textures. Using render textures in the Unity editor without touching a script, I was able to achieve the GUI element below:

Due to the awkward size of the video, you can also view the source .mov here:
http://gtproductions.net/projects/springFling/springfling_heightbar.mov

Behind the scenes, this progress bar consists of two planes, one with the ruler texture and height text, and a separate single poly plane positioned over the ruler. The shader is then set to additive and the scale is modified in the playerScript. The y-height of the player directly affects the scale of the red bar. The single poly plane used for the red bar needed to scale from the left side so the pivot point had to be manually moved in my DCC app (Maya) in order to get scaling to happen in the correct location. Once this setup was working, I moved it out of view of my main camera and created a second camera and pointed it at my height bar. This second camera would look at the UI setup I created out in space to the side of the main level geometry. I then created a new render texture and in the properties dialog of this second camera, I added my render texture into the ‘target texture’ field. Lastly I positioned my render texture near the bottom of my main camera and voila, a 3d UI overlaid on my game scene. This unfortunately is a Unity Pro-only feature so I needed to find another way to do this.

EDIT: Thanks to Dreamora and Matt for the guidance. It also seems that render textures do not actually work on iPhone hardware so this solution is wonderful for Unity Pro desktop games but for the iPhone, another solution can be used. You can accomplish the same result using two cameras and no render texture. Just set everything up as I mentioned above but instead of using the render texture, set the “Clear flags” on camera2 to ‘none’ so basically the background of will be transparent and camera2 will be rendered first and then the main level camera second. This allows the gui to be overlaid on top of the scene while allowing 3d geometry to come BEFORE the gui elements. This is key for any type of crazy/interactive gui in almost any game. Hey we’re using this technique at work for rendering a 3d UI over a background scene.

One other thing I’m experimenting with is the use of Unity’s great new GUI system known as UnityGUI vs the old tried and true method of GUITextures and GUITexts and manual UI development. Instead of event driven GUI development, UnityGUI uses an Immediate Mode GUI system, or ‘IMGUI’ which basically boils down to the fact that you work with the GUI in a separate GUI-specific update loop where you use logic to change GUI elements dynamically. This makes fades, slides, transforms, and other animated GUI operations much simpler and mirrors the regular Unity update loop in almost every way. Below is a basic example of a flashing button:

//flashing button example
function OnGUI () {
if (Time.time % 2 < 1) {
if (GUI.Button (Rect (10,10,200,20), "Meet the flashing button")) {
print ("You clicked me!");
}
}
}

Those familiar with Unity iPhone development will note that it is not advised to use Unity’s built in UnityGUI system and instead opt for GUITexts and GUITextures due to performance reasons. This is a valid concern as Unity’s GUI system does have a significant overhead associated with it but it really only comes into play with HUD UIs where UI elements are rendered over a 3d scene that requires a high framerate for gameplay. In a dedicated menu scene, UnityGUI works perfectly on the iPhone but as I move forward with custom UI art, I might switch over to the old GUITexture method to save resources. The last week of development will surely be focused on performance testing so I’ll be able to give more solid statistics on the impact of UnityGUI compared to single UI element placement. If you’re planning on using UnityGUI on the iPhone make sure to turn of automatic layout by putting this line in your Start() or Awake() method:

useGUILayout = false;

It will reduce your GUI overhead to an almost acceptable level for iPhone use but as I mentioned before, it’s not a great idea for a HUD where the game scene runs behind the UI. :)

Lastly, I stumbled across a post about iPhone optimizations and learned that string comparisons are much more expensive than int comparisons. Previously I was managing both game and GUI states with a static state string variable in my main game script. All all other scripts would query this state during the update loop ala:

if(game.state == "flying"){
//do stuff
}

This worked for me as I was able to easily see which state was being addressed by the string name, but after after hearing about the performance hit, I decided to switch over to enumeration. I also rely on a second state variable which I have named guistate to keep track of my different (for a lack of a better term) GUI states. These, for example, consist of ‘mainmenu’, ‘highscores’, ‘shop’, ‘stats’, and of course ‘none’. With the ability to get and set these global states at any time from any script, I can determine where the user is in the logical flow of the game and exactly what they are doing there. Then my onGUI function contains each of my GUIs and wraps each one in a quick if statement ala:

if(guistate == aguistate.death){ //player has died
GUI.BeginGroup ( blah blah GUI creation for death screen goes here);
}

Well there you have it. And if I can leave you with some words of wisdom, GUI takes twice as long as you think it will, even if you know this fact to be true.