OpenKeeper
OpenKeeper copied to clipboard
tonihele
Implement vision & hearing for entities (traps & creatures)
Implement vision & hearing for entities (traps & creatures). For actually starting to get dirty :) I'm anxious to get the level 1 to be playable already! I have no idea what to do with hearing, but since it comes with the same method really...
I asked this in the forums: https://hub.jmonkeyengine.org/t/what-is-the-best-way-to-add-vision-hearing-to-game-entities/37323
And that gave me an idea, we are 2D game, so forget everything about ray casting etc. Unless the original really used them. But I have this wild idea that once per tick arrange all creatures to map tiles (TileData, List<CreatureControl>, or by ownerId to Map<Short, List>) by getting their coordinate, also doors and traps should be put here (the boulder trap is the only moving one, but I don't know if it matters, so they could added when they are added normally). I think the other kind of objects, such as room objects do NOT count as visibility blockers, doors probably do. So ray casting is something we don't need. And this way they are accessible to all without n*map.get() etc.
So now they are in our regular map matrix. Check visibility (to all directions? or is this where the hearing comes to play?) just by checking the neighboring tiles, solid you can't see through (diagonally also no seeing..?).
Like so :) Vision & hearing are essentially same except hearing is 360 degrees and seeing 180 degrees to where facing (only N, S, W & E). I guess some have poor hearing and somebody can sneak on them. Etc.
It looks easy if the obstacle is on a straight line with the creature, but otherwise we have to calculate more of a cone like shape. The question is how exact this needs to be.
And we should definitely have a visual representation for debugging.
Yes, visuals for debugging. This is a start, but I recon we never need cones etc. Somehow I believe that the original was very very simple. Nobody can really tell did the creature hear or see the target when it sensed one.
For scenario 2 maybe even all of G, H, I & J is not seen to make the algorithm more simple, the hearing compensates here.
This data can also be used in minimap.
I yesterday just looked the stats for Imp only and I've never really observed this in the original game.
Not the best visualization, but it is a start. Maybe somehow should just enable/disable with interaction
to a creature and draw its arrows and maybe a grid of tiles seen.
https://github.com/tonihele/OpenKeeper/compare/master...ArchDemons:complex_fix
I change CreatureControl and StateMachine. Looks better but sometimes catch threat make changes in other thread.
@tonihele, I can extract other fixes if you do not want to merge this changes
I don't accept those changes, sorry. That is the opposite I try to do. In your code you are making the AI responsible for visual stuff, also you are updating (at least in some places) it in the render thread. What I want is that we have models, logic, all that as separate stuff, in its own thread. Visual stuff is just a slave listening for the changes. With AI + visual integrated into one (mixed with the regular Control), it just can't work with multiplayer. And like you said, concurrency issues hint that the design is difficult to handle, much like our current one.
In the new design the packages are more sanitary too, all game code is under game. Visual stuff is just visual and game stuff is all like: "tiiidididi can't touch this" for the visuals.
And wont this make the creatures possibly have a god mode: https://github.com/tonihele/OpenKeeper/compare/master...ArchDemons:complex_fix#diff-f913becfe79f04519e48d648c550b051R208
If the fatal blow is not exactly the amount of remaining health, deduct 0 health.
In perfect world our game models, logic, map generation reading don't require any 3D engine to run (that is why I even used Vector3f from javax.math there). Only the visual part does needs an engine. And with interfaces and what not one should be able to easily bolt another engine there.
Visual stuff should be isolated in one package.
Our Entering Dungeon animation does not work because in Entering_Dungeon when update it is changes to IDLE. No wait when animation completes. How you want fix that @tonihele (without getting animation state. Because animation - visual part) ?
Now we have ugly playStateAnimation(), onAnimationCycleDone(), onAnimationStop(), isStopAnimation(). Animation change stateMachine, but stateMaching can`t change animation. This is absurdity.
our state machine - simple enum, which do nothing
Well, the entering dungeon animation worked before. I haven't checked lately.
Of course we need to sync the AI to animations. And I do not have a ready pattern for this, but it most certainly can't be the real animation playing. Perhaps a time unit or something and what is the design then. I don't have perfect solution for this. But the game should be able to simulate without visuals.