SpringFling Submitted!

Hey everyone. This will be the final update before the all-important release of SpringFling on the App Store. The big news is that:

SpringFling v1 has been submitted to Apple for review!

This means that the world can get high flying springy action in 1-2 weeks, hopefully before the end of October.

Since you last heard, SpringFling has had a large amount of final polish added, including a full character customization suite that allows you to equip silly hats, beards, and glasses on the character. Some other things have been taken care of, such as a full fledged interactive tutorial, finalized level art, finalized custom soundtrack, framerate improved after some significant code optimization, and many many bug fixes. Thanks to my testers for helping make the game as solid as a v1 release can be :)

Since I’m speaking to a good amount of game devs here, I’ll mention that working with Unity iPhone was a breeze and I’m glad I chose to use the Unity engine to develop the game instead of attempting to roll my own solution. To be honest, I don’t have the programming skills to hack my own engine, and if you happen to, I can only say to shoot for the stars, but developing an engine incurs a significant overhead of time and therefore money that some would rather not deal with. Buying an engine also costs money but I have only good things to say about my development experience. Take away from that what you will.

Follow SpringFling updates on Twitter for updates from Mr. Spring
@springflinggame (twitter.com/springflinggame)

SpringFling – Website + Trailer

That’s right folks, a real video trailer for SpringFling has been released. In addition, the app website is up and running! It’s been a long week at my full time job and a long week working on the video and website but it’s finally paying off to see it go live.

Check out the site at SpringFlingGame.com and look below for the new trailer. Let me know what you think!

And as always, the link to the HQ Quicktime Trailer.

SpringFling – Sewer w/ audio

So here’s the new sewer level and accompanying musical score courtesy of Brad Scoville and Josh Dick. Any suggestions as far as art/musical stylings?

Sewer Audio

SpringFling – Parachutes in action

Well it’s been a few days since the last update, so I thought I’d show some new goodies. I’ve been hard at work on the backend for achievements, online scoring, and other various implementations and fixes, but there’s also some eye candy to show.

First up, there’s a new powerup in action. The parachute!

This allows for much needed in-air influence over the spring at certain critical times, such as when your jetpack runs out of juice and you’re stranded over a pit of doom. Boom, parachute. Now you’re like frikkin James Bond, floating back down smoothly, the ladies eyeing your shiny metallic finish. Smoooooth.

Also, I have the art created for my next powerup, the jetpack/rocket. Things are coming along nicely. :D

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.

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.