Driving 4 Dollars: A Game In Five Hours, But One Doesn’t Count.

Posted by Rampant Coyote on November 5, 2012

A half-hour before the Zero Hour Game Jam (in my time zone), I still wasn’t sure what I was going to make. Part of me wanted to see how Unity could handle something along the lines of a “Bullet Hell” shooter. Part of me wanted to do something completely traditional – a 1980-era arcade game whipped together as quickly as possible (in zero hours!).

Suddenly, and quite mysteriously, I was struck by a desire to make a game where you drive around in a car picking up things.  Actually part of it was thinking it’d be fun to have a deathrace-style game where you also have to shoot or smash other cars to get at the best prizes (yeah, a decade and a half later, my baptisms by fire with Twisted Metal and Jet Moto still come back to haunt me, I guess…)

Of course, doing anything smart with AI was pretty much out of the question. I still kinda fantasized about having turrets shooting at the player, but I decided that would be an enhancement when it turned out that my concept was WAY too simple and was going to be done in thirty minutes…

Yeah. Right.

I’ll link to it here so you don’t have to search through this wall of text for the game: DRIVING 4 DOLLARS!

BUILDING THE GAME

I got my tools fired up in advance – Blender (which I never ended up using), the Unity engine. Should have loaded Gimp and Genetica too, but ah, well. Within seconds of hitting 1:00 AM (for the first time), I created a new project in Unity. Well, I started creating a new project. I’d included too many resources, and so Unity took a couple of minutes to pull together all the assets and finish creating the project. When you only have sixty minutes to work with, two minutes spent somewhat idle is not a good thing. I finally moved on to see if I could work on something else just as Unity finished.

I started by creating the playing environment – a ground bounded by four walls.  Since I’d only come up with an idea a few minutes earlier, I hadn’t really thought through everything I’d need. My idea for the gameplay would be that you’d have to navigate the world maze-like picking up prizes while avoiding smashing into obstacles (possible deadly ones). I still have no idea how I ended up spending fifteen minutes just putting together the playfield. I found myself tweaking sizes and stuff, and then realized that it was now almost twenty past the hour. My time was two-thirds gone and I’d accomplished next to nothing! Time to get cracking on the most important part, the player’s vehicle.

I really screwed up on this one. I’d over-designed the system. Badly. I haven’t done enough work with rigid bodies before in Unity, and realized that I’d duplicated a lot of work that rigid bodies already handle. So I ended up yanking much of the code I’d already done to handle accelerating, braking, and turns, replacing them with simplified versions that would work with Unity… and found I’d spent a half-hour writing player code. I had only TEN MINUTES to finish the game, and at this point I could barely drive around the scene.

I took a couple more minutes to import NGUI for some potential UI, and set up the basics of a UI camera and a special UI-only layer, added a UI and a panel (with nothing in it), and now I had only a few minutes. Game over, man, and I didn’t really have a game. I broke something, un-broke it, and time was up. I went to bed in failure.

Being how I am, I found myself unable to leave it at that. If I’d scoped things poorly (like I always do), then how much time WOULD it have taken to make this game in my head to the level I felt acceptable?

The following afternoon, I re-opened the project and started tinkering. Since I was curious about the time, I watched the clock.

It took another hour to rip out around half of my homemade physics and replace it with stuff more friendly to the Rigidbody physics of Unity. Since I’d only used rigidbodies in a non-scripted way before, part of this time was spent looking stuff up. A lot of the tweaking was done through trial-and-error. For example, to (partially) cancel out sideways movement of the vehicle (you can skid, just not much – definitely not as much as you could in earlier builds), I have to take the velocity vector for the vehicle, transform it into local coordinates (using the handy-dandy WorldToLocal matrix of the transform), and then apply sideways forces that I kinda have to guess on to counter whatever the sideways velocities are. After a few iterations I came up with something close, and leave it at that. That applies to the local X forces. Then there’s acceleration and braking, which get applied to the local Z coordinates. Then I re-transform these back into world forces using the also-handy-dandy LocalToWorld matrix in the object’s transform, and feed it into the rigidbody.

So two hours into the project, I was driving around a square, empty arena. And I had some basic stats up on the screen via NGUI telling me speeds, angular velocities, etc. Woot.

The next hour and a half was spent adding in the gameplay. Since I was no longer working against the clock, I took some time, learned how to use the 3D Text objects in Unity (to display the dollar values), built an overall game-logic object (as well as the “collectable” logic that fires when the car collides with the prizes).  I threw in some more walls in the arena to make it an interesting area to drive in, and … there we were. Three and a half hours later, I had kinda-sorta the game that I’d had in my head twenty minutes before the 0-Hour Game Jam. Okay, the game in my head had used a 2D perspective, but it was so easy to use the 3D camera following you around, and it looked cooler and more interesting, so I’m pleased about that change.

But since I was not constrained by time so much (though I still wanted to be “done”), I took over another hour to “polish” the game. The game currently ended rather unceremoniously, with your previous inputs still valid, running you into a wall or something. So I added a clean end to the game, including a “game over” message that tallied your final score. Plus, I made the game re-entrant, so you could hit the space bar to reset the entire game.  I added the ability for money to re-spawn as you played, which I’d planned initially but realized than in 60 seconds you had little chance of gathering all the money in the arena anyway. (Every time you grab a prize, it tries to respawn two prizes in positions OTHER than the one you just obtained the prize from, at random. If those are already occupied, then nothing happens. In practice, this means the more empty the arena gets, the more likely prizes will respawn in empty positions).

I also took some time to create and add sound effects. The rumble from the vehicle is from Unity, and I vary its pitch based upon your velocity. The pickup sounds were whipped up via BFXR. I built a stand-alone executable, which is why I give the option to press the escape button to quit (sadly, only at the end of the game, bad design but ah, well). Part of that last hour-and-change was spent creating the stand-alone and the web-based builds.

PLAYING THE GAME

It is not an incredible game by any stretch. It’s a five-hour game, and a failure of a zero-hour project. But it was an interesting exercise, taught me a couple of new (or at least forgotten) tricks in Unity, and was overall good “practice.”

So here’s the context: You are in a game show called “Driving 4 Dollars!”, where you have sixty seconds to drive around an arena in your purple truck (with the way the vehicle currently handles, and it’s boxy shape it’s definitely a truck ) picking up cash prizes in $10 and $25 denominations.  The truck is controlled by the arrow keys – up arrow for gas, down arrow for brake & reverse, and left and right arrows for steering. I think it’s kinda fun, but it’s my baby so naturally I’m naturally inclined to like it.

Play Driving 4 Dollars!
A game that couldn’t quite be made in only zero hours…

Getting up to about $100 is pretty easy. My high score so far is $150. Can you beat it?

If I were to expand upon this idea, I’d improve the handling (and graphics generally), fix the steering in reverse so it better matches reality. For gameplay, I’d probably give the player two minutes, and have a special tile (or four) where the player could drive into in order to purchase more time with some of their dollars… say $40 to buy 30 more seconds or something.

LESSONS LEARNED

The key to getting good at making games is the same as getting good at pretty much everything… practice.  And evaluating how you did, and how to improve. Here are some lessons I learned (or re-learned) making this project:

#1 – Plan ahead! I did a poor job of this one, other than opening up tools a few minutes beforehand. I don’t think it’s breaking any rules to spend some time in advance identifying what assets you need to create, what libraries you might use, and spend some time looking up information on anything you are less than comfortable with.

#2 -Keep  Engine / Tool Notes: When I started working with Unity about a year ago (yes, my last zero-hour game project was one of my fledgeling efforts in Unity), I started keeping a list on my desktop that I call “Unity Tips and Tricks.” It’s based on a similar (much longer) one I created for Torque. Whenever I have to look up how to do something new and potentially tricky, I record what I’ve learned in this text file – especially if it’s something I don’t do very often and can easily forget. During this project, I referred back to these notes a few times, and added a couple of new entries.

#3 – Start Simple and Grow: I made a mistake of over-designing the car physics from the get-go, spending too much time on unnecessary code that was eventually tossed. I should have started with the rigid body system, and figured out in advance what inputs it needed to go, rather than trying to do the physics myself and then tried to force the rigidbody to behave accordingly.  However, I was correct in starting with the core gameplay – the interaction driving around an arena – rather than jumping into something like gun turrets or overall game logic. Also – I feel I was write in keeping my assets simple – mainly just colored cubes. I’d opened Blender, but colored cubes and text works just as well for early prototyping.

#4 – Create Milestones and Fallbacks – this goes along with Planning, #1. I was “in the zone” when I was building the car controls, logic, and physics, which is a good thing, though it meant I didn’t realize how much time had passed. Any other time, this would be a great thing.  I love that. But when working on ANY project, whether for a tightly time-limited game jam or for your own indie project, you need to break things down into milestones, and decide what needs to be done if you find the schedule slipping. In some cases, it might mean removing features or simplifying things going forward. For something like a 1 hour project, I’d expect to have the very basics of the game up and running (interactive but perhaps not playable) in the first 20 minutes, to have the core gameplay done within 40 minutes, and the last 20 minutes would be spent turning that playable hunk of whatever into an actual game.  For a larger time frame, I might allocate things into quarters, and the last quarter would be devoted to testing and polishing.

 

 

Filed Under: Free Games, Game Development - Comments: 4 Comments to Read



top