Cherry Chaser slot machine is now available on the Android Market:
https://market.android.com/details?id=net.exobyte.cherrychaser
https://market.android.com/details?id=net.exobyte.cherrychaser
Cherry Chaser has now been uploaded to the Android Market. Interesting process, learnt a bit about signing APK files with my own certificate and that the Android Market requires a 512x512 application icon. I wasn't quite prepared for that so I've just used the standard game icon for the moment until I can create something better. I'm still waiting for the app to appear on the market itself, hopefully it will be on there by tomorrow. Looking at the vast number of slot machine games there I'm not expecting much. I think to get anywhere in the Android Market these days will require either an exciting and unique game or a strong marketing campaign. I've decided to launch Cherry Chaser slot machine on to the Android market in its current state. I had plans to add some features such as multi-currency support and the ability to save the game state over multiple sessions before releasing it. I've changed my mind based upon the philosophy of releasing early and iterating quickly. These added features can easily be added in future updates to the app. I think it is much better to get the app out there where people can use it and start getting feedback. I added a feature yesterday to make particles pop out of the buttons as the player presses them. I showed it to Jen this morning and her advice was that it didn't look very good and it was unnecessary. Looking again with objective eyes I agree with her. This means that some of the work I did yesterday to add the feature is wasted but sometimes you have to try things just to find out that they do not work. Anyway the hardest bits of code I wrote can almost certainly be used later so all is not lost. I'm now adding adverts to the game using the Admob advert service from Google. This will be a little experiment as my first game with adverts to see if it generates any revenue. The original Cherry Chaser game I wrote for Windows Mobile had 60,000+ downloads as a freeware app, that was back in the days when the mobile market was much smaller. Against that, the number of apps relative to the size of the market these days is probably even higher than then, so hopefully my app won't get lost in the masses. I've completed all the programming on the game code now and everything all seems to work well. That means I'm about half way through the development process by my reckoning. Things still to do include: Nice animations for jackpots and easter eggs. More interesting animation of lights during game. Help and credits screens. Game options screen. Support for multiple currencies. Storage of persistent data on game close. Adverts for free version. Animated cash win tray for premium version. Then there is also a lot of testing and bug fixing before I can upload it to the market. As part of the job of porting Cherry Chaser to Android I want to make a number of improvements to the game. One feature that I felt needed improvement was how the nudge feature worked. In the Windows Mobile version of the game you would win nudges and then nudge the reels manually using the buttons beneath each reel. There was no facility to nudge upwards and visibility is limited to only the fruit directly above the winline. That meant that it was very difficult to get a decent win with nudges. In Cherry Chaser for Android I've just implemented an auto-nudge feature that will entirely replace manual nudges. Once the amount of nudges awarded has been established the machine looks for the best possible win attainable with those nudges and then performs the nudges automatically. I've now got all the cash win and credit functionality working and Cherry Chaser is slowly turning into a playable game. The gamble feature is also in place although I need to alter the timing code to make it independent of processor speed. I've also put in vibration feedback as each of the reels stop which feels really nice. I've now "wired up" all of the lights that can flash on and off on the main play area of Cherry Chaser. This was one of the most laborious tasks that needed to be done and involved carefully measuring the location and size of each part of the screen that could be independently lit up. In all the main screen is composed of 62 lights all of which can now flash on and off. I'm finding some interesting challenges porting my Windows Mobile games, that were all developed in C++, to using java on Android. It's very handy that the syntax is largely the same but there are quite a few things about java that bug me. If I came from java to C++ I'm sure I'd be even more distressed, or even horrified. I have to admit that I am not too fussy about type safe data types and I find the convenience of being allowed to be somewhat reckless with my data in C++ makes up for any extra debugging required. As Cherry Chaser is a port of the C++ version I'm shoehorning a C++ style on to my java programming. One particular area where I'm doing things in a non java way is in the use of enum types. Cherry Chaser enumerates lots of things from the game state to what the names of all the lights are. At the moment I'm using enums very much as I would in C++ and using the ordinal values far more than I probably should. For example my array of lights is indexed by an enum type. Reprogramming to use an enummap would be more appropriate but that would mean rewriting quite a lot of code. Recently I've been doing a lot of work on the graphics for Cherry Chaser, making them more suitable for the high resolution displays on most Android phones. I've just about completed my texture atlas ready for use in the game.  The main issue I have is that to make the animation of the reels simple I need the entire reel in a contiguous region in the atlas. This means the atlas needs to be at least 1024 pixels deep. That's not a problem on better phones but on low end phones having a texture over 512 pixels degrades performance considerably. The other side effect is that I have quite a lot of spare texture space so I've laid out the rest of my graphics with a view to ease of mapping rather than squeezing them tightly together. I have "lights off" and "lights on" versions of the main screen and I switch lit up regions between each as necessary. The game will also feature three currencies, pounds, dollars and euros, so I have spare parts of the texture atlas assigned to hold graphics for the alternative currencies. In terms of programming I have implemented two important features which will help the game to run well across the varied range of Android devices that are out there. The first is screen resolution independence. No matter what sized screen the device has the game will stretch or shrink itself to fit. The other feature is frame rate independence. The reels now spin at a fixed number of pixels per second. That can be important on low end devices where the frame rate is more prone to stuttering. Now my code is working I've taken another big step forward and got the game running on my physical device rather than in an emulator. It's a lot easier to set up debugging on a device than I was expecting. It did break when I upgraded my Hero using the new Android 2.1 OTA update, but reinstalling HTC Sync fixed it. So now I have Plasma Duel running on my phone. You can't do much yet apart from move paddles around the screen, but from now on progress should happen a bit quicker. I've spent a few days now trying to get a very bare minimum framework for the game started. As is my manner I coded a fair amount of the setup stage of the game before I attempted to run it. Of course it crashed as I mentioned in my last post. To debug that crash I gradually commented out more and more code until all I had left in the project was the engine setup code and an instruction to put a single sprite on the screen. It still didn't work. There was a lot of head scratching, researching of the Eclipse debugging tools and general background reading in search of a solution. No matter what I did, nothing showed up on the screen when the game was executed. I finally found the problem. In my code I referred to a subdirectory called "textures" and on disk that folder was named "Textures". The hardest to find problems are often the simplest ones. On a positive note I'm now a lot more comfortable with debugging using Eclipse. |
RSS Feed