It’s been a while since I posted something for you to play with.

Well, here you go.

It will take a minute to load (lots of stuff to calculate). Once it does, just play around with the sliders to customize the guy’s face. You can click and drag on his face to turn him around. Cool, huh?

Unfortunately, I can’t say that I whipped this up after Thanksgiving dinner. Actually I’ve been working on it for a week or so, trying out different methods of achieving what I wanted — and some methods of getting nowhere close. Actually, this version is the most complex one I did. The fact that it works is reason enough to post it.

How it works
Now the thrilling explanation. One of the features that Unity lacks at the moment is the ability to handle morph targets (aka blend shapes) imported from 3D tools like Maya or Cheetah. So, the only way to implement them is to code a system by hand. After scouring the Unity forums, I found a script that would handle simple mesh morphs but didn’t do anything as complex as multiple blended attributes.

Using the basics of that script, I manged to put together a system that works pretty well. Here’s the basic flow of things:

• To set everything up, I assign the base mesh (3D shape) in Unity, then create a list of attributes that I want to adjust. Each attribute has a reference mesh created by editing the original mesh to get the most extreme version of each facial attribute.
• When the scene loads, it first stores several pieces of information (this is why it takes a while to load):
  • For each attribute (24 of them in this scene), it builds a list of vertices in the mesh that are affected by that attribute.
  • At the same time it builds a list of offset vectors for each vertex affected by each attribute. This information stores the maximum possible offset for each vertex per attribute. Lots of data building up here…
  • Then we build a list of which attributes affect each vertex. This is the converse of the first list above, and it’s necessary to keep the code running smoothly.
• After all that data has been stored, the default mesh loads along with a bunch of sliders to control the various attributes.
• Each time a slider is adjusted, we calculate the proper amount to adjust each vertex affected by that attribute. This is done by using a weighted average of all the attributes affecting each vertex in question. By using a weighted average, we can combine attributes like the width and height of the eyes without getting conflicts (this part took me forever to figure out).
• Once we have the right offset vectors, we adjust the affected vertices by those values and redraw the mesh. Voila!

Optimization
Because there’s so much manipulation of individual vertices in this code, it was really hard to optimize. I spent almost the entire day trying to get it to run at an acceptable speed, and I still don’t think it’s good enough. The main problem is that when a vertex (or group of vertices) is affected by multiple attributes at once, the weighted average becomes harder to figure out and requires more processing juice. I attempted to store offset values rather than recalculating the average every time a vertex is affected, but I couldn’t figure it out before dinner. This version runs well enough, so it will have to do.

Oh, and happy (late) Thanksgiving!

EDIT: I posted a new version of the file after getting some serious optimization help from Jamie. It still takes a while to start up (but not as long), and it runs considerably faster once it loads. My code now also morphs the normals as well as the vertex positions, which I had overlooked before.

I’ve still been working away on several things since my last post, but most of the sweat has gone into correcting a few issues with the looping terrain I linked a couple weeks ago. I’m happy to report that I’ve finally fixed the two things that were driving me crazy:

• Published versions of the file were strangely not rendering the main instance of the terrain from certain angles. Something about it was not working nicely with the camera. I never figured out why the problem was happening, but I did manage to work around it.
• It was painfully obvious where the seams were between tiles. The cause for this was pretty obvious as well: While the vertices lined up perfectly on the edges of the terrain tile, the normals did not, which made light react differently to two vertices located in the same place along the edges. Unfortunately it took way too long to fix the problem. In the end, very little code was involved (which is not to say that I didn’t write a lot of unnecessary code along the way), but I used quite a bit of scratch paper trying to figure out how to access normals on the mesh’s borders.

Anyway, check out the new, improved version.

But wait, there’s more! I also developed a system to generate floor tiles around you as you walk. This means you could walk forever in any direction, and there will always be something to walk on. By itself this isn’t terribly interesting, as you can see. Still, the possibilities are pretty cool. If I could generate random terrains a little more quickly, I could generate a truly endless, randomly generated terrain.

Or, even better, I could create any number of seamless terrain meshes and load them in as necessary around the player a la World of Warcraft. I would just need to store a master grid of terrain tiles and keep track of the player’s location. I’m still a few steps away from there, but it’s starting to look doable. Pretty cool, huh?

Absentee bloggers are no fun. They entice you with a stream of regular posts and then disappear for weeks at a time, offering not a peep. When they do return it’s just to supply excuses about a busy schedule or an obsession with the latest big game or to post frivolous items like creatures of the week.

Well, I’ll not become an absentee (denial is an ugly thing). I have no excuses. But, for those few loyal readers who still stop by from time to time, here’s a little update on my activities.

In short, I’ve been scattered, lacking focus. When I started writing this blog, I was working steadily on a single, massive, impractical project. Then I decided to turn my attention to SPUDZOOKA, and still I was focused. After releasing SPUDZOOKA, though, I haven’t been able to settle on anything. I still work on things, a little here, a little there. But three things have primarily held my attention the last few months:

• A new game. No specifics yet, but I’ve been working on a concept for a new game quite a bit different than SPUDZOOKA, one that will focus more on story and character and, I hope, have a wider appeal (not that potato cannons aren’t universally entertaining). The difficulty so far is that story and character are tricky to develop and, while I think the concept and setting are good, I haven’t been able to find the game in it. People might explore for a while, but what would compel them through the story?
• A web site concept. I had an idea for a web site recently that I’ve been exploring, which means reading a lot about databases, php, and xml, and then tinkering with them to see if I’ve got the programming chops to make this idea happen.
• Procedural terrain generation. Huh? I don’t know where this stuff comes from, but I got it in my head that I would try to see if I could generate an application in Unity that would dynamically generate and display an endless terrain. The usefulness of something like that is maybe a little suspect, but it could spin off into some interesting applications. Unity’s terrain system is a little limited right now, for example, so something like this could help people generate more realistic terrains and link them together to create truly massive worlds. Even just linking sections of terrain terrain together is something that could be useful right off the bat, particularly in, I don’t know, an RPG. I hit a few tricky parts, but I did manage to create a randomly generated terrain that loops forever. Check it out (it may take a few seconds to compute).

So, I’ve been working, just not on a single project. Once I settle, I’m sure regular posting will resume. For now, don’t forget to check back for the next creature of the week.

Edit: I fixed the bug that people were seeing in the web player and put a new file at the same location.

Wanted to give a quick shout out to a kindred spirit, Marraboy over at Unity 3D — Zero to Hero. He recently started a blog to chronicle his progress building a game with Unity and Cheetah 3D. He’s only written a handful posts so far, but I just want to say, “You can do it, Marraboy!”

It’s still by no means proven whether I can do it, but I did get some much-needed words of encouragement from a good friend over the weekend. This no-budget-game-development thing can get pretty daunting, particularly on days when I realize how much more there is to learn.

Case in point: Unity’s ShaderLab. It’s a programming interface for creating shaders in Unity (a shader describes how an object will look in the game — what textures it will use, how it will react to light, etc.). This mind-bogglingly powerful feature of Unity is, I’m beginning to discover, the difference between amateur work and real professional visual quality. Sure, modeling and texture art are essential, but custom shaders add the flair.

Of course, working with shaders requires some knowledge of OpenGL’s shader language, of which I have none, so I feel quite outmatched at the moment. As usual, though, I’m probably getting ahead of myself. SPUDZOOKA isn’t done yet, and I can’t get too caught up in the next thing.

No, I shouldn’t be worrying too much about shaders yet. They just remind me that I need to take things one step at a time. Visual polish is not my strong suit, since I never had any formal training. But that’s ok. I like to think that what I lack in skill, I make up in blind determination.

One of the challenges for small game development teams must be division of labor. Your standard team might include a programmer, an artist, an animator, and a game designer. If you’re lucky, you’ll even have a writer (though most big-budget titles don’t even seem to have those). But, as with any small team, there is likely to be some crossover in roles, particularly as deadlines approach.

Seems easy enough, but what if your team only includes one or two people? The first thing you would probably say is, “Don’t waste your time on an epic RPG.” We already know people like me would ignore that, so the question becomes, “Where do you start?”

You could start anywhere, really. Obviously you need a concept and a premise. Then you could work on character designs, level designs, concept art. The right thing to do would be to write up a formal design document to force yourself to think through all your major design decisions.

My answer: gameplay programming. This is odd to me, since I am not a programmer by training, or even by interest, really. So why would I treat it as the starting point for my game? Structure.

The way I see it, concentrating first on programming lets me create a functional skeleton for the game. Once that is in place, I can begin replacing placeholder elements, like my blue box man, with more–interesting–objects. I think of it like the outline of a paper. Once the structure is in place, the real creative work can begin.

Is this the right way round? Who knows, but it makes sense to me, and in a team of two with no deadlines, that’s all that matters.