dpk’s weblog

Note 2011-03-09: I’m in the process of revamping this with some new understanding of how to rotate in 3D. I’ll also write up something separate about using the “new” InputProcessor class.

I spent some time this morning looking up how to process user inputs while using libgdx. There are some old tutorials out there that appear no longer relevant (InputListener is gone, for example). I couldn’t find something demonstrating the new input scheme (just a note that the tutorial is out of date). So, here’s something really, really basic that will hopefully get folks started.

Continue reading ‘libgdx, cubes, handling inputs in ApplicationListener.render’ »

So, as I said earlier, I couldn’t help myself. I had to keep working on dAST. I’ve added a whole new control scheme, updated the main menu and game over screens, and added online tracking of scores. I’ve rejiggered the way the graphics are drawn on the screen and tuned the tick methods, both based on a lot of traceview analysis (profiling). I made a new game layout for large devices, but I’ve only been able to test it on the emulator.

The new control scheme is the most exciting update. Instead of having two “virtual joysticks”, the player can draw a path that the ship is to follow, and then fire from the ship while it is traveling. The further the ship travels along the path the larger the score multiplier goes. I received some early feedback (don’t yet have permission to reveal the name) suggesting this sort of control scheme and I’ve finally gotten around to implementing it. I think I like it quite a bit. It should work well on large format devices, but it works OK on phones, too. It has a couple of rough edges, but I think it’s at least ready for a wider “test” to find out what people think of it. As always, I’m collecting feedback (although sometimes it takes me a while to get to it, as was the case here, d’oh…)

When Eclipse won’t generate/locate R.java (Updated link)

I just recently ran in to an issue where my R.java file disappeared. R.java stopped updating and I thought that going to Project->Clean would resolve the problem, or at least give me a hint about what the problem was. Instead, it left me R-less.

I found the link above, which is helpful in that it gave me a hint that one or more of my XML files has an error, which makes some sense because I was working on one of the layout files at the time. Additionally, that may explain why R.java was not updating automatically.

However, all of the layout files were syntactically correct and removing the layout file I was working on was not sufficient to trigger the regeneration of R.java file. I tried exiting Eclipse to manually create a R.java file. This got me close; upon reopening Eclipse I got the error: “R.java was modified manually! Reverting to generated version!”. Unfortunately, Eclipse just left the new empty R.java in place. A similar result when I removed R.java while in Eclipse.

Finally, after a bunch of searching, I found out how to manually run aapt in order to generate the R.java file

cd $eclipse_workspace/project; aapt package -m -J src -M AndroidManifest.xml -S res -I $path_to_android.jar

and the result was an error displayed to stdout:

AndroidManifest.xml:22: error: Error: No resource found that matches the given name (at 'label' with value '@string/highscore_label').

I couldn’t guess why Eclipse did not put that error in the Error Log or its Console. Finally, the actual problem: I had removed a string that was being used by the AndroidManifest as a label for one of my activities. A pretty simple, stupid error, that Eclipse is apparently incapable of reporting. Well, I hope someone else benefits from this. Check your AndroidManifest.xml strings carefully, by hand.

I know I said I’d release a “final” version, but I just can’t quit it. I’m taking a break from the new game (which is enormously more complex than dAST, oy) to improve dAST. I’m working on a new control scheme, built for tablets but suitable for phones, where you draw the path the ship is to travel. As the ship is traveling along the drawn path you can shoot down asteroids. The further the ship goes on the path, the higher your score multiplier will go, encouraging long paths. Currently, the path drawing works, and the ship travels along it, but I need to add some code to get the ship to move faster on the straight-ish portions of the path. Otherwise it’s kind of boring watching it plug along slowly. I’m going to playtest replacing the fire button area with full-screen fire detection, where you’d press anywhere on the screen to have the ship fire in that direction. Again, useful for tablets, and hopefully suitable for phones.

I found a potentially serious problem that likely caused lower frame rates on some devices, involving 32-bit graphics intermixed with 24-bit graphics. D’oh. Thought I had caught all of those earlier on.

I’m also going to add online leaderboards (with rudimentary cheat detection) and introduce some tracking of control schemes so I can determine whether or not I still need to support the poorly-received “original” controls. I may rename the game, too, although that will probably wait until yet another graphics revamp is ready.

Even after all of the above is done I don’t think dAST will truly be a full game experience. It’s still missing something.

I’ve started twattering small notes about upcoming dAST and other dpk-game things, for when I don’t feel like sitting down to write a whole blog post.

dAST 0.4beta is now on the market. It has all of the features I mentioned in the previous post (excluding those I secretly removed from the post) and one more: a “radar” feature that shows you where enemies and bonuses are when they’re off screen.

Based on my purely unscientific study, the best time to release app updates is in the morning. Doing so nets the greatest number of downloads and plays. This update has also garnered some feedback and ratings, which is nice, even though they both hated it. (I haven’t received any feedback and ratings from any other release except for the first.)

Despite the ratings I am pretty proud of the game, in that it doesn’t have any game-breaking bugs (to my knowledge) and runs well, at least on my device. My plan now is to release a final version next week (ahead of schedule), although it will basically just be a version code update assuming there are no bugs found during the beta. I’ve had a bunch of ideas for my next game but I couldn’t just leave dAST unfinished; once the final release is out I will move on “free and clear”, hopefully to a game that will be better received. (Just a hint: It will not be an arcade game, and it make better use of the fact that it’s on a touchscreen+mobile internet platform.)

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.