Sculpting

Sculptris has been around for a little bit, but I decided to be all late to the game and whatnot, so I just tried it a couple days ago. About a half hour after downloading it I made this.

15 minutes later it looked like this.

Then I did this in 40 minutes. The video is only about 2 minutes. I just sped up the recording to tolerable levels.

Sure, they aren't stellar sculptures. Unfinished sketches really. I had no plan when I started each of these, I was just messing around with the tools, trying to see what I could do with them. My experience was absolutely frictionless.

I love discovering new tools. There is always that crusty old man voice in my head remembering how hard all this used to be. How I had to build up models a polygon at a time, or animate without IK. The voice is still there, but it has been getting quieter and quieter. With Unity3D, Blender (now that they have a sensible UI), Silo, Gimp, etc. the tools have never been better or easier to use, and now a lot of them are affordable, or even free. Did I mention that Sculptris is free. Sometimes I feel like I could just mash my hand on the keyboad and, something cool will pop up on screen. The crusty old man voice wants to hate that, but honestly, tools like these, are just to awesome to hate.

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.

old and new

reboot

Okay, I’ve been working on the same project for ages. In multiple languages, and a couple different frameworks. My plan from the outset was to create something small so that I could learn the tools and languages I would need to create my own games. Not clickity click around in some game builder either. I wanted to have a really firm grasp of what I was building. I wanted to write the code, and work with the tools on a fairly low level. That said, despite overwhelming evidence to the contrary, I’m not a complete idiot. I realize that the constraints of time and familiarity with the tools wouldn’t allow me to create my own game engine, or anything like that. I started by Using first XNA, dabbling with OGRE, and then settling on Unity. All three allowed me to work quickly enough to see progress, but still required that I learn JavaScript or C# and, more importantly, some work flow, structure, and design strategies.

If, in the future, I’m ever provided with an opportunity to work with a programmer more skilled than myself, a parrot or eggplant for example, I’ll at least understand what they are talking about.

I just recently created an app for the Blackberry Playbook. It is currently going through approval. It is a very small, very simple toy for very young children. Random shapes bounce around the screen and you poke at them to make them burst and fade away. You also hear a satisfying sound. That’s it. It’s called ShapeToy. The point is, simple or not, ShapeToy is a completed app. It’s a finished thing. That you can play with. I’m pretty sure that I couldn’t have done that a year ago.

The main problem with “Color Game” is that I never really designed it as a game. I created a school, and sent myself too it. Like school, learning was the point, and anything that you created has very little value as a stand alone work. There may be something that I can dig out of that and polish up into a game. ShapeToy was designed for a specific purpose. Until I reconsider the color game concept as a game first, it will never really be successful.

So I have decided to shelve Color Game for a bit until I can really rethink it.

I have started up 3 new projects. Each one designed to be a game first. I’ll likely learn something along the way, but these projects are all focused on the finished product, not the process. I’ve started on the one that seems to be the most unabashedly “video game”. If, or rather, when I get hung up on some issue, I will bounce around to the other two projects, hopefully learning something new and clearing any mental blocks. I fully intend for at least one, if not all of these projects to be finished things. That people can play, or even buy. Probably on a phone.

I’ve already started working on the next iteration of ShapeToy, that includes letters, numbers, and different sounds. I’m just waiting on a tool update from RIM that makes some of the local file storage/access features of HTML5 useable from an app. Since I think there is still an enjoyable core to the thing, I’ll probably dive back into Color Game as well, but for now, I think I’ll focus on making some games.

what did you do at game jam?

It's been so long that I was tempted to title this post "Neglect".

I participated in the Global Game Jam at the end of January, so I figured I should take a minute to reflect.
As soon as I arrived home from Mount Royal, my son asked me "what did you do at game jam dad?".

So I have to think. What did I do “at game jam”. More importantly, what did I learn.

My team were all basically strangers. Two programmers, two artists. A couple of us had met very briefly at igda meetings, but that's about it. To me, that seemed to be the right way to do things. Meet with a group of strangers, put our heads together and build something. Anything.

We started by finding ourselves a nice, quiet, centrally located, fishbowl. That glass room became our studio / flophouse for the weekend. Next we needed to decide what to build. We had a basic concept based around herding creatures to their doom. That concept was quickly fleshed out in the most ridiculous ways we could conjure. We then moved to divvying up the work. We split along very obvious art / code sides. The programmers would write code, and the artists would create the art. I went to the event fully expecting to find myself in a team full of artists. I figured I would probably end up with visual studio afterimages permanently burned into my retinas. I was cool with that. I was much cooler with leaning back painting sprites in photoshop for 48 hours. So we put our heads, and talents, together, and we made... something.

The truth is our game was a bit of a failure. It's a bit janky, the controls don't really do what they should, the little animals kind of run everywhere, and there is no front end. It functions, but only just.
That does not mean that I think that the team was unsuccessful. In 48 hours we went from not really knowing each other, and not having a game concept, to creating a functional HTML 5 "thing" that at the very least, made everyone grin for a second.

So what did I do “at game jam”. Working on my own I get pretty used to wearing several hats. Scratch that. I wear all the hats. At the same time. It's a leaning tower of fucking hats, and most of them don't fit me. At game jam I wore one hat. I wore the artist hat... Actually I probably just wore the brim. I didn't go there thinking that this would be a relaxing time. I went to do some work. It just happened that there wasn't a ton of work for me to do there. It's been a while since I've had to brave a tense all nighter to meet a deadline. Typically in those situations I would have more work than Any single human could hope to accomplish, and about 37 seconds to complete it. The days when clients call up at 4:30pm on a Friday, requesting radical changes for an important meeting Monday morning at 9:00am, are hopefully behind me... or at the very least, I now have the options of saying no or setting my price. My expectation was that I was, in fact, doing this exact thing, to myself. Instead I felt incredibly relaxed. There was quite a lot of work to do, but I could have easily done double. At one point during the 48 hours I thought about offering up art services to the other teams diligently working on their stuff, but :

1. most of the teams seemed to be well into their projects, and adding another person might be detrimental.

2. a few of the teams were working toward possible commercial releases, and really couldn’t recruit new team members for legal reasons.

3. I was enjoying just relaxing and drawing environment tiles.

At another point I made a 3D model of one of our characters and did a turntable animation of it. I was reasonably sure that this would never be used in the game, but it was fun to do, so I did it.

As it turned out, about 1% of all the work I did actually ended up in the game. At the time, I found that endlessly comical. I still find it funny.

So I really didn’t do that much work, but what did I learn “at game jam”.

Bring an air mattress. The floor is hard.
Bring a kettle. Sometimes you want tea at 3:00am.

I’ve created countless seamless textures for 3D work, but I had never created a tile set for a 2D game. I am pretty sharp with the photoshop and I can hide repeats like a mamajamma. There had just never been any call for me to create a tile set. While I didn’t learn any new techniques, I did do something new, and that is always fun.

I learned that tools are important. Not just important. Perhaps the most important. Or even the mostest important. On the art side we had tools out of every available orifice. Couple different versions of photoshop. Some vector tools. A few different animation softwares. 3D modelling and animation tools. Graphics tablets and touchscreen transforming laptops. Paper. Pencils. Burnt sticks and cave walls. At one point we could have built stuff from spiral pasta. Had anyone ventured into our centrally located fishbowl looking for art, we probably could have stuffed their pockets with doodles and sent them on their way. Since we were creating a HTML 5 game, I was unaware of any coding tools, engines, frameworks, etc. that could have helped our programmers. I’ve since found several great HTML 5 tools that we could have used to speed things up and lighten the load on our team, but not having those tools available when we needed them probably hurt us. I still think our programmers pulled off some amazing things given the time allowed.

I think that, next year I will try to offer up my time to other teams. Maybe I will create a work board for people who want to offer up their time to multiple projects. Teams can go up to the board and put down a request for art or music or assistance from an expert in some field or other, and anyone with time to spare can check the board to see where they can lend a hand.

I think mostly I remembered that it’s fun to work with other people... not really something I learned, but it’s certainly something I needed a refresher on.