In a couple of Gamasutra blog posts, Adam Saltsman (of ‘Canabalt’ fame) ranted against what he feels are ‘evil’ game design systems. I characterized his arguments as ‘hysterical’, which is perhaps a bit unfair since rants are meant to be hot. Anyway, at some point I felt compelled to write a long reply, and I’m reposting it here. I’ve edited it only slightly, so it’s possible that some of it is confusing outside of the context of the original discussion.
My guidelines are not for gamers; they’re for humans. My guidelines are not about styles of game or difficulty of game; they’re about treating players with a modicum of respect.
Now, we agree that all players and all humans should be treated with respect. But there is no inherent lack of respect in ensuring that your game encourages players to pay if they like the game and want to enjoy more of it. If anything, you are asking players to respect YOU as a creator by paying something for the enjoyment they derive from your work. Short of a pure donation model, this encouragement must affect the product you create in some ways. That doesn’t make the creator greedy, which seems to be Adam’s characterization of the monetization process.
If you played with the Stage3D spinning cube sample I linked in the previous post, you will notice one thing: the vertex colors in the vertex buffer are given as 3 floats (red, green and blue). This is rather wasteful in most cases because color components often vary between 0.0 and 1.0, and it’s more efficient to specify vertex colors (including alpha) as a single 32-bit value. For example, in hexadecimal notation, 0xFF800040 would mean alpha of 1.0 (0xFF), blue 0.5 (0x80), green 0 (0x00) and red 0.25 (0x40).
If you look in the Stage3D docs, you will find the constant Context3DVertexBufferFormat.BYTES_4 to use in the call to Context3D.setVertexBufferAt(). But if you naively just change the vertex buffer array to turn each vertex color’s set of 3 components into a single hex value, make dataPerVertex = 4 instead of 6, and use BYTES_4 for va1, then you will find that the colors are coming out wrong. Why? Because the function VertexBuffer3D.uploadFromVector() always stores the values from the Vector in floating point format. Of course! This is the most common situation for the components of the vertex positions, normals, texture coordinates and such. But we need our BYTES_4 color value to be stored verbatim as a 32-bit uint.
Vector.<Number> and uploadFromVector() do not give you control over the byte format of value. How do you solve this?
A couple of days ago, Adobe released to the masses a new version of their Flash Player, and an updated SDK. The biggest change (for me at least) is the inclusion of hardware-accelerated 3D, known as Stage3D. Here’s a quick tour of what I did to compile and run my first Stage3D program (Windows 7 PC but should be applicable everywhere). Useful because the Adobe site is not really clear about this.