Sunday, December 12, 2010
I welcome any feedback, I am already making more improvements and features.
Thursday, December 9, 2010
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
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
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
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
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
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!
Friday, February 5, 2010
The initial way I am going to handle this problem is by adding border enemies. They are 80% implemented and may even make a debuit in v0.5.0 But now I also have a few other ideas that stem around changing the ball to a more organic enemy. Giving him a bit of smarts(and perhaps weapons and friends) rather than just having him bounce around the area. This may also allow me to put a bit of a story around the game.
From the beginning, I have been planning on have a free version and a cheap paid version. I don't like ads, and I don't want the free version to be a "demo." I want the Lite version to be fully playable and enjoyable, and just for the paid version to have a little bit extra. Smart enemies and a story my be just the solution - Abduction does a great job of this. The free version is a great game on its own, and World Attack adds a story, themes, characters, challenges, and levels. If I can't figure out how to do this well, the whole game will be free, but I think if it can be done well, it is beneficial for everyone.
Sunday, January 31, 2010
Being able to restore games required one specific fix to the border polygon that I have been planning on making anyway. The player no longer stops at points on the border that used to be corners but aren't any longer. The reason that this had to be fixed with the ability to restore games is that the intermediate lines in the captured area aren't shown after a restore. So you can't even predict when the player is going to stop on a straight line after a restore. Now he never will, except when closing the boundary.
I also added dialogs when the game is paused and between levels. I spent a lot of time trying to figure out all the different ways I could use dialogs and alertDialogs, and making custom buttons. I am happy with the result, but need to resize the dialogs a little for smaller resolution screens. I developed them for the Droid(480x854) and they work on smaller resolutions, but I think it will look better if I scale the dialogs and buttons down a little so that they look about the same as they do on high resolution screens.
Sunday, January 24, 2010
3.5 Stars with 17 ratings. I am happy with a 3.5 star rating, that looks good in the rating bar, and I still have lots of fun to add to the game.
Where things aren't as good is in the comments. I only have 3, which seems a little low for 17 ratings, and their average rating is 2.6.
- The first is a 5 star rating from someone who seemes to love the original Qix and enjoyed my game.
- Second is 2 star rating saying that swiping doesn't seem to work properly yet.
- Third is 1 star that states it doesn't work on the droid.
I wish I had a little more info about the bad reviews. I know it "works" on the Droid, that is where I do 90% of my development. I wish I knew what didn't work for this user; controls, display, presentation of the game. And swiping for the other comment. For a long time, swiping was the only input method, D-pad and trackball were last minute add ons. I don't know what type of phone that user had and if it was a sensitivity issue or some real issue with my swiping algorithm on that phone.
Just knowing the average rating isn't quite enough for me. I don't know how many 3 star ratings there are. Are the ratings a bell-curve or an inverse bell-curve. Maybe they are mostly 1 and 5 star reviews, without many who rate it "ok."
If the ratings are a bell-curve, the game simply needs to be improved to shift the curve to the right to create a better game. If it is an inverse bell-curve, I need to figure out how to make it work for the 1 star reviews. Reduce the low-rating spike and the rating will jump to the right where the real bell should be. And this is a legitimate assumption based on the few comments for Claustrum Lite.
I have already normalized touch sensitivity across different screen sizes, and my next update will have adjustable sensitivity. I improved the graphics a bit so the player will be easier to see and identify at the start of a game.
So my plan now is to improve the presentation of the game using propper game menus which may help users understand the gameplay better. Fix one "glitch" where you can grab ahold of the ball and throw it around the game area, which is a tool I used for testing and debugging collisions but forgot to remove before releasing. Then look for a few beta-testers that can help me identify what the "it doesn't work" errors may really be.
Sunday, January 17, 2010
v0.1 - initial release with basic gameplay.
v0.1.1 - quick update to support Android 1.5
- Added a few graphics to replace basic circles.
- Scaled sizes and speeds based on screen resolution - I develop mostly on a Droid and the objects were much bigger and faster on smaller resolutions, I fixed that.
- Increased touchscreen sensitivity on smaller screens.
- More graphics enhancements
- Player no longer cut in half when on edge of game arena.
- Better drawing of the Header.
- Adjustable touchscreen sensitivity.
- Propper game menu system(still no game save or resume).
- Removed an old "cheat" where you could grab the red ball and "throw" it around the screen. I used this for testing collisions. I hope this is the cause of some of the errors.
- Better UI between levels and at end game.
- Save and restore game.
- Polygon behavior update(player no longer stops on straight portions of the polygon, that used to be corners)
- New Title Image and cleaner menus.
- No restoring a game(to last menu button press) after dying.
- Pause on restore game, resume from phone call, resume from sleep.
- Better dialog handling.
- Added a little depth to drawing the arena
- Border enemies. When, how fast, and how many per level isn't decided yet, but they work. Currently 0 on level 1, 1 on level 2, and 2 on all other levels.
- Fixed to run on 1.6 QVGA devices(Tattoo).
- New scoring function that rewards larger captures.
- Option for "Casual" or "Intense" game. Currently only difference is that border enemies appear in the intense game. The Casual game gives total safety while the player is on the border.
- Double-tap to use speed bonus(boost). Optional, turn it on in the settings. Only activates while out in the area, still can click on the header to ready for next entry though.
- Player instantly looses invincibility after a death once they leave the border.
- Prevent unrecoverable suicides. If the rachman is 1 unit away from his tail, you cannot turn him towards it. This prevents the dreaded U-Turn suicide where you were likely to over-turn back into the rachman's tail.
Ready For Next Version
- Better respawning of border enemies to make more than 2 possible.
- Eliminated the need for new collision management system.
- Continued graphics enhancements.
- Fix header on QVGA devices.
- Fix some in-game jitters from java garbage collection.
- More advanced interior enemies.
- Level setup. Enemy type, count, and speed/skill for each level.
- Fix a few polygon bugs with the outer border
- Save high scores / Finalize scoring system
Saturday, January 16, 2010
Better touch sensitivity for different devices
- More intelligent area enemies.
- Improved graphics
- Better collision manager so more enemies can be added
Border Enemies that can kill your player on the 'safety' of the edge
- Finalize scoring system.
Menu system, the current one is a total hack job to get the app to market