Bonus, Shadows, Game Over

So, if you look carefully in those screenshots, above, you'll notice there's a black rectangle underneath the tank. And you'll see a black projectile beneath the yellow projectile. I just did the simplest thing I could to get shadows in. The tank shadow is actually two triangles, that's pretty darned simple. I tried to draw two triangles for the projectiles, and for some reason, that didn't work. So, I just drew a black projectile on the ground, underneath where the projectile in flight was. It works, it's gross, but you can't really tell.

Also, you may notice in the top screenshot that I've added a "Bonus" timer that counts down. Each location has its own starting point value, and rate that it ticks down. Some of the late levels start with a big score that ticks down fast. Good luck!

There's a thing you don't see in those screenshots, but you would if you played the game:

http://bigdicegames.com/BZone/bzone.html

I'll assume that you just went and played the game, and locked on to a target. Up until now, the angle that was displayed in the target display (upper right, but less upper than before, now that I've wedged the bonus display in there) was in radians, because, of course it's in radians. Except now, it's in degrees. Maybe that's easier for people to understand.

I've commented on stuff I could add to this game before, and I won't rehash old features. Some stuff that suggests itself now:

• less dorky tank shadows - they kind of remind me of bases for miniatures. Which is OK in its own way, but sort of an accidental effect.
• less hacky projectile shadows - I'm sure I have some typo in the code somewhere. One thing that's bad about WebGL, and really, a lot of graphics pipelines, is that it's often tricky to figure out why you're not seeing a thing.
• score balancing - right now, the game heavily rewards the quick player. That's OK, but not exactly the gameplay style I had in mind.
• firing rate tuning - if you're heading full speed ahead, and you let loose with a barrage of bullets, they cluster together like a big wall. That doesn't seem right.
• smarter cutscene logic - the tanks just try to leave the area, but they could easily get hung up on an obstacle. It wouldn't be too hard to find a free path, but I never got around to that.

Still, I've got a game that reminds me a bit of Battlezone, and a bit of Wing Commander. Time to start working on my next game.

Now with more, different big red boxes

Running out of time in July, there's still several things that I'd like to get done that I just won't get done. However, I did get the code hooked up that reads object information out of the location description. So, now, when you leave one place, you'll sort of feel like you've gone to a different place.

Having a bunch of big towering blocks makes it feel a little like you're fighting inside Stonehenge.

http://bigdicegames.com/BZone/bzone.html

I might be able to get to one or both of these:

• Bonus - Each location might have a bonus clock that ticks down - the faster you complete the level, the more bonus you earn.
• Shadows - those tanks look awfully floaty, especially during the flyby cutscene. They're not really flying by, but shadows would help sell that these guys are actually on the ground.

Several things I won't get to:

• fixing the crash on Chrome - still don't know what this is. Something weird with WebGL, probably. Probably something weird that I'm doing with WebGL.
• fancier explosions - I'll have to save them for the next exploding game. The one with blimps. Exploding blimps, I guess.
• reticle - I've got ideas for fancy targeting scopes. Next game.
• glass break on player death - it's too bad, because that really belongs in this game.

And a lot more, besides. Still, it's not a bad chunk of work for a month. Especially starting from not knowing WebGL. I'm reasonably pleased.

A New High Score!

No, I don't keep track of high scores. But I am keeping track of score within a mission, that's something. But, as Clive Anderson liked to say, the points don't matter. However, let's take a tour of what you would see if you went here: http://bigdicegames.com/BZone/bzone.html

(I'm not saying you can't go there - maybe you'd like to. Who am I to judge?)

So, the new stuff:

• Cutscenes - in between locations, the tanks take a little bit of time driving away. Opportunity to remind the player the name of the game, in case somebody walked in. And, if the 2.35:1 aspect ratio of the normal game isn't wide enough, the cutscene letterbox makes it even better. I haven't calculated it, but it's gotta be almost as good as Cinerama. (Look it up!)
• Message Scroll - if you look above the radar display up top, you'll see some of that pointy font that you love so much. I did a little bit of research, and I might write my own TTF tool, because, hey, tools. But not for this game. So we're stuck with a font made up of pretty much connecting (-1, 0, 1) (-1, 0, 1). Pretty much. It's legible, and the 8s don't look exactly like the Bs, and that's enough. Messages come in, and they show up onscreen, and after a while, they fade out. Most of that is just a simple animation of color from white to green to transparent. I like it.
• Target Lock - not exactly what I had in mind to begin with, but if you hit "T", the tank in front of you can be selected as a target. Locking on would be super handy if there were missiles in the game, but there aren't. I display range and angle to the locked target. Which would be handy, maybe, if there was artillery in the game. But, again, not. However...
• Buddy Commands - I think this was just about the last feature that I wanted to get in, and here it is. If you target a tank, and then you hit the '1' key, your buddy will try to go and attack that tank. If there are tanks in the way, that might not happen. If you're in the way, your buddy will try to drive around, but good pathfinding never got in, so it might be a while until your buddy finds his way around the immovable object.
• [1] Attack My Target - as I was describing above; specifies a designated target. This bypasses the buddy's detection radius, which makes the buddy vaguely useful - you can identify a target, send your buddy at it, and tend to tougher foes, and your buddy may have taken care of things.
• [2] Follow me - sometimes your buddy gets far away and you're worried about his safety. This will get him to try to be close to you. Which can be maddening.
• [3] Patrol - this is the default state, but you have a button to send your buddy out on patrol if you change your mind about some order you've sent.
• [4] Run away! - sometimes, attacking isn't the right idea. In this mode, the buddy will identify the closest enemy, and try to get away. This isn't super smart, and it is confined to his detection radius, which is still pretty small. But you can see him in trouble, and tell him to flee. Unlike the other modes, this one will override the tank's desire to shoot at what's nearby.
• Score Display - I touched on this already. Score upper left. You get points for shooting tanks. You don't get points for tanks your buddy kills. You lose points if your buddy dies.
• End of Mission Score / Press Space - feel free to insert another quarter to play the next game. If I can figure out an easy way to have a $0.25 PayPal link on that page, it'd be fun.
• Locations position tanks - in the description of each mission, there's a position for the player tank and the buddy tank. I actually use these now, rather than having the players pick up from where the cutscene left them.

My "TODO" list is getting short (which is good, as the amount of July remaining is getting slim). Part of it is that I've been finishing stuff faster than I've been adding new stuff. I've also been moving some stuff into the "maybe later" category. Not a lot, though.

• location bonus timer - If you clear out a location quickly, you deserve a bonus. Kind of like playing "Donkey Kong".
• weather effects - I may jam this in at the very end, depending on how excited I am. It'd be nice to have rain and snow. They'll have to be positioned in the world, so that when you drive through them, they move relative to the tank, and turn... Whew, I don't know if I'll get to them... that's going to be a lot of tuning to make them look right.
• location objects - that big red box in the center of the world... that should be positioned based on location data. There's actual data in the location data that specifies box positions, which I'm ignoring
• game over scoring - You can win a game and then lose the game, if the bullets cross in the air. I've done it. Maybe that's OK to leave in. But, while you're watching the Game Over screen, you can actually see your score change if your buddy tank gets into a fight and loses. That feels wrong.

Oh, one other note - if you look at the "Game Over" text, you may notice there's a drop shadow, now. In fact, there's always been a drop shadow, but the tutorial I was reading about rendering transparent stuff had me using glBlend(1, 1-srcAlpha), which I think sounded a little weird to me. Blending is tricky, there are a few blend modes that make a lot of sense, and a lot of modes that make no sense at all. I was noticing that pieces of textures that were supposed to be opaque, in fact, were somewhat transparent, which led me to use glBlend(srcAlpha, 1-srcAlpha), which got me to what I was trying to accomplish all along. And, once I got the transparency sorted out (ha!), the drop shadow that was there all along started showing up. I don't have a good explanation for what those words are casting a shadow on, maybe the words are on a pane of glass, and the shadow's on another pane of glass... which makes me think I ought to stick lens flare into this game.

Actually, I should figure out a way to make a blimp game. I was thinking during the first half of the year that a blimp game would be good (because how could it not?), but I was sticking to 2d games, and blimps are problematic in 2d. But now the sky is the... sorry. Now, it's really easy to do big objects like blimps. So, maybe that's August.

Spawners, Missions now have multiple locations

http://bigdicegames.com/BZone/bzone.html

I've got a single page of notes in my "TODO" list, though I keep adding stuff to it, I'm also wrapping up big pieces at the same time.

The big change here is that the enemy tanks now spawn over time, using a "spawner" object, so there's more of an inexorable creep of bad guys assaulting your position. Each wave has one or more spawners, each spawner spawns one or more tanks. Once a wave's spawners are depleted and the wave's tanks are destroyed, the next wave starts. You may have a few seconds to take a breath. Waves are organized into "locations", and when a location is cleared, you now get a little message, congratulating you. Again, take a breath, because you'll soon be dumped back into the fray.

Top of the TODO:

• mission interstitial cutscene - to further sell that you're going from place to place, I intend to have a simple cutscene that shows the tanks driving. It'll be short, I promise.
• message display - now that I have font rendering, I'm able to have a scrolling log of messages, such as:
• buddy tank status
• buddy tank order acknowledgement
• your own orders
• location information
• score (maybe? I intend to have a dedicated score display, too. Not sure if store events need to be reported)
• location object spawning - the big red cube in the center of the clearing isn't supposed to be all alone in all locations. And the player tank and buddy tank should spawn from mission data, rather than just be a hardcoded starting spot.
• targeting reticle - figure out what tank is in front of the player, animate a box to the appropriate location. Display targeting information, like what kind of tank it is, and whether it's friendly
• buddy orders - this is going to change the feel of the game again, once you can actually ask your buddy to get out of the way, or come help you.
• radar - I want to try displaying distant tanks on the radar, clamped to the edge of the display. Right now, I find myself scanning the treeline by eye, rather than using my radar - maybe that's the right thing; maybe the radar is just for targets basically in range of your gun.

Tank Templates, Mission Improvements

Yet another "Game Over" screenshot, because there's not a lot of visual work going on.

Work In Progress: http://bigdicegames.com/BZone/bzone.html

Recently Done:

• tank templates - movement, armor, engagement radius, detection radius - all of these are now being read out of the template dictionary, along with tank color, so now, it's meaningful to say "I hate those yellow tanks, they sit out at range and snipe at you". 
• yellow tanks that sit out at range and snipe at you - implemented. Also, blue tanks that see you from a distance and come running. The combination of the two is that you're fending off the blue guys at close range while the yellow guys are taking their infrequent shots at you, keeping you moving. Also, red tanks that are slow but have lots of armor. Look out!
• mission tweaks - the different missions should feel like there's a progression from mission to mission, and within each mission, from wave to wave.

At this point, I'm having a hard time completing missions 3 or 4, though I'm probably not taking advantage of weaknesses in the AI that I could.

TODO:

• mission mechanics
• multiple locations within a mission - I need to take the time to make this happen. It's probably not hard, and it doesn't add a lot to the game, but it's a chunk of code that just doesn't exist yet, and when it works, I expect it'll make each mission feel like you've accomplished something. Also, it'll capture a little bit of the feeling of mission-based vehicle combat games.
• spawn tanks using "spawners" over time - right now, all the tanks of a wave get created at the beginning of the wave. What should happen is that one tank at a time should appear, at a spawn frequency. Waves wouldn't reset objects (trees, rocks), like they do now.
• driveby interstitial cutscene between locations - gratuitous, but I'll enjoy having it in.
• score - points per tank destroyed (tank value stored in the tank template dictionary), bonus points for clearing a location quickly, points off for damange, points off for losing your buddy.
• buddy AI
• orders - engage at will, attack my target, flee, form on me
• AI modes - modes that attempt to comply with the above, with some opportunity to switch between modes as situations warrant
• targeting reticle - gratuitous HUD candy, but also a means to see what you're targeting. Also a means to "paint" a target as a precursor to ordering your buddy to attack it.

Fonts, Menus, Missions

Main Menu

"About..." Screen

Some of the missions are too hard for me

So. I've been doing a few little things, and it seems like I've spent a lot of time, but not a lot of cool screenshots to show for it. So, as usual, the work in progress is up: 

http://bigdicegames.com/BZone/bzone.html

From a "minimal functionality" perspective, I've made a working main menu, which allows you to turn sound on and off (in case you forgot your headphones when you play this at work), as well as the "About..." and credits menu. Also, when you select "Play", you fall into a mission selector, and the four missions are, in fact, somewhat different. Well, they're all "kill three waves of tanks without being killed", but the waves are separately defined. And the ground, sky, and tree colors are all different. Mostly different. There are some differences.

Probably the biggest thing, from a code side, was getting a vector font rendering, as well as generating the data for that font. It's legible, but I wouldn't want to read more than about one screenful of text. Being a vector renderer, I can scale the font how I like, and the font will still look about the same. This will be good for a score display - I think I will have a score, with positive points for each tank you destroy, negative points for losing your buddy tank, and a bonus that ticks down, which will reward the bold.

I also want the buddy tank to be able to send you messages, like "taking damage, bugging out!" or "I'm engaging the enemy". This also ties in to acknowledging orders, which I don't have implemented yet - neither issuing nor acknowledging.

So, looking back a few posts, there's still most of the same TODO list, which I won't duplicate here. Some new thoughts:

• missions - not exactly new, but missions currently have 3 waves of attackers each. That's a start - I intend to have something like 3 different locations per mission, with a little cutscene as the tanks move from location to location. The cutscene will serve little purpose except to entertain me, and really, that's enough.
• tank models - I think it's worth poking at the existing tank model inside Blender and saving out a variety of different tanks, mostly having different numbers and sizes of gun barrels. I want the various tanks to look different, once I start getting richer AI and different tank templates.
• tank templates - I've got several tunable parameters that I could adjust, like armor, movement speed, firing rate, and detection radius. All I really need to do is make a file with all of this in it. Oooh, or I could put all of this into a spreadsheet, then write a script to convert a CSV into JS. That's almost compelling.
• weather systems - now that I have 4 different battlefield appearances, I kind of want to do something with the weather. We'll see.
• smarter AI - I expect this is something that I'll end up tweaking until the month is over. I've increased the tank detection radius, which means less opportunity for the player to sneak around, which is maybe OK - this is probably not much of a stealth game, anyway. As I put more obstacles in the world, I'll need to see what feels right. There's going to be a feedback loop between the enemy tank AI, the buddy tank AI, and the level design so that things feel appropriately challenging.
• tank spawning - right now, all the tanks of a single wave appear at once. There should really be spawner objects (not rendered, just a part of code) that spit out a specified number of tanks per wave.

And there's a bunch of little stuff that's not entirely working; bits of the mission description structure that isn't correctly wired in, objects get moved around within a location between waves. I should set up a bug tracking spreadsheet. 

Now with ground and sky

Nothing terribly interesting here, but a screenshot nonetheless. I added a "groundColor" and "skyColor" attribute to my mission description object, and the above is a demonstration that those are working. The ground is a disk (circular-ish one-sided mesh) that's positioned directly under the player's tank. The sky isn't really anything - when I erase the scene, I use the sky color, and any pixel that doesn't get drawn with ground or objects gets left with the sky color.

By positioning the ground disk under the player's tank, I get most of the effect of camera-positioned geometry, like you'd use for a proper skybox. That's probably worth revisiting, maybe next month, for a more involved implementation. But for now, this is sufficient.

Fight Evil, Little Green Tank!

http://bigdicegames.com/BZone/bzone.html

Actually quite a few things in this update, most of which are small amounts of work, some which have some gameplay effect.

• normals / shading - I poked around a little bit in the various Blender exporters, and discovered that I probably should have been using the OBJ exporter to begin with, as that's a much simpler file format to play around with, but even with the X3D exporter, there are options that I hadn't even paid attention to. I could rotate the model so that Z is forward (no thank you), I could bake the hierarchy in (nice to know, but not useful just now), I can triangulate (would have been nice to have known, but not useful now), and, most interesting, I can output normals. So, I disabled my normal calculation in my converter script, and just pulled the normals in from the X3D file, which helped a little bit. It's still not great, and I think I want to write my own exporter someday, but for now, it's fine.
• now, with some more wave-to-wave continuity! - as the player killed off all the enemy tanks in the wave, everything would reset, including the player's position and health. I've ensured that those, at least, don't get reset between waves, but there are other things that still change (e.g. the trees) between waves, which isn't right.
• now, with less playability by the colorblind! - I've made the enemy tanks shades of red. And grey. And I think there's still some yellow and blue. Mostly red and grey, though. The colorblind issue comes up with this next point:
• now, with an allied tank that gets in your way and steals your kills! - in the above screenshot, you'll see a tank on the left. Those that aren't red/green colorblind will see that the green tank is shooting the red tank. Green=good, red=bad. Also, grey=bad. And every other color of tank is also bad. The buddy tank has a few more hitpoints and a little bit better armor, but he needs it, because he's dumb, and he wades into combats that he shouldn't. Player shots do not hurt the buddy tank (yet), and in fact, they pass right through, which doesn't feel right. Maybe they can plink off the tank with little or no effect, but they shouldn't pass through. It's a limitation of the hacky way that I keep the player's projectiles from hitting the player's tank - I could give the projectiles a "parent" object and not allow the projectile to collide with the parent, or maybe be smarter about launching the projectile, or not do collision detection during the first few updates as the projectile is launching.

The addition of the buddy tank is perhaps the last substantial feature that I've meant to add. There's quite a lot of other stuff I want to put in, but that's just filling in the way that stuff works. The buddy tank was a major piece that I wanted to have in, but just haven't got around to adding. Now that it's there, I can tune based on more realistic play experience.

Having the buddy in makes the game feel harder, as I want to keep the buddy tank alive, so I find myself chasing after it, making sure he's not squaring off against a foe that will eventually kill him. I don't think that level of babysitting is what I want for the game - and when I put in the ability to issue orders ("form on me", "engage at will", "retreat"), that won't be as important. Also, I intend to have better AI all around, which ought to make things a little less inevitable. The buddy tank will retreat when damaged, and presumably not try to engage when he's down.

But that desire to keep the buddy alive is player-imposed; having the buddy around gives you additional firepower, which makes the game easier. If the buddy goes off and loses a fight, you're down to where the game was without the buddy - so there's no way that the game is actually any harder. Well, except when he physically gets in front of you. You can't drive through tanks, so that could be a little frustrating.

Ok, with that, there's still over a page of things on my TODO list, some of which I've started marking as things I likely won't get around to, as they're probably obsolete. Ok, having separated out the "probably will not fix" tasks, I still have a page of stuff to address.

What's left:

• wave to wave continuity - as mentioned above, when you go to wave 2, the trees regenerate. Probably the projectiles and particles get wiped out, too. That's not what I intended. Maybe tanks ought to spawn one at a time, rather than all at once.
• mission to mission transition - as you complete a mission, it'd be nice to display something, give the player a moment, then transition.
• mission to mission interstitial scene - in fact, rather than transition directly, after that little "mission complete" cooldown, I want to have a cinematic indicating that the player (and buddy?) are moving between locations.
• prettier explosions - I like the effect as you're hitting the tanks. I want something bigger when they explode. One thing I've meant to do is have burning bits - particles that leave smoke trails as they fly out.
• HUD: targeting reticle - a little tricky, as your gun is off-center. Maybe it isn't a reticle at all, but a smart targeting cursor.
• HUD: target information - if you're locked on a target, it'd be nice to give some information about that target. Including if that target is your buddy. That would help the colorblind players, a bit.
• buddy tank: model - or, I could make the friendly tank just look different starting with the geometry.
• buddy tank: AI modes - the buddy is really just using the same patrol logic as the enemy tanks right now. I want to add at least a mode where the buddy is staying close to the player. All tanks should also have a "retreat" mode, which will keep the buddy from throwing away his last few hitpoints in a battle he's certainly going to lose.
• buddy tank: orders - simple keyboard commands, maybe on keys 1-4, with instructions to switch into one of the AI modes. Depending on circumstances, the buddy might not follow those orders for long - an order to engage at will would put the buddy into patrol mode, but that might immediately turn into pursuit, engagement, or retreat, depending on what's around.
• vector font display - this should be really easy, and will allow dynamic information displays. Also, will allow things like the about page and credits page without me just typing a bunch of text into a texture and dropping that onscreen.
• score - I guess, with the buddy tank, this is now a thing; every kill that your buddy makes and you don't means points you don't get. I could also score based on accuracy and time spent completing the mission. This is pretty close to going into that "probably will not do" category. It's pretty low priority.
• menus - there's several pieces of the menu that need to be completed or reworked. The main menu needs more than just that huge "play" image, there needs to be mission selection. I intend to have a "credits" and "about" screen, with scrolling vector text.
• missions - there's a single mission right now. I think there should be at least 4 missions, with at least 3 locations per mission, with at least 2 waves per location. I intend to have a variety of tank descriptions (faster, stronger) which will make the missions feel a little different from one to the next. Also, changing the ground/sky color could change things.

Wow, that's a lot still to do. But I've got about two weeks. I could knock off most of that, I think.

New Colors, Better Colors?

I decided to finally spend some time rewriting the color code, which involved rewriting basic vector math in Python (because, sure, I've got that stuff written somewhere, but it's easier just to rewrite a cross product than to figure out where the last libraries I used were located).

Calculate the normal of each of the faces, for each vertex, sum the normals, then normalize, then grumble that "normalize" and "normal" seem like such similar words, but the one is an operation on a vector that makes its length 1, and the other is a vector perpendicular to a plane, and really, they could have found different words.

The vertex normals seem about right from the testing I did, so then I did some dot products with a directional light source shining straight down. (I'd do something fancier than that, but I wanted something simple, and this gave me a static light that held up when the tanks rotate.)

So... is it an improvement? Sort of. There are a bunch of artifacts that I don't like - in particular, there are gross streaks running down the gun barrel. I see what's going wrong here - the issue is that I'm averaging across creases in the geometry, which I knew was going to be an issue, but I didn't know how big an issue it was going to be.

Consider the vertices at the end of the gun barrel - each vertex there touches some number of polygons on the end of the barrel, and something like four triangles going the length of the barrel. I'm using the same vertex color for all of those triangles, which would make sense when the geometry was smooth - averaging all the nearby faces gives nice smooth shading. But with a crease, you've got polygons on one side of the crease that shouldn't spill color information over to the polygons on the other side.

So, I could change my model exporter to facet all of the models - not sharing any vertex information anywhere, which is simple, and would give a different look again, maybe a little better.

Or, I could be clever and detect creases in the model (where one triangle meets another triangle at maybe a 45 degree angle or sharper), and break the vertices apart based on that crease. I've done that before, but yeesh, that's been years. That's a lot of work, and I don't think I want to do it right now.

Or, I could poke around inside Blender and maybe find some sort of setting on the exporter I'm using, or some different exporter, that does all this for me. Seems like Blender would have these features already implemented.

Or, I could write my own exporter that sits inside Blender, rather than use their exporter and my conversion script. That'd probably be the best way to go, but again, more work than I want to do.

Or, for the moment, I could say that this is as good as it gets, and let it go. Punt!

Well, for today, anyway, I'm done. Maybe I'll come back and implement the faceted approach, where vertices get duplicated all crazy like, and normals are per-polygon, without averaging, which makes me sad, but I think it'll be the best appearance for the least work.

Top of the TODO:

• Buddy - really, having an ally tank won't be hard. Getting it to play smart and be a balanced part of gameplay will be the hard part. Also, following directions you send it (here, boy!) will be work.
• Mission Menu - selecting missions from the mission menu won't be hard, just writing a menu display and getting keyboard events.
• Main Menu - right now, there's a huge gross "Play" screen. That's an abomination and a placeholder version of a main menu that isn't fully implemented. Play, About, Credits, Sound - all of those belong on that screen. Again, wiring, keyboard input.
• Vector Font Text Rendering - I intend to have dynamic text (a score?), or at least the ability to turn a string of text into something graphical, so that I don't have to do all ingame text as textures. This isn't a big deal, but it'll require writing yet another set of shaders and a custom rendering pipe. Not a big deal, and I see how all the pieces fit together. I haven't done this in WebGL before, but it should be straightforward. If you remember my space golf game: http://www.bigdicegames.com/Woody/ that's the feeling I want to capture. In particular, here's the settings menu: http://www.bigdicegames.com/Woody/Screenshots/07-04-05-09-19-optionsScreen.png

Game Modes, Missions

http://bigdicegames.com/BZone/bzone.html

There's really nothing visual that I can point to with this chunk of work, so no screenshot here. But, go ahead and play the game, that's where the pudding is at.

Stuff I did:

• game modes refactoring - I've got this pattern that I've been using, or motif, or code habit, I call it "modeMgr", and it's a convenient way to break up pieces of gameplay. Often, I implement it hierarchically, so, modes can be part of a stack, and sometimes I don't bother. But a mode has some basic drawing and updating, and when its done with what it's doing, it tells the modeMgr to swap to a different mode. I had a sort-of implementation of this going on, but today I cleaned it up a bunch, and now I have several more modes, and they don't have a lot of JavaScript cruft in them. Some cruft, because I have to leave myself some cleaning to do over time.
• title screen / menu - this is the other half of the push and pull of game mode refactoring; now when you get to that "game over" screen, you can go back somewhere, and play a new game.
• missions - it's not impressive yet, but I've set up a data-driven mission structure. Right now, there are three waves of tanks in the one mission that you can get to.

Stuff to do:

• tank templates - different missions will call for different kinds of tanks. The first mission will generally have easier tanks, and later missions will have faster, tougher, smarter tanks.
• smarter tanks - at this point, the game's not challenging, because it's easy to stay out of sensor range and snipe. I have a few ideas:
• longer detection range if they're facing you - as though they could see out the front of the tank, not just pick you up on a radar display
• dynamic paranoia - as player actions effect the tanks, they ought to notice. A bullet hits us? Hm, maybe we should turn in the direction that it came from. A tank just blew up? That's not normal. Let's see about that.
• Chrome crashing - Chrome has been complaining about WebGL having problems occasionally. I had thought this had to do with sound, but now I wonder if I'm doing something weird in my shaders that's not cleaning up properly.
• main menu - the main menu will give you a few buttons to click on. Or at least prompts to do stuff. Maybe I'll just make them keys, that's easy.
• sound toggle - not everybody wants to hear my fancy 2 minutes of screwing around in Audacity sound effects.
• mission menu - select a mission and away you go
• buddy - about time to get a second tank in the mix and see how that changes the feel of the game
• mission interstitial scenes - once you clean out a location, it's time to go to a new location. I intend to have a brief cutscene of you (and your buddy) driving to the new location. Not super long, just enough to sell that you're going to a new place.
• secondary wave spawning - right now, each wave cleans out the level and puts you back where you started. This doesn't feel right when you're already in the location.
• model exporter / normals / dynamic lighting - that thing I keep talking about doing to make the tanks look better.

It feels like there's a lot of stuff left to do, but it's good stuff (even the menus). I think I've increased the scope of the game this weekend - there are enough pieces working that some of the stuff that was just barely good enough before no longer seems acceptable. 

Pretty Explosions

http://bigdicegames.com/BZone/bzone.html

When a projectile hits an object (a tank or a static object), you get a simple little explosion effect. When a tank explodes, you get a somewhat bigger explosion effect.

I could spend the rest of the month tinkering with the effects, and I probably will do some tinkering, but between now and then:

• game modes - that thing with the "game over" and hitting F5 is stale. There ought to be a menu screen.
• buddy - heyyyyy budddeeee.
• chrome crashes - I'm not sure if it's in the way that I'm doing sounds, or if it's debugging code that I left in, or what, but I was seeing a few crashes when I went crazy with my projectiles.
• lighting - this is actually several pieces:
• model exporter - the exporter can be made smarter to understand normals
• object shaders - because I so loved the shader debugging I did today, I can't wait to modify the shaders to use the new normals. Or, I could bake the lighting in as part of the export process. Nah, that wouldn't be as satisfying, because of the next thing:
• dynamic lighting - maybe the bullets are a light source. Maybe the explosions are. That'd be keen.
• missions - in my head, this sort of ties into game modes, but really, game modes are a precursor to missions. A mission will have several stages. Each stage will have a level layout. Each stage will have one or more waves of enemies. There may be pickup waves (think the "bonus stage" in "Mario Bros.").
• skycube - maybe I'll actually get around to doing this. With the trees, it hasn't seemed as important.

Fireworks

Just a debug screenshot, but it looks like they're celebrating with fireworks. And I'm celebrating, too, because I got the particle systems working in the shader. Guh, 3d math can be confusing, but I figured out what was going wrong.

No time to explain, but it's important to add your vectors in the correct space, and if you're dividing by w, which is how the perspective transform works, and if you're tinkering with vertex coordinates in screenspace, that means that you have to divide by w before applying your screenspace tinkering, which means you have to do the division by hand. Not a big deal, but I just wasn't seeing it for most of the afternoon.

Functional Radar Display

http://bigdicegames.com/BZone/bzone.html

The radar now works. Red blips for enemies, white blips for static objects, dark green blips for yourself. It's nice to be able to see when somebody's sneaking up on you.

Hm, I wonder if I can reuse my "blip" shader code to make interesting particle systems for my explosions? In part, I imagine - drawing a little box on the screen will be simple enough, positioning it in the world will require lifting code from the model drawing. That's not so bad.

I guess explosions are the next thing that I'll work on - visuals *and* sounds.

Positional Damage, better Radar Art

http://bigdicegames.com/BZone/bzone.html

Stuff I did:

• Radar Display Art - so, RADAR (RAdio Detection And Ranging, invented in part in Building 20 on the MIT campus: http://www.ll.mit.edu/about/History/RadLab.html, though, sadly, the history of RADAR page on Wikipedia doesn't mention MIT: http://en.wikipedia.org/wiki/History_of_radar but if you want to build your own, there's this: http://web.mit.edu/professional/short-programs/courses/radar_systems.html). I redrew the art at 1024x1024, being careful to keep edges crisp. I then shrunk it down to the ingame size of 128x128, and it looks much better.
• Positional Damage Model - damage is now tracked in five locations (four sides plus interior).
• Positional Damage Display - the trapezoid on the bottom right is how your tank is doing. You can take 2 hits at each location. The guy in our screenshot is hurting; one point of damage remaining in front, zero on the left, and the interior components are down to one point of damage. Careful!

Stuff to do:

• Radar Blips - is that the technical term? You send out a "ping", and I guess it comes back (certainly not called a "pong"), and then it's a blip on the screen. Yet another custom shader, or perhaps two. Some fancy things I could do would be to simulate sweeping the world with radar, so some blips are stronger than others. I could even update the individual blips only as part of the sweep, so a dot appears, then fades away without moving, which would be accurate, but annoying.
• Revisit Projectile Damage - I haven't seen problems yet, but I can imagine that a fast-moving projectile might get most of the way through the vehicle and appear to do damage to the far side of the tank. There's even the possibility of shooting through objects that should be solid, if the projectile's moving faster in one update than the size of the object. It's not a hard fix, but it's not something I need to do yet, so I might keep this at low priority.
• Explosions - with the new positional damage, I've got rid of "one hit, one kill", which was true to old arcade games. The upside is that the enemies take more work to destroy (more gameplay), and you won't lose the game if you weren't watching your six for a moment (though, with a few hits, you'll still be out). The downside is that there's no indication that you've hit an enemy tank. So, a projectile hitting a tank effect will be good, and then a tank blowing up effect will be good. Maybe some particles? Those are easy. Also, sounds.
• Missions - I still want to do this. I've thought a little bit about making them simpler than my original concept where there'd be a lot of tanks in a big world, and you'd be free to wander around and discover them all. That's probably more work than I want to do. So, maybe a few small scenes, rather than a continuous world.
• Damage-aware AI - if a tank gets damaged, it probably ought to run away. And it'd be best if it turned its strongest side to you. Though, if its strongest side is its front, should it charge you? Maybe.

Texture transparency sorted out, beginnings of Radar

In my last post, I was complaining about getting the transparency working correctly, and given a few hours away from the keyboard, I realized that I wasn't doing the dumb stuff that you gotta do to make that work correctly. With this screenshot, you can see a radar display (really, that ought to be RADAR, as it's a proper acronym), which uses texture alpha correctly. I probably need to redo the art, because it has all sorts of sloppy edges. Still, the technology is working.

You won't see it in the screenshot, but if you go to http://bigdicegames.com/BZone/bzone.html you will see the win/loss textures displaying. I'm still not sure that everything's right there - the loss text seems like it has more transparency than the win text. On the list to revisit.

TODO:

• radar - actually display blips for enemy tanks (and objects?)
• damage display - I made art for a damage display, which I intend to put on the lower right corner.
• positional damage model - I'll want to track how the projectiles hit the player so that damage is assigned correctly.
• proper game modes - right now, you have to hit F5 to restart the game. That's no good. Also, there ought to be a title screen and stuff.
• buddy - fight evil, little wooden boy!
• sounds - really.

Nothing on that list is difficult, nothing on that list is anything I need to learn how to do.

Win / Lose messages displaying

I struggled to get texturing working, and I'm not sure it's even really fully working - all that black space in the screenshot above is probably supposed to be transparent.

Still, there's now a clear win and loss message, which is good.

Now with less bumping

That screenshot is from a debug build with shooting turned off - ordinarily, tanks wouldn't crowd around like that and let you live.

I've added in a test to see if the place the tank wants to move is "free", and if it is, complete the move. If it isn't, and the tank is patrolling, the tank just selects the next patrol point, which seems OK for simple patrolling. If the tank is pursuing you, then there's some hacky code that gets the tank to jockey away from the colliding objects. 

I think real pathfinding would make both of these better, but as it is, having tanks that don't poke through each other is an improvement.

Next up:

• collision: projectile/object - will actually be really easy, and will make static objects tactically interesting to duck behind.
• pathfinding - will make enemy tanks a lot smarter
• HUD - radar, damage display

Now with extra Pew Pew and Game Over

http://bigdicegames.com/BZone/bzone.html

I did some work last night, laying the foundations of making the tanks know better than to drive through stuff. I created an object registry singleton object, which will hold tanks and obstacles, and will be useful for querying to see if the new location is actually obstructed.

I'll also want the AI to be smart about being able to drive around obstacles and tanks. I'm planning to do a simple ray-circle intersection and steer tangent to any intersecting circles. Should be good enough for sparse environments.

I realized that there's a lot of work there to do, so I switched gears to what was then low-hanging fruit: making the AI tanks react to the player. With the object registry, tanks can ask what other things are nearby, and if any of them are player tanks. (I still like the idea of a buddy tank, so player-allied tanks are a thing I'm thinking of, even if the player isn't actually in control of the tank).

I added two behaviors - pursuit and engage. At a certain radius (50 feet, currently), the tanks will detect the player tank. (Bad radar in the enemy tanks, I guess.) They'll turn toward the player and then drive until they get to the engagement range. If they're still turned toward the player, and they haven't shot in the last 3 seconds, they'll shoot.

Simple enough, but enough to be challenging. You can't race in to a bunch of tanks now without repercussion; evading one shot is possible, evading several is hard.

With win and lose conditions, I consider this a complete game. There's quite a lot left to do:

• sounds - sound effects make a big difference.
• collision - tanks should collide with each other, tanks should collide with static objects. Projectiles should collide with static objects.
• pathfinding - enemy tanks should be able to drive around static objects.
• HUD - the "heads up display", containing a radar map of nearby enemies and a display of tank damage
• positional damage - maybe it isn't one shot, one kill, maybe you can take a few hits to a side before dying.
• game modes - win/loss, title screen, mission overview
• buddy tank - stay on target!
• better model lighting - at some point, I'll calculate the normals at each vertex and use that for coloring. The tanks will probably look better.

Bugfixes, Model Rendering Work

http://bigdicegames.com/BZone/bzone.html

One thing I've got a lot of value from is breaking of weekend-scoped pieces of development, so that you can show off your progress to your coworkers on Monday morning. Some games have more weekend-sized pieces than others, but I think the ones that can be broken up that way are easier to maintain progress on as you move along.

With "One Game a Month" there aren't a lot of weekends per game, so that idea has to be modified some - either smaller chunks, or smaller games.

I told some coworkers about Zone of Battle: Tank Patrol yesterday, and almost all of them had problems loading it. Weird. Now, I had only tested on Linux/Chrome, which isn't representative of all OS/browser combinations out there, but even some Linux/Chrome coworkers couldn't load it. They were able to give me some valuable debug output.

So, recently done:

• Tank movement - I got this in yesterday morning. There's arrow key steering for simple control, or tank steering, if that's your thing.
• Some obvious browser bugs fixed - no guarantees about your browser, but I'm guessing more people will be able to play it now.
• Projectiles launching from the muzzle - this was a small change, but it makes a big difference in the feel of the projectiles.
• Static objects in the world - I made a cone and two sizes of cubes. They don't block tanks or projectiles, they're just visual, but they make the tanks feel like they're in a space, rather than just floating around onscreen.

And the top of the TODO list:

• collisions - between tanks and objects, between tanks and tanks
• enemy tanks shooting at you - this will be the last important piece of gameplay. It will probably change the feel of the game substantially, requiring tuning speeds and scales, but that's a great place to be.
• HUD - radar, score, damage display

Now with steering

A small update here, with a few improvements, which feel at once like nothing much, but also a big deal.

• player tank onscreen - the camera's hovering over the tank, giving that first person view that you remember from, say, "Doom". Or "Wolfenstein 3D". Do you remember the old MUSE game "Castle Wolfenstein"? I have vivid memories of completing "Beyond Castle Wolfenstein". Oh, look, http://www.oldskool.org/pc/BCW/faq.html
• steering, finally - the left and right arrow keys rotate the tank right and left. 

With the addition of tanks not driving into each other, and actually shooting at the player, I could wrap up the basic bits of gameplay in short order. However, here's the top of my TODO list:

• obstacles - adding in stuff to drive around will make things feel more solid. Right now, there are just a bunch of tanks in this formless void.
• skycube - I'm actually thinking this will be a cylinder. I was thinking of a cone for a while, but a cylinder is just fine - a really simple heightfield going around the map with a zigzaggy mountain line. That makes two sawtooth cylinders, one in dark blue, for the mountains, and one in light blue, for the sky. Easy. And, once this is in, the tanks will seem more anchored, as well.
• player movement revisited - I would like to have the independent left and right tread stuff working, to give that tank drive feel, and 8-way steering. It won't be hard, it'll just mean getting around to doing it.
• projectile spawning position - the projectiles launch from the center of the tank, not from the muzzle of the gun. Converting the muzzle position into a world position is a simple application of the model->world matrix, which I have, or I can create.

Tank Battle: precursors

Clearly, the game I'm building has lineage that traces back to the early arcades. And there's some pretty heavy influence going back to combat sims on home computers. I remember playing a submarine simulator on an acquaintance's Mac years and years ago. I don't recall the name of the simulator - GATO is about the right timeframe, but Wikipedia says it wasn't a Mac game. Maybe Sub Battle Simulator?

The History of SubSims

Submarine Simulators on Wikipedia

Of course, there was Seawolf, which was an arcade game, but I'm not considering that an influence.

The arcade game I had in mind, of course is Battlezone, the 1980 vector shooter. The KLOV page has some good footage of the game being played, and several features that I haven't got around to implementing yet, like:

• sound effects - player movement
• sound effects - new enemy in range
• HUD - targeting reticle that "locks on" to a target
• half-height obstacles - block movement, do not block shots

Thinking back, I think that I spent the July 4th weekend of 1994 tinkering around with making a Battlezone clone, using C (C++?), Visual Studio, and Fastgraph. I didn't get a lot done that weekend, but I did get a parallax background displayed. That seemed like a lot back then. 19 years later, I've looped around, and done what, back then, was the hard stuff. Maybe this week, I'll get the skydome working. I suspect I still have the hard drive with the assets and code for that stuff, but they wouldn't be useful, even if I could spin the drives up and get the data off - that stuff was probably 8-bit, and designed for a 640x480 display, at the highest. So, I'll start from scratch, and make something that visually works with my current implementation, and that'll be good.

Over this weekend, and mostly coming from a different context, I've been thinking about Malcolm Gladwell's claim that you need to spend ten thousand hours doing something to become good at it. I don't know how many hours I've put into game development in the past 19 years - if I count 40 hours a week, working for 14 years in the industry, that easily knocks me over thirty thousand hours, but I hesitate to count all of that. Still, going back to Battlezone, and thinking of what I accomplished when i was much younger, compared to what I did this weekend, even with a bunch of other stuff going on, I'm clearly much more productive.

Oh, and it's a lot easier to make games today than it was two decades ago. Back then, Mode X was black magic.

You Win!

For the first half of the year, my One Game A Month games have been non-violent affairs, no shooting, no cudgeling, no stabbing. I guess that run ends today, as you see two projectiles (laser beams? plasma bolts? Something bullet-y) in the above screenshot.

I imagine that most of the remaining games will have some sort of shooting gameplay involved, but maybe these are robot tanks, if that helps your own personal violence meter. No animated blood.

I'm also pretty pleased to have those projectiles in, because it means that I have a "pipeline" to bring models into my game. I was just joking today about how I wouldn't need to make any more 3d models for the rest of the year, as tank games are a rich vein that I can mine for at least a few games over the next several months. Well, I made a projectile in Blender today (I took the cube that you start with, and scaled it to be long in the X dimension and skinny in Y and Z), and used my converter script, and it pretty much just worked.

Back when I was working in game middleware, and certainly on hobbyist forums and mailing lists that I followed, there was talk about "what belongs in a game engine?", and my opinion was "whatever you reused when you made your second game". There's a certain amount of snark there, saying that if you haven't finished two games, stop waxing philosophical and just make games. And I'm OK with that. But I'm sticking with the literal sense, too - that an engine is just a series of tools, and if you're not using your tools, throw them out, and if the tools are any good, they'll be reusable. Anybody can hack together a one-time solution.

So, with the advent of that projectile, my model converter script has become a real tool. And the code in the game that handles rendering and model loading seems to work. I think it could be simpler, but that's under the hood tinkering to do later. Maybe next month.

If you go to http://bigdicegames.com/BZone/bzone.html now, you can hit the space bar to shoot projectiles. If you time it well, you can shoot tanks. One hit, one kill. No explosions, no fountains of blood, no fanfare. If you're lucky, the tanks will have patrol routes that cross your line of fire. If not, well, reload.

And this marks one of those milestones, sort of - I detect when you've killed all the tanks, and I print a message to the JavaScript console saying "You Win". So, that's always a good sign. Having success and/or failure conditions makes the game a game. Otherwise, it's maybe an interactive simulation. Something. I'm hedging this even more than usual today because I've got a bigger scope in mind for this game.

Zone of Battle : Tank Patrol Game Concept

In ZoB:TP, you command a tank that can drive around a battlefield of the future. Your tank has a forward-facing cannon, capable of shooting deadly laser beams. The enemy has similar weapons and is intent on destroying you.

The structure of the game consists of a series of patrol missions, where the player is given a series of patrol locations to visit. At some of these locations, there will be enemy tanks to destroy. If the player returns to base safely, that mission will be considered a success.

Helping the player will be a second tank, who will accept simple orders:

• engage at will
• attack my target
• hold fire
• form on me
• retreat

In-game UI will include a radar display to locate friendly and enemy tanks. There will be a map screen that the player can pull up that indicates the patrol route by pressing 'M'.

The player can activate autopilot by pressing 'A', which will navigate the players towards the first waypoint that hasn't been checked off their list. The autopilot disengages within a certain distance of the waypoint, and also disengages if enemies are within range.

Ok, that's the design sketch; I think I can get most of that done before the end of the month. And, even if I don't go all the way, I've got most of the pieces of a simpler version of that, which gives me slack, in case I get distracted and do something else in my spare time.

TODO:

• player steering - because I'm getting tired of enemy tanks driving up to my line of fire and then driving away.
• player movement - depending on how I'm feeling, I might implement tank controls, or maybe just simple WASD navigation. YINM, maybe, with Y/N controlling the left track, and I/M controlling the right track. I'll see how that feels.
• player tank on screen - I'm planning on a "chaseplane" view, which can be tricky to get right. I may do something simple, like have the camera always be pinned to the same position relative to the back of the player tank.
• visual effects: explosions - there needs to be something visual when a tank blows up.
• sound effects: explosions - also, sound. Sound adds a lot, it turns out.
• sound effects: projectile firing - it won't be me saying "pew, pew" into the microphone, I promise.
• game modes - lose mode that takes you back to the start screen. A start screen. A map view.

Lots of stuff to work on, nothing actually too hard. Lots of stuff not on that list, those are just the interesting stuff at the top of the list.

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.