I'm trying to create a 2D worms game and I'm having some difficulty in figuring out how to store the terrain.

My plan is to create an algorithm that generates terrain by combining several images together to get one final texture.  For example, I'll start with the shape of the terrain then fill in mountains, add grass on top, add rivers to the inside, create caves, etc.  However, in the end I will just have one very, very large texture.

However, I also plan to allow very large resolutions (eg. 1920x1200 [my 24" monitor's native resolution], 1280x800 [laptop's native resolution], etc), and thus this requires massive amounts of video memory and lots of textures.

For example, if I want to use 1920x1200 (w/32-bit color) and have 6 screens worth of terrain (3 screens wide and 2 screens high), then it will require 55 MB of video memory.  Even 1280x800 requires 24 MB of video memory.

The other problem is that typical maximum texture size is only 1024x1024 so I'm guessing I'll need to split my image into many, many smaller textures and then figure out which ones to deform when a collision happens, etc.

Am I approaching this problem wrong?  It seems like 1920x1200 * 6 screens just requires a ton of video memory and there is no way around it...

Step 1 in making these sizes reasonable is to forget about 32 bit color. Use DXT1 format instead.

If that's still too big, you should think about whether a single huge texture is really the best way to go. A more concise representation might be to store the outline of the terrain in a geometric vector format (perhaps as a collection of curves), then generate a set of triangles when you want to draw this, using a tiled texture to apply your grass/dirt/etc patterns.

Thanks for the reply!  (By the way, I really enjoyed your networking tutorials)

I've never even thought about using another texture format but that sounds like a great idea.  It's actually difficult to find information on DXT1, but according to the Unreal Engine wiki it's only 4-bits per pixel?  That would reduce my 55 MB RGB8 texture to a mere 7 MB!  That's pretty incredible...  However, how good does DXT1 look?

Can you explain a little bit more about your alternate idea of storing the texture?  I can store the outline of the terrain as a series of vertices, but I'm not sure what you mean about generating triangles / using a tiled texture.

If I generate my terrain image by composing various textures together, how could I generate tiles to save space?  (eg. if I break the terrain into several smaller pieces, no two pieces will be the same)

One alternative idea is to re-draw the grass (and every piece of the terrain) every frame.  (eg. instead of using the algorithm to generate one texture it would be used to draw the different items of the texture every frame)  This would work but I would work it makes collision detection much harder... (eg. because the terrain is deformable)

Hello,

Me and a group of 3 others are creating a student game using this concept for this year in school. We've had basic talks on how we are going to approach and it might help you.

However, be warned that we haven't coded so there may be issues with this process!!! It's pure hypothetical theory until we start coding it at the end of the summer :) Still figuring out design concepts and such. Also, we are coding in C++ from scratch without using XNA.

We are going to create a collision map of two colors, white and black (not sure on format, but we only really need one bit per pixel). White is no collision, black is collision. We then can figure out some information about the terrain during the draw phase (if it's surrounded by black pixels for example, draw a rock texture, if there's a white pixel above, draw grass since it's a top level).

That should only need to be done once.

Then from that we still have a bunch of ideas on the best ways to do the deformable terrain (in terms of accuracy and graphics quality of the terrain).

We may only have explosive weapons like rockets which have circular explosions, so someone suggested just overlaying a circle on top and making it same as the background, and ignore collision within that circle. This doesn't sound like the best solution to me because that means it's not easy to do line collisions (bullets) without creating a bunch of circles which wouldn't look good.

Here are two links I just found that may be worth looking at.

http://www.indierover.com/ktb-tutorial-1-2d-randomly-generated-terrain-for-worms-style-game/

http://www.yoyogames.com/wiki/show/23

If I have any ideas brainstorming with my team, I will let you know!

~Brian

briguy992:

We are going to create a collision map of two colors, white and black (not sure on format, but we only really need one bit per pixel). White is no collision, black is collision. We then can figure out some information about the terrain during the draw phase (if it's surrounded by black pixels for example, draw a rock texture, if there's a white pixel above, draw grass since it's a top level).

That should only need to be done once.

Thanks for the reply!  I think I understand what you're saying, but creating the texture isn't really the problem.  The problem is that the size of the created texture needs to be huge for high resolutions and is going to create problems due to the lack of video memory, etc.

I'd really, really like to know how Worms did their terrain for the XBLA game.  Anybody have any connections to these guys? :)

Disclaimer: I've never made a game like this, so I'm just throwing out some ideas here. They might well all turn out to be rubbish since I've never actually tried any of this myself :-)

Remember that Xbox 360 has half a gigabyte of RAM. If your game is all about destructable terrain, you shouldn't be afraid to spend a significant amount of that memory on the terrain. A couple of hundred megabytes of textures might not be unreasonable, if that turned out to be the best way to achieve your goals.

But be warned, if your design ends up having to do significant CPU work over hundreds of megabytes of data, it isn't going to be terribly fast!

I suspect a good starting point would be to separate your logical representation from your graphical representation. If you get too focused on just how you're going to draw the terrain, you might forget that you also need to be able to collide against it for your gameplay code! This requires the terrain data to be available in a form the CPU can easily access, which probably means an array of bytes or booleans rather than a texture. There's no need to worry about color in this data: that's just a display thing; what matters here is knowing which pieces are solid.

I would then think how I can generate what I'm going to render from this simpler CPU format representation. That's probably going to involve some caching, since you don't want to transfer the whole data from CPU to GPU each frame, you'll probably want to send it over just once and then store a copy in texture format. When sections are destroyed, you'd only need to re-upload the areas that were damaged (or it might be faster to use render-to-texture to duplicate the same "erase area of terrain" operation on CPU and GPU in parallel, rather than trying to compute it on one and then transfer data over to the other).

If you separate the processo f applying textures to the GPU format data from the underlying format of that data, I think this will make coordinating your updates a lot easier. This could be as simple as a pixel shader that chooses between a couple of different multitexture layers (surface grass, rocks, background) for each pixel, or might be some more complicated multi-pass render to texture operation: it really depends on how fancy you want to get. There's lots of room to cache this stuff and only re-render when things change, but the 360 GPU is fast in any case so it might not be a problem even if you are doing lots of work each frame.

I would also reconsider whether you really need your underlying representation to exactly match screen pixels. Screen pixels are just for display: who says you need to use the same thing for your underlying data format? It's going to chew up a lot of CPU cycles if you have to do all your collision checking against an HDTV resolution image! If you separate underlying format from display format, you can do the underlying simulation at any resolution you like, and then just add detail when you apply the final texturing and graphics effects for display.

Shawn Hargreaves:

Remember that Xbox 360 has half a gigabyte of RAM. If your game is all about destructable terrain, you shouldn't be afraid to spend a significant amount of that memory on the terrain. A couple of hundred megabytes of textures might not be unreasonable, if that turned out to be the best way to achieve your goals.

Well, I'm designing this primarily for the PC (with the 360 as a secondary objective) and I'd like this to run on the lowest possible spec machine so I do need to conserve memory, etc...

Shawn Hargreaves:

I suspect a good starting point would be to separate your logical representation from your graphical representation. If you get too focused on just how you're going to draw the terrain, you might forget that you also need to be able to collide against it for your gameplay code! This requires the terrain data to be available in a form the CPU can easily access, which probably means an array of bytes or booleans rather than a texture. There's no need to worry about color in this data: that's just a display thing; what matters here is knowing which pieces are solid.

Yeah, I'm planning to have an array of bits (or whatever) that simply says solid or not solid for each pixel.  (NOTE: This array will be a standard size or "resolution" for all players but each player might be using a different display resolution)

Shawn Hargreaves:

I would then think how I can generate what I'm going to render from this simpler CPU format representation. That's probably going to involve some caching, since you don't want to transfer the whole data from CPU to GPU each frame, you'll probably want to send it over just once and then store a copy in texture format. When sections are destroyed, you'd only need to re-upload the areas that were damaged (or it might be faster to use render-to-texture to duplicate the same "erase area of terrain" operation on CPU and GPU in parallel, rather than trying to compute it on one and then transfer data over to the other).

Are you saying that if my display resolution is 1920x1200 and I want six screens of terrain, that I would create 1920x1200 * 6 textures on the video card?  Because of maximum texture size I'm guessing I would actually need a whole bunch of 1024x1024 textures instead of 1920x1200 textures, etc.

Shawn Hargreaves:

If you separate the processo f applying textures to the GPU format data from the underlying format of that data, I think this will make coordinating your updates a lot easier. This could be as simple as a pixel shader that chooses between a couple of different multitexture layers (surface grass, rocks, background) for each pixel, or might be some more complicated multi-pass render to texture operation: it really depends on how fancy you want to get. There's lots of room to cache this stuff and only re-render when things change, but the 360 GPU is fast in any case so it might not be a problem even if you are doing lots of work each frame.

I'm still a beginner graphics/XNA programmer so I'm not completely sure what you're saying here.  I understand the basic concept of pixel shaders, etc, but I am just learning XNA so I don't think I'm ready to write my own custom shaders :)

Shawn Hargreaves:

I would also reconsider whether you really need your underlying representation to exactly match screen pixels. Screen pixels are just for display: who says you need to use the same thing for your underlying data format? It's going to chew up a lot of CPU cycles if you have to do all your collision checking against an HDTV resolution image! If you separate underlying format from display format, you can do the underlying simulation at any resolution you like, and then just add detail when you apply the final texturing and graphics effects for display.

Yes, I agree.  Like I'm describing my first comment above, I'm planning to create a smaller resolution independent array that represents my terrain.  That way I can use a smaller size (eg. 800x600?) but still represent it nicely on 1920x1200 displays.  The problem is that 1920x1200 still takes up a boatload of video memory and requires a ton of smaller 1024x1024 textures to split up the entire thing, etc.  (plus I need to code terrain destruction when half of it occurs on one texture and half in another, etc)

I really appriciate all of your help!

Does anybody have any more suggestions or comments on my latest post?

Thanks in advance for any help!

I still don't understand why you're not using a tile based approach. Having large images is always going to be a problem and loading up hundreds of smaller images that tile to make your screen is going to be better. Is there any reason you can't create 2D worms battlefields using tiled images?

I agree with George. For rendering you are much better off using a tile map along with the use of the stencil buffer to create the visual aspect of your game. See my post here for details on how to do the stencil part: http://nick.gravelyn.com/2007/09/12/dynamic-terrain-using-the-stencil-buffer/. Note that I use one large image for the background, but it is irrelevant to the technique how you draw the terrain. I merely used one image for simplicity, but mine was much smaller. (Sorry the code on the post is messed up, but there is a link to a download at the bottom).

Then you keep a totally separate array for the collision data and update that appropriately. Shouldn't be too hard to set up and will be much more performant on the rendering side.

Nick Gravelyn:

I agree with George. For rendering you are much better off using a tile map along with the use of the stencil buffer to create the visual aspect of your game. See my post here for details on how to do the stencil part: http://nick.gravelyn.com/2007/09/12/dynamic-terrain-using-the-stencil-buffer/. Note that I use one large image for the background, but it is irrelevant to the technique how you draw the terrain. I merely used one image for simplicity, but mine was much smaller. (Sorry the code on the post is messed up, but there is a link to a download at the bottom).

Then you keep a totally separate array for the collision data and update that appropriately. Shouldn't be too hard to set up and will be much more performant on the rendering side.

Thanks for the replies!

I agree with the stencil buffer and seperate array for collision data, but I'm not sure what you mean by using a tile map...

Here is my plan to create the terrain..

 

Step 1: Create the terrain outline

 

Step 2: Fill the terrain with a texture (eg. a real texture and not a solid color)

 

Step 3: Apply grass texture to the top of terrain

 

Step 4:  Insert river and cave textures running through the terrain

 

Step 5:  Draw buildings on top of terrain, that will actually become part of the terrain image (eg. they are destructible)

 

Step 6:  Create the collision terrain (eg. just an array [or whatever] of "solid" versus "not solid" pixels).  This will be a resolution independant size so that during multiplayer each client can use their own visual resolution size.

 

How could I create tiles from my final (eg. Step 5) terrain image?  If I split the texture into 64x64 chunks, no two chunks will be exactly the same.  Also, in order to accomdate high resolutions (eg. 1920x1200) and because I'm overlaying textures on top of textures I need textures the same size as the display resolution (eg. 1920x1200 * 6 screens wide/high).