It’s an early release. I’m calling it version 0.0.1. It’s going to change a lot by the time it’s done. There are at least 3 powerups I can think of that need to be added to the game. The sound effects will be tweaked. I want to have global high scores, and I’ve already written most of the server code for that.

So if you have an Android device, please check it out. It installs to the SD card by default and it only takes up 1.9MB of data.

Also, if you have any issues to report or want to discuss the game or ask questions then you can do so at the forums. Or reach me over Twitter.

I’m just polishing up the last little bits I can in the time permitted. Just last night I started working on the tutorial. I would like to believe the game is simple enough to figure out without instructions, but it can’t hurt to be prepared.

I hope to have the tutorial finished tonight or tomorrow. Then I can go back to fixing the last couple (low priority) known issues. And then adding sound effects. And hiding the advertisement when not on the menu. And then tweaking the scoring system. And then… there’s a whole list of things left to do. Oh yeah, I kind of still need to add squishy bugs to the game. You know, the things that give the game its name? Yeah, they’re still not in here. And finish building the web site…

I’m still on schedule for a December 24 release. Progress will be posted here, as usual.

Now that a date is set, what do I do about the price?

I’ve been considering the following plan. First, the game gets posted to the Android market December 24 essentially as a fully featured demo. All power-ups and game-play elements are in place but users are restricted to a limited level set. And the game would be ad-supported.

Then I continue to polish the game. The December 24 demo would be considered the “first 90%” of the game. When the game is at a semi-polished level, somewhere in the last 10% of the development cycle (for those not in the know, the last 10% of development is the longest part of development) then I put a new build of the game up on the market with the lowest possible price point. $0.99. And I remove advertisements from the new build.

Early adopters get in at the low low price of $0.99 and get to play and suggest features as the game reaches completion. This could be a month, it could be half a year, but they get in at $0.99. And when that last 10% is done then the price raises to $1.99 (but not without a nice sale price for the first week or two to transition new purchasers into the product).

At least, that’s the thought right now. I’ll be continuing development on the game. I’m trying to post new screenshots every Saturday but there’s really not much new to show. It’s the same sort of screenshot every time. And I suppose I should get WaggSoft and the forums operational some time soon, too. I’ll need those forums to get feedback on demo.

This is an initial screenshot of my current project. It’s a pretty rough “outline” of what the game will become.

I’m writing the game in libGDX so I can test the game natively on my workstation and compile it for Android at the same time.

Though I started the game just about a year ago, “Space Fight” development is on a bit of a break. It’s an ambitious project and for a guy like me who has never made a big ambitious project, it’s a lot of work. And since a lot of work takes a lot of time, my wife suggested maybe I should get something smaller out quicker (insert that’s what she said joke here). So in the meantime I’m learning how to develop for the Android platform with the book Beginning Android Games. My wife and I brainstormed what we think may be a fun little game for touch screens so I’ll be making a small game for Android before moving on to the bigger more ambitious projects.

Kev Glass has started to flip my world upside down now with his HTML5 version of Legends of Yore! He has written the game in Java and compiled it into Javascript using GWT and the canvas widget. How cool is that? It’s significant for me as I was going to look into HTML5 game development but it appears that now you can just code your game using Java2D and have it compiled into Javascript and runnable on all manner of platforms (iPhone, Android, WebOS, PC, etc) right away.

I suppose the best course of action may be to finish Space Fight in it’s current framework and worry about porting it over to Java2D later. But first I learn Android development!

It will look very similar to this image.

So what’s the difference? Well, the previous image shows off a very inefficient 55878 polygons with 579 nodes. The image above proudly displays a much more efficient 3417 polygons with only 16 nodes.

You may notice the right hand side, there’s an inconsistency with one of the sub-maps (a recursed AccessibleAreaMap) that appears to have stopped rotating when there was still room to continue mapping. Likewise in the top-right area. So there is still room for further improvements.

At the very least, I’m happy that the AccessibleAreaMap generation happens almost instantaneously where previously it took at least a few seconds. Rendering the AccessibleAreaMap also no longer strains the loop.

I had the theory churning in my head and this tigsource thread helped me solidify it in my brainspace.

It’s not something I absolutely needed in SpaceFight! but it’s kind of a staple for 2-dimensional games. Mostly, I was trying to wrap my head around an alternate method of accessible area mapping. When working with “lighting” it’s important to forget about the light. What’s important are the shadows. Now I can try working these ‘light sources’ into the accessible area map, placing one at each available node, and I could have that efficient accessible area mapping algorithm I’ve been looking for.

Still, this is the “accessible area map” implemented in SpaceFight!. If you visit the prototype page you should be able to give it a try. It needs some improvement. It’s a resource hog, especially where there are a lot of wall tiles side by side. And the polygons haven’t joined together as I’d hoped, as you can see by the multitude of ‘pie slices’.

After I’ve reduced the inefficiencies of the algorithm and made the accessible area mapping look good, I get to work on the path-finding. Something to map points of the shortest distance between the player’s location and where the player wants to go within the accessible area. And to display that path. I’m sure it will be all kinds of fun. Seriously. It was all kinds of fun getting the accessible area map to the point it’s at now.

The purpose of this “Accessible Area” map is for the game, SpaceFight!. The orange area represents the places that the player character can reach given a certain amount of time. The algorithm works something like the following:

1. Build a list of visible wall nodes (corners) within a range around the player
2. Sort the list from closest to furthest
3. Cast out spokes at given intervals with a minimum length of whenever it collides with a wall and a maximum length of the given radius
4. Create and add to the ‘area list’ a polygon based on the previous spoke coordinate and the current spoke coordinate
5. Iterate list of visible wall nodes
6. Calculate new radius by subtracting the distance between the starting location and the node location from the given radius
7. Start over at the top of this list substituting ‘player’ for ‘node location’ and keep going until the new radius is too small

I really wanted to add (union) the polygons together to create one polygon consisting of the outer-most points. Unfortunately, that messes up and I’m left with what looks like a crumpled bridge at the best of times. For the time being I’ll have to use the list of hundreds (due to the recursion) of polygons as seen in the image above. It’s not so bad as in the game it’ll be displayed in between turns when the frames per second doesn’t matter. Perhaps there’s a Java package out there that could do the job for me, giving me a simplified list of the union of all the polygons.