I have hinted about this on the Diecast, on the blog, on Spoiler Warning, to friends, and to anyone else that’s exchanged more than two words with me in the last couple of weeks. I have hinted at this so often that I really should stop calling it “hinting”. To wit: Yes, I’m programming again.
The why is often as interesting as the what, so before I talk about what I’m working on let’s talk about what I’m not working on. Let’s jump back to three weeks ago…
I’ve got this idea in my head for making a city of destructible buildings. Maybe it’s because we watched Pacific Rim recently and I’ve got building-pulverizing action in mind. I’m not sure WHAT – in gameplay terms – would destroy the buildings. Superheroes? Godzilla monsters? Missiles? I dunno. We’ll figure that out once we have a working demo of blasting away at a building until it falls over.
The idea works like this:
I’d have a procedurally generated city of buildings. The buildings would be made from voxel cubes, Minecraft-style. Note that the world isn’t made of Minecraft cubes. One of the drawbacks of Minecraft is the huge memory footprint required for huge volume of cubes. But here each building would be its own local cube space and the area between, below, and above each building wouldn’t need to be tracked. This would give us a nice set of mutable data that doesn’t need to eat tons of memory or take tons of time to generate. Each little cube space would have its own local axis, which would mean the buildings don’t need to be aligned to the world axis. In plain terms, you could have buildings along curving roads and turned at an angle without turning their walls into jagged blocky diagonals.
Each building would have these conceptual support pillars going up through them. Every block must be within a certain distance of a support pillar to be considered… erm… supported. If we hit the building with an explosion, it will remove a volume of cubes. If a support pillar is broken, then we remove the pillar above the point of the break. After the explosion and particle effects go off, we re-evaluate the building again and look for cubes that lack support. Any cubes that are without support will be removed from the building and dropped as physics objects.
This is not the problem.
The problem is this:
No, not the yellow background. Although I do wish I could fathom why I set the background to yellow. Was that an accident? I can’t remember. Anyway, this looks too photo-realistic. I’m not saying it looks real, I’m saying it looks like it’s trying to look real, which is even worse.
Remember Pixel City? That was this:
One of the most common comments from people was that I should make a daytime version of this city and turn it into a GTA clone. I know these people are trying to encourage me, but that’s about the most annoyingly demoralizing thing to hear. It’s like if I drew these eyes:
Nice picture, Shamus.
Thanks, it was hard for me to-
But you should make a version where we can see the monster.
Yeah, just brighten it up a bit so we can see the face.
Pixel City was a cute trick, which is what I set out to accomplish. But it’s no use to us here. This problem is on a much larger and more complex scale. Somehow, I need to depict this building in a way that won’t scream “REALISM!”. I want cartoony, stylized, or some other cue for your brain that this is far removed from reality and shouldn’t be judged as such.
So what do I do? Blocky pixel textures? Cell shading? Flat color? Ultra bright colors?
The problem isn’t that this can’t be solved. The problem is that there are a dozen ways we could attempt to do it, and I have no idea which one might yield interesting results. This is an art problem.
I suppose I could just proceed with the job I intended and ignore the visuals, but:
- If we build a huge city generator and THEN pick an art style, we could end up having to go back and re-write a lot of the building-maker code. This isn’t an art pipeline where we can ask an artist to make different things. We have to know what we want ahead of time.
- It’s a real drain on enthusiasm to work on something that looks horrible. It’s like, “THIS? THIS IS WHAT I SPENT FOUR DAYS ON? WHAT AM I DOING WITH MY LIFE?” It’s one thing if you’re coding for a paycheck, but if you’re doing it for fun then it needs to be fun.
As I ponder this, I realize that I’m always running into problems like this. Like, that was a big part of my job and my hobby programming for a decade and a half. There’s nothing wrong with that, but I’m suddenly feeling very restless. Do you know that in all my years of programming I’ve never written a single implementation of A*? I’ve never written sound code. I’ve barely messed with physics and I’ve spent very little time with gameplay.
So that’s what I’m going to do. I’m going to make a project specifically designed to let me blow past all the graphical hassles and work on the other stuff.
Brace yourself. We’re going to move to 2D.
EDIT: And to be clear, I’m not doing the destroying-buildings idea. I’m doing something else entirely. I say this because so many people are talking about Rampage and I don’t want you getting your hopes up.
The Strange Evolution of OpenGL
Sometimes software is engineered. Sometimes it grows organically. And sometimes it's thrown together seemingly at random over two decades.
Games and the Fear of Death
Why killing you might be the least scary thing a game can do.
Starcraft: Bot Fight
Let's do some scripting to make the Starcraft AI fight itself, and see how smart it is. Or isn't.
Do It Again, Stupid
One of the highest-rated games of all time has some of the least interesting gameplay.
The Plot-Driven Door
You know how videogames sometimes do that thing where it's preposterously hard to go through a simple door? This one is really bad.