Here is a new entry http://elmkom.tripod.com/cgi-bin/l.pl it is a Lode Runner clone (first 4 levels).Use the arrow keys to move. Use , and . to dig. Escape to exit.Collect all the gold and reach the top to advance to the next level.Avoid the guards.

Plays great! Though I couldn't move up the ladder to switch from level 2 to 3 even though I had taken all the gold on the map. I also found it to be a tad bit to easy. Your AI would probably be harder if the enemies kept going up/down if they were on the same y-coordinate as you but couldn't close in on their x-coordinate.

Nice game! Some notes about it:- You need to collect all the gold to pass level?, but you must collect 1+gold_view_in_screen to pass level. Maybe by design but it's confuse.- If you are trapped in a dig you make you must diw when the wall reappears but the game hangs.- If you make 2 digs one after the other, a bad-boy fall in one of the digs and you fall in the other the game throws a java.lang.ArrayIndexOutOfBoundsException: 433.

Yes I should kill the player if they fall in a hole. (why are you falling in holes ) I will try to squeeze it in. If you reach the top and can't go to the next level it means that one the of the bad guys has some gold. You must trap him in a hole to make him give up the gold. Yes I had to keep the AI simple to get it in 4K. The algorithm is like this.

As you pointed out the try to close X is not smart. Do you have any suggestions on how to make it a bit smarter with out adding too much code.

I think carefully in the question:- The most effective way is to add some backtraking to search the best ladder to reach player. Probably from player so you solve all the directions of all the enemies in "one step". But, yes, this add some code. - Other solution: remember last lader used by each enemy and check if the level of the enemy continue bellow/above the level of player for some amount of time/ticks (or distance of player, or some sort of this). Then use another lader when search for the nearest lader. Not sure if this works.- One more solution: add areas to the map definition.Imagine you add 8 bits x cell. Each bit indicates an area in the map. So, you check the player cell and determines he is in the area 3 (3th bit set). Then you known the emeny must go to the lader that have a 3th bit in its cell to reach the player. This reduces the number of levels (but compression must do its job and finally the bytes diff must be minimal). Good luck

Thanks for the ideas. I have fixed the exception and now kill the player if he gets stuck in a hole. I have not yet had a chance to see if I can rework the AI. I would still appreciate if any one familiar with maze games has a good path finding algorithm for the enemy to find the player.

Are you sure you got all the gold. There are 6 sacs of gold on the first level. The top right guard normally picks up one of the sacs at the start of the game. You must trap him in a hole for him to give up the gold. An easy check is that your score if you have not been killed should be 600 to advance to the next level.

Yes it was one of my old favorites too. I actually have all 140 levels I just can't fit them all in. It takes about 70 bytes per level. I have tried many ways to compress the levels. But the best I have found is to not do any compression just store the level data as a string, one character per tile and let the compression do the work. This is a 416 byte string (26*16) that gets compressed to ~ 70 bytes. There are 10 unique characters in the string. So for example a level would look like this.

you could store the levels as compressed PNGs and parse those. I know I keep pointing to this example and need to update it, but it would be something similiar to this: http://woogley.net/misc/RisseN/ - yes, the code is very old

anyway just save the levels as PNGs, load them via ImageIO, and read each pixel on the image to get your level data. i.e. a red pixel (0xffff0000) could be a ladder piece, a blue pixel (0xff0000ff) could be a floor piece, etc ..

I haven't tested this method on a 4K game but it's worth a try. It might not work because I have heard inline Strings compress pretty decently, so it's a bit of a toss-up. If you don't mind me seeing the source I could help you write the method to do it. (woogley[at]gmail.com).

you could store the levels as compressed PNGs and parse those. I know I keep pointing to this example and need to update it, but it would be something similiar to this: http://woogley.net/misc/RisseN/ - yes, the code is very old

That would probably be far worse than the string method. Not only do you have the overhead of the PNG header, but you'll also be storing a lot more bits per value than is necessary. And the fact that the file will already be compressed will negatively impact the ZIP compression of the JAR file. Not to mention all the extra code that would be needed for decoding.

I think the solution he has right now is probably best. The only other possibility is to bit-pack the level, but I don't know if that wouldn't again defeat the compression.

A quick analysis suggests the following unique values in the map: "EGHX-P "

That's 7 possible values, meaning that the board could be packed into 26x16x3 bits. (1,248 bits total) Dividing by 8, we arrive at 156 bytes per level. Since he has so much empty space, the bit packed version may be highly compressable. Someone would have to run some tests to find out.

One optimization that can be done with both the String and the Bit Packed versions is to eliminate the arrays. Since you know that the level data is always 26x16, there's no reason to create a separate string for each level. Just pack all the data into a single super-string, then compute the offset for the level you wish to load. You should see decent savings uncompressed (fewer constant pool entries, less string string overhead, fewer array accesses, etc.), and even better savings compressed (the unbroken stream should be easier for the compressor to work with).

before you read this reply, just know I'm not familiar with bitpacking

anyway I read one of your posts (or maybe it was the wiki) about inline Strings compressing decently, so I tried it.

I've been these clouds as a background for my 4K game:

I figured I'd try the whole String thing, so I compressed it to this one String

however I found that just keeping the GIF instead saved more bytes than trying to inline the data inside the class file (17 bytes to be precise, so it was close). I have 3 image files and I tried inlining them all into my one class file - though it did compress pretty well, the JAR that simply used GIFs turned out to be smaller.

so, in my particular case, using images is smaller. it just goes to show you should try all possibilities.

something to note though, as I said before, I'm not familiar with bitpacking, so it is very possible that the String I made just isnt small enough. Do you know a better method to inline that image? do you have a tutorial for bitpacking? Im always open to learning something new

I figured I'd try the whole String thing, so I compressed it to this one String

I'm getting a 404 on those links. Are they uploaded yet?

Quote

however I found that just keeping the GIF instead saved more bytes than trying to inline the data inside the class file (17 bytes to be precise, so it was close). I have 3 image files and I tried inlining them all into my one class file - though it did compress pretty well, the JAR that simply used GIFs turned out to be smaller.

It's hard to say without knowing what data you're packing, but there are a few things I can say:

1. You're probably not reducing your information in any significant fashion. Just changing the format is no guarantee of better results.

2. Whenever you change your compression method, it's always important to include the decoder into the computations. When I use SuperPackME, I'm accepting a fairly hefty cost in the code for the image decoder, but I more than make up for it in the space saved in the images. I did some tests with oNyx's JetPack game last year and found that the low number of images he used combined with the low number of colors meant that SuperPack (not the ME version) would actually be larger.

Keep in mind that you're wrestling with the theory of information. If you don't fully understand how your data is stored, it can be difficult to further reduce it.

Quote

something to note though, as I said before, I'm not familiar with bitpacking, so it is very possible that the String I made just isnt small enough. Do you know a better method to inline that image? do you have a tutorial for bitpacking? Im always open to learning something new

Bitpacking is a simple concept. There are 8 bits in a byte, right? So let's say you have an image that only has two colors. If you store it as a PNG, the PNG will store 4 bytes (32 bits) per pixel. That's a lot of wasted space for only two values! But if you look at each bit as a color, then you can pack the image into 1 bit per pixel. Here's the results for a 320x200 pixel image:

Thanks for the input. I have already tried the bit packing route. But the added cost of the decode and the lose in the compresion ratio (once packed it no longer compresses as well) makes it worse off. The suggestion to put all the strings together is a good on. It could save a few bytes I will give it a try. It just looks like I can't beat the default compression. I also looked at trying to represent the data as a set of sparse arrays. For example the P character only apears once per level and the E and G only 4 to 5 times. So I thought I could just store there x y locations instead. But this also was not any better than the simple string method.

I have changed the levels to more challenging ones. You now need to think a bit more to solve the level. If you get stuck the 'a' key can be used to abort the player and start the level over. There is now also status at the bottom on how many bags of gold have been collected and how many remain. The guards feathers also change color if they have a bag of gold.

Let me know how the new version plays.

Ps. If java webstart does not load the new version just hit the link again. It needs two load attempts for me to get the new version.

Well I had a lot of fun with the other levels, and I was looking for something a little more challenging, but I think you went a bit far on "making you think" more. I can't get past the first level. That one should be the second or third, it's very difficult and it's easy to mess up such that the only option is to start over. If the other levels are like that it's ok, but the first should still be something of an introductory level. My opinion-ish anyway.

I've only been trying for about 5-10 minutes though, I'll see if I can figure this out...

As you pointed out the try to close X is not smart. Do you have any suggestions on how to make it a bit smarter with out adding too much code.

This is an easy change you could do which hopefully will improve things a bit:

if (crazyMode> 0){ crazyMode = crazyMode - 1 find nearest ladder or edge and climb up/climb down/jump down.}else{ If(player above) find nearest ladder and climb up if(player below find nearest ladder or edge to jump off if(player on same level) { if(possible to close in on X) close in on X // It is possible to come closer on the X-axis, so do it! else crazyMode = 100 + random(100) // It is not possible to come closer on the X-axis, switch to crazyMode for 100 to 199 steps. }}

It will stop the enemies from getting stuck which is the most important part. It's not a lot to change from your current code.

Well I had a lot of fun with the other levels, and I was looking for something a little more challenging, but I think you went a bit far on "making you think" more. I can't get past the first level. That one should be the second or third, it's very difficult and it's easy to mess up such that the only option is to start over. If the other levels are like that it's ok, but the first should still be something of an introductory level. My opinion-ish anyway.

I've only been trying for about 5-10 minutes though, I'll see if I can figure this out...

You may be right the new second level is eaiser than the first. I think I may take your suggestion and switch them around. The key to the first level is not letting the left most guards get the gold at the left bottom of the screen if he does there is no way to trap him to get the gold back. The guards alway try to follow you so stay above them untill you can safely jump down and get the gold before them. Any other guard that gets some gold can be traped. For instance if a guard falls in the hole with the gold at the top. Just dig away the block at the side of the hole and make the guard follow you into the hole (it won't look like a hole, but he will still get traped).

This is an easy change you could do which hopefully will improve things a bit:

if (crazyMode> 0){ crazyMode = crazyMode - 1 find nearest ladder or edge and climb up/climb down/jump down.}else{ If(player above) find nearest ladder and climb up if(player below find nearest ladder or edge to jump off if(player on same level) { if(possible to close in on X) close in on X // It is possible to come closer on the X-axis, so do it! else crazyMode = 100 + random(100) // It is not possible to come closer on the X-axis, switch to crazyMode for 100 to 199 steps. }}

It will stop the enemies from getting stuck which is the most important part. It's not a lot to change from your current code.

Thanks for the suggestion. Try the new version an see if you still think it needs tweeking. I have change the AI slightly. It is now like this.

If(player above) find nearest laderif(player below find nearest lader or edge to jump offif(player on same level) try to close X (even if it means falling off a lader or edge)

So now the guards don't get stuck. But they may look silly jumping off a short ladder only to reclimb it and jump off again in and endless loop if the player does not move. But the new levels keep you moving so this is not so noticable. I will see if I can fit you suggestion in and see if it makes an improvement. What will add some code is that since in crazyMode the guard is no longer following the player. I will have to remember if they were going up or down a ladder and to continue in the same direction. Also when they finish climbing a ladder. What will stop them from finding the same lader as it will be the closest and just climbing back down. Now that I think of it, won't your algorithm just make them climb up and down the same lader.

Well I tried the new 1st level and got beat up bad. One problem I noticed was in the empty square closest to the start with the gold bag. I fell in it, and none of the bots were smart enough to get up to me and chase me in, and I couldn't figure out a way to restart. So I smacked all of the keys in hoping of finding a restart key, no luck.

Well I tried the new 1st level and got beat up bad. One problem I noticed was in the empty square closest to the start with the gold bag. I fell in it, and none of the bots were smart enough to get up to me and chase me in, and I couldn't figure out a way to restart. So I smacked all of the keys in hoping of finding a restart key, no luck.

Quote

If you get stuck the 'a' key can be used to abort the player and start the level over.

Btw I figured out how to do the first level now. Actually I figured it out last night, just didn't make a post. After trying a couple strategies and not being able to win, I finally realized you could dig a hole while climbing a ladder. Big help.

Just had to add that you've done a great job with this one! I've always liked Lode Runner though.

Suggestion to add some sparkle: Make the background dark blue and have pixel stars scroll from right to left in the background (easily doable if you are using double buffering and are redrawing the entire screen on the backbuffer each time.). It was something I thought about adding to my Sokoban4k game but in the end I crammed in a couple of more levels instead.

I duno Donald, I think maybe you should cut maybe 4 or 5 levels and give us that extra sparkle Smiley you'd be surprised how little things like that can increase the likeability (if that's a word) Wink

Hm, you might be right. I guess no one will be disappointed if I decrease the number of levels from 95 to 85 anyway.

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