Trap boulders & co

[Bertram]

Heya,


Trap boulders:
As we're in the middle of the trap specs on github, I wanted to say that there is the following class implemented in game:
TrapBoulder.cpp/h

Can someone tell me how it is supposed to work? Is there a model or icon missing maybe?

& Co:
Should I open an issue about making the cannon rotate toward its target?
Should we do that now or later?

Best regards,

[Akien]

Should I open an issue about making the cannon rotate toward its target?
Should we do that now or later?

Seems like a good idea. We can maybe plan it for the 0.5.0 release, so set it on Later at first. I think we can understand Later as "it's not a high-priority feature, but if you find it fun and easy to implement, feel free to do it". It's a hobby project after all, so the milestones are not too strict IMO, we do what we want (keeping in mind what has the highest priority).

[Bertram]

Hey,

Seems like a good idea. We can maybe plan it for the 0.5.0 release, so set it on Later at first. I think we can understand Later as "it's not a high-priority feature, but if you find it fun and easy to implement, feel free to do it". It's a hobby project after all, so the milestones are not too strict IMO, we do what we want (keeping in mind what has the highest priority).

Completely true. You're right. I'll open an issue and set it to later. If someone wants to take it, it will be there, ready for that.

Ah, while I'm thinking about it:
The cannon trap is dealing 104-120 HP per hit atm as seen here:
https://github.com/OpenDungeons/OpenDun ... on.cpp#L32
As the average HP / level is 2-5. I do think that dealing 5-10 HP would be more than enough already as a quick-fix, even if the game isn't balanced yet.
Would you be ok with such a, even temporary, change?

Best regards,

[Akien]

The cannon trap is dealing 104-120 HP per hit atm as seen here:
https://github.com/OpenDungeons/OpenDun ... on.cpp#L32
As the average HP / level is 2-5. I do think that dealing 5-10 HP would be more than enough already as a quick-fix, even if the game isn't balanced yet.
Would you be ok with such a, even temporary, change?

I agree. I think as long as the game isn't properly balance, any such change can be done as long as it follows common sense. IMO, you should feel free to tweak any value that might improve the current gaming experience.

What is needed though is to have a good idea of which variables (hardcoded or in a catalog) should be tweaked when we do the proper balancing.

[Bertram]

Created cannon rotation (and size) issue:
https://github.com/OpenDungeons/OpenDungeons/issues/177

I agree. I think as long as the game isn't properly balance, any such change can be done as long as it follows common sense. IMO, you should feel free to tweak any value that might improve the current gaming experience.

Ok, I'll make a pull request. If someone is against, he will be able to tell it there.

What is needed though is to have a good idea of which variables (hardcoded or in a catalog) should be tweaked when we do the proper balancing.

I also agree. The trap damages and room/trap hp per tile should be considered while balancing, and thus part of the config.

Best regards,

[hwoarangmy]

IMHO, we could define traps like creatures (being able to add traps by changing a config file).
A trap would be defined by its kind :
- hidden : appears when triggered. Cannot be attacked. To kill it, a Kobold needs to claim its tile. example : spikes
- visible : always visible. Can be attacked by creatures. example : cannon
- camouflaged : appears only when an ennemy creature is nearby to ennemies. Can be attacked while it is not hidden. If no ennemy creature is nearby, it is hidden for ennemies.

We could also define missile types :
- Bullet : deals damage to first creature / Room / Attackable trap hit
- Spell Bullet : casts a spell when it hits something

Then we could define models for them
And their definitions : range, attackable entities (creature, room, trap), price, damage, ...

[Bertram]

I would add two things:

Once a trap has been made visible, it should remain visible to the player, whatever its visibility to the creatures is.

Danimal wants to add a cannon with a mobile part and a fixed part. AFAIK, he will need to create two meshes, but feel free to correct me if you've seen a way to rotate/move a submesh independently.
Thus, at some point, we might need to add support for a list of meshes for OD entities.

I'm ok with the rest in general, even if I think it should be made configurable later, once the config manager and the entities loader are done.

Regards,

[Danimal]

Trap boulders:
As we're in the middle of the trap specs on github, I wanted to say that there is the following class implemented in game:
TrapBoulder.cpp/h

It sounds like it is the rolling stone from indiana jones, i thougth it was never implemented

[Bertram]

Ah ok. I don't know what the code does yet, Though.

[hwoarangmy]

Ah ok. I don't know what the code does yet, Though.

From what I've seen, nothing

Now that we are talking about traps, I've seen in code they are handled like Rooms : they can be on several tiles but they have no active spots and do not handle absorbtion.
I think we should decide if we keep this behaviour or if we stay on 1 trap <-> 1 tile.

IMHO, using several tiles per trap only makes sense if we want :
- Have traps that deals more damages if bigger (something like a gas room)
- Have traps that have a minimum size before being possibly triggered

In any case, if we keep the room like behaviour, I think traps should extend rooms.

What do you think ?

[Danimal]

nah, too complex

[Bertram]

Hi hwoarangmy,

Now that we are talking about traps, I've seen in code they are handled like Rooms : they can be on several tiles but they have no active spots and do not handle absorbtion.

Sorry, I don't get it. You say they are like rooms but then you say their behaviour differ?

In any case, if we keep the room like behaviour, I think traps should extend rooms.

Could tell me more about your idea?

Regards,

[hwoarangmy]

nah, too complex

What is complex ?

Sorry, I don't get it. You say they are like rooms but then you say their behaviour differ?

I'm just saying that the code is almost the same as room. As I am currently integrating Spike trap and allowing traps to be destroyed by force or claiming, I prefer to understand the philosophy
Currently, traps are more like Tile container.

Could tell me more about your idea?

If we say we want a Room like behaviour, for example a trap that could not be used if too small (for example if it needs 3x3 tiles), we could extend Room to share its code.

To say things simply, not talking about code, to decide, we need to answer these :
- Do we want traps that deals more damages if bigger (for example a gas room - if 1x1, it would deal 2 Hp/turn, if 3x3, it would deal 5 Hp/turn)
- Do we want traps that have a minimum size before being possibly triggered (Do not do anything before a minimum size - like training room)

[Bertram]

Ah I see better, thanks for the explanation.

- Do we want traps that deals more damages if bigger (something like a gas room)
- Do we want traps that have a minimum size before being possibly triggered
This will first depends on whether an artist will agree to provide graphics that fits all the cases if we go that way even if I know we're a bunch of pragmatic guys.
IMHO, it would be better, at least for the current release, to stay simple on traps. As a player I'd be annoyed if I realized my trap doesn't work because it's not big enough, for instance, while funnily I'd understand it for a room.

So it would be a 'no' for me while I understand how desirable such a feature can be.

@oln, @akien?

Regards,

[Akien]

nah, too complex

If even our gameplay lore-master finds it not worth it to put too much effort in room-like traps, I'd say let's go with the simplest solution for now. If we find awesome gameplay elements that would rely on multi-tiled traps, then we can reconsider. But for now it's really secondary IMO.

[Danimal]

Yes, its just going overboard, a one tile trap is just as effective as a 3x3 room that just spawns one active object trap at its center (and way less complicated); if you need more damage simply lay more traps near each another, the reduced space also helps creating a corridor of death.

If we find awesome gameplay elements that would rely on multi-tiled traps, then we can reconsider. But for now it's really secondary IMO.

Thats rigth, if we find something that justifies having room-traps ill comply.

[Bertram]

Can/should the temporary and unused trap boulder code die?

[hwoarangmy]

Can/should the temporary and unused trap boulder code die?

If we believe the comments in the file, it is just missing a boulder mesh to be usable. It should not be that hard to find, is it ? If a modeler can provide something, we could integrate it.
IMHO, if a modeler wants to work on that, we should wait. If not, we can drop it until it is required (as it is a pretty simple trap).

[Danimal]

i had something like that done in pixel style, i will convert it this weekend

[Bertram]

[Danimal]

Look here:
viewtopic.php?f=38&t=4100&p=59832#p59832

[Bertram]

Ah ah. A trap that damages anything in its path. Interesting. I'm not the sentimental type with my kobolds anyway. ;})

Time for an icon, what about this one? http://game-icons.net/lorc/originals/stone-sphere.html

[Danimal]

looks good

[hwoarangmy]

This will need a little bit more time to be implemented. Currently, the only working trap is the canon and, in code, damage is dealt by the canon itself when it fires. This will have to be changed so that damage is done only when the missile (being a bullet or a boulder), will hit something. It would also allow to pickup a creature before it is hit and, when FPP will be ready, to dodge bullets.

[Bertram]

Do you want me to do the win32 release, or do you want to release something first?

No pressure though. I know it's an uneasy subject, especially as you are tracing the road on traps in the code atm.
And we have already so much new things to show.

Best regards,