Feature thought (for SB) - destroyable cubes

by Wolfgang on 04/15/2006 11:22, 15 messages, last message: 11/15/2007 22:22, 1786 views, last view: 04/22/2024 21:25

Yesterday evening before I got asleep I came to an idea for a feature that I think would be really, really cool for Sauerbraten - and is in full compliance with Sauer's minimality approach ;-) .

The idea is the following. In the map editor a level designer can mark cubes as "destroyable" (the developer team will find I fitting key for it I think).

When you play that map and shoot with your weapon at that cube it becomes destroyed - or even better: when you shoot with a light weapon some little cubes of a (big) destroyable block will disappear and when you use a heavier weapon (like rocket launcher) the number of cubes (of the big detroyable cube) will be a little bit larger (for example 2x2x2 instead of 1x1x1 "basic cubes").

I believe it should not create big trouble to implement it - the only thing that could become difficult is to get it to work together with the lighting.

What do you think of that idea?

   Board Index   

#1: ..

by FrenchMax on 04/15/2006 19:48

IIt's an good idea, why not... but ...
I think it's like the noclip for secret passages : You must find it.

But why not set in the cubes special textures which mean "this cube is destroyable" !

reply to this message

#2: ..

by CC_machine4 on 04/20/2006 16:53

you could make a "destroyable" material

reply to this message

#3: ..

by SanHolo on 04/20/2006 22:42

Glass for example could easily be recognized as "destroyable". =)

reply to this message

#4: Re

by Death(ChaosLLeader) on 04/21/2006 00:36, refers to #3

how about just have like a note when the level begins there is like a note to look out for destoyable cubes, I don't like the idea of a certain texture how about anything is destoyable. like barrels trees and cubes. it would be pretty cool to have a whole level where you had to tunnel though cubes to get around for multiplayer. but there could be a choice between a noticable cube texture and non noticable textrue like a normal wall texture.

reply to this message

#5: Destroyables...

by Pxtl on 04/21/2006 03:23

Really, this is a subset of the issue of "doors" - the problem is that doors affect lighting and culling in a strong way. Destroyables are basically doors that you shoot to open and never close. So it's all one big issue.

reply to this message

#6: Re: Destroyables...

by Passa_using_another_persons_pc on 04/21/2006 06:25, refers to #5

maybe for SP maps, when you recompute lightmaps, it saves 2 versions, one with all the doors open and one with all the doors closed.

reply to this message

#7: Re: Destroyables...

by Pxtl on 04/21/2006 14:34, refers to #6

Umm, how do you know which textures to update when a single door is opened? what happpens if the lightmap changes exist for two different doors on the same patch of ground?

One could brute-force it, compute every permutation of doors open/closed and then calc a lightmap of each... then just store the diff information from original so as not to waste space... but the computation process would be agonizing, and doors/destroyables would have to be used sparingly.

Simple destroyable md2s on the other hand shouldn't be too bad. Like barrels in Doom/Quake.

reply to this message

#8: Re: implementation thought

by Wolfgang on 04/21/2006 20:17

Pxtl, destroyable md2s would be a good beginning (but of course *only* a beginning ;) ).

What I personally thought how that could be implemented with lighting (after having read the answering posts):

for each "door"/destroyable cuboid (consisting of a*b*c simple cubes) we only calculate what has been changed when this one becomes opened/destroyed.

When more than one becomes destroyed we simply combine these 2 change light maps (the new light that comes from each of the destruction changes is simply added). I know that this is only an approximation (we ignore the more complicated dependencies), but I think that it could do it, since the new feature adds more to the gameplay then the approximation mistake removes ;)

If this leads to artefacts in some cases (which can't be excluded) I would say that it is in responce of the level designers to design the level so that such "evil" cases are avoided.

reply to this message

#9: praxibetel-aka-nic886

by Wolfgang on 04/22/2006 22:06

I agree: but there is only the single problem that when we have n destroyables there are 2^n combinations. And that grows exponentially (which is ugly as every computer scientist and mathematician should know).

So we have to use some little tricks like perhaps the one that I posted.

reply to this message

#10: Yep.

by Pxtl on 04/25/2006 14:23

For now, destroyable MD2s are probably the closest thing to attainable for now.

reply to this message

#11: ..

by makkE on 04/25/2006 17:42

Nah, destroyable md2´s will result in a mess. Md3 would work.

reply to this message

#12: destroyables

by pi on 11/15/2007 19:59

Whta if destroyables were assumed to be dark? I would not mind a few lighting glitches in exchange for the tactical implications of destryables.

I feel that sauer is limiting itself from expansion in the name of efficiency. Efficiency is a noble trait, and if it means that you wait longer, or work harder, so be it. But it should not prevent growth. That said, If this is not a direction aard wants to go, so be it.

reply to this message

#13: Re: Destroyables...

by tentus_ on 11/15/2007 21:04, refers to #7

We could make it so that the engine assumes that a destroyable cube will affect all the adjacent cubes or equal size. So, let's represent the destroyable cube as X.

-----
-OOO-
-OXO-
-OOO-
-----

All the O cubes would have an alternate lightmap as well as the X, but the - cubes would be unaffected. So, when X is destroyed X and O are swapped out in all three dimensions, and if any lightmaps extend beyond that range, oh well.

Alternately, if Sauer had a means to recalculate small areas individually, rather than having to do everything all at once, we could achieve the same thing- it would be messy and inferior, but it'd look right enough. It'd also be tremendously useful for mapping.

reply to this message

#14: Limited-area LM permutations.

by demosthenes on 11/15/2007 22:05

What if you calculated all-open, no-open, and all one-open possibilities? Or even all permutations for doors within a certain distance of each other?

Then each client draws in the LM for the closest open door and forgets (occlusion, ftw) about all the rest. No, it doesn't work with multiple open doors in one room, but as far as I can tell, it would be a *slight* improvement. Also works in MP, btw, each client drawing their own LMs on the map.

reply to this message

#15: ..

by SheeEttin on 11/15/2007 22:22

Perhaps the destroyable should be lit, but not cast a shadow?

Of course, if you built (for example) a wall with part of it destroyable, the shadow of the wall would show the wall as it would be when destroyed.
Not the best, but not the worst, either.

reply to this message

   Board Index