Level editor ?

I've been toying with the idea of building a level editor for TurboGarbageTruck. Going over the advantages versus work required, I think I have to give it a try.

I've been pretty much just conducting experiments in the game so far. Very surprisingly, almost all of the experiments have been successful. While the game is not terribly ambitious, there were a few slightly uncommon elements that I took on right up front. The idea of a continuous, looping play field is likely as old as Pac-Man warp tunnels or Combat on the 2600. Maybe Defender or Asteroids... okay, the fact that I'm pulling this stuff out of my head really dates me. I'm old, nuff said. Moving on.

So anyway, continuous scrolling, or wrapping game levels have one major advantage over *standard* levels. They can feel free and open while still being very small and contained. You know that feeling when you walk really far in one direction knowing every step you take is one more added to the return trip. Continuous levels eliminate that. Exploration is simple and fun. Like a game.

This another one of those times that a technical limitation created interesting mechanics. In Combat for the Atari 2600, lining up a shot that passed through the bottom corner of one side of the screen to hit your opponent in the top corner of the other side, was a carefully honed skill. The headshot of its time. I'm working with Unity3D, a modern 3D game engine with all the appropriate dingers and tweeters. Technical limitation isn't really a problem I'm faced with. Sure, there are limits, but nothing I have come up with just flat out can't be done with this engine. With a small amount of ingenuity, you can create whatever you can dream up.

The problem I have run into is that the built in tools for level building in Unity3D are just not well suited to creating spherical levels. I mean really, outside of Mario Galaxy, how many games are built on a ball. Not too many. I could simply build all my levels in Maya or Silo and import them into Unity. While that would take pretty much no upfront work, it would also give me almost no flexibility. The best option seems to be to create some more appropriate tools.

The first tool I will have to create is a way of placing objects on the surface of the sphere that doesn't require manually rotating them around a point at the center of the planet. The second will be setting up a way to save out the level into either a serialized format or an xml file. There are ups and downs to both, so I'll have to research it a bit more. The positive offshoot of a save system is that I will have also created the basis for a game  save system, or even a way to save the state of levels, If I go that route.

 Before either of those though, I will go through and just manually assemble one level. While building it I will take notes on all the things that the tools will need to handle. What things will I need to include in the base object class, and what will I need to set up for the save system. These are things you could paper prototype for days, but until they are placed in a running game environment, they will only ever be educated guesses. I have no one to answer too and no reports to prepare, so fuck it, I'll build it and see what happens.

So thats the road map. That is what I'll be working on for the next while, and since I work for an hour or two a day I should be done in the next couple years. I will still be posting up builds though, and depending how deep I go with the editing tools, I'll post that up too. If you like playing with broken toys, follow me on twitter (over on the right there) and I'll spew forth a tweet every time an new build gets uploaded.

In the Lab

I've been working on a lot of experimental things. Many of them have been in the builds, and you might have seen some of them. Some others, I have been working on in other scenes and tests. Since I haven't set up the ability to play with previous builds (still coming), I figured I should give a quick run down of some of these experiments.

On the ball


Probably the most difficult challenge so far has been to get the endless spherical world working. I started by creating the obvious. I made a sphere and the built in sphere physics collider, and put the truck on it. That was an absolutely spectacular failure. The truck would go shooting off in random directions, jiggle violently in place, or fall trough the planet (sphere). Often it would do all three. I figured that this wouldn't be adequate to the task, but it never hurts to try for very simple straightforward solutions.

Next I tried setting up a sort of artificial gravity. The physics engine has a built in gravity that applies a force of 9.8 newtons along the negative y vector. Simply put, stuff falls down. I needed stuff to fall toward the center of the planet. Lucky for me a lot of other people over at the unity forums had done a bunch of that work, so I only needed to modify it. Once I adapted some of the other artificial gravity systems and simplified them for my needs, it actually wound up being one line of code. The object with gravity applied to it simply looks for the center of the planet and then moves toward that with 9.8 newtons of force. Done.

So the artificial gravity worked fine, but stuff would still keep flying off the sphere collider, and would occasionally end up in orbit around the planet. Literally. I could hit a garbage can with enough force that it would fly off the planet ending up in a perpetual free fall. It was really funny, and I might use it for something later on, but it meant that, given enough speed, the truck would also leave the surface of the planet, and that was pretty much the end of the fun. The truck would also freak out pretty regularly and usually fall through the planet The main culprit turned out to be the sphere collider. For any math nerds out there, this is probably pretty obvious. A sphere is not a really a stable shape to set things down on. So I ditched the sphere.

The next obvious road was to create a mesh collider. The physics engine and the graphics work off of separate models. The physics engine really only works with very simple objects. The graphics on the other hand can be very complex with little to no slowdown on most devices. For every object that you want to react to gravity or collisions, you will need both a physics and a display model. Using a mesh collider, you can effectively, use the same mesh for both, if the display model is simple enough. Making a decent looking sphere requires a pretty dense and complicated mesh. So that was a no go.

The best collision objects in the engine tend to be cubes or boxes. So I hit on an idea that worked out really well. I figured, why not have the truck just bring the ground along with it. I made a box that's a little larger than the truck and placed it just under the wheels. Then I made a script that told the box to follow the truck around  so no matter where the truck drove in the world, it would bring its piece of ground with it. On a flat surface it worked fantastically. I went about adapting my artificial gravity code to make the collider rest on the surface of the planet sphere and rotate smoothly around the center of the planet to stay positioned under the truck. That also worked very well, but caused some other problems with the camera flipping over and the the controls would sometimes jank out when the truck passed over the poles due to an unfortunate side effect of Euler angle math called gimbal lock. Here is one of the best explanations I've ever seen of gimbal lock.

So I could go back and change all the code I had in place for making the truck move around, or I could change the rules of the game world. So I did that. Instead of driving the truck around a ball that sits stationary in space, the truck drives around on a flat XZ plane and the planet follows around underneath it rotating in the opposite direction. And the rotations are all using quaternion math, so gimbal lock won't be a problem. Any object that doesn't require player input, like the garbage cans and blocks aren't affected by gimbal lock, so they just roll around on their own little ground colliders and everything looks like it is resting on a sphere.

So that is how I went from driving around on a flat plane to driving around on a ball. That's pretty much the stuff I think about day to day working on TurboGarbageTruck. I'm certain that there are better ways to do all the things I'm doing, but development is an iterative process and I should gradually figure out what works best for this game.

I've set up a twitter account so you can follow development over on the right there. I'll tweet any time a new build goes up or I do anything significant with the development, like posting up concept art, videos, or blog posts. You can also follow me @Owen_McManus for dev and non dev related tweeting.

The Brokenest Build

I  just put up a new build of TurboGarbageTruck. This is easily the most broken build I've put out since the very first tests. It's also one of the most interesting, as far as I'm concerned. There are a few things that I've been working on in different experiments that have gelled together in this build. That it functions, on even the most basic level, is enough for me to call this a success.

Forward we go.

Truck sketch

I did up a new Truck design sketch. I think I'm getting closer to capturing the character of Truck. Seriously, this an anthropomorphic garbage truck who's sole purpose is to alternatively smash and gather things in his world, to make a larger and larger garbage pile. I'm really just designing him as a character because I find it entertaining.

I compressed about 45 minutes of sketching down to 3 for the video. Much longer than that and some of the slower bits really get pretty boring to watch.

I have never recorded myself sketching. It's weirdly intimidating. Most of that self conscious feeling I use to have when someone would watch me draw or paint has faded with practice and time. Now, if someone comes to peek over my shoulder while I'm drawing, or modelling, I don't really worry about what they think of my doodles. I'm usually much more concerned that they will just get bored. Recording myself sketching, I'm just worried that the screen capture will break or the computer will crash. It felt like I was drawing to beat the clock. After a few minutes I sort of relaxed into it a bit, but this is definately a new process, and it will take me a while to get comfortable. Modelling with the screen capture running will be... interesting.

screen capture

I finally got my screen capture software to work properly.
Here is a quick test I did to make sure I could capture any concept work.

I sped it up quite a bit, because nothing is more dull than watching someone draw a poor sketch for a long time.
I'll be trying to capture any concept and modelling I do. The sketches will likely be better, but I'll still try to keep the videos short.

Is there anything that anyone would be particularly interested in seeing a video of? Would commentary be good?

Also, fresh builds are always going up. Go test it out. There is some sound now and the truck is much harder to flip.

Experiments

I'll spare you the usual novella. I tend to just pound on the keyboard, orangutan style, until my hands get sore, but I'm a bit tired so here's a small one.

I posted up my development list for TurboGarbageTruck. It's not really a design doc. It's really just a list of things that I want to add or test out. I expect that I will grow the list fairly steadily and then drastically hack it down when it grows too unwieldy.

In the latest builds I've been conducting some experiments. I created an infinite terrain setup. Essentially if you drive out the north side of the environment you will come back in the south side. You can drive in one direction forever... or until the physics break and the truck falls through the world. This is just stage one of a larger experiment with continuous environments. So far so good.

The truck flips over way too easily. Working on it.
Also, currently there is no limit to the speed that the truck can reach. You can break the sound barrier in that mofo. Still not sure if that is good or bad.

TurboGarbageTruck

My newest game experiment is up.

It's TurboGarbageTruck... a name and concept stolen entirely from my son. So... not really my idea.

I have a theory that feedback on a game (or quite probably any other media) can't be gathered too early. I suppose it isn't much of a theory, and it really isn't my theory either, since every major developer employs, or keeps employed, dedicated testing staff. Feedback is what these people do. It's all they do. It's less of a theory and more of an imperative. And again, not my idea.

I've talked about "open kimono" development before. I've also seen this referred to as "open door" or "transparent" development. The basic idea is that you let your potential players in on the development of your game as much as possible, while you are making it. Demos, tests, concepts, design documents... they are all on the table. I posted up builds of my last project while I was working on it, but I really didn't commit to open development. I think I know why very few developers even attempt it.

It's scary as shit.

There is that old chestnut "you never get a second chance to make a first impression". So I could go ahead and post up all my dev builds, any concept art, any design docs, knowing that the first version of any or all of those things will probably be garbage. Going by the first impression rule, that would sour anyone who saw it on all future versions of the game. The damage would have been done with the first broken play test. A trend toward development secrecy almost goes without saying, if this first impression rule has any merit. It does and it doesn't.

Minecraft.
Kickstarter.

Everyone brings up Minecraft. Constantly. For good reason. It's a goddamn phenomenon. When it was first released, no one would have guessed that it would be a phenomenon. No one. Because it sorta sucked. Mojang didn't catch lightning in a bottle. They built steam slowly, one beta version at a time. Only thing is, slowly in internet time is anything longer than six months. To those not acquainted with internet time, this is pretty much the same as instant. Had they toiled in secrecy for that same amount of time and released the current version of Minecraft whole hog, to an unsuspecting internet, I suspect it would be met, initially, with a collective meh.

Minecraft isn't some strange exception to the rule either. Kickstarter is a funding and business model pretty much built around showing your work. Offering updates and "making of" style information to the people who will fund your project is pretty much a requirement. I doubt that there are any successful projects on Kickstarter that say "Fund my project. It's a super great idea that I can't tell you about."

I only chose these two examples because they are current and relevant to indie game development. There is a long history of "patrons of the arts" which is short for "I will pay you to let me look over your shoulder while you work". That's exactly where the first impression rule breaks down. If you are meeting someone face to face and you know that they will be judging you, as a person, by all means, bring your A game. When it comes to "things" the rule no longer holds up. In fact the exact opposite is true. Everyone likes to watch things being built. Skyscrapers, houses, cars, paintings, movies, and yes games. As long as you don't have to do the work yourself, watching it get done is fascinating. I've lost count of the amount of people who stood around to watch me apply decals to their car. Where things that people are building are concerned, it would probably be more accurate to say that the final impression is what matters. If the final work resonates, any problems during the making are forgiven. People have died while making movies. Died! Making movies! Successful ones. As a first impression, I can't think of much worse.

So transparent development shouldn't really be all that scary. I understand the need to withhold some details. Plot twists, puzzle solutions, easter eggs, etc. Most players have such an aversion to anything that would spoil their fun, and rightly so, that they would likely cry foul if you released that stuff anyway. Any other development details really don't need any protection. In fact, I think a lot of the best big budget titles could benefit from transparent development. Patrons of the arts love to look over the shoulder of their heroes at work.

I'm starting TurboGarbageTruck in the most transparent way I can think of. I'll let you play it. I'll be adding a method for you to play all the previous builds and experiments too. As I get to scanning them I'll be posting up concept art and maybe even design docs (though this game sort of speaks for itself). I'll definitely be posting up my road maps and upcoming features. Please feel free to ask me if you want to know more about anything I'm working on, or if you just want to call me out on anything I'm doing that you think is bullshit. I'm good with that.

Update: When I wrote this I hadn't read the Game Developer article where John Graham of Wolfire Games pretty much breaks down how and why open development works. If you're looking for an example they seem to be the current masters.