At the beginning of a project there’s always a big burst of progress. Every ten minutes you’ve got another feature or another improvement, and it’s easy to delude yourself into thinking you’re John Carmack. But then you enter the middle phase of the project and suddenly it’s time to tidy things up, get your interfaces in order, and work on some of the boring, non-sexy stuff.
So that’s where I am right now. Sooner or later I need to do the Great Big Post About Gameplay Mechanics, but I keep putting that one off. Up until now this game has been all things to all people. Everyone can look at these screenshots and fantasize about all the ways it could be exactly what they wish. Everyone can look at it an scream, “Shut up and take my money!” because so far they haven’t seen anything that indicates it’s not something they would like. When I finally get around to nailing things down I’ll end up breaking some hearts, and I’m not quite ready for that trial yet.
So let’s dig through funny screenshots.
This one was from last week when I was trying to get a sense of just how many objects were in play. How many robots were usually active? How many bullets? How many particles? So I set up a few tests.
What I learned was that I was greatly over-estimating the number of bullets in play. Even in this extreme scenario, we’re looking at less than 200 bullets. At the same time, I’ve been under-estimating the number of particles I was using. This scene has over 4,000 active particles.
It’s not really time to optimize just yet, but having a clear picture of which systems are doing the most work can help guide my decisions about how I ought to design things.
This one is technically a re-enactment. Way back in the first few days of the project (long before I designed the main character or settled on lumpy cave walls) I was working on making homing missiles. I wanted missiles that could be avoided with quick lateral cuts, or shot down with gunfire. I wanted just the right mix of speed and turning radius. If they moved too fast, then the player wouldn’t have time to react. If they moved too slow, they wouldn’t feel dangerous. If they turned too fast, the player wouldn’t be able to dodge them. If they turned too slow they wouldn’t be enough of a threat.
Rather than having robots shoot missiles at me, I just made my own missiles home in on me. When I shot one, it immediately began turning to come back around. Because they are my own missiles, they can’t actually hit the avatar. They sail right through me. So these poor missiles live a doomed existence, forever pursuing the player but never catching them. They form this great spinning, undulating cloud that changes shape as I move.
As with testing missiles, it’s way easier to test things if they’re attached to my avatar as opposed to being part of some capricious AI. Otherwise you end up doing this:
Hm. Looks like the legs move a little funny when moving left. Or was that my imagination? Get back here you little bastard, I need to see you walk left. Arg. Now it’s holding still to attack. Or is it? Is this a bug in the AI, or is it supposed to be doing that? Should I stop working on these legs and crawl down into the guts of the AI to see what’s what?
It’s just better to have direct control of the thing I’m testing. Once I’m sure the legs work just right, THEN I can attach them to an enemy robot and let it run wild.
Halfway through designing the legs I realized they felt really, really cool. (For the record, the legs aren’t actually involved in locomotion. I’m just flying around and the legs automatically span the distance from where I am to the floor.) I wanted to jump, climb walls, and hang from the ceiling. I wanted to drop everything and start making a game built around spider-type activity.
Apparently making one videogame means passing up the chance to make a dozen others.
When giving the spider-legs to the robots, I mistakenly gave legs to ALL robots, even ones that fly.
While writing this post I randomly found this screenshot in my archives. This must be from really early in the project. Don’t know why I took a picture of this, but it’s kind of interesting. I’d totally forgotten about the phase where the avatar had one eye and one really clunky arm.
My first maze designs were really complex and disorienting. But playtesting revealed that being lost and confused was directly at odds with the fast-paced nature of the game I’m trying to make. It’s a complete killjoy to run down a passge, hit a dead-end, and have to backtrack and try again. It’s also no fun to accidentally loop back to where you were a few minutes ago.
Maps that look a little complicated at a distance are bewildering up close, and maps that are confusing at a distance are unplayable up close. It only takes an occasional split or twist in the passage to make it feel like the space is really big and convoluted. A little complexity goes a long way.
Most of my work has been simplifying and streamlining the passage design to give the player a clear sense of progression. As the game goes on, it adds more blinds and side-tunnels for ambushes, but an attentive player should (ideally) always have a sense of which way to go to reach their goal.
Here is yet another of the many, many directions the game COULD have gone:
It is really hard to stay focused on a single design and not get dragged into all these other possibilities.
Crash Dot Com
Back in 1999, I rode the dot-com bubble. Got rich. Worked hard. Went crazy. Turned poor. It was fun.
The Witch Watch
My first REAL published book, about a guy who comes back from the dead due to a misunderstanding.
Secret of Good Secrets
Sometimes in-game secrets are fun and sometimes they're lame. Here's why.
Pixel City Dev Blog
An attempt to make a good looking cityscape with nothing but simple tricks and a few rectangles of light.
Do you like electronic music? Do you like free stuff? Are you okay with amateur music from someone who's learning? Yes? Because that's what this is.