I’m planning to add these changes to a final alpha release, scheduled for end of January:

• Animate bonus cooldown/timeout (for triple gun and shield) – done 2010-12-19
• An instruction interstitial between the main menu and the game. It’ll have a few “frames” showing various game actions, without words (where possible). (Formerly demo mode, which is hard and people probably wouldn’t enjoy it, anyway. MTTW) – done 2010-12-26 (albeit ugly)
• Achievements. Every game would track various stats in order to award achievements. They could be earned multiple times, making them a bit different than those on other systems. They’ll be basic things (was going to do like, 80% for X minutes, but it’s more trouble than it is worth) – done 2011-01-03
• Better “game over” screen that shows more stats – done 2011-01-03
• Rudimentary sound – done 2010-12-24
• A serious round of profiling and optimization. I’ve been profiling the game throughout but it could probably use a more concerted effort. There’s still too many places where memory is allocated mid-game, for instance. – “done” 2010-12-26, however it is one of those things that needs to be reexamined from time to time

All in all it will be an interesting bunch of additions that should make the game more polished. Past updates have been minor by comparison. This list will round out the entire set of features I have planned for the game, so once it is done and released, I’ll push it beta, do a few rounds of bug fixes (probably), and then, finally, glorious version 1.0. Ooh and ahh.

Quoting myself from my Android page:

Version 0.3alpha has been released to the market. I am really excited about this release. The game now has collectible powerups: the Mega Bomb which, when activated, will wipe out all enemies (and bonuses!) within visual range; the Shield which protects your ship from enemy fire; and the Triple Gun which triples your gun power (clever name, huh?) by firing bullets in a spread. [...]
210 total installs, 72 active. Heading in the wrong direction! Heh.

This update did not take me as much time as the last, a fact that leads me to believe that I’m getting better at this Android nonsense. I still run in to snags from time to time but they are on the order of using R.layout.* in a findViewById call (when I need R.id.*) or not being careful enough about recycling bitmaps proactively.

I’m still thinking about what to do for Game 2. I have a couple of ideas that are quite doable. Some of the behind-the-scenes changes I made to dAST are in support of making the components more extensible, which should (hopefully) help speed the development of Game 2. dAST will likely be updated pretty regularly for months as I try out new features destined for Game 2 and beyond. For example, I’m looking at adding a generalized global high score + achievement system. I know that some already exist, such as Scoreloop and I may end up going that route ultimately. However, I strongly feel that this is the sort of thing I should be able to write, so I’m making it a challenge to myself to do so. If that makes sense.

Anyway, I’ve strayed off topic here. If you have an Android phone, please try dAST out and let me know what you think of it, good or bad.

As hinted in my last post I’ve been dipping my toes in game development and Android development simultaneously. The first result: dAST. It’s a very simple game but it exposed me to several new or at least rusty-to-me topics: multithreading, MVC coding style, Entity Systems, Android-specific concepts. It will likely remain my “new feature” test platform for games to come.

The game is at a pretty good state now. There is one bug I am aware of, involving the new control scheme. You’ll see it if you steer and fire at the same time and then let go of either the steer or fire controls. There’s an easy solution, and that solution will be rolled out in the next release (this weekend, most likely). There are more features on the horizon (temporary gun powerups, warp, radar, sound, …) but as it stands now it is a wholly playable game.

I’m beginning the design phase of the next game; it’s probably going to be a puzzle game. I don’t have a timeline on that one yet, though.

Entity Systems are the future of MMOG development – Part 1

I found this series on /r/gamedev. It describes a way to organize game “things” (I’m avoiding the term object here) into lists of characteristics about the thing, rendering the thing nothing more than a unique id (think GUID). As the author says it naturally leads to easier multithreading, which is awesome. My only concern after reading this is that the programmer would need to be careful about ensuring that the component lists don’t end up referring to defunct game things. Off the top of my head I’d say that could be taken care of with a periodic GC thread that goes through the component lists to see what is no longer referenced in some “mandatory” lists. For example, a thing without a coordinate component may be eligible for being entirely wiped from the system. I think that could be accomplished by maintaining a list of “Remove” components that are only read in GC.

I recently wrote a game for Android (I’ll announce it for real this weekend or next weekend) that uses traditional OOP game objects and, well, I made some early design decisions that I now regret. The game’s visual objects are all represented by a subclasses of a common class with several common attributes and methods. That’s mostly fine, but then I also stuffed the animation rules in as a member class that hangs off the common class. (I’m sure there’s a pattern or anti-pattern name for this concept, but I’m lousy with names.) The thinking behind that is that I wanted to be sure that the object was able to easily access its own shape for things like hit detection. Anyway, tossing the graphics in with the data attributes has made the objects heavier than they ought to be. This article has inspired me to redesign the objects so that things like the coordinates are kept in one components, hit points in another, etc, and then redesign the game so that it makes use of more threads (beyond the natural Android UI and “master game logic” threads). That probably won’t be complete by the next alpha release but maybe a few releases down the line.