The dirt in Scorched Earth

#1 Lots of particles?

#2 Oops... just responded to the other one... ok just in case you never go back to the public forum I'll repost my meaningless drivel here:

Just my opinion but I'm pretty sure doing dirt would require serious low-level (lower than script) modification to the engine. T2D is a brilliant tile-engine with fantastic rigid body dynamics thrown into the bargain, but those games (scorched earth, Worms, D.I.R.T.) use "pixel engines" for modification of the terrain. I don't think it would be an impossible thing to add to T2D, but it would be coding a pixel engine within the framework that's there. Methinks T2D (and all other tile engines) may weep at a scripters insistance on a screen full of 1 x 1 pixel "tiles"...

If you're interested in the basics of just WHAT low-level modifications you'd have to make - mebbe this can help:
no-skill.kbs-design.net/drupal/gamedev/jnrdev/pixellandscapes

-Tim

#3 Actually though Pat is on to something...nothing says (as far as I am aware anyway!) that you cannot mask a tile switch with a particle burst...when the particle burst clears, the new tile is in place. you would need a nice and wide tile set obviously so that it wasn't the same one every time, but that's how 2-D games have been for ages, hehe.

#4 Aye THAT you could do... but unless you limit your explosions to geometric figures or expand your set of tiles to include a truly incredible number of possibilities, it will be difficult to get that... scorched earth/ leiro effect. I'd LOVE to see any effort put in that direction though.... pixel engine games have always been near the top of my favorite games list... (mebbe just under voxel engine games)... I wish you the absolute best of luck in any such project!

-Tim

#5 Any other input on this topic? Thanks.

#6 Yeah, I'm interested in this as well. I've never played Scorched Earth, but I've been thinking on ways to create destructable terrain using the tilemap.

I was thinking:

Get explosion radius
find the tiles within the blast radius
remove those tiles
Replace the tiles along the diameter of the blast with angled/ragged tiles to approximate the blast edge

At time of explosion, when you remove the tiles, throw some sprites out of the explosion that look like the ground's been blown to pieces. The sprites would, of course, be collision active.

This might not look real good. I dunno, I haven't tried it yet (still new to TorqueScript), but it's a possibility me thinks.

#7 If you're wanting the pure Scorched Earth feel (as opposed to something that is simply similar to it, like others have suggested), you're going to need to forgoe a lot of what T2D gives you. You'll need to write your own, pixel-perfect collision system. You'll need to write a terrain system that can handle falling dirt (not hard). Most difficult of all, you're going to need to update images frequently, which is going to require lots of poking at some of the low-level internals of T2D.

Overall, I wouldn't use T2D for such a game. At least, not the graphical part of it. The core bits of it (input, sound, etc) are fine, but the rendering/collision/physics are not designed to handle anything with the needs of Scorched Earth. It's going to require a fair bit of code hacking to rip much of the rendering out of the system.

#8 Can you have tiles that are 1 pixel wide and many pixels long? You could have them arranged horizontally like slices of a terrain, and then scale them or move them to give the impression of a jagged terrain.

#9 Ho man, that sounds like it would CHUG. But, I'm sure there's a creative way around this. I'll have to do more research, but... is there a way to create a sprite that would cancel collision only in the space it takes up (kinda like a bridge over water to stop you from falling into the water, except reversed)? or would you actually be required to change the ground itself?

Is there something that can be done with vector shapes? I'm still learning, so I have no idea if vector shapes to mark collision are even supported. I do know that in an upcoming version of T2D, there'll be something like masking, where you can make parts invisible.

Doing these things would require new objects on screen for every hit and explosion that occurs in the game...

I don't know. I really don't know much about this engine yet. I just know as much as in the tutorial. Also, I'm an artist, and not a programmer. I'm not intimate with T2D's inner workings :).

#10 The current collision system in T2D isn't hard-wired. There's a virtual member that can be overriden to allow you to do whatever you want. The associated callbacks are also seperate so that all you have to do is fill-in the appropriate structures and pass to them so that you then automatically support the standard callback system.

We'll be adding a couple of other standard collision types, probably something like swept-circle in the future as well as lots of other standard collision-responses but that's a little off-topic here.

This is all off the top of my head so it's trying to be a little 'creative' and maybe not a perfect solution but forgetting the issues related to doing sub-updates of textures to achieve this effect, the collision detection could work in a number of ways although I'd hazard a guess that doing it in a swept fashion would be extremely expensive but far from impossible.

Adding a couple of constraints makes the problem a little easier here.

If the landscape was solid (no interior holes), you could effectively just handle the landscape 'horizon' which isn't so difficult a test. If the per-texel landscape "height" was encoded as a local-space values then it would be easy to do the check that would become a line/line intersection check. You would need one of these for every landscape column so you would want to trivially reduce that testing set. You could do this by moving the colliding objects polygon into the terrain local-space. It would then be a simple matter of doing a projection against the landscape base to determine which landscape column ranges need to be checked. You could also expand that projection to give you a broad-phase box to check against.

All this can be done by overriding the standard collision function and implementing your own in your "dynamic terrain" object. I wish I had more time to play with stuff like this. Maybe there are existing algorithms on the net, I've never looked and maybe this is just reinventing the wheel.

Very cool project though. It could provide an interesting bit of tech for lots of games.

- Melv.

#11 Melv, could you add a getPixelArray() function that'd return a pointer to read/writeable pixel data for a given surface?

#12 Heh, I have no idea what Melv just said...

#13 I'm glad I'm not the only one... =)

#14 Hey, nobody said it would be easy. I've got a picture of how to do it in my mind but that translates poorly into words. ;)

@Adam: We don't have surfaces but rather memory textures which need to be uploaded to the graphics card but what you ask for is possible.

- Melv.

#15

Quote:We don't have surfaces but rather memory textures which need to be uploaded to the graphics card but what you ask for is possible.

Actually, I would suggest that this functionality not be exposed as an API. Transfering data to/from hardware memory is not fast, and it is best that an experienced C++ programmer tailor make each use of it for a specific game, rather than attempting a one-size-fits-all solution. This kind of stuff is pretty far out in left field for virtually any graphics system, and it needs special-case code to make it perform.

#16 Hmmmmmmm I smell a TPE on the rise (Torque Pixel Engine). Haha.

#17 @Smaug: Agreed. It is unlikely that we would provide anything in the near-future at the script-level but we do have plans to construct better interfaces in C++ for this kind of stuff. Essentially stuff that will work behind the new T2D image-handling system rather than having to go low-down into the core to manipulate bitmaps, texture-objects and the resource-manager.

- Melv.

#18 Agreed Rob but the discussion here is one on a much finer scale, probably around the pixel-scale. The overhead of having lots and lots of very small tiles could become huge, especially for collision considerations. It would all depend on the scales I guess.

Because the tile-layers can be changed dynamically, you can certainly use it for that.

- Melv.

#19 Is there not a way that you can use the alpha channel / mask layer for collision detection as well as for masking of destroyed bits of terrain? That way, destroying pieces of land would be as simple as drawing the explosion onto the alpha channel.

#20 @Alex:
Boolean operations would be pretty neat :) I'd like to see that also because it could be used for a lot of other things as well.