Patrolling Tanks

The first thing to note is that you can see the current state here: http://bigdicegames.com/BZone/bzone.html

Stuff I've got done since the last update:

• build, deploy script tinkering - I had thought that my build script didn't work with WebGL stuff. Maybe I fixed some problem I was having. Maybe there never was a problem. It seems to work, so, cool.
• new tank class - makes things like position and heading be easier to deal with.
• updated the model - not that you can tell. The old model was facing down the Y axis, which made the heading 90 degrees off from what made sense to me. So, the new rule is that models face along the positive X axis, with up in the positive Z direction. Y is, of course, left, because we're using a right handed coordinate system.
• updated the model conversion script - again, not visible. The new script is Closure-friendly, using "goog.provide" and having a namespace. Also, it avoids breaking IE8, who freaks out if you put a comma at the end of your list: [1, 2, 3,]
• rudimentary tank AI - riffing off last month's guard patrol route code, I've given the tanks some simple patrol routes. The tanks turn to face their next patrol waypoint, then move at full speed until they reach it. They can sometimes overshoot, but I've only seen that a few times. The waypoints right now are just points on a big circle, nothing smart.

Next up:

• player control - the player ought to be able to move around.
• projectiles - pew, pew!
• skycube - I've been thinking about using a texture, but maybe flat shaded polygons would be OK. I'll probably need to set up a special view matrix for the skycube.
• obstacles - stuff for the player to hide behind, stuff for the tanks to avoid
• pathfinding - once I've got static obstacles, I'll need simple pathfinding
• collision - tanks should not be able to drive through each other, nor should they drive through obstacles. Projectiles should not shoot through tanks or obstacles.
• mission system - as I'm getting the simple mechanics knocked off, I've been thinking about what the bigger gameplay design is going to be. I think the player will be assigned some number (4) of patrol waypoints, to which they'll have to navigate (pretty easy, and there'll be an autopilot). Along the way, they'll encounter some enemy tanks, which they'll have to shoot. At the end of the patrol route, the player can return to base. The end. Not a new game design, not super compelling, but a little better than "there are tanks, shoot them". If I were feeling really ambitious, I might have an escort mission or bigger enemy tanks (think "capital ships"). Or enemy bases. Bases might not be too hard, except making something that feels like a living base might be more work than I have time for.
• buddy AI - I've thought about adding a friendly tank that will help you in your patrols. Maybe you can give him orders, like "shoot my target", "hold your fire", "engage at will", "form up next to me". This doesn't seem too hard, we'll see.
• HUD - I'll need a radar display. Maybe a damage readout.
• damage model - moving a little bit away from the simplest arcade "one hit, one kill" model, to a model where different sides of the vehicle have different levels of defense, which can be degraded.
• animation smoothness - for some reason, the movement of the tanks is visibly jerky; every so often, I'll see a hitch in the update. I'm not entirely sure what's going on there, maybe I'm measuring incremental time progress incorrectly. I'd like to fix this, but it's in the "important but not urgent" bucket for now.

Animating (sort of) Tanks (sort of) as far as the (virtual) Eye can See

Over the past 12 hours, I got the Jaws.js framework and the WebGL sample code to mostly talk together. I think they were fighting over who got to control the canvas.

As mentioned in the previous post, I like the 2.35:1 aspect ratio of old CinemaScope movies, so that's what we have here, at least for now. It gives a certain epic grandeur to the window, I think.

What you can't see here, but you can take my word for, is that the camera is doing a slow pan, orbiting the origin, so there are 360 degrees of tanks stretching out to the horizon. Each of those tanks is, itself, rotating at its own angular speed - some to the left, some to the right. So, it looks like a whole bunch of movement. Since I've just been posting screenshots, perhaps the significance there ought to be underscored - up until this update, I had been drawing a single frame. I've now begun actually drawing multiple frames. No problem.

But that has nothing to do with the game I intend to make - I'm just doing tech demos for myself along the way to making... a tank pursuit game? An arcade shooter? A kart racer? Still haven't decided.

TODO:

• player control - give the player a tank to drive around. Steering, throttle, shooting.
• AI control - steering, throttle, shooting. Pursuit?
• skycube - distant stuff to look at, but never get close to.
• obstacles - closer stuff to drive up to and around. Maybe they block projectiles.
• projectiles - something for those gun barrels to launch
• better lighting - I can be smarter about the normals of faces. I want to have dynamic lights, too.
• HUD - score, map
• tank object refactor - object orient that stuff all up in a class, yo.
• deployment work - I don't think that the current stuff compiles for deployment properly. That may require some work. I want to give you a link that works.
• game design - oh yeah, that.

Traffic Jam

Nothing super important here, but I wanted to show off a few things:

• better matrices - after all that complaining, I finally got around to doing something about it. Not a big deal, and now it works. I'm doing a vector times three matrices per vertex - is that a problem? I expect that hardware can handle it, but I know that I can do those multiplications once per object, which seems like a win - isn't it?
• not just green tanks - I now pass down an RGB (well, RGBA) vector into the fragment shader for the base color of the car, which modulates the interpolated vertex color. Again, I'm not sure if I'm getting the best performance, but it's working.
• multiple tanks - I guess that was the other thing I was going to mention. Pretty painless to draw tanks all the way out to the horizon. I did some dorky math to come up with random looking values generated from the x,y positions, which I used to generate the colors and the rotations. Since that was really just there to create this screenshot, and it looks OK, that's fine. (Well, there's a sharp line starting in the middle-foreground and proceeding up to the top right, dividing red from green, which I don't care for, but I won't fix.)

The next big thing (maybe today, maybe later this weekend...) is to graft this in to my Jaws.js framework that I've been carting around from game to game. The sooner the better, and it'll be painful at some point - but it only gets more painful as I write more code.

I don't know if you can tell from looking at that, but I created that screenshot at 1024x768. Not sure if that's the size or aspect ratio I'll stick with. I kind of like 1.85:1 or 2.35:1. And then there's 1.618:1, which you know as "phi" or the Golden Ratio. Bah, the Greeks didn't know anything about widescreen displays.

More tank-like objects

I spent some time today tinkering with my low-poly tank models, which I had drawn out on graph paper, and laboriously entered in one vertex, one triangle at a time, and as fun as that was (well, it was fun in its way, for a time), I decided to screw around in Blender and see if I could output something that might be a little less dorky.

That sort of looks a little bit like a small car with a large gun. Yeah, that's good enough. 

Blender has a number of built-in exporters. I used X3D, because it has an X in it, and I wrote a small Python script to dig through the output and return the vertex coordinates, and the indices. I even made it do a fake coloring of the vertices, based on their z position:

One thing (more as a reminder to myself, than anything else) - the X3D output from Blender contains a couple transformations. I understand that there may be a transformation above the geometry, and you'll want to "Apply" the location, scale, and rotation to bake that information into the actual vertices (or, you know, make your exporter smarter), but there's another rotation above that that rotates 180 degrees around the [0 1 1] axis. I guess that flips left-handed vs right-handed coordinate systems, but I'm sad that we live in a world where we'd have to do such a thing.

TODO:

• matrices - I'm still faking the model->camera matrices. I really gotta build a smarter matrix stack.
• jaws.js - it's time to rip this stuff out of the html file that I've been hacking all this time. The car/tank model, above, is now in its own JS file (more because I got tired of copying it around than anything else).
• tank movement - these guys ought to move around
• "skycube" - maybe not a cube, but a cylinder. Or maybe a box. I hear cubical textures are fancy. Something to make the background more interesting.
• mouse input for steering - I heard that the guy who invented the mouse (and a bunch of other stuff) died recently. Here's to http://en.wikipedia.org/wiki/Douglas_Engelbart
• mouse clicks for shooting - do I want a shooting game? I guess so. Maybe I'll make a cross-country racing game, where you shoot mischievous stuff at your enemies (a la Kart racing games)
• player projectiles effect enemies - whatever projectiles do, they should do it
• tanks shoot back - I spent all that time on that gun barrel
• enemy projectiles effect the player - you'd hope.
• obstacles - depending on the kind of game I end up making, this could be simple stuff to hide behind, or it could be more involved. So, maybe markers for the track.
• better shading - Here's what I think I want right now - a directional light source, maybe from overhead somewhere. Maybe a couple of point light sources (projectiles?). The combination of these things, multiplied by the tank's color (which will be different from tank to tank) should be simple to do. Shininess costs extra.

Something shaped like a Tank

I played around with LearningWebGL's Lesson 4, and got gl.drawElements working. I now get that it's using the same indices to look up the vertex positions as well as the color positions, which is why the vertices were duplicated. I still think there's a way to be smarter about this, but I'm going to have to dig further back into my OpenGL attic to dredge it out.

the grey quadrilateral on the ground is a shadow, but it's not because I've done anything fancy with the lighting - I just made a polygon that lies on the ground to give the vehicle more solidity.

So, next up:

• smarter handling of colors - right now, if I want a vertex to be colored differently on different faces, that means duplicating the position data. Maybe that's unavoidable, but it seems like we're storing and transforming positions more than we need.
• more model tweaking - that tank needs a gun barrel
• movement - the tank should be able to drive around
• player input - the player should be able to drive around

They're Boxy But They're Good.

So, what you see here is two separate programs, for no really good reason, with 5 different batches of vertices - one for the triangle, and then four faces of a cube.

Along the way, I migrated to glMatrix.js v2.2.0, which is a comfort. Not a lot necessary at this point to do the migration, so I'm glad I did it when that was true, rather than later, when it would have been a lot of annoying teasing out of weird errors.

Next up, I think, is to pass in the vertex colors into the fragment shaders, as demonstrated in the Learning WebGL Lesson 4. I get what it's doing, so it's just a matter of copying and pasting to get it in, and then tinkering to get it right.

I still intend to break the "model-view matrix" into a "model->world" matrix and "world->camera" matrix. That, too, should be pretty easy.

I've skimmed Lesson 4, and I think I get what's going on. If I understand it, though, it's transforming 3x the vertices necessary and moving down 3x the color information. I'll see if I can get it to run, and then see if I can fix it.

Stumbling back into the third dimension

There's not much to look at here, but what you're looking at is a variation on the Learning WebGL, Lesson 1 sample, which is, itself, a variation on the NeHe OpenGL Lesson 2 tutorial. So, we're back to square one. And triangle one. Yay.

I've done a fair bit with OpenGL over time, but I've never got the hang of using shaders. Well, it looks like WebGL is all about shaders. Whee.

A couple of things I've tinkered with, above:

• Colors - not that interesting. The background color is just a different argument to the gl.clearColor call. The red polygons involve changing the value returned by the uniform fragment shader. Actually, I created a red uniform fragment shader, in addition to the white one that the lesson provided, and then plugged that fragment shader in. I'd have colored the two polygons different, but I don't know how to do that, yet.
• Angles - vaguely interesting. Lesson 1 positions the polygons relative to the camera, rather than relative to the world, which is a little gross, but I can see what they're doing, I can see what I'd have to do to make it less gross (hint: a matrix for where the model is relative to the world, and a matrix for where the camera is relative to the world). In the lesson, they use translations (no rotations) to put the polygons in interesting places onscreen. What I've gone and done is use mat4.lookAt to move the camera to a more interesting position to look at each of the polygons, giving us a little more interesting view. Not very interesting, I'll agree, but a little more suggestive that we're using a 3D system that can handle perspective, if that's what we want.

A few things that I feel I ought to do next, before progressing to the next tutorial:

• Update glmatrix. This sample is using glMatrix 0.9.5, which I'm sure was fine in its own way, but the current documentation for glMatrix is 2.2.0, so... yeah. There are improvements that I'd like to use, as well as being able to know where my arguments belong.
• Refactor. Maybe I can put stuff into my game framework earlier rather than later this month.

And then, a few things I want to learn in later tutorials would include:

• Multiple Materials. Red is fine, really. But I will want to do more than that.
• Texture Maps. Maybe. Well, especially if I want to do screen stuff. Probably.
• Lighting. This doesn't have to be fancy, just a flat shaded dot product to the light source kind of thing would be fine, just something to make my cubes that I intend to draw not look like a flat hexagon.