Tomorrow I go to cuba for two weeks. I'm bringing my brand new Eee 901 to possibly get some coding done on the flight.. and I'm working on this:

MEG4kMAN, an extremely tiny version of Mega Man.It's 1612 bytes so far, and that includes a spectrum graphics like renderer with a single 8x8 1 bit bitmap per tile, with a 5 bit color (r, g, b, intensity, x flip) per tile.

Very impressive, but short. How much space does a screen take you? If it's a lot you could use some procedural levels to cut size and make it a lot longer.

If you're interested in trying that, the obvious algorithm is to just make a row of platforms at random heights, with none raising higher than the character can jump. This can be done in a really simple loop (for x, if x > width: width+=random, for y, if y > height: fill) so it should be pretty small. Put an enemy every few platforms and whatnot. But that's the most boring algorithm you could use, as well.

I feel that your most interesting screens are the 2nd and 3rd ones. There's an old roguelike algorithm that you should be able to modify to come up with something like these. In it, you divide the screen randomly, adding a door between the halves, then divide the halves each randomly, adding a door, and so forth. I'm not sure how you'd modify this to be non-recursive, mind you, so fitting it in the space could be tough.

Right now, the game is at just over 3kb, and each screen I add is another 300 bytes of raw data that seems to compress down to about 30 bytes per screen. With some additional trickery, I should be able to get the levels down to about 90 raw bytes per screen, but I'm not sure that would compress any better.I figure I can get about 30 screens of hard coded levels in there. I'm shooting for a Mega Man 9 type experience where the game is bloody hard but speed run friendly.

Since I'm going pretty much the opposite direction of my normal design here (no procedural content, and making a demake of an existing game), I'm tempted not to do any randomly generated levels in this one. =D

Highest priority right now is adding a satisfying death animation in as few bytes as possible. Any ideas?

The graphics are 1 bit per pixel graphics, made up of 8x8 pixel blocks that each have a color (0-15, think EGA) and a x flip bit. Each 8x8 pixel chunk of graphics takes up 8 bytes of raw data, and the sprite sheet is 9x7 tiles, for a total of 504 bytes of raw data (not counting extra bytes used in UTF-8 encoding).

Whenever you leave a screen to the right or down, you move to the next screen, whenever you leave up or left, you move to the previous. That's why it crashes when you jump after dying (I need to remember to set onGround to false), it tries to change to screen -1.

Each tile in a level contains 2x2 tiles of graphics, and the mega man character is usually 3x4 tiles of graphics (more when jumping or hurt).

Right now, the game is at just over 3kb, and each screen I add is another 300 bytes of raw data that seems to compress down to about 30 bytes per screen. With some additional trickery, I should be able to get the levels down to about 90 raw bytes per screen, but I'm not sure that would compress any better.I figure I can get about 30 screens of hard coded levels in there. I'm shooting for a Mega Man 9 type experience where the game is bloody hard but speed run friendly.

Since I'm going pretty much the opposite direction of my normal design here (no procedural content, and making a demake of an existing game), I'm tempted not to do any randomly generated levels in this one. =D

Highest priority right now is adding a satisfying death animation in as few bytes as possible. Any ideas?

Shift (on Kongregate, in the Puzzles section) has a death animation which wouldn't take many bytes, but it doesn't really fit your graphical style.

perhaps you would make a decent space saving by directly embedding the byte data into the class file as an Attribute post proguard/etc optimisation?

It had saved me a significant amount of space with my 2007 entry SubPar.

you can use the undocumented "-addData <file>" of the 4KJO tool's command line options to insert the data file into the class file. Have a look at the source of my entry as to how i read in the embedded data. (My data did have a unique magic number sequence at the beginning of two bytes equal to "||".

Mookie, did you compare doing it that way with just having the file as a separate entry in the .jar? I find it slightly surprising that the extra bytes required to put "a.class" in the constant pool (vs using "a", which is already in the constant pool), skip past everything you don't want, and label the attribute don't more than cancel out the extra bytes required for a second zip entry.

Mookie, did you compare doing it that way with just having the file as a separate entry in the .jar? I find it slightly surprising that the extra bytes required to put "a.class" in the constant pool (vs using "a", which is already in the constant pool), skip past everything you don't want, and label the attribute don't more than cancel out the extra bytes required for a second zip entry.

For my game i compared it against a separate entry in the JAR and against encoding the data in a string.

It saved about 80 bytes if i recall correctly when compared against a separate entry.

I liked it a lot. one thing i dont get is how the heck did you make it only 3kb I have an asteroid field game that is a lot simpler and it is over 12! only reason I didnt beat it in 30 seconds was cause of the whole jumpingwhen you die thing. and there are a lot of spikes

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org