Dec 27 2010


Here it is, the long awaited PuzzleRunners. I stipped out multiplayer support and am releasing the single player version only. Design notes up later this week (maybe).
Read more »

Dec 20 2010


The deadline for the 8bitRocket 16kb Atari Inspired Retro Re-make Contest has passed, and the entries are available for viewing. That mean, it’s time to release BattleWire16K.

The version here on nightflyergames incorporates the MochiMedia leaderboard API, to allow for a global high score list. I’ve also uploaded the game to Kongregate incorporating their API in case you prefer to play there.
Read more »

Dec 19 2010

BattleWire16K Design Notes

BattleWire16K is my entry for the 8bitRocket 16kb Atari Inspired Retro Re-Make contest. I made several blog entries during the development, here is a list of all the previous ones.

This entry is my notes on project completion. As it will run somewhat long, I’m hiding it behind a ‘Read More’ tag. I’ll add a link to the actual game on Monday when it’s available publicly.

Read more »

Dec 17 2010

Update 12/17

I submitted BattleWire16K to 8bitRocket for the 16kb contest yesterday… you’ll be able to play it on Monday when all the entries are available!

In the meantime, here’s a screenshot:

I also built a version which incorporates Mochi Leaderboards for distribution into the Flash gaming channels. I’ll put that into distribution also on Monday. I’ve also written up most of my design notes… the text file is already larger than the game! That doesn’t mean there’s a lot of good information, it just means I need to do a lot of revision before I post. 😉

The theme for LD19 was announced 4 hours ago (Discovery). For some reason I can’t seem to come up with anything that wouldn’t be too complex to complete in the 44 remaining hours. If I think of something, I’ll work on an entry… but it’s not really looking too likely.

Dec 13 2010

Cleaning up after myself

Not too much to this update.

– Realized when I showed the game to someone at work, that on end game the airplanes, starfield, and radar are not removed. Oops. Now fixed.

– Adjusted airplane generation so they should be much less frequent early on. May still be too many though.

Playable after the ‘Read More’

Read more »

Dec 12 2010

Second Star on the Left

Two significant visible changes in this update.

First off, I always thought the space above the horizon was pretty empty. It’s also difficult to come back to a point on the map once you’ve moved away from it, since there’s no easy way to tell what direction you’re moving in. Accordingly, I’ve implemented a starfield. The stars are randomly generated, and defined as a yaw and height… so if you’re traveling north (0 degrees yaw) you’ll see the same stars ahead of you (until you reload the game). Under the hood, the starfield is it’s own sprite, which the stars get rendered to every frame. A check is performed on the terrain, to prevent stars from appearing underground… there’s at least one condition where the check fails (tank in a deep hole where one or more of the points defining the rim is above the screen), and I’m not entirely happy with the way I’m handling occlusion (one high point in the terrain will cause all the stars near the horizon to not render), but it works more or less.

I also added airplane enemies. Right now they’re worth 5000 points… because they’re a little hard to hit. (To look at all right, they need to move faster than the bullets!) Currently they continuously drop ‘bombs’ (which are the same as all the other shots), and just fly towards wherever the player is when they’re generated. I haven’t decided whether to turn off the bomb dropping until the airplane is near the player… I think it looks pretty neat to see the airplane flying by with a wake of explosions behind him.

Although the idea was to provide an incentive to keep moving, it’s not guaranteed that an airplane passing overhead will drop a bomb on the player. This isn’t trying to be an exceptionally punishing game.

At this point, I’m at 15.2kb- 15,534 bytes exactly according to Flash Develop and my FTP program. Since the game needs to weigh in at 16.0kb (16,384 bytes) I need to be close to wrapping up. I probably don’t have enough space left to put in another model for example, even after I optimize for .swf size. There is also quite a bit of tuning left to do. My current plan of attack is to spend through Wed working on tuning, and fixing a few remaining internal errors* then branch the game and implement the Mochi and Kongregate APIs for a public (non-contest/larger than 16kb) version ideally releasing that when the list of entries in this contest goes live. That should leave me with the weekend open to participate in the Ludum Dare.**

As before, click the read more to play the game. Comments always welcome!

*- For example, if a player holds down W for 27.7 minutes, he’ll drive off the map array…

**- If Notch can release a major update to Minecraft the day after LD19, I don’t have much of an excuse to skip just to tune this game.

Read more »

Dec 09 2010

Intros and Outros

So, the 16K Atari Inspired Retro Remake Contest deadline was extended to 11:59PM 19 Dec 2010 (PST). Although I think it’s great since more people will have time to build something for the contest, I don’t know that this helps me much… Ludum Dare 19 (48-hour game dev competition) starts on the 17th, and if I’m going to participate in that I need to be completely done with this game before then. But I haven’t really decided whether I want to do LD19 or not.

This update fixes some internal bugs, adds a simple title screen, adds a camera spin in effect when the player is placed on the field (either at the start or after he loses a life), and adds a musical outro. The main soundtrack is now 65.4 seconds long. The player now (briefly) has a model (which is just the enemy tank model drawn in yellow)… in principle I could change the model, and I may, but considering that that model only appears for 3 seconds per game I probably won’t.

One issue the outro solves, in addition to just being a little more polish for the game, is that in the previous version, if the player was firing at the same time he loses his last life, the game could restart immediately with no feedback. Having the outro, even if the player holds down space he at least is aware that he is lost and the game is restarting.

The release build is now 12.9kb. It’s also getting fat, I’ve identified some points where I can compress this. I want to finish all functionality before I try to optimize though.

At this point I wish I knew how to use SVN, git, or something similar, because I’d like to experiment with rendering filled in triangles, but I don’t want to end up leaving remnants of dead code throughout my project if it doesn’t work. That can wait until after I get this wrapped and submitted. Likewise I’m holding off on my stats module, even though I’d like to collect some gameplay statistics… I’m just afraid I’d be setting myself up for hours of work trying to remove the module from the final. Version Control has definitely been added to my ‘I need to learn how to do this, soon!’ list.

Current build after the ‘Read More’
Read more »

Dec 06 2010

In Living Color

I think I’ve reached that point in the project where it’s 90% done, leaving me with just 90% more to do. :) I had six items in my TODO file when I got home from work, I finished 2, and now I have 9 items left on the list…

Biggest change from the previous version is that the wireframes are now rendered in color. This actually raised an issue I hadn’t expected– when everything was being rendered in white, I had made the line thickness for edges on moving objects 2 pixels, and was rendering the terrain at 1 pixel. I had to do this because it was hard to differentiate between the ground and the shots/enemy tanks otherwise.

Once I changed the rendering to color, this concern went away, but the lines for moving objects didn’t look right. So I reduced the thickness back to one. I decided to leave both modes available… the game defaults to the color rendering, but you can switch back to the white/thickline rendering by pressing V.

Another change was the addition of in-game instructions… I’m not sure I like how they turned out, and they may not make the final cut. You’re supposed to read the manual for Retro games anyways!

Oh.. and I added a pause feature. Almost all the games from the 80s had that.

There are also some minor fixes that aren’t really worth mentioning. Play the game after the ‘Read More’. Comments always welcome!

(EDIT- Forgot to add: Current build, 11.7kb)
Read more »

Dec 05 2010

Turn down that noise!

I now have fully deformable terrain! Srsly, click the read more and try the game! :)

If you didn’t guess from the title, I’ve added sound to the 16k game. This was kind of interesting. Generally, I’ve done sound by embedding mp3 files in my games. So my first attempt was to generate some sounds– shots and explosions with sfxr, then package them as 11khz mp3s in Audacity. Unfortunately, the smallest I could pack the mp3s was about 3kb.

I tried embedding one of the explosion sounds into the previous build, but the release size went up from 8.88kb to 11.9kb. I only wanted 2 sounds, so that was doable, but it would eat up all my remaining space and I’m not quite done adding features to the game.

The other option is to use FP10’s ability to dynamically generate sounds. Dr. Pettersson (the guy who wrote sfxr in the first place) gives a good overview of sound synthesis here. If you need an overview of how to actually do this in AS3, see here. After playing around with noise for a while (varying how long each amplitude was being held), I eventually got an explosion and shot sound I could live with. (EDIT: Forgot to mention, to provide some additional situational awareness to the player, the volume of the explosions and shots is proportional to the distance of the player to the sound. I did consider also adjusting the Left/Right levels based on the relative x/y of the sound and the player, but haven’t implemented that yet if at all. It’d be hard for me to test, since I’m working on a laptop.)

Unfortunately, I thought this led to a game that was a little too ‘sparse’ sounding. I needed to add a sound track. Again, this isn’t too difficult, I just used sine waves as my ‘instruments’ as depicted in the second resource. However, making 8192 (or multiples thereof) calls to Math.sin() every time the buffer needed to be refilled was a performance hit I couldn’t take. So I changed the game to pre-calculate those values for every note when it is loaded (just 3 octaves from A3->A7) and store them in an array (wavetable). This was the first performance optimization I needed to make in this entire project.

I also found I was getting a clicking sound every time the notes changed. So, switched from feeding the raw wave amplitudes to fading the notes in and out. (Apparently my speakers don’t like abrupt changes in the waveform coming to them.) That covers playing notes… to actually play a tune I store the score in a class I creatively called ‘CScore’ which also tracks where in the score the soundtrack is currently playing. A method in that class returns the indexes of the wavetable for the notes to be played.

Every time the sound buffer needs to be refilled, the next note is called. This happens every 1/5th of a second… so my CrummySynth is locked at about 240bpm. I actually designed the melody 4 bars at a time using a website for children checking to make sure they weren’t too discordant. (I don’t have composition software) Then, because CScore understands notes by semitones above A3, I encoded each melody by hand first into the lowest octave and then into the middle. To make everything string together, each 4 bar melody starts on a C (stop laughing Meg).

Honestly, in a production game where embedding or streaming wasn’t an option, I’d rather just use FLOD.

To keep everyone sane, I added a Mute at this time as well. Press M to turn off the sound.

Right, so with a soundtrack of sorts, the game was starting to look and sound good. One thing that had been bugging me is that I had set the center of my collision spheres to be the center of rotation– basically the (0,0,0) coordinate for the enemy tank models. As a result, you could shoot under the center of the tanks to kill them. Since the game did need a little more stuff going on visually, I added a check to the shot movement code, to see if the shots were moving underground. If so, I added an explosion… That looked ok, and while playing that version I realized I could decrease the height of the terrain where the shot impacted. Thus deformable terrain. Wikipedia is remarkably mealy-mouthed on the subject of which game was the first 3D game with deformable terrain. If anybody knows, leave a note.

Click the read more to play the current build. Release build is now 10.8kb. Any comments are welcome… but I’m particularly interested right now in whether the game is running smooth or not on different computers.

Read more »

Dec 03 2010

Breaking the Plane

Battlezone (1980) had a unique control system where the two joysticks on the arcade cabinet controlled the left and right treads of the tank. We can’t really duplicate that well with a keyboard, so to keep the two handed gameplay, this version of my game separates the turret and tank controls. I can’t remember seeing this in a game prior to Mechwarior (1989), but surely something had used it before.

The other major step was to take the flat terrain, and replace it with a rolling random terrain. This causes the player (and enemies) to pitch and roll as they move across the ground. As far as I know, none of the ‘action-tank-sims’ had this type of 3D movement until Arctic Fox (1986). (subLogic however, had released their first consumer flight sims by 1980, suggesting the early 8-bit machines would have been capable of it).

Since I’m getting close to done, I’d appreciate any comments. Game and instructions placed after the ‘read more’. Next step will probably be to add sound… Current release build, 8.88kb.
Read more »