SubPar (shooter in the making)

Contests 4K Game Competition - 2007
#1

*** UPDATED 08-02-2007 ***
http://www.java-gaming.org/forums/index.php?topic=15776.msg126194#msg126194

I have been experimenting with a new system to stucture images and embedd them directly into a class file by means of a custom ‘attribute’.

http://javaunlimited.net/hosted/moogie/test.jnlp
(use keyboard to move around… reloading with start you in another ship)
Please let me know if it
a) does not work for you
b) has bizarre behaviour (i.e. choppy then smooth)

It has been an interesting challenge but i have been successful, there are a couple more ideas for optimisations I want to try however it is at a point where it is giving significant dividends.

The main idea for my image storage is that there are likely to me gradients in an image and so by ordering the colour index of an image so that like colours are ‘near’ eachother then the indecies of the actual image to be stored will likewise be ‘near’ to eachother. So instead of recording the actual corresponding index for each pixel of the image, i instead record a delta. This delta will is always positive. Delta’s which bring the index over the number of colours will cause the resultant index to be wrapped. This mechanism was chosen over the more intuitive negative and posive deltas as it was found that the implementation code need to read the image back was less expensive when using the wrapped positive delta mechanism.

This also means that multiple images with different colour counts and indecies will have a similar looking output allowing for better compression using the a deflate compressor.

There are some other tricks used in this test game to get it under the 4k limit ( I do not record the dimensions of the graphics or some other control flags in the image data as the image dimension data is read seperatly and the image is assumed to have a transparent colour. The more general version of the image format contains this information in the header.)

So for this test the following image:

is optimally compressed by pngout to 2580 bytes (plus the extra overhead of creating a “whole” image by flipping and drawing multiple times)

my current scheme brings it down to : 2020 bytes after compression using kzip. (also due to the nature of reading of the format, the whole image can be created in a single pass reducing the expense to recreate the images)

The shooter ‘SubPar’ will probably either remove sprites or I will need to reduce the colour count in order to fit in some game logic. I have a couple of ideas which may reduce the number of bytes needed with out loss of quality however I do not think that it will be sufficent. The first is make the image format more readily compressable by placing all the individual image ‘headers’ at the front to make a super header and thus having all the compressable data in one complete block. (this is do-able due to the fact that I know the sizes of the images before hand. The second idea is to attempt permuations of the ordering of the constant pool and other components of the classfile. This will probably not gain me much but every byte counts :stuck_out_tongue:

#2

Wow! Fantastic work! Really smooth on my rig.

-Chris

#3

Nice ships. I seriously doubt you’ll be able to make a workable game with that :slight_smile:

#4

Thanks :slight_smile:

The ships are from ‘free’ sprites i have found on the web.

I am hoping that I can get away with 400 bytes of game logic and some how reducing the sprites’ byte requriment.

Ideally I would have liked to have it fullscreen as it really adds to the experience but it is probably a luxury that cannot be afforded.

#5

I have saved further bytes by:

  • having at most 8 colours per sprite (i previously had 9 colours) this has had very little impact on the quality of the images thankfully.
  • reordering the sprite storage order
  • making the game now a vertical shooter (not 360 degree)
  • multiple miscelaneous optimisations

And so I have saved a further 211 bytes :slight_smile:

the latest: http://javaunlimited.net/hosted/moogie/test1.jnlp

I have a non-executable jar version which is full screen and thanks to the saved bytes likewise fits under the 4K limit… however with signing It is over the 4k limit :frowning:

fullscreen version: http://javaunlimited.net/hosted/moogie/test_full.jar

next step is to introduce enemy behavior…

#6

Some progress :slight_smile:

-have added preliminary projectile fire (both the players and the enemy ships)
-added pixel perfect collision for projectiles
-added and removed some graphics

To do:

  • add different ship movemnt patterns
  • add “levels” (not sure if it will be random or scripted)
  • add different projectiles/weapons
  • add power ups

latest can be found : http://javaunlimited.net/hosted/moogie/test2.jnlp

#7

hmm… just tested the test2 version… some interesting behaviour with ships dissappearing… i think it is related to array index overruns.

#8

Hi,

it’s not working with java 1.4 on mac OS (uses System.nanoTime() which is available since java 5)

Lilian :slight_smile:

#9

ah good point.

using nanotimer freed up a couple of bytes… i will put it back to the getcurrentTime method and sacrifice the bytes so that my mac brothers can play :).

#10

well, don’t forget the 4k contest rules specifies java 5, not 1.4…

you could also do like everybody else : put a 1.5+ in your jnlp file (I don’t care, I’ve got another mac with java 5 ;D)

Lilian :slight_smile:

#11

well it was only a couple of bytes so unless i desperately need it leaving it using the older methods should be fine. (i currently have a budget of approx 130 bytes spare)

#12

Update :slight_smile:

http://javaunlimited.net/hosted/moogie/test3.jnlp

I have only had a little time to devote to my j4k game but the concept is stable and this latest version is the one which will evolve into the finished game.

In this version:

  • there are now ‘waves’ of enemies which will progressivily get harder. (probably too hard learning curve at the moment)
  • (Starts at wave 5 to give medium difficultly start point :stuck_out_tongue: )
  • 9 sprites each with 5 different colours giving 45 sprites :slight_smile:
  • two attack ship moment patterns (spread and single file)
  • 15 waves of attack
  • enemies initally spawn only at the top of the screen but will spawn progressively around the other sides as the waves continue
  • enemies initally fly poorly toward you to begin with but will progressively get better aim at the waves continue
  • enemies initally only attack with 1 or two ships in a sortie, but will progressively attack with more per sortie.

Still to do:

  • POWER UPS :slight_smile:
  • implement enemies health rating (i.e. how many shots to kill an enemy)
  • add more movment behaviours (e.g. sine wave, random walk, homing, etc)
  • add different enemy fire (e.g. missles)
  • change movment behaviours to be based on the type of ship.
  • sound?

I have removed some un needed sprites and performed some other optimisations and now I have 416 bytes left to use so i hope to be able to put in most of my to do list.

Can people let me know if this version works with 1.4 and is stable? Can a Mac user and a Linux user let me know whether there is any interesting behaviours?

Cheers

Nick