Destructible terrain
BlitzMax Forums/BlitzMax Programming/Destructible terrain
| ||
| I vaguely remember someone posting a project or code snippet involving randomly generated destructible terrain. I am interested in learning techniques for implementing this, similar to games like Scorched Earth and Worms. Is it possible to work this with a sprite engine, like sswift's? Can I use sprite physics and just re-capture images of the terrain, or is that a bad idea? This is new territory for me. Thanks, SpaceAce |
| ||
| Searched using scorched |
| ||
| Ah, there's a decent start, thanks. I'm interested in any other links or code anyone wants to share. SpaceAce |
| ||
| Other links? I also searched on... Destructable Destructible Worms which listed posts like this |
| ||
| I mean possibly outside of the Blitz forums. I don't necessarily need BlitzMax code. I am weak on the concepts, but I can adapt the information from other sources. SpaceAce |
| ||
| I am weak on the concepts, but I can adapt the information from other sources. You should learn how to use Google, instead of asking others to do your searching for you. |
| ||
| You can do some pretty cool destructable things using tile maps. Very easy to do and very fast. ;) |
| ||
| You should learn how to use Google, instead of asking others to do your searching for you. Thanks for the tip. I'm sorry the concept of sharing information flies so far above your head. Feel free to make your worthless snarky remarks elsewhere. You can do some pretty cool destructable things using tile maps. Very easy to do and very fast. ;) Yeah, it seems breaking the scene into chunks and manipulating alpha is a reasonably fast method. I'm leaning toward that, at the moment. SpaceAce |
| ||
| I think this used to be a matter of using a massive bitmap and cutting chunks out of it using index zero -- to this end, you'll probably find that the original Worms playfield is the same width as an Amiga hardware screen. The problem you've got now is that the old approach involves direct pixel work and there are elements of that which can be slow on modern 3d-oriented hardware. If you were thinking of using Blitz+ or B3D then you at least get 'proper' 2d buffers but reading pixels (for collision detection) might be a bit of a bottle-neck. If you were going to go with Max then you'll be wanting to master pixmaps -- remz is shit hot with them so you might want to ply him with booze or something. |
| ||
| You could also have a couple of textures positioned next to each other and do "render to texture" code to knock out terrain, etc. That would basically duplicate the bitmap method of worms. I also remember (ages ago) some discussions of this type of coding using tile maps on the older consoles. You could convert an entire bit map screen into tile maps which was cool. ;) |
| ||
| Thanks for the tip. I'm sorry the concept of sharing information flies so far above your head. Feel free to make your worthless snarky remarks elsewhere. If I already knew about this I would certainly share, but I will not be your search bot. |
| ||
| I also remember (ages ago) some discussions of this type of coding using tile maps on the older consoles. Probably because you had to, because they had tile-mapped displays. Outrun on the Master System -- a *racer* of all things -- was tile-mapped too, but you'd never decide to write a driving game that way today because the hardware isn't forcing you into that methodology. If the comparatively gargantuan memory capacity, clock cycles and gfx buffer bandwidth of modern computers mean you don't have to tile-map then, really, don't -- it's going to add a whole layer of complexity that you can well do without. More here. |
| ||
| I did a google search on 2D destructable terrain technique 2D destructible terrain technique which returned lots of good results including, among others, this Thanks for the tip. I'm sorry the concept of sharing information flies so far above your head. Feel free to make your worthless snarky remarks elsewhere. However, there are better ways of sharing information. The best way is to do some searches and find what you can. When people reply you'll have some reference material to see their responses. Something I don't understand. The original links I gave listed the best ways found (so far?) to do Scorched Earth techniques in Bmax. I am assuming you're using Bmax so what was wrong with using that code? |
| ||
| The Amiga had superbitmaps whereby the backbuffer was essentially much larger than the visible screen area and then you could just tell the hardware at what x,y coordinates to position the top left corner. That way you could also do `hardware scrolling` where you can move the entire visible display without having to copy-paste any data whatsoever - given that the backbuffer is preserved, of course. These days you have the slight limitation that the backbuffer is not allowed to be any bigger than the display resolution. So for a 1024x768 display your buffer has to be that size as well - not particularly helpful for keeping track of a per-pixel destructible terrain several screens wide. You are allowed, hardware dependent, to have textures which are larger than the backbuffer - on some systems it could even by 2048, 4096, or even higher maximum width of the texture, which may be plenty for a reasonably sized destructible terrain. What that then means is simply that you draw the entire thing and let the hardware crop it for you to the visible display. The only problem then is how to modify the texture - either copying it to the backbuffer and changing it and then copying back to the texture - which is possible with OpenGL 1.1 commands e.g. glCopyTexSubImage2D is reasonably quick to copy a dirty-rectangle from the backbuffer to the texture. If your hardware doesn't support textures as big as you'd like you can use multiple textures and just split up the copy operations if they go over the texture boundaries. Another way is to use the tilemaps as mentioned above, whereby you define, say, textures of a given size like 64x64 or 256x256, you assemble a large tilemap, and then when you need to modify an area of the landscape you just need to lock one tile (or a few), modify them, and then unlock them to reupload the changed pixmaps to their respective textures. Not exactly the fastest way to do it because the data has to upload over the graphics bus each time, but if the tiles are small it may not be enough to cause a problem. That's basically the same as having an off-line super-pixmap in main memory, which you modify, and then just upload the changed areas to textures in video ram. If you wanted to get more advanced, for example, you could use OpenGL extensions, use the framebuffer objects if supported, which lets you define a new render target as a texture, which would be up to the maximum texture size, and then you can just render directly to the texture and then turn the framebuffer object into the `backbuffer` and flip it for display. Minimal copying needed. Personally I think that you can't trust the maximum texture size being supported on all machines, and should count on needing to define multiple textures/images as a kind of tilemap with large tiles. Then set about whatever preferred method you have for modifying the contents of the respective textures, either copying them to the backbuffer and modifying them and copying them back, or modifying their source pixmaps in main memory and reuploading the texture, or whatever. Besides how to store and refresh and draw the landscape, you probably also need to think about how to generate the landscape image, and you also need to think about how it is going to behave. Is it going to simple be a kind of heightmap where each column is a solid column of pixels up to a given row on the screen (ie no overhanging landscape areas), or are you going to allow overhang? Also when something blows up are you going to leave pieces of land floating in the sky or are you going to make them fall? If they fall, how do they interact with the land they fall onto? Do they filter down like grains of sand? Do they fall as columns and rest when the column touches the ground beneath? Do you try to do this in realtime or between turns? Do you use physics? Do you fake the physics or do a realistic simulation? etc Generating the landscape image itself is not too difficult once you've decided what kind of land mechanics you are going to simulate. You probably want to think from an artistic/design point of view what kind of control you want the game to have over the kind of landscapes that get generated - is it going to be like worms where you have to hand-draw the land and load it later as an image? Are you going to create a generator? Worms had you basically drawing with a large circle and then it would sort of decorate the results for you by adding grass surfaces and shaded layers of earth, etc. Are you going to auto-generate landscapes? How are you going to do that and give yourself enough control to exploit it in the game - e.g. cliffs, hills, flatlands, slopes, etc? I've thought about this stuff quite a bit because it's one of the kind of `game engines` that I'm working on. |
| ||
| Sledge - I am leaning toward BlitzMax, as of now. I don't own any of the other Blitz languages, so it's BlitzMax or something like C++/C#. I'm OK with pixmaps, largely due to a karaoke player I wrote in BlitzMax. Karaoke image data is rendered in 6x12 blocks, so I already have some experience cutting up the screen and manipulating the pixmaps. MGE - I am definitely not up to speed on the concept of render-to-texture. I remember seeing a lot of discussion of it, hereabouts, so I will look into that. Plash - I did not ask you to be my search bot. If you think I am asking for something you don't want to give, close the thread and move on. tonyg - I also did many Google searches on this topic. I found basically two useful resources, both repeated/quoted/mirrored over and over again. One dealt with a teddy-bear based artillery game, and one about using a midpoint procedure to build terrain. The information is useful, but that doesn't mean I don't want to find more information. Google returns literally millions of results for nearly any search terms. If someone were to post here asking for information on the karaoke file format, or methods for building a karaoke player using BlitzMax, I would post links and information that I have already bookmarked, because I have already researched the topic. If someone were to ask for information about 2d tile map editors, I would also be able to help because I have at my fingertips a significant amount of information regarding 2d map editors. There is absolutely nothing wrong with the links you posted, but if someone has additional links or papers on the subject, BlitzMax or otherwise, I am interested in reading those, as well. The link you posted to Worms.doc (thank you, by the way) is EXACTLY the sort of thing that compels me to ask questions of other people in addition to doing my own research. I went through literally HUNDREDS of search engine links related to this topic over the last two days and did not come across that document. Changing or omitting a single word in a Google search can drastically change the results. Or, I may just miss something that someone else saw. ImaginaryHuman - Wow, thank your for that detailed reply. As you mentioned, I don't trust everyone's hardware to support anything even remotely non-standard, so I am thinking 64x64 tiles. Generating the land is exactly what I am on to, now. My first attempt was a simple "move one pixel up, down, or right until you get to the other side of the screen" procedure that, obviously, generated completely unacceptable results. Next, I adapted a terrain generator from a Java project I found on the web, and it works, but it works slowly and I am not satisfied with the resulting terrain. I have plowed through TONS of Google links on the generation issue, as well as the destruction issue, and I find a lot of abstract ideas, such as "generate a 3d landscape then slice it in half." Well, great, but that's a bit vague. Ideally, I would like terrain with protrusions that can curve forward or backward, overhangs, the whole nine yards. I have been unable to find useful information on how to achieve this. I've considered pre-made terrain shapes, which could be planted on a generated horizon to add features. I have also considered a negative version of the above: libraries of shapes that could be randomly applied to cut out chunks of terrain. Naturally, I would probably use a combination of the above. Do you have any input on the above methods, or suggestions for other things I could investigate? Do you, dare I ask, possibly have some links or resources to share? I would appreciate any direction you could give me on the issue of generating such complex terrain. Thanks, SpaceAce |
| ||
| There is Random 2D Terrain and Land generator for my game - please criticize . Blitz source is provided in one of them. What Bmax code do you have so far? You might want to post it for others to improve or get some use from. |
| ||
| Thanks, tonyg. I managed to dig up those ones, already, and definitely plan to dissect the code in the second one. So far, I have written three generators. All three only generate a horizon line, no texturing, no fancy tunnels or overhangs, nothing like that. The first one draws a simple line from left to right, throwing in some ups and downs. The second one (which I deleted but can re-create) draws a bunch of circles of varying sizes then flattens peaks and does some other little bits of processing. That one, I adapted from a Java game I found. Finally, I wrote one using the midpoint algorithm. So far, the second one produces the most "Worms-like" terrains, but the third one is my favorite due to its speed and the ease of manipulating the results by adjusting a few variables. I'm happy to share the code, but it's nothing to write home about, at the moment. I'll clean up the one I am currently fiddling with and post it, soon. SpaceAce |
| ||
| Hey. Have you decided yet how complex you want to go with regard to handling `land fall`? ie, when you explode a circular area (lets say) which cuts into the landscape and possible leaves a chunk of land floating in the air, what are you going to do with it? It's important to think about it because the way you handle the falling of land parts (if at all) is closely linked to the kind of landscapes you can generate. You can't generate overhanging parts if you don't also find a way to deal with or explain what happens when an overhang is sevvered from its supporting structure. Overhangs are a lot trickier to deal with than to simply make the land `fall vertically`. The easiest landscape physics to code is simply none at all, which quite accurately explains the Worms games. One of the reasons (I think) that worms had tunnels and floating land parts is because the author did not know how to deal with making the dislodged land fall and settle. That said, if you do want to have tunnels which cut right through a hill without the hill above collapsing it, then you are basically saying that land never falls at all. Also floating land parts allow you to do things like swing from ropes like a ninja, grappled onto some floating lump. If those are the kind of `features` that you want, then you probably don't care about making the landscape fall in any even barely realistic manner. But if you do want it to fall, such as in Scorched Tanks/Earth, then now you're getting into different territory. You need a way to detect the disconnected landscape parts (e.g. anything `above` the explosion area). If you are detecting the columns above an explosion then all pixels in those columns need to fall until they touch another pixel below. That's one way. You could conceivably give your landscape overhangs which would suddenly turn into separate columns when it gets cuts off. Then you might want to consider whether you want the dislodged land to have any particulate effects - does it fall like grians of sand and pile up on the floor? Do you get landslides? Do you process real physics interactions or fake it? etc. But anyway. As to generating landscape images, I've seen a lot of different approaches. Atomic Tanks has a pretty nice looking landscape generator with different levels of substrate, although there are no overhangs. You should ask yourself how you want to generate the landscapes and whether you want the user to generate them, and if so with what kind of tools? The midpoint binary subdivision works pretty nice for basic landscapes but not with any overhanging features or tunnels. Are you aiming to provide a level editor? How would the user edit the landscape? How will you render the landscape and take some of the work out of it for the user? The thing I like about the midpoint method is you can start off with a `rough` landscape design based on some parameters - eg fairly flat, fairly random, more cliffy, etc, and then subdivide it to make it look landscapeish. The user could adjust the points on the landscape at any of the levels of subdivision to modify it, and it's pretty easy to generate it randomly. I've seen some games that use splines to create the landscape (e.g. Charr on the Amiga). You could use other graphics techniques. Your idea of using predefined landscape cookie-cutters is not bad, actually, you could approximately detect the edges of a rough land shape and cut out from it using randomized masks. Rendering the landscape can be a bit more difficult than generating the outline - you might think of rendering an entire screenfull/world full of dirt and then cutting out the sky parts instead of trying to fill it in afterwards. Here are some bookmarks that I have of this type of game, but I've never found any particularly useful information online about how to create this kind of game. http://www.geocities.com/porter_loring/ http://arstechnica.com/articles/culture/scorched.ars http://www.apex-designs.net/frontalassault.html http://www.armchairarcade.com/aamain/content.php?article.51 http://atanks.sourceforge.net/ http://www.isotope244.com/games/acp/media.html http://battleduel.terstiege.de/aboutbd_e.html http://www.charreddirt.com/ http://www.ctspgames.com/ http://www.gamealbum.com/Games/Arcade/Atomic_Cannon_400_Review.html http://freshmeat.net/projects/atanks http://pc.gamezone.com/extlink.php?SiteID=gamezone.com&Link=http://www.avault.com/reviews/review_temp.asp?game=warhds&page=1 http://www.the-underdogs.org/game.php?name=Scorched+Earth http://savannah.nongnu.org/projects/koth/ http://www.macgamer.com/features/?id=1462&page=2 http://www.isotope244.com/ http://www.scorched3d.co.uk/index.php http://www.saigame.com/ http://scorch.classicgaming.gamespy.com/ http://gunbound.net/ http://sourceforge.net/projects/atanks http://www.wormux.org/wiki/Image:08b3_c.png.php |
| ||
| Have you decided yet how complex you want to go with regard to handling `land fall`? Yes, I intend to let unsupported land hover in midair in defiance of all known physical laws. I will classify this, in my head, as a "feature" which creates additional obstacles for the player to deal with. Also floating land parts allow you to do things like swing from ropes like a ninja, grappled onto some floating lump. I am one of the greatest ropers ever to play the game of Worms. That feature alone kept me playing Worms: Armageddon for literally years. I loved roping! I enjoyed it so much, I've considered building a game entirely around the concept. Currently, I am leaning toward midpoint generation of the landscape, followed by stamping and cookie-cutting using shapes at varied rotations and scales. If the project I have in mind actually comes together, I will probably provide a level editor, but I think it will be something simple, like the one from the Worms series. Another method of terrain creation I have considered is to generate a bunch of ovals to create a lumpy landscape, then use a horizon line generated by one of the other methods to cut off the top x% of the ovals. I am not sure if this would be a worthwhile endeavor, though. Thank you for the links. Anything I can learn will be helpful. SpaceAce |
| ||
| Your oval thing sounds like it would work, at least as an option. There isn't really any limit to how your land `looks`, if it's a part of the style of your game. For all anyone cares you could just use a randon number between 400 and 500 for the ground level of each vertical column. It'd give very spiky land. If that works for you, then hey. You could make it with rectangles, splines, ovals, premade shapes, fractals, whatever, or even go with the hand-drawn bitmap approach. Have you decided how large your landscape will be? Will it require scrolling? How will you do the scrolling/tiling/update? Does your land wrap around at the edges or do you deal with bouncy screen limits or just let stuff go out of play? Have you thought about weather effects? I guess if you're going with pieces of land overhanging and remaining floating in the air - one thing worms did was to have a `dark` land image which would appear where there used to be bright land foreground, so you cut a crater hole and replace it with dark/black pixels where it overlapped the land, making it look like the land still `supports` the stuff above it, like there's still some land `further back` away from the main playfield holding it up. That's one way to do it, or just blow all the way through to create sky. If you go this route then you don't need to think about making the land fall or anything. |
| ||
| Have you decided how large your landscape will be? Will it require scrolling? How will you do the scrolling/tiling/update? Does your land wrap around at the edges or do you deal with bouncy screen limits or just let stuff go out of play? Have you thought about weather effects? I intend for the playing field to be larger than the screen. I am thinking something like 2048x768, but that's just a planning number and subject to change. As for the scrolling and tiling, I am considering rendering the land to a bitmap, then loading the bitmap as an animated image strip and using a simple tilemap engine. If I make each tile 64x64 using the dimensions listed above, I'd only be looking at around 384 tiles. In some of the projects I've goofed with, I've had no trouble with tile maps of 10,000+ tiles. As it sits in my head, I have been envisioning the land just ending in limbo on either side, although scrolling around would allow for amusing "shoot left to hit guys on the right" scenarios. I do not intend to have bouncy walls or any kind of borders, but again... nothing is set in stone. I may or may not bother with some sort of underlying texture for the land. I don't think the hovering land detracts from the enjoyment of the game, but I suppose I could be wrong. When playing BnGs on Worms, I always kind of liked the obstacles that could be created by the hovering landscape bits. Thanks for the thoughtful replies and questions. How far along are your own project(s) along these lines? SpaceAce |
| ||
| At the moment my landscape game is pretty much just a bunch of designs and ideas. I'm working on a more generic engine/platform which it will eventually be developed on top of, so I sort of am working on it but not specifically at this point. I did start to make one in BlitzBasic on the Amiga some years ago but I didn't get further than the scrolling and some of the user interface controls. I didn't have a land generator or anything, I was using processed images from a 3d landscape generator which I just loaded in. Are you hoping for your engine to work in DirectX and OpenGL or just one? I don't think hovering land is a problem, it's just different. There are other dynamics of gameplay that arise when you have to think about whether land will fall on you, for example, but then you can't really do tunnels and stuff. |
| ||
| I'm working on a more generic engine/platform which it will eventually be developed on top of, so I sort of am working on it but not specifically at this point. That's my poison, as well. I have tons of engines and libraries and whatnot, but I am often so burned out from writing them, that I never implement them :) I hadn't given any thought to DirectX vs OpenGL. I virtually never use any low(er)-level calls if there is any alternative. Are there some issues you know of that I should be watching out for? SpaceAce |
| ||
| I was just wondering what kind of drawing commands you were going to need to use in order to render your landscape, mainly, or to cut parts out from it, or to reupload images, etc. I guess Max2D is enough to do the basics of it but nothing advanced. Otherwise you'd have to either dip into writing your own DX/GL code, or use some other graphics engine. |
| ||
| I was just wondering what kind of drawing commands you were going to need to use in order to render your landscape, mainly, or to cut parts out from it, or to reupload images, etc. I guess Max2D is enough to do the basics of it but nothing advanced. As I mentioned earlier in the thread, I've written a karaoke player in BlitzMax. Image data for karaoke graphics is stored as bit-flags, so you have to perform pixel-level manipulation. I've actually gotten it to a point where I think the process should be plenty fast, especially using WritePixelFast. Since I envision this as a turn-based game, there shouldn't be an issue with multiple explosions causing mass damage all over the map. Also, I intend to make the damage areas generally circle-shaped, so I can just find all pixels within the blast radius and take care of those. SpaceAce |
| ||
| WritePixelFast? Blitz3d? |
| ||
| No, BlitzMax. There are a couple versions floating around. SpaceAce |
| ||
| Oh, writing to pixmaps, something like Int Ptr(PixmapPtr(mypixmap))+xcoord+(ycoord*mypixmap.width) kinda thing? |
| ||
| No IH, writepixel |
| ||
| Ah. Well the above code is basically what writepixel does and it's not as efficient as if you were planning to write many pixels, in which case you can store the Int Ptr(PixmapPtr(mypixmap)) in a local, and store pixmap.width in a local, and use a local xcoord, then it'd be ptr[xcoord+(ycoord*rowwidth)]=value. Allegedly there is some kind of WritePixelFast function floating around, which is why I said that. |
| ||
| So do you have some kind of theme designed for your game? like, worms was around the idea of teams of worms, are you planning to use teams or solo characters, and as what? worms, tanks, castles, people, rodents, etc? One thing that I did like about a game like scorched tanks was the interactivity with the landscape, for things like the underground burrowing missile, lava flowing down hillsides, etc. I missed that in Worms which focussed much more on the worms and the weapons, taking the focus away from using the landscape itself as a weapon. |
| ||
| I've toyed with various themes, but I haven't settled on anything. One idea I kind of like is a plastic soldiers angle. The game dynamic I have been visualizing centers on a 1-on-1 conflict with each player having a single character to control. However, the toy soldier theme mentioned above lends itself to something I find to be pretty sexy: different soldiers with different weapons. So, maybe each player could "recruit" a team of several soldiers at the beginning of the round or pre-build teams that could be used over and over, again. Maybe the game could even include an experience/leveling system with an online component to match up teams of equivalent experience. Man, this game sounds awesome. Someone who is actually good at programming and/or art should make it. SpaceAce |
   |