Kana Invaders 4k

Traditional gameplay with an educational twist. Each alien is a japanese hiragana, which can only be destroyed by a matching bullet. Select the bullet type by typing the romaji equivalent.

Play Kana Invaders 4k

Controls

Move Player: Cursor Keys
Fire Weapon: Space Bar
Select Weapon: Type Romaji
Start Game: Enter Key

I know this is a bit of a niche game :smiley:
This might come in useful :slight_smile:

Notes:

  • OS X bug workarounds incorporated 28/1/2006

Oh noes! 500 internal server error :-\

Thereā€™s been a server upgrade. All my webstart stuff is currently broken :frowning: Will look at this this evening

/Edit: Had to modify my .htaccess files, but all should be working now

Good game!
But, why not simply firing when the romaji is typed?
to fire a, just press a; to fire shyo ~ sho, just type it and go!
Itā€™s a bit difficult to type and aim at the same time.

   Rafael.-

nice game :slight_smile:
I worked out the first 5 characters by simply trying.
For the others I had to use your dictionary-link to get an idea of how to do this.
*never knew anything about japanese letters - now I do :wink:

it gets a bit boring for later levels, because itā€™s simply always
o e u i a
with only different consonants before - and you even get those with using that page :wink:

Or does this change for later levels - Iā€™ve never got that far - ā€˜neā€™ was my highest -
but I think with some more playing I would get better :wink:

you could also let the letters that come in the level pop up before the level starts for e.g. 5 sec, so people see them before playing, which might result in better remembering and more positve results while playing.
In the end I only worked down the combination and actually didnā€™t pay any attention to the letters.

Glad you like it. You can hold the space bar down for continuous firing, which may help :slight_smile:

Alan

It doesnā€™t really get harder because otherwise the player would not get to practice the hiragana on the higher levels much.

Itā€™s a good idea, but including 47 bitmaps in the 4k has left me a bit pushed for space. Perhaps, if I can crunch things a bit more.

Alan

good game, fun, I play it a lot severals years ago!! on an Atari 2600. ( nostagly :ā€™( : http://www.twitchguru.com/2005/08/20/when_movie_tie/index.html)

Bruno

[quote=ā€œAlan_W,post:7,topic:25535ā€]
You should SuperPack it. Used correctly in cunjunction with 7Zip, I guarantee that it will reduce the size of your program. :slight_smile:

Iā€™ll take a look at doing that (or something similar) this coming weekend. Currently, all the images are in a single 1bit depth png with transparency. Several tools were tried to shrink that png; pngcrush was the most effective by a good margin. However the resultant file is only about 50% of the size of the raw bits, so it should be possible to do better by inserting the data as strings or longs into the main class. Hopfully netbeans is up to the task. I managed to crash it by pasting in an entire music track as ā€˜longsā€™ on a single line. It was ok as a number of shorter lines. Not that thereā€™s been room for sound in anything produced yet.

I also need to investigate why the ships are invisible on OS X. Either the images are not loading, or more likely, thereā€™s a compositing problem. First invisible monsters, then invisible cars (both now fixed) and now invisible aliens. Maybe I should write a game where invisibility is part of the gameplay, since it appears (sic) to be so easy ;D

Alan

The problem with using long arrays is that Java creates a constant index for each of those values, then creates a load instruction at the beginning of the program for each element of the array. Java arrays are a lousy way to keep your size down. :frowning:

[quote]I also need to investigate why the ships are invisible on OS X. Either the images are not loading, or more likely, thereā€™s a compositing problem. First invisible monsters, then invisible cars (both now fixed) and now invisible aliens. Maybe I should write a game where invisibility is part of the gameplay, since it appears (sic) to be so easy ;D
[/quote]
The SuperPackME decoder (see Decoder.java) is guaranteed to work on OS X. (It should, I developed it there!) The key is to use the GraphicsDevice.createCompatibleImage() call instead of specifying your own image format.

Here is a simple way I found to have simple images.


        colors['*'] = 0xFFFFFFFF; // white

        data          =("   ***   "+
                        " ******* "+
                        " ******* "+
                        "**  *  **"+
                        "**  *  **"+
                        "*********"+
                        "*** * ***"+
                        " ******* "+
                        " * * * * ").getBytes();


        for(int i = 0;i<data.length;i++)
        {
            image['K'].setRGB(i%9,i/9,colors[data[i]]);            
        }

Just draw the image using what ever characters you like. Try to use the same ones for all images so they compress well.
Then set the color of each character. No need to set the transparent character as it is 0 any way.

The simplicity of the creation of the image plus letting the zip utility do all the work of compressing seams to win. At least for my images. Donā€™t forget to change the 9 to match what ever image size you need.

The example image is the skull from my LadyBug game.

Thanks for the suggestion. Lots to try at the weekend now :slight_smile:

I had a look at the invisible ships problem and sadly found another bug in Apples java implementation (all versions)


drawImage(Image img, int dx1, int dy1, int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, Color bgcolor, ImageObserver observer) 

If the source and destination areas are the same size, i.e. no scaling is required, then the library treats it as a special case and renders it much faster. Unfortunately the special case code ignores the ā€˜bgcolorā€™ parameter and leaves the background colour unchanged.

To work around this problem either requires splitting the sprites up into separate images, allowing drawImage(img, x, y, color, null) to be used, which does work, or prefilling the background of each sprite with drawRect(x,y, width, height). The latter is a bit nasty, but might be possible.

/Edit: Nasty kludge incorporated to support OS X. Hopefully works on the Mac now.

Alan