Sunday, December 12, 2010

New Release of Claustrum avaliable in the market

I just published a new version of Claustrum to the Android Market. Unfortunately I could not update the old version because I lost my keystore as mentioned before. But it is time to make the change from "Lite" to "Full" anyway. I updated the description of "Claustrum Lite" to suggest getting the new version, but that isn't seen as an update to existing users. I really wish there was some way I could get a message out to my existing users. They are what make this fun!

I welcome any feedback, I am already making more improvements and features.

Thursday, December 9, 2010

Making Progress

Development is going good this week. I still haven't implemented the local high score database, but put half of the structure for it into the game, and should have it done by tonight. The first world has just the basic ball as the main enemy, and 4 maps are designed for it. Graphics still need some improvement, but some of those can come incrementally after a release. So I am on schedule for a release this weekend. Look for "Claustrum" the non-lite version to hit the market soon!

Right now all my menus are very basic button driven menus with no background graphics. My original intention was simply to keep the graphics from detracting from the game, since that is my biggest weakness. But now I think it is time to attack that and try to use the graphics to add a little personality!

Tuesday, December 7, 2010


I lost my keystore! I think that means I can't make any updates to Claustrum Lite. So the next "update" will have to be a new program. I am going to see if there is anything I can do to push the new version to existing users, but I am not sure if I can.

Perhaps this will just be the jump to the non-lite version of "Claustrum". But I don't want to make a new program and start my review and download counter over without having all the 1.0 features, because you will get negative reviews for a lack of them! This means at a minimum having local High Scores. I think I can get that done pretty quick now that I have gotten a little further along with my overall design.

So I probably still can get a new release out this week with local high scores and a view into the expanded layout with the first world available and a few maps on it.

Sunday, December 5, 2010

Back on Task

After a very long layoff from doing any Game development, I am back at it. I missed it while I was away, and jumped straight back into Claustrum this weekend. Most of my effort was to clean up and organize my code better, but I also started changing the design to allow for my plans for the future.

Right now Claustrum gets very tedious as you progress because the enemy speeds up and you are forced to capture very small areas, build a trap, and be patient. It would play better if difficulity increased in multiple ways, not just incrementally faster opponents. I am going to add a time bonus to counter the advantage of building a small trap, and waiting; and more maps and setups to force different strategies.

And not just more maps, whole new worlds. Each world will consist of different monsters, and each map on a world will have different number of monsters, different layouts, border monsters, and other surprises.

Watch for new updates coming soon!

Thursday, February 11, 2010

User Feedback and Comments - Claustrum Lite

One of the things that really helps to make a game great is user feedback, especially for independent developers that don't have access to large focus groups or a slew of testers, or devices to test on. Now I know that all users aren't going to like all games, and that isn't my main concern. I want to make a great game that works perfectly for the poeple who like the game.

In 4 weeks since I first relased version 0.1 of Claustrum Lite onto the Android Market, I have had 4140 downloads, 62 ratings, and 13 comments. Both the total rating and the comment rating average above 3.25 right now. I have gotten a few good tips in the comments: such at to add double-tap to activate speed boost, that some people don't like the border enemies, a device that the game didn't work on(also a false negative here), and scoring suggestion.

I have also have a few negatve comments about user control. I am working to improve that in every way that I can think off. After the first comment I added touch sensitivity to the options, and I am working on eliminating 3-turn suicides for the next release. But I don't know specifically what the problems the users who commented were having(at the least I wish the system would tell me what phone they were using).

I want the game to be the best it can be more than any of the users. If you like the game and want it to be better please report any bugs, problems, or suggestions to me. Comment here in this blog or send me an email. I will work hard to fix any bugs and make any improvements that I think will improve the game overall.

Sunday, February 7, 2010

Change Isn't Always Welcome.

Some people don't seem to like the border enemies, thinking about calling them fence runners. With a 1 star raing, paul says "Oh well, it was fun until the latest update." Well the last update made it work on 1.6 QVGA devices(Tattoo), added highlights to the border to give it a little depth, and added border enemies. The border enemies are the only real change - they are obviously the culprit.

I had implemented border enemies, but hadn't finalized their use in the game. But after finding out that the game didn't work on 1.6 QVGA devices, I wanted to push a fix as quickly as I could. So I made the fix, and just put 1 border enemy on level 2, and 2 on all later levels. Border enemies require a lot more attention to the game. You can no longer assume safety on the border and look away mid game. Having "casual" gameplay on a handheld device can be a great strength though. A game doesn't have to be "intense" or require 100% attention to be a solid game. And it wasn't my intention to take that away.

I rushed a change and broke a strong feature of gameplay in my game. And not only is that a good feature, taking it away(publishing beta versions) also alienates existing users. I hope Paul, hans on to Claustrum Lite long enough to get the next update, which will happen today, within 24 hours of his comment.

My solution to the problem is to add 2 game types, "Casual" and "Intense." Currently the only difference is the presence of border enemies. This allows gameplay to continue as users have grown accustomed to, or to choose a mode that requires more attention and skill.

Saturday, February 6, 2010

Claustrum Lite Didn't work on 1.6 QVGA?

And getting bad reviews because of it too. Today Claustrum Lite recieved a 1 star rating with a comment, "Doesn't work on tattoo" I have gotten a similar comment about the Droid which I knew wasn't true since I develop on a Droid, but I wanted to check this one out. The HTC Tattoo runs Android 1.6 on a QVGA phone. I build an emulator to match the Tattoo, and "New Game" crashed my app.

It turned out that I wasn't even using the code that was causing the crash. So it was an easy solution to remove that code that made a bitmap that wasn't even being drawn any more. Another thing that fixed the problem was to include the bitmap in the "drawable-ldpi-v4" resource directory. I had been relying on this file to exist in the "drawable" resource directory, and for most cases that seems to work. For me it was breaking in 1.6 if I called Bitmap.extractAlpha() in my Application's onCreate on a bitmap that I just tried to load from resource that was in the "drawable" directory. The bitmap loads, at least eventually, because removing the extractAlpha() call solves the problem, but putting the bitmap in the "drawable-ldpi-v4" resource directory also runs successfully.

I also tested a 1.6 HVGA but did not have the same problem. It took me a while to configure a 2.0.1 QVGA emulator, but when I did, the "bad" code worked there too. So it looks like it was isolated to 1.6 QVGA devices. I know 1.6 is still about half of the android market, but don't know how many of those are QVGA.

Perhaps the problem is calling extractAlpha() on an auto-scalled resource, or maybe decoding the resource doesn't complete before I was calling extractAlpha() on the following line, if the resource isn't in the most direct resource directory.

I thought I was covering all bases testing with 1.5 and 2.0.1, but that isn't true. I wasn't testing all resolutions/densities. But even if I was I still would have missed the problem because it appears to only exist in one desnity on one OS version. Time to up the testing procedure, but at least I got all of my emulators built now.

I hope this cuts back on some negative reviews. I haven't really fixed the header info(score, level, lives, etc.) yet, but not crashing is more important than looking perfect for tonight. I am going to publish the fix tonight, along with everything else I have been working on, most excitingly, border enemies!