Apr 18 2011

BattleWire:TaOS now available on BlackBerry App Store

Edit 5/22/11: I’ve submitted a new version of the game to the AppWorld, which should fix the control issues.

BattleWire:TaOS is a version of BattleWire16K for the BlackBerry Playbook. It adds a new enemy, and uses on screen controls. If you have a Playbook, the game is free (as in free beer, not as in free software) so give it a shot! And since I don’t have a Playbook, you might let me know if the controls work ok? I wasn’t able to test pressing two buttons at once in the simulator…

Edit 4/21/11: The developer of Twystem, a puzzle game for the Playbook, happens to have an actual device and was kind enough to test my game. Apparently the controls do work, but multitouch does not (so the player can not move the tank, and move the turret, and fire his gun all at the same time). I have a pretty clear lead on how to correct this, so expect an update in the next week or so. And if you have a Playbook game that needs testing, you might send him an email.

Here’s a screenie from development:

If you want to play the original game, click here, or here to read the dev blog. I’ll write a better post later, after I figure out how to link to the game on the app store, and when I have more time. The approval caught me off guard this morning, and I have other things that need to get done today.


Jan 17 2011

8bitRocket’s 16K Retro-Remake Contest Results Announced

Go read the official announcement here.

I’m really happy with how BattleWire16K did- but to find out for yourself, for now you have to click through. :)

Jan 11 2011

BattleWire16K in Chinese

BattleWire16K was translated to Chinese courtesy MochiMedia/ShandaGames. You can see it here. Note that that’s a link to a Chinese website and other than to note that the orange button below the screenshot launches the game, I don’t really know what any of the text says.

The one issue that came up, is that the recommended font, Microsoft YaHei, is large and embedding it into my .swf turned a game made for a 16kb contest into an 7,823kb monster. (MSYH, being a font designed for use in China contains character information for over 20,000 characters in comparison to an English/Latin font which has a few hundred.)

However, the translation needed only a handful of these. The solution was to embed by unicode range. Of course I didn’t know the character numbers for the Chinese text, and don’t have a utility to readily find unicode character numbers. Fortunatley, there are several web pages which will take arbitrary text and turn them into a series of unicode characters. I used one by Russel Cottrell.

To get the characters which needed to be embedded, I took the text sent back by the translator and copy-pasted it into the block which is labeled ‘Click to insert characters below’, selected Hex and click convert to HTML. This produces in the bottom block output which will look like “知名坦克”

Copy paste that block to a new file in any adequate text editor, and find-replace &#x with U+ and ; with ,

Remove any linebreaks and you now have a list of Unicode characters used in your translation, which you can copy into your embed tag using the unicodeRange= option. Using this process, I was able to reduce the file size from almost 8MB to a more reasonable 76kb.

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 »