inexorgame-obsolete / meta

A meta repository for all organization related issues
MIT License
0 stars 0 forks source link

Damage Material #12

Open SF-Fatality opened 9 years ago

SF-Fatality commented 9 years ago

I was helping on a map today and an idea arose while standing in a brick kiln. What about a material, like death or water, that damages you at a slow rate instead of instantly killing you? Kind of like standing in lava in Quake. It would be pretty useful for many instances on maps, like a heated room, quad damage room, lava, ice water, etc.

Croydon commented 9 years ago

I'm supporting this idea. Also the creators of each map should be able to configure how much damage the material should cause.

koraa commented 9 years ago

+1

koraa commented 9 years ago

A configurable material would be hard to do though, what do you think of an entity instead? (Xpos, Ypos, Zpos, Radius, Damage/s)

Croydon commented 9 years ago

A entity would never be such accurate and flexible as a material. I'm not aware of the source code, but when one goal is too make anything more modular and flexible it shouldn't be that hard to define another non-clip material and an is-player-currently-touching-that-material-check.

koraa commented 9 years ago

How are you going to implement two spots with different damage/s?

On 12/26/2014 12:49 AM, Michael wrote:

A entity would never be such accurate and flexible as a material. I'm not aware of the source code, but when one goal is too make anything more modular and flexible it shouldn't be that hard to define another non-clip material and an is-player-currently-touching-that-material-check.


Reply to this email directly or view it on GitHub: https://github.com/inexor-game/code/issues/65#issuecomment-68115808

Croydon commented 9 years ago

I suppose that's a general issue we should address. Because of that problem with different attributes for the same material there is water, water2, water3, water4, lava, lava2, lava3, lava4 as a nasty workaround.

Fohlen commented 9 years ago

+1

Zebrazilla commented 9 years ago

+1

Having been in a similar situation as this myself, I personally ended up taking the approach of adding attributes to the base cube struct - this may just as well be contained within cubeext however I'd imagine. This way I could have a material, which while doing its thing upon being inside it, would lookupattribute of the specified cube which had the given material and use that as a way of determining what to do and how to do it. Attribute in my case was just uchar but I can imagine you could use bitflags if wanted, or even have more than one set of attributes possible on a cube. Possibly flags along with an absolute value.

This naturally however requires world geometry loading and saving to be changed as well and each map to be converted to having these attributes (accomplished probably in the shortest way possible by loading in map not containing these values by setting a default value and then save it)

aschaeffer commented 9 years ago

A more flexible map format is also on our TODO list, and extending cubes with attributes makes sense. With a set of attributes it would be possible to do rather complex things including damage material.