Jump n Run with a Worms like World

Java 2D
#1

Yes, thats it. I want to make a jump n run style game, with a world like Worms, where you can destroy every pixel of the landscape.

I am facing 2 problems:

  1. Storing the world. Worms seem to used a bitmap or graphic and operate on a pixel level. I did the same in a test, I use a BufferedImage and
    work with pixels and alpha. But worms has a limited map of maybe 800x600 or less pixels. A jump n run would be several screens wide, I cannot store this in memory, its like 3000 x 600 pixel and more.

I thought about making the world into slices of 200-400 pixels width and I need to do some extra work to operate over the borders of a slice. When I have an explosion on the border, I need to manipulate the current slice and the adjacent one. But its possible to handle that. I must restrict “going back” or “going left” in that case, so you cannot return to areas where you have already been, because I have to delete the Images I left behind to get memory free.

Do you have any good ideas how to manage a wide level which can be manipulated on a pixel level?

  1. When the player destroys the landscape with explosions, he might create a gap or hole to wide and deep to continue his way. The player can trap himself by creating unpassable gabs and such. I have 3 ideas so far
    a) Some sort of climbing to get out of anything
    b) Some sort of terrain changing weapon with unlimited “ammo” It can be used to create a ramp or stairs to get out of a hole.
    c) Some sort of pixel physics. To make “loose” pixels fall down or to the side, so that they always form a slope of 45° which the player can master. I would use an algorithm which checks whether a pixel is free in the air and then make it fall. This works well for terrain but makes trouble with objects. A tree for example would have pixels hanging in the air, and I want them to stay there as long as the tree is not destroyed.

Do you have ideas? What would you like most? Worms had tools like drills and bungee ropes, which is category a. I just dont like this for a jump n run.
Version c is my gameplay favorite, but makes some trouble to decide when I want pixels to move / fall and when I want them to stay in place. And I cannot hold additional information besides the Image because I do not know if and where in the image a special object like a tree is.

-JAW

#2

as far as the “going back” problem, you can handle this by just remembering where the deleted pixels are. you can do this in two ways:

  1. store in a hashmap every “event” that took a pixel out (i.e. a bullet at a specific angle and speed) and recalculate the holes when you re-create the Image.

  2. simply store all deleted pixels into a HashMap


deadPix.put("124","320"); // there is now a dead pixel at 124x320

// later on, when its time to reload the image..
Iterator keySet = deadPix.keySet().iterator();
while (keySet.hasNext()) {
  String x = (String)keySet.next();
  String y = (String)deadPix.get(x);
  image.setRGB(Integer.parseInt(x),Integer.parseInt(y),0x00000000);
}

pretty ugly, but it would work

#3

I’m not sure what this is about but are you making this game for J2ME or something? Because if not I’m not sure I understand why you think that 3000x600 pixels is a lot? 3000x600 = 1800000 pixels, let’s say 16 bits per pixel is enough which would give us 1800000 x 16 = 28800000 bits = 3,4MB of memory that you would need to store something like that. That’s not a lot, is it?

#4

agreed to storing the entire bitmap. It shouldn’t take that much memory. How would you store the levels on disk, anyway?!

About “getting trapped”: I don’t it’s a very big problem. If some weapon of the player caused a gap, he can re-use that weapon to shoot his way out, can’t he?

Personally, I like the idea of a grapple weapon. Some Worms games had something similar: a rope with a hook you could shoot into some overhanging pixels. Quake has made grappling into an art. If you build your levels around the concept of a grapply, you’ll have made a jump’n run game with a very distinct feel. Someone who masters the grapple very well, can probably get through the levels much faster than someone who’s just running.

#5

Please, please don’t do this. There are so many things wrong, conceptually and in the sample implementation, with this that I half suspect it’s an elaborate joke that I’m just not getting.

#6

Personally I’d store the terrain and the objects separately. Terrain would be pixel-y and have various properties (like some of it being sand-like and flows) and objects like trees would be destroyed in a more conventional manner (possibly breaking into into smaller chunks which bounce around the map).

Then I’d say go with short and fast levels with (say) a 30 second time limit. If you really do manage to get trapped then you simply restart the level and try again.

I did a pixel-y sand/water/terrain thing not too long ago, with simple-ish logic. It’s not too difficult to get sand behaviour, but it can get quite heavy on the cpu to update the whole map. You probably want some kind of dirty rect scheme where you’re only updating portions of the map that you know to be unstable (ie. the bits which have just been hit with a weapon).

#7

Thanks for the replies.

Well about image size. I dont know, it really is only 5 to 10 MB… I once made something with relativ moderate sizes, a BufferedImage 4000x4000 and it made a heap overflow. Well, I will just start with 3000 to 6000 width Images and see if he can handle it. I’ll come up with something else if it fails. Why bother now?

Yes, I will only operate on rectangular areas. In my test I used BufferedImage and WriteableRaster, which has a getPixels function. You can specifiy x,y,width,height for that one and manipulate only that area. I will keep a “dirty region” information, or some event / trigger based mechanism to decide where I have to do something.

My problem with getting trapped is just ammo. If the player uses maybe 2 rockets and creates a gap, I dont want him to waste 2 or 3 rocketes just to make the area passable for him. He might run out of ammo and then he is stuck. A grapplie sounds nice, but I will have to consider if the player can exploit it to move around the level.

For objects like trees, I made up an idea. Every pixel must have a connection to the ground, in order to stay in place. If a pixel hangs free in the air, ie it has no connection to the ground, it falls. I will use a “sand” mechanism. As Algorithm: If a pixel is not connected to the ground by any other pixel next to him, he is free. If a free pixel has no pixel below, it falls down. If a free pixel has a pixel below, but not diagonal downwards, it falls diagonal to the side, where no pixel is. In other words, i always have a pyramid, each pixel needs 3 pixels below in order to stay in place. One down, one down left, one down right. If any of thos are not there, it falls to that position. It always falls left first, because the player comes from left.

To keep Images limited, a level will be made of several Images (scenes). You leave one to the right side and enter the next one. You cannot go back to previous scenes, but you can move freely within an Image.

Question: Anyone knows the best way to handle the Image and pixel modification? Is BufferedImage and WriteableRaster a wise choice? I’d use one BI for the level, setting Alpha for destroyed pixels. I will probably keep a list of freely moving pixels to know which ones I must move. As soon as they find ground, they return to be fixed pixels until another event happens.

Sadly, I have not time to develop all this right now. It will take some month until I can really start this project. I just want to check, if its worth beginning at all.

-JAW

#8

All I know is that 4000x4000 image is huge…
that’s 4000x4000x4 = ~64MB … that x4 is ARGB (values are stored as inside 32bit, 8 bit per value). I never worked with pallete type images, but it would be very smaller if you use that… still a minimum of ~16MB if it uses 1 byte pallete value + pallete itself.

EDIT: by pallete I mean color indexing

#9

Use a cell approach, where each cell is about a quarter of a screenful. Assuming you can recreate each cell on demand, just use a simple bitmap (1’s and 0’s dictate active and inactive pixels) to store the the modifications. That’s eight pixels per byte rather than 1/4th a pixel per byte. An entire 800x600 screen could be stored for about 60k. This could be futher improved by storing only the scanlines affected and using an RLE compression scheme. If you want to do pixel manipulation beyond that, like your sand mechanism, you’re better off just saving each cell as a pixel map and caching them out to the harddrive when they aren’t on screen.