"Happy GO Driver!" Promo Codes and Dev. Postmortem

I’ve posted this description and screenshots in the “Unity iPhone Apps in the Store - List Yours Here” thread, but I’m reposting it here, along with 5 promo codes:

N9NF4Y9NATPM
34XEF7LEXYK7
KH6KY6XN4X6M
TL3PNL4EEKJ9
JNJ7H7FM9R7W

If you use a promo code, just post a quick note saying which one, and maybe come back later and post some comments or criticism? :slight_smile: We’re eager to do a “1.1” after Unity iPhone 1.1 comes out.

I’ll post a follow-up message in this thread, with some technical background on the game, in just a few minutes…

iTunes link: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=327054539&mt=8

From the store:

“Happy GO Driver!” is a casual arcade game where you control the traffic signals in a city of car-crazy drivers. Keep the traffic moving and don’t cause any accidents… unless you’re feeling a bit mischievous!
FEATURES:
-Lush, hallucinatory hand-drawn backgrounds and sprite illustrations.
-Eight levels that progress from easy to challenging — each level has its own unique strategy and subtleties. There’s something for every skill level.
-Easy controls: Large touch areas around each intersection ensure that you won’t miss a “beep.”
-Stop signs bug the drivers; they display thought-bubbles to show their growing impatience.
-Traffic patterns vary for each road and level: Some roads move faster than others, some carry more traffic, and still others carry slow trucks instead of fast cars.
TIPS:
-Go with the flow and find each level’s rhythm.
-Sometimes, it’s not about how fast you are, but how good you are at waiting.
Happy GO Driver! is developed by John Balestrieri Peter Hamlin and published by Tinrocket, LLC. Made in Brooklyn, New York.[/code]




This was a two person project. Total development time was about 4 months, and included many variations, changes in direction, tweaking and re-tweaking, mid-project breaks (where nothing was done), beta testing, and final rounds of changes based on user feedback.

I did all the Unity iPhone development and my project partner, Peter Hamlin, did the character design, graphics illustrations.

Here are some development notes, off the top of my head, that may be of interest to fellow developers. I’m happy to answer any specific questions, share code, or elaborate on any part of the development process. Ultimately, we hope to have a section on our game’s website, dedicated to Unity iPhone development info and resources, based on our collaborative project experience.

Development Brief:

The app was developed entirely in C#. The text editor used was TextMate, with a C# language bundled developed by one of the forum members here. (Sorry, I can’t remember who’s it is at the moment.)

The main development challenge was dealing with performance on 1G Phones.
This game has a lot of draw calls – the game uses billboarded sprites with the blend mode used by particles - premultiplied alpha blend. By the time development got underway, it was too late to switch to Sprite Manager. I’ll probably look into that for the next game, though.

Sprite sizes range from small – the cars, to large – the backgrounds. Each level has a background comprised of 2 RGBA textures that are 512x512. GUITextures were only used for interface elements – score bar, icons, etc. because the other game elements, i.e., the backgrounds, needed to be rotated. Rotation occurs by shaking the camera when vehicles crash.

Most animation was mostly done in Cinema 4D and played back in game. This type of animation was much easier to work with than anything animated programatically. Some problems arose with animation playback, where the final keyframe was never played, leaving the animation in an unfinished state. This problem was discussed elsewhere on the forum, and the solution was to set the animation playback to clamp the last frame ‘forever.’

Secondary animation occurs when cars crash – Unity’s physics system kicks in. However, it’s only turned on after a bounding box collision occurs between two or more vehicles – until then, it’s dormant and does not take any CPU cycles.

The only physics bounding volumes used by the game, for collision, are around the cars, so the physics parameters were tweaked so that no collision moved any car too far – ensuring no awkward placement of cars over the static background elements like trees or buildings.

All physics rotation was restricted to the Y axis of each vehicle, so there were no 3d rotations in space.

Finally, the physics behavior in the crashes sometimes yielded ‘boring’ collisions – so some code was added that is executed when two cars collide: There is random torque applied to each car, making them spin a bit.

For the art process: All the game elements were illustrated in Adobe Illustrator by Peter and I would work as technical artist to fit them into the game, preparing texture maps in Photoshop, building the 3d billboards in Cinema 4D, adding animations, etc., ‘normalizing’ color palettes/brightness/gamma, etc. For a game of this size (I would think it’s pretty small) there were an amazingly huge number of assets required. Peter generated a lot, and some have not yet been incorporated into the game yet, because I fell-behind on finding time to add them all in. We’re planning to use additional art assets in future updates.

I just took 34XEF7LEXYK7. Thanks.

This looks like a really nicely done game. Congrats!

This looks fantastic! I love the art style. Great work.

Used: KH6KY6XN4X6M

Thanks! I’ll have more feedback forthcoming.

I love the screen shake when cars collide.

Absolutely fantastic work here. It’s great. I, too, am a fan of the camera shake. Lots of nice little touches, like the birds and clouds, etc, in the foreground (though I’d prefer a slightly lower alpha for the clouds as sometimes they can obscure traffic below).

I’m testing on an iPod Touch 1st gen. The framerate is a bit low, likely due to draw calls, but for a game of this type, it is not a big deal.

Provided your sprites all use the same material, you should get a very substantial “free” performance boost with 1.1 from what I’m told as it is supposed to combine meshes that share a material into a single draw call. I’m looking forward to seeing what that will do.

I was a bit unclear as to how level progression was to take place. I wound up playing the first level interminably (I presume I could have gone on forever?) until I took the time away from playing to notice the little “unlock” icon at the top and decided to see what happened when I tapped it. Sure enough, that’s how to go to the next level. It might be good if this could be made a bit more clear to the player.

Again, excellent work! I expect you’ll do very well.

I took JNJ7H7FM9R7W. Thanks, looking forward to trying it!

I took N9NF4Y9NATPM

I look forward to playing it tinrocket! Looks great!

Hi, I believe there is still 1 promo code available?

TL3PNL4EEKJ9

Or, if someone out there tries this code, but it’s been used already, can you post a message saying that all the codes have been taken?

I will send a new promo code via PM to the first person who does this. :slight_smile:

Thanks,
John

Thank you, kenlem Brady. It’s been a rough week, sorry for the delay in responding:

I’ve submitted version 1.0.1 to the app store. Now, on first-gen devices, the frame rate is fantastic, all thanks to Unity 1.5. :slight_smile:

Brady, I see your point; I plan on adding a clearer way to signal the player to move to the next level, in a future update.

Thanks again,
John

I’ve just been notified by PM that all codes have been taken. :slight_smile:

Thanks for all the information. It’s great to hear how others accomplished things differently. I went ahead and just bought your game to support our fellow developers. I did run into the same problem mentioned earlier where I didn’t realize I could go to the next level. Also, I felt like the difficulty might have gone up a little too fast, or maybe I just am not good at the game =)

On another note, I would be fascinated to hear more about how you utilized Cinema4D. For the current 2D sprite game we are finishing up, we have done all the cells of our animation by hand in Photoshop which has been quite the task and is very limiting. I want to find a better solution for our next game.

Thank you, Michael.

For the C4D work, I set up billboards for all the game’s textures, and placed and scaled then in Unity. Anything that was animated was animated in C4D, and I would apply the animation track to separate objects in Unity. It was definitely a learning process.

All texture animation – such as changing images in a texture atlas – were done with a C# script I wrote to play animation from a texture (The waiting emotes use this). It also has some extra features, such as picking a random frame at instantiation time (The driver’s heads work this way).

This script grew out of an earlier project my partner and I started, then abandoned. For that project, he drew frames of animation in Flash, which were then exported to Photoshop where I would create a texture atlas. We would then preview the animation in C4D with an XPresso tag I wrote to do the same thing as the C# script.

I’d be happy to share the C# script, the XPresso tag, if that helps.

Also, while creating all the textures in Photoshop, I used an action I created, heavily, to create an alpha channel from a layer’s transparency. It reduced the work required – a few steps – down to a keyboard shortcut. I’d be happy to share that as well.

Let me know if you want any more details on C4D integration or help with your workflow. :slight_smile:

John

Thanks again for all the info and your willingness to share. I would love to talk to you more about this once we get past our current project. Working every waking moment right now to get this done =)