The game I’m working on now, which I’ll refer to as Gas until I have a real title, involves locating clouds of smelly stuff and sucking them up. I mocked up a cloud of tiny black triangles to serve as a test model, and discovered they were invisible against the busy background of the game world.

You can’t see them until you’re right on top of them, which defeats the purpose of drawing them at all. How do we make it easier for the player to detect them?

My first idea I ripped from Batman: Arkham City. In some quests, Batman has the unenviable task of homing in on a signal without any directional information. The player has to look at the distance to the signal and determine if s/he is moving closer or farther away–kind of a high-tech version of Marco Polo.

Well, that’s how smell works, too. You can’t home in directly on a smell–it’s based on molecular concentration, which isn’t directional. I whipped up a readout of how close the player was to the nearest cloud of smelly stuff and slapped it on the HUD.

It worked, but it was really a pain in the ass. I had to bob this way, that way, down and up, then left a bit. It works in Arkham City because the map is effectively 2D: much, much wider than it is tall. Gas is 3D. It’s as tall as it is wide, and your target may be right over your head or just under your feet.

Or: several hundred meters under your feet. It’s a big place.

Also, you don’t have any feet.

Anyway. The Marco Polo method didn’t work for me. I needed more information. I decided to try out an idea I’d had a while back, a solution looking for a problem. I’d wanted to create a low-information version of the scene itself, like when a game uses simulated night vision. You block out aesthetics, and only show stuff that a player absolutely needs to see, or the stuff they normally can’t see.

I called it smell-o-vision. It rendered the clouds of smelly stuff as black blobs on a big square canvas off to one side of the screen. I stepped back and admired my work. It didn’t take me long to see that it looked hideous, and was completely stupid. You’ve got a GPU pipeline, why are you writing a software renderer?

I wiped it out, and made a small change to the shader instead. Now, the triangles that make up the clouds render as white, not black. You can see them for miles.

If you want players to find stuff, you can give them readouts and gauges and clog up the screen with fancy HUD gadgets. Or, you can just make it easier to see.

Is the question really that (forgive me) black and white? I’m not sure. I think it has to depend on what’s fun about the game. Gas is a flight-based game. You’re flying about in the sky, and that’s pretty fun. If you have to read a little meter and stop and turn, read it again and stop and go down, read it again, and so on, it’s not so much fun anymore.

In Batman, you do glide above the ruins of Arkham City. It should be fun, but it’s Batman, so it’s really severe and gritty and technological and loaded with guilt. As far as I can see, the only fun Batman really has is punching goons. Punching goons is the best thing in the game. Everything else is pretty much window-dressing and getting from one place to punch goons to another place to punch goons. The meter doesn’t get between you and the goon-punching, so it’s really not a problem.

Plus, Bruce Wayne’s parents were gunned down in a back alley. Dealing with a dinky little meter isn’t going to make any impression on him at all.

Little progress on my latest project. I’m running not into code issues–I wish I were as those are much easier to solve–but questions like should it really work this way and do you need combat in a game to create risk and why does internal monologue register as italics, anyway, I mean, who thought that up and so on. It’s frustrating, but it will pass.

Anyway, I put the source code to Easy Does It into github, right here. I hope it’s of use to somebody.

One big code style change I forced on myself over the last few months was using the prototypal model in deriving JS objects. For Foam, Fissure, and Pavo, I used classic inheritance and object creation: function objects and the new operator. It looked familiar enough from my days as a C++ developer, and when you’re trying to get a foot into the door, familiar is good.

However, in JS, classic inheritance feels like what it kind of is: an attempt to shoehorn a familiar pattern into a language that was built with something else in mind. Prototypal inheritance is that something else, and I have to say, I’ve come to enjoy it. I rebuilt my WebGL wrapper, Foam, into a prototypal library called Soar and I’m happy with the results. Easy Does It is all prototypal, as is the game I’m working on now. I haven’t seen a new operator in months.

For objects that I’m going to create more than one instance of–drawable objects in particular–I’ve found this pattern incredibly useful. No idea if it has a formal name, but it’s like having a static function on a C++ class.

GAME.enemy = {

	init: function() {

		// create shader object shared by all instances
		this.shader = shader.create(...);

	},

	create: function() {

		// create an instance and populate it,
		var o = Object.create(GAME.enemy);
		o.position = this.getRandomPosition();
		o.damage = this.getRandomDamage();
		return o;

	}
};

...

	// initialization code
	// creates all shared resources
	GAME.enemy.init();

...

	// create lots of objects
	for (var i = 0; i < lots; i++) {
		list[i] = GAME.enemy.create();
	}

...

	// activate the shader for this type of object
	list[i].shader.activate();
	// draw all instances of this object
	for (var i = 0; i < lots; i++) {
		list[i].draw();
	}

Changes to the base object are, of course, propogated to all instances. I find this oddly pleasing, more so than I find the idea of a fixed base “class” as in C++ and Java. I have to admit it’s taken some time to warm to it, but here I am. Good place. Good place.