Terrain dammage!

#1 This could potentially be possible with a lot of hacking, however it wouldn't work for network play at all. The burnt thing could be done as a decal no problem.

#2 Thanks!

Hmm you mean that the other clients couldnt be aware of that change? Maybe this information couldnt be sent thru the network similar to players position ?

Fred

#3 As of right now the server cna edit the terraain however it still moves the clients along the original terrain while you move along the new terrain. They dont' see the changes. Also you have the problem with shadows on the terrain that will still be the original untill you relight

--KallDrexx

#4 For the casual developer id say bump maping decals onto the terrain would be the easiest. Ofcourse torque dosnt have bumping though so youd have to code that first. I was thinking about deformable terrain the other day.

#5 if the prob is that the client and the server do not agree on the terrain, perhaps there is a way to send the same terrain bending commands to the client.

I tried a test of editing the terrain while in a play-test, and the other guy walked along the terrain as I saw it. As he saw it, he walked through hillsides, and got stopped by thin air.

So since the server is in control of the physics, it works that far. Really, the only thing needed is a way to pack an terrain modification off to the client.

#6 Here's another idea, create a game object that appears to be terrain, but once it gets damaged it kinda appears to sink in and then apply the decals. Kind of like a layer effect. If that makes any sense to anyone. :P

#7 I had always wondered about the possibilities of deformable terrain in TGE. Since it seems this would be mostly for eye candy and player gratification, why not just use .dts craters? Possibly make a 'crater manager' to manage and eventually fade out the craters after a certain amount of time. Sure you couldn't dig big holes, but it'd look nicer than a decal and would be relatively easy to do. Just a thought. :)

#8 Guys,

Putting aside the lighting issues related to using static lightmaps, I don't see this as being, at least initially, a tough nut to crack.

I would approach it this way:

1) Create a custom C++ object that could be configured with 'Crater' datablocks, in effect, creating crater brushes. Its purpose, when activated at a location, is to lower the terrain around it's position e.g. produce a crater. This is quite simple to do; in-fact you can do this within the existing editor. The trick is for this object to do this collaboratively across the net.

2) When the command to activate the object, perhaps from a collision trigger, the server object is activated which makes the terrain deformation and sends the activate command to all clients which themselves deform the terrain. If this is done on the server first then minor predictive errors for players should be resolved.

3) Sit back and destroy some terrain!

To sum up, new C++ object that can access the terrain object and deform a datablock-defined crater when trigged. It's server portion will trigger a network update to its ghosts on the client who will also deform the terrain block appropriately. These objects could be placed anywhere over the terrain and even overlapped as the crater effects can be additive.

You'd also probably want to scar the terrain with decals etc for effect.

With regards to lighting, knowing the issues, you can easily design your map to take this into account. Simply because there is a problem doesn't mean that the whole approach has to be scrapped. Allowing every possibility for every object to interact correctly will come along with more powerful hardware but for now, simply work around it. :)

I always wanted to try this but I never got the time, if no-one else trys this over the next few months then I'll do it around June time.

- Melv.

#9 Thanks to everyone for replying, in my opinion everyone have very good ideas ;-).

And indeed what the artists of our team were telling me is that they would like deformable terrain or dynamic terrain!

@Matthew & Paul
From what i understand is that if change the terrain on the server, for me everything would have change visually but for the client only the collision detection would have change. Which mean the player might go thru some part of the terrain since he wont see graphically the new changes.

@Tim & Nathan
Of course decals have to be use also ;-), to display some scratch, burning, etc... But the terrain also need to be modifiy, let say i have my ship that weight a few tons that crash to the earth at high speed, it would definately make a huge hole in the terrain!

@Tyler
For us it is not for eyes candy only but it will be considered in the design of the games itself. Similar to Red Faction where the outcome of the game can change depending on what you did (you dig a hole thru a wall to make a surprise attack, etc...). And do some kind of manage would be a good idea.

@Melv
Wow your idea is in the same line of thinking i had, but you have much more better skill than me to put it in words. Thanks alot, i think this is definately a good starting point! I dunno either when ill start working on it yet (we are still in the design stage and also my task now is to eveluate the possibility of TGE which prompt me to ask all those questions on the forums ;-). But so far it is verrrrry good and if all goes well we will make the decision next thursday to pick up TGE!)
Maybe we could collaborate together? This is one of the great thing about TGE is the communauty where people can team up together, exchange ideas, help each other, etc...
I think it is much more better than having everyone having to reinvent the wheel in each of their corner (You should know what i talk about since you read the same book i did ;-). The first book on your monitor hehehe!). Btw what are the other books? (I know the first one is game architecture, then 2 game gems books, the rest i am not too sure the picture isnt clear enough, just know one of the them is from Addison-Wesley)

Fred

#10 Melv that is a good aproach, but I think it would be a nightmare to impliment. I think that deformable terrain could work on a single player type thing (though like you said it would mess up the lightmaps) but multiplayer it's just too difficult to assure that everyone is seeing the same thing.

The making other shapes and making it appear as terrain would not work at all. Nothing in Torque is designed to be deformable. You could deform an entire object with a vertex shader, but that is not at all what you want to do. Besides that, making a shape like terrain would chop performance big time.

#11 Pat,

I tend to disagree that it would be difficult for a couple of reasons:

1) The terrain is simply a height-map and changing it's dataset simply changes the rendering in realtime.
2) Changing the terrain on the server affects objects which are dominant in terms of object position.
3) Lowering the terrain does not result in objects falling through whereas raising would.
4) The command from the server object to client objects is extremely minimal, simply a flag, no other info required.
5) Collision lag is no worse than any other kind of collision on the server.

Given a little time over the next week or so I could demonstrate the basic idea in action. I'm not trying to smack in the face of what you're saying Pat but I really don't see it as that much of a problem.

The biggest concern (excluding lightmaps/shadows) is prediction on the clients.

- Melv.

#12 Well I guess all you are passing is a datablock that would tell it how much to dig out, but it just doesn't seem like it would be that easy. I think I'll trust your judgement on it though, Melv, since you have a bit more experience than I do ;)

#13 yep, and at least one project using Torque has implemented it for a multiplayer game, and the author doesn't qualify himself as the uber-hacker ;)
(you know who you are, so I'll let you decide to talk about it or not, since I'm not involved ;))

#14 Nicolas is correct - I definitely don't consider myself an Uber-hacker, and managed it implement it. However, I did things a little different than Melv's description but not too much. Mine is pretty hacky, but, I had different goals when I was hackin' on it.

I'll be releasing my code - when I FINALLY call Trajectory Zone 'done' and release it. (Hey - if everyone has it, where's my Unique Selling Proposition? Best to wait until after it's out I guess ;-) I just added another console command (setTerrainHeight(location, height)) and handle it directly in scripting. Deformations have to be sent to both the clients and the server of course.

For single player it's bloody simple, for multi-player you'll have to keep track of all deformations that occur in the environment, and transmit them to newly connected clients. Also, you have to trigger re-adjusting the collision mesh for the terrain too, usually 1 square each direction larger than your deformed area (otherwise, odd things happen ;-)

While you play, lighting the terrain ends up not bein' to big of a deal. Your brain pretty much fills in the gaps automatically, and dynamic lighting works just fine goin' across a crater.

One serious problem I've ended up with, though, is a good way to handle changing the terrain color. Retexturing isn't much of an option (causes hits to the blender, and if you start getting enough texture changes going on, starts to affect performance. Since I'm targeting low-end stuff, well, it's a big deal to me ;-) The problem I have with decals is figurin' out how to get 'em to conform to the terrain, and STAY conformed - IE, when the next shot comes in behind the first, the decal doesn't stay at new angle caused by a second deformation. Never figured that one out, and given my really laggy development schedule at the moment, probably won't deal with it again until I do something like Trajectory Zone 2 (which is where all the 'cool stuff' I'd love to do ended up going ;-)

Anyway - that's my experience with Terrain Deformation. Dunno if any of that helps. If ya ain't in a hurry at all on it, I'll get around to posting a resouce eventually :-)

#15 Instead of keeping track of all of the deformations would it be concievable to safe it to a terrain file and then send the new terrain file to the client? This might not work too well for dialup connections, but I don't see it as being a problem for boradband. Terrain files are about 380k(well atleast the example ones, not sure if this number is based on just the size of the terrain) and would be no problem for a broadband connection. Maybe you could divide the terrain files up into say 6 parts so that you only have to send the parts that changed and then put them together? That would definatly be eaiser on the dialups.

#16 Not really, here's why:

If you are trying to keep consistency between all the clients, and the server, then you have to have a list of deformations and transmit it on the fly (making sure before they get into the game that they are current, including the deformations that have occured while the server was sendin' the deformations that occured before the client attempted to join.) That last part about sending more deformations between the time the client started recieving deformations and completed recieving the inital deformations is where transmitting a terrain file instead falls down. In other words - by the time you recieve the 300+kb terrain file, there's already new deformations that have occured (and you can't adjust the terain file while it's bein' transfered.)

My solution might be a bit simplistic, but, it works - just keep track of all deformations for the entire level (which can be significant for a game with a lot of players), and start transmitting the deformations to the client. When they finally reach the end of the list, they are ready to spawn in.

If you wanted, you could transmit a terrain file, keeping track of the deformations that have occured between the begining of the transmission of the terrain file and the end of it, then send those just before entering the game.

One other note about Terrain Deformation - in a game with a lot of people in it, it's adding even more network trafic (at least the way I did it ;-). On broadband or LAN play, it's not signification. However, I'm waiting to see what happens in a 20 player game with one or two people playin' on dialup - it could get a bit ugly watchin' the landscape try and keep up with the deformations, and the clients bein' a bit more laggy than normal!

#17 Well, hopefully you're not changing all the terrain all the time!

I would guess that if you put your terrain updates through the same scoping process that other net traffic goes through (so near-player changes get sent first), it wouldn't be too bad, even on a dialup. You just start sending updates, nearest first... Distant hills might not update right away, but at least the terrain you're walking on would be accurate.

Having a synch phase for new connections would be good, too. Given that probably not all the terrain is deformed - or perhaps that not all the terrain is significantly deformed, there's lots of areas where you could save bandwidth. For instance, sending delta data instead of the whole terrain map could save you 50% or more depending on the size and overlap of explosions.

A quadtree update structure might be an efficient way of storing and prioritizing for transmission deformation information.

My two bits, anyway.

#18 Frederic is not an sdk owner, so any C++ changes are not realistic for him.

Jeff Tunnell GG

#19 Ah. In THAT case, it can't be done. The terrain object isn't exposed in such a way that it's accessable from the scripting side - that was somethin' I had added to my app. Bummer.

#20 Id like to thanks again everyone for their very interesting contribution on this topic.

It have give me alots of ideas/insight of what is possible to do in TGE (once of course i get my license to code ;-)).

@Jeff i am not yet a TGE SDK owner but soon, i will ;-)
(we are in the last phase of our evaluation of the engine,
a decision should come very soon! So far they are no other contender, like you have point out often they are no better deal on the planet ;-))