Exobyte Smartphone Games
  • Home
  • Articles
  • Contact
  • About
  • app-ads

A nudge in the right direction

7/6/2011

0 Comments

 
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.
0 Comments

Roll the credits

6/28/2011

0 Comments

 
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.
0 Comments

Illumination and enumeration

6/2/2011

0 Comments

 
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.

0 Comments

Moving towards independence

5/26/2011

1 Comment

 
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.
Picture
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.
1 Comment

First milestone

7/30/2010

0 Comments

 
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. 
0 Comments

Reaching the starting line

7/28/2010

0 Comments

 
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.

0 Comments

Bricks and bats

7/25/2010

1 Comment

 
This session I attempted to get my bricks and bats displaying on the screen.  Bricks are arranged in 2 walls, each wall consisting of five rows of six bricks.  The fifth row being elevated some distance above the player's paddle to create an obstacle between the two player's paddles.  Not all the bricks will be present depending upon which level is loaded but for now I am trying to display every brick.

The paddles should (theoretically) be quite simple to display, just draw their sprite on the screen in the right location.  I didn't set things up quite so simply in my C++ version of the game however.  A paddle can expand, shrink and grow lasers, the sprite is made up of not one but up to 9 different texture parts because of this.  I'm attempting to reproduce this method in the java Android version.  I will find out whether it works once I can get it running.

1 Comment

Plasma Duel - Based on the LibGDX Engine

7/22/2010

0 Comments

 
The outcome of my game engine deliberations is that I have decided to use LibGDX.  It's probably the best known Android game engine and has a nice community in its forums.  The developer is very active as well and open to suggestions.  That could be very useful in future.

I had a short coding session today in which I set up my library code stub and then created classes for my paddles and bricks.  Paddles are based upon a sprite class and bricks based upon a basic texture class.  Next step is to load some textures and draw them in on the screen.  Luckily I already have most of the texture assets I will need from the Windows Mobile version of Plasma Duel.
0 Comments

Plasma Duel for Android - Choosing a game engine

7/19/2010

0 Comments

 
I started the the development process by reading up on the various game engine libraries that exist for the operating system.  There are not many to choose from, three or four possibilities.  I also had the option of creating my own engine but that's not really my area of expertise and I hate reinventing the wheel.  The other reason for using a ready made game engine is that it can provide me with access to OpenGL without having to do the coding myself.

In the end I'm using LibGDX, it's a nice library with a great community and even has a fair bit of documentation.

Earlier journal entries can be found in my "Nova Dawn Development Journal" which is separated from this journal as its focus is on game development for the Windows Mobile platform.

Continue to Nova Dawn Development Journal
0 Comments
Forward>>
     
    Regular updates on twitter

    Development
    Journal

    Archives

    October 2024
    January 2022
    October 2021
    August 2020
    February 2020
    March 2019
    October 2017
    September 2017
    May 2017
    February 2015
    February 2014
    January 2014
    November 2013
    August 2013
    July 2013
    June 2013
    February 2013
    October 2012
    August 2012
    June 2012
    March 2012
    February 2012
    January 2012
    July 2011
    June 2011
    May 2011
    July 2010

    Categories

    All
    Advertising
    Cherry Chaser
    Libgdx
    Plasma Duel
    Super Snake

    RSS Feed

Privacy Policy
Terms and Conditions


​All content copyright Exobyte Ltd 2012-2024