on Sep 2, 2013
As many of you requested, I’m not going to document every feature that goes into this thing. This means we’re going to jump ahead and start talking about stuff I’m dealing with now-ish. A side effect of this is that you’re going to see unexplained features appear and be tempted to ask, “But, what is this feature and how does it work?” Understand that the answer to that question would take a post. A post which would have precluded the writing of this one.
You can’t trick me into writing twice as much by asking me to write about current stuff and then asking me to fill in the blanks in the comments. Well, you CAN, but it’s going to make for a less interesting series for everyone. So just get yourself into some sort of zen state where you’re okay with seeing unexplained mystery content.
So on Friday I talked about the line-of-sight system I came up with. A few people suggested a completely different way of doing it that would be many, many times faster. And now we come to the part of the project where we have to make the hard choices.
See, there’s one thing I didn’t mention on Friday. That’s this:
The visibility system I devised had this side-effect where it was super-easy to implement this “flashlight mode”. Actually, “implement” is sort of overstating it. It implicitly WAS flashlight mode, and I’ve just been setting the beam to be 360 degrees wide.
It’s really cool, and you kind of need to see it in motion to appreciate just how suddenly panicky and claustrophobic the game feels like this. This was an accidental discovery while working on the LOS system, and it was so interesting I began toying with the idea of making it part of the game.
(The foes depicted are these spinning sawblades that try to swarm you and chop you to bits. They look strange to me in freeze-frame like this, since in-game they’re always spinning.)
On the other hand, it’s friggin’ HARD. Hard enough that it changes the entire feel of the game. Foes are really good at approaching from all angles and in flashlight mode you can’t dodge their attacks because you can’t see them coming. If I went this route I’d be leaving behind the fast-paced dogfighting of my original concept and sliding into something with the pacing of survival horror: Edge forward, fire some shots, back off and check behind you. Move slow, flush enemies out, and try to keep your back to a wall.
It’s a totally different game.
The typical gutless design approach is, “Make it an option!” That was my first instinct. But really, these are two very different games we’re talking about here. They each demand different and mutually exclusive approaches to AI, art, weapon balance, and enemy design. Heck, even non-gameplay stuff like music needs to change. You don’t want the jaws theme creeping along in the background of the burly brawl and it doesn’t make sense to have Keep Hope Alive thumping away while the characters search the haunted house with the dodgy flashlight, whispering to each other and jumping at shadows.
When you’ve got two divergent gameplay modes like this you can:
- Neglect one mode in favor of the other. (Try our game! It comes with a tacked-on second game that’s not worth playing!)
- Build two different and mutually exclusive games. (Because time and money are no object!)
- Split the difference and make two crappy games instead of one good one. (Because we don’t have a clear vision!)
This problem should sound familiar to any developer forced to add mutiplayer deathmatch to their single-player game.
As much as I hate to kill this flashlight mode idea, it’s too far from my original concept to be added on and it’s too different to coexist.
I spent all day Friday thinking about the wall-extrusion idea that was proposed. It was eating at me, so I decided to try it out. Here is how it works:
You look at the area directly around the player and find all the line segments that form the walls.
For every wall, you take the endpoints and draw a line from the player to those points.
Now give those points a big ol’ shove along the direction of that line.
Now use the new and old points to form a polygon. Draw it.
Do this for all the walls in the area and you get shadows. No line of sight checking. No fussing with collision.
Now, the game runs plenty fast and I didn’t need to do this for performance reasons. But this wasn’t really about performance. This is just a better way to do this.
- This new system creates pixel-perfect shadows. The old system still had a little bit of wibble-wobble when looking around corners. This way is flawless and smooth.
- This new system is about 50 lines of code smaller. Somewhat counter-inuitively, programmers love it when they get to delete code. (Well, deleting recent code stings a little.) Less code means less text to wade through, less to document, less to worry about and less to examine when things go wrong. Making something with less lines of code is like making an airplane with less metal. It’s just good engineering. (Assuming, of course, you’re genuinely getting rid of lines of code and not just packing the lines together using tight spacing and “clever” formatting tricks. Don’t get me started.)
- And if you DO happen to care about performance: Old system did 1,000 to 2,000 checks, depending on local topography, and always drew 180 polygons. This new system does 25 checks (looking for walls) and draws between zero and thirty polygons. That is, my worst-case rendering situation with the new system is still way, way better than the best-case situation with the old system.
With this new system I would no longer have this cool flashlight mode. Oh sure, I could ADD it with some tricky stencil operations. But that would be adding a feature, instead of having the feature be sort of a byproduct of how you’re already doing things.
Is it worth fussing with the stencil buffer to restore flashlight mode? I guess I sort of spoiled that conclusion earlier in the post. It’s not. It’s a fun gimmick but it doesn’t work in this particular game.
Now, there are a bunch more optimizations I could do here to trim those polygons down even further. For example, some of these walls face AWAY from me and therefore aren’t needed for the purposes of blocking sight.
If I ignored the walls that faced away from the player I could come close to cutting the poly count in half. But right now that would feel like cutting coupons after you won the lottery. Look, I’m as frugal as they come, but we’re talking about an optimization that would – under maximal circumstances – save us ~16 polygons a frame. That’s not even worth thinking about right now.
Well, that worked out as well as could be hoped. Let’s try another community suggestion. Way back in part 2 I talked about having the camera chase you around and some people suggested having the camera fly ahead of you.
It’s pretty easy to look at which way the player is going and just have the camera try to stay out in front of them. The old 2D Grand Theft Auto games did this. As you accelerated, the camera would pull back and move ahead of you, letting you see more of the world. It was facilitating fast movement and rewarding high-risk travel. Let’s give that a try in this game.
OH MY GOSH WHO RUINED MY VIDEOGAME!?!?!
We have many layers of things going wrong here. While I can see right away that this is a disastrous idea, it takes me a few minutes of play to figure out why.
In Grand Theft Auto, you were traveling in a slowly accelerating vehicle with a turning radius. Even the best cars in the game took a few seconds to reach top speed and required half the screen (or more) to perform a U-turn at speed. But in this game we’re controlling a flying robot that accelerates in about two seconds (and most of the acceleration happens in the first half second) and can reverse direction almost instantly. This means that in GTA you would get these wide, sweeping turns, and in this game you get abrupt cutbacks. In GTA you reverse direction rarely. In Good Robot, you spend most of your time zig-zagging through enemy fire.
The result is that the camera has to make huge movements to stay ahead of you. When you reverse direction it suddenly needs to be on the opposite side of you. These swinging camera movements are a roadmap to getting puke on your keyboard. It’s that bad.
The other problem is that you spend a lot of time fighting while moving backwards. Having the camera fly ahead of you will turn this view:
Into this one:
So the camera is often shoving the important projectiles and robots off the screen so it can show you empty space. This is a textbook example of “fighting the camera”, where the challenge of the game comes from trying to get the camera into a useful position without dying in the process.
Well, one idea worked out and the other didn’t. Both were interesting experiments.
Shamus Young is an old-school OpenGL programmer, author, and composer. He runs this site and if anything is broken you should probably blame him.