Bertram {l Wrote}: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 {l Wrote}: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.
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
From what I've seen, nothingBertram {l Wrote}:Ah ok. I don't know what the code does yet, Though.
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.
In any case, if we keep the room like behaviour, I think traps should extend rooms.
What is complex ?Danimal {l Wrote}:nah, too complex
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 philosophyBertram {l Wrote}:Sorry, I don't get it. You say they are like rooms but then you say their behaviour differ?
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.Bertram {l Wrote}:Could tell me more about your idea?
Danimal {l Wrote}:nah, too complex
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.
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.Bertram {l Wrote}:Can/should the temporary and unused trap boulder code die?
Users browsing this forum: No registered users and 1 guest