a slightly irritated rant

My music-creation app Quencher is currently available on Google Play. However, I’d heard that Amazon’s App Store would be a good place for a tablet app, so I went ahead and made a developer account, gave them my tax information and bank details and so on. As I was trying to create the actual application listing, I came across this little gem.

wtf-amazon-1

Yeah, it’s a required field. Now, I understand that phone support is a nicety, and I’m not opposed to talking with customers. The problem is that I’d rather not give out my personal phone number, and a second phone line really isn’t possible right now. Well, no big deal; I’m sure we can resolve this peaceably. I’ll just give their developer support line a call.

wtf-amazon-2

Ah-ha. Thanks, Amazon!

in lieu of an actual post

My current game project has been sucking up time, so the blogging schedule has become even more eccentric than usual. Nevertheless, please enjoy a procedurally-generated image of what I can only assume is a cartoon character getting shot in the head.

boom

I produced the image by iterating the following code over (x, z).

function source(x, z) {
	var a = Math.sin(x) + Math.cos(z) + Math.sin(2 * x) + Math.cos(2 * z);
	a = Math.sin(x + a) + Math.cos(z + a) + Math.sin(2 * x + a) + Math.cos(2 * z + a);
	a = Math.sin(x + a) + Math.cos(z + a) + Math.sin(2 * x + a) + Math.cos(2 * z + a);
	a = Math.sin(x + a) + Math.cos(z + a) + Math.sin(2 * x + a) + Math.cos(2 * z + a);
	a = Math.sin(x + a) + Math.cos(z + a) + Math.sin(2 * x + a) + Math.cos(2 * z + a);
	a = Math.sin(x + a) + Math.cos(z + a) + Math.sin(2 * x + a) + Math.cos(2 * z + a);
	a = Math.sin(x + a) + Math.cos(z + a) + Math.sin(2 * x + a) + Math.cos(2 * z + a);
	return a;
}

Obviously, I’ve been playing around with phase synthesis. I might even have a post about that at some point.

official announcement

I can definitively state that the next game is taking place underground. Not in a cave, though. Caves are so 4 months ago. Anyway, I’m busy drawing up a map, working through some gameplay mechanics. I’m still sticking to my no-code-until-specification-complete rule, and by “sticking to” I mean “getting around via a hacking project”.

Also, some excellent Javascript game development tips.

a bit of this and that

I spent so much time playtesting Gas Food Lodging that I’ve developed a case of trigger finger from holding down the W key. Never let it be said that I don’t suffer for my art. It’s also instructive to note that if you make a game with basically one button, you’re going to be pressing that button a lot. I think the next one will use a few more controls, just so I don’t have to spend another two weeks soaking my hand afterwards.

The Nexus 7 looks amazing. It’s the first tablet I’ve seen that has me checking my budget. The lack of WebGL on Chrome makes it unlikely I’ll go much further, though that may come in time. On the positive side, I’m seeing more people here and there asking about WebGL support on mobile, so hopefully there’s momentum building.

Regarding the issues I was pondering in the last post, I’m still dithering about open world vs. linear narrative. As it happens, I have a second project I want to work on, so I’m dithering about that now. Sorry, it’s all a bit vague. The important thing is that I’m not jumping right into code. Lesson learned.

Giles Thomas of LearningWebGL gives Gas Food Lodging a nice mention in his latest dispatch. Awesome!

locked doors and broken dishes

The locked door problem is driving me crazy.

It’s been said specifically about Half-Life, but applies to many other games, that a player winds up having to travel through miles of monster-infested corridors just to get to the other side of a locked door. Concerned made good use of this trope: you’ve got a crowbar, a pistol, a machine gun, a rocket launcher, and you can’t get through a locked door? Hell, you’ve got a foot. Door frames aren’t made from adamantium.

Of course, the door can’t be blasted into bits because going down the monster-infested corridors is the point of the game. The locked door enforces the narrative flow.

Another way of enforcing the narrative is to let the player go anywhere they want, but lock them into a sequence of interactions. Bob won’t talk to you until you’ve talked to Amy, and Amy won’t talk to you until you’ve found the broken dish, and the broken dish isn’t even visible until you’ve talked to Steve. Seriously. Like talking to Steve made it just magically appear. Steve is not a fucking wizard, okay? And what’s Amy’s deal, anyway? Why’s she acting like a stuck-up dork? I didn’t break the goddamn dish.

Same problem as the locked door, but in some ways, more frustrating. In the real world, people won’t refuse to talk to you just because you’re missing an item of crockery, and things certainly don’t just appear out of thin air because it’s the “right time”.

There is a third option: the out-of-order narrative. Let the player go anywhere and do anything, and let a narrative assemble itself from these interactions. No plan, no flow. It’s the mode of play that most resembles real life, but oddly enough, it’s used the least. Wander around a city sometime looking at random things, and talking to random people, and see how much of a story you can put together. Human beings don’t find this sort of thing very satisfying. We need to see the arrows: this happened because of that.

The reason I’m obsessing about this right now? I’m writing the narrative for a new game, with as much detail and thoroughness as possible up front, and I’m getting angry over how much work I’m going to have to do to keep the bits of narrative from bumping into each other. Like, okay, there’s a corridor over here that holds plot point 1A, and the room over here holds plot point 1B. There is no earthly reason why you can’t go to 1B if you haven’t gone to 1A yet. And yet, to maintain a linear narrative, I have to put a locked door in front of 1B (that magically unlocks once you’ve dealt with 1A) or take 1B right out of the game (and have it appear, mirable dictu, just when you need it).

Or I let players visit 1B before 1A, and the game makes no sense half the time.

Most successful game designers just pick one and get on with it. I’m not there yet so I have to rant a bit. It strikes me that the problem arises from wanting a game to work like a story and like real life. This is something that writers deal with all the time. You can make a story realistic or you can make it interesting. Even gritty cop shows have to use dramatic conventions to keep viewers from tuning out. Every reality show involves some degree of editing to cut out the dull bits, or even to synthesize conflict out of random bits of tape.

I haven’t found the right compromise. Still looking.

Also: Darien Acosta of webgl.com has written some very kind things about Gas Food Lodging. Bookmark that site.

some things never change

Today:

You’re writing a game with a story? Bleh. Why not write a novel instead?

A thousand years ago:

You’re writing a story in prose? Bleh. Why not write an epic poem instead?

Ten thousand years ago:

You’re writing a story? Bleh. Why not paint on the cave wall instead?

A hundred thousand years ago:

Bleh bleh bleh bleh? Bleh. Bleh bleh bleh bleh bleh bleh instead?

no wait, let me tell you a story

There’s an interesting discussion going on here regarding the author’s belief that scoring isn’t being done well in gaming right now. I didn’t get where he was coming from until I read his linked post in which he argues that “story” and “game” hurt each other and shouldn’t be combined. If you take stories out of gaming, the argument goes, you take away the “end goal” model that he believes has plagued game design for far too long, and you can focus on the “mastery” of the game mechanic.

I don’t have a useful opinion on it beyond “I disagree”, as the author implies that story games are objectively worse than non-story games. His argument rests heavily on telling people who enjoy story games that they don’t really enjoy story games. I’m sorry, what? When I step away from a game, all I care about was “did I have a good time?” If I did, then the game succeeded. End of.

presented In glorious smell-o-vision

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.

midweek madness

The new project-thing is starting to move again, as I suspected it would. The only thing that worries me is that I seem to have more source files than actual functionality. It isn’t clear how many source files I’m supposed to have, but maybe this is too many. Or it isn’t. No idea.

I’m sure I’ll read about it on Hacker News, which I read every day just for this kind of thing. Someone posts an article endorsing some piece of programming/life advice. It’s earnest, harmless and silly. Someone else posts a rebuttal arguing the opposite advice. It’s earnest, harmless, and silly. Someone else has a convoluted mirror-universe take on the original advice. It’s–we’ve been here before. Given my example above, we’d have:

Too Many Source Files Makes You a Bad Programmer

Not Enough Source Files? You’re a Dick

Source Files: Can You Have Too Many?

I’ve Got Your Source Files Right Here

Steve Jobs Might Have Mentioned How Many Source Files You’re Meant to Have

Evil Government Attempts to Regulate Source Files

There’s plenty of useful tech articles, so I don’t mind the fluff, which is actually endearing in its own way. It’s human, and often serves as a pleasant chaser to the straight-up tech shots.

Speaking of useful tech, there’s not much in this post, is there? Never mind. Back to work.


easy does source, and prototypes too

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.