Tuesday, October 23, 2012

Tell a Story

Wouldn't you know it, only a few weeks in and I'm already lagging on the blog. Truth is I'm working on a piece about why you should embrace formulaic game mechanics, and it has to be perfect before I let anyone see it or the world will end, etc.

In the meantime, I've got a random programming tip: Tell a story with your code.

When you're working on shared code I actually don't recommend this. But if you're working alone, you can waste a lot of time grappling with those chunks of code you don't touch for months at a time - you know, the buried artifacts from your own past that you dust off and hold it up to the light and wonder whether you wrote them while blackout drunk.

So when code starts getting gnarly, I try to figure out a way to make it about a character trying to accomplish a specific goal, and either succeeding or failing. It's a great memory aid.

One class I just revisited this morning is supposed to update chunks of voxels using some weird proximity rules. It's complicated and huge. When I initially created it I called it a NodeProximityUpdater, and when I cracked it open a few weeks later I felt like I'd had a stroke. So I created this base class:

public class InfectorScript : NodeScript
     public virtual void TryToReawaken ( )
     public virtual void GoDormant ( )
     public virtual void SpreadTo (Node targetNode)
     public virtual bool FindPotentialHost (out Node targetNode)
     public virtual void AttemptToAlterHost ( )
     public virtual bool IsNodeSucceptible (Node targetNode)
     public virtual bool HasNodeSuccumbed (Node targetNode)
     public virtual bool IsNodeInfected (Node targetNode)
     public virtual void Die ( )

Flash forward another month - this time when I opened it up, I felt up to speed right away. Infector, okay - an infector infects things like a virus, altering hosts until they succumb to changes, then spreading to another potential host. When it can't find a host it goes dormant, then tries to reawaken once in a while. If it's without a host for too long, it dies. Got it.

All the gnarly complexity is still buried in there, but when you're reading the highlights of a story, you only need broad strokes to summon a complete memory, even if the particulars are complicated.

Wednesday, October 3, 2012


EDIT: The game has changed quite a bit since this ambitious start, so as you read this keep in mind that I'm describing a product that doesn't exist any more. When deadlines began to slip I ditched most of the tech I was working on and started over with an existing terrain engine.

Alright. Today I'm  going to spill the beans about the game I'm working on.

First, strap on your time travel helmets because it's time for a lengthy flashback.

(Spoiler: the game's called FRONTIERS, and if you don't care about origin stories, skip the orange.)

Still with me? Sweet.

Way back in the early 2000s when I was still in college, I wanted to create a particle physics based game engine. I dubbed it the PPBGE. (Anyone who knows me will tell you, names are not my strong point.)

I'll resist the temptation to get into the gory details, because there were only two bits that mattered. First, all geometry would be virtualized; world objects would be stored & manipulated as point clouds and rendered at run-time as isosurfaces. Second, every point in the cloud would be treated as a physics particle. I'll let your imagination run wild at that thought.

Cool story? Definitely. But plausible? I honestly didn't know. So before I wrote a single line of code I arranged to meet a half dozen physics professors and computer science professors at my university. During these meetings I quickly realized that I was out of my depth technically. I met some computers will never be fast enough resistance, which I knew was hooey, but all the same I was blown away by how complex even a simple physics engine could be. While most of the profs agreed that there was no reason in principle why a system like this couldn't work (a hollow concession but one I still took pride in) they also stressed that if it happened it would be the work of a team of dedicated experts, not the work of a lone art student moonlighting as a programmer. And I agreed. PPGBE was way above my pay grade.

But for all the resistance I met on the technical front, what sticks out to me is the funny looks I got when I tried to explain what kind of game I wanted to make with it.

"I want to create a virtual world where you're free to do whatever you want in a physically realistic environment."

"Okay, so what's the goal?"

"Just the same as it is in real life, you wander around and change things and try not to get killed while you're doing it. Like if you want to build a bridge across a ravine, you can gather materials and build one. But have to do it without falling into the ravine."

"Right but what's the winning condition?"

"There isn't one, it just keeps going, until you die or get bored."

"Why would anyone want to PLAY that?"

I couldn't explain why. I just did.

I'm not accusing them of being obtuse, because it sounds like some pretentious film student's original screenplay: "It's a movie about real life... nothing much happens, and then it's over." Wow nothing happens huh, sounds like a blast. So instead of pushing the issue I'd usually say "It could be a first person shooter," and BOOM, instantaneous understanding.

In any case, I shelved the project before it began, knowing it was beyond my capabilities.

Flash forward several years. Minecraft hits the virtual shelves. Suddenly it wasn't a chore to explain why I would want to play that kind of game. All I had to say was, "A Minecraft clone with physics." BOOM. Instantaneous understanding. I was free to stroll down the trail Notch blazed for the rest of us. (Side note: next post I'll be talking about the pros and cons of making a clone.)

Meanwhile, I'd learned the ropes on Unity while working as lead artist on another (yet-to-be-announced) indie game, and I realized that while not ideal, the engine had pretty much everything I needed to create my PPBGE, assuming a few compromises. Not only that, but my own skills had progressed to the point where I felt I could fill in the missing pieces on my own. So I started developing alongside my other projects about six months ago.

This game eventually developed into FRONTIERS*... and that brings us up to present day.

The focus of the game has tightened since those early days, and it has become a cross between Minecraft and The Oregeon Trail.

Your goal is simple: KEEP MOVING FORWARD.

Your destination: anywhere on the massive spherical world you inhabit, from the bottom of the ocean to the top of an active volcano. How you get to that destination is completely up to you. Climb over that mountain range, or dig under it. Swim through that river, or build a bridge and walk across it. Creep through that deadly jungle, or burn it to the ground.

Just don't die of dysentery. Or hunger. Or thirst. Or rockslides. Or wolves. Or exposure to the vacuum of space.

That's right - if you're really looking for a challenge, how about choosing a destination on the surface of the moon? Hell, why not the surface of another planet altogether? Think you have what it takes to build  a space elevator or a rocket ship? Go for it.

Hey, the game is called FRONTIERS - there's no way I'd leave out the final frontier.

That gives you an idea of the scope of the game. Now before you get too excited, understand that all this flexibility comes at a price. This is an indie title after all, and compromises are necessary, especially when it comes to graphics. But you can judge for yourself as I start posting screens and demos over the coming months.

More to come...

*My wife came up with this name, by the way. You don't even want to know what I was going to call it.