Pocket Tanks ground

[bert]

I put this in the Game Logic area because it didn't really fit anywhere else. I'm trying to make a program that uses features similar to those in Pocket Tanks where the ground can be eroded or blasted away. I'm having problems figuring out how to keep track of where the ground is and where it isn't. I've tried vectors for the ground's surface, which is a nightmare to keep track of if a hole is blasted far underground, and I don't think a double-subscripted array would be the best because it would fill the memory with 800x600=480000 numbers to just hold the ground data. Another reason why I don't think the vectors would work is because you can see the layers of the earth moving and surface vectors would not be able to reproduce this accurately. With the double-subscripted array you can use an

int

array to represent each type of terrain. (Or you can use an object, but that would get messy real quick. (In my science class we're having a Pocket Tanks tournament because it's the end of the year. This frustrated me to no end when I could not replicate the ground moving around on my computer at home. I will find out on Monday if I've won the tournament.)

[Malohkan]

int[][] data = new int[800][600];  should work fine.  It's really not that big   You have to store that much info for an image that size anyway and that's no serious drain.  Just have each int represent a color and play with that.  Use a 0 or 255 alpha to know if something is there or not.  That way you can still use gravity and such to pull down pixels that don't have anything below them.

[CommanderKeith]

A harder method would be to let the ground be a polygon & blast chumks out of it using constructive area geometry (see Area & Shape classes).  This could be better since then you could have projectiles ricochet off the ground & also slide down the hill etc since you can work out gradients & angles.

Games published by our own members! Check 'em out!

[bert]

All right, Malohkan, you've convinced me. It'll work. The storing of the numbers wouldn't be too too bad, but drawing them to the screen would be a pixel-by-pixel ordeal. I've been trying an "optimizing" drawing method that only updates the pixels that have changed. Of course, I might just be afraid to do anything at all graphics intensive because my computer is a slug. (I filled it all up with free downloads and demos... I'll never do that again!) I could probably get away with total update on a better computer but I'm still going to only update the pixels that need it.
Oh, and CommanderKeith, to cause the projectiles to ricochet or roll, to find the slope you just have to use trig on the x and y coordinates of the topmost pixels to either side of the ground pixel where the projectile has hit.
Also, one last thing, I'm also creating a copy of this software in PocketC (www.orbworks.com) and running it on a Palm Pilot will take a lot of optimizing and stretching my luck. My company website is not up yet but when it is you'll be able to download either version. (I'm not selling this... it's just a little pet project of mine.)

[JAW]

I was interested in a WORMS clone and did some experiments. I used a BufferedImage and WriteableRaster to access the alpha date of an ARGB BufferedImage. You can easily set Pixels to visible or hidden. Then you just draw the BufferedImage to the screen. If pixels move, eg if they fall down, you can change the color values of a pixel at a certain position. Collisions are made on the Alpha information of the BufferedImage. If Alpha > 0 it is ground, so the worm stands, the rocket hits, etc.

As long as you have a limited Image size, like one screen, it would work. I am interested in a long jump and run like level, this is far too much for a single BufferedImage, I will need to make some Image loading on the fly.

Message is, try BufferedImage and you dont need per Pixel painting. You can access the Image Data as Array with the WriteableRaster. You get Image data as one dim Array, but convert it into a two dim array using the Image width to divide the data into lines of pixels.

-JAW

[CommanderKeith]

Oh, and CommanderKeith, to cause the projectiles to ricochet or roll, to find the slope you just have to use trig on the x and y coordinates of the topmost pixels to either side of the ground pixel where the projectile has hit.

But the pixels surrounding the one hit can only be left, right, above or below.... so there's only 4 angles possible, all multiples of 90 degrees.  Maybe worms gets over this by using the 2 nearest pixels to make an angle, giving more possible angles.  Using a path that has floating point coordinates solves this, but for a worms style game - that pixel-based design you have in mind sounds solid. 

I'm just wondering whether it is practical from a Java2D perspective since accessing pixels in an image breaks hardware acceleration so the rendering may be slow...

[BloodRain]

Using rectangles or circles would be easy , but unfortunatelly the fun part of the game is the perfect collision . The main problem is that I don't know yet to get the color of a particular pixel, but I will learn that. I think I will use polygon(with lots of points) collision . Is it faster ? My idea is to create a secondary program that is very slow (but it just doesn't matter because it will be used only in the developing of the game) that makes a polygon from a sprite.I mean some kind of bounding polygon. I'm not sure if I can do this but I will try. 10x again.

[Kova]

about modifying pixels in bufferedimage: http://www.java-gaming.org/forums/index.php?topic=14236.0