@asser_fahrenholz Now I remember something: In World of Warcraft a spell lasted shorter than it actually lasted to account for latency:
Imagine Firebolt takes 2 seconds, then the game had a configurable(!) setting, say default is 100ms, then you could re-cast another spell after 1900ms or start walking again after 1900ms (but the spell bar still moved until 2 seconds).
There were two possible outcomes of that: It worked or the spell failed/recasting didn’t work. So I guess the setting is set so that you can cast again and the packet just appears in time after said 2 seconds.
Now I still have a few more questions for Mr. Speed though:
A) I’ve reworked the way movement/sprinting is handled and while it technically works, it exposes a bug which to me feels like a memory corruption / multithreading issue / strange thing. Now since we’re using Java this is more than unlikely, so I don’t know what’s wrong there. One fact is that changing the value of an unrelated variable and even changing something in other places of code changes the bug. My best guess would be that in the Physics Character the Controller Approach you use doesn’t work, but that doesn’t fit to the symptoms. Now onto the facts:
What I did was to make the client only send the walk direction together with a sprinting flag because of 3 facts:
- That way you always walk 3 units / second and not sqrt(2) * 3 [when you’d press W and D, you’d walk 3 units/s in both directions).
- Prevent cheating by simply modifying the speed value, that way the client only ever sends the direction
- Make room for further boolean state movement types (isDucked, …)
The code is here:
The Problem is the CharInputDriver: vTemp is always wrong and most of the time showing 1.5f in the direction I wanted to walk (though the Debug State shows that the Spatial moves at 0.5 at most). When I stop walking, vTemp still lags behind quite a few frames even though the visual representation again does not:
Now here’s the catch: when I change the code, that means the constant runSpeed without EVER sprinting, I can walk faster (when decreasing runSpeed, with runSpeed 4 you can barely walk). Due to the values, I’d suspect the applied force overcompensating the speed so that in the next frame it’s braking again. But if that was the issue, I’d see the sign always changing, I more suspect that when I change the code, the execution time is influenced, because I also saw that: As I was only moving the world spatial, the behavior changed, which shouldn’t be at all, because that was view-only. And I’ve discovered it makes a difference between launching the project in IntelliJ and with gradlew, with gradlew you can walk faster…
B) We still have the lemur problem with Jaime as posted above unfortunately.
C) This little side project really increased my interest in the whole networking stack but I have to say that I didn’t feel that comfortable in the code base, it felt foreign and strange to me, probably because it’s far away from jme’s “rootNode.attachChild(assetManager.loadModel())” and instead is adding a value to two enums, adding code to a huge switch statement, having lots of code spread across many parts, so many considerations to do.
I fear that when I’d port my game, I wouldn’t have the same behavior any more in single player (this starts with the 100ms delay thing). I’m not at all afraid of the coding undertaking but that it ends bad and I throw away either 3/4 of my game or the networking branch.
Simple Issues I have so far is that I’d prefer to have a headless jmeApplication at least for the AssetManager and using AppStates broadly instead of GameSystems (again not an issue, whether I’d use one or the other doesn’t matter, I could probably even write a wrapper class).
Another thing is that the code isn’t split into client, server and shared and so I jump through the code like a headless monkey. I guess this is also only an issue of Gradle Magic.
I know that I may be asking the wrong question on purpose: Can I adopt/modify the SimEth ecosystem so that it feels natural to my code base? Because currently it doesn’t feel like being bolt on but instead being the mortar between the whole game bricks. If I only think about the AI Systems and synchronizing them to still keep the client completely up to date so that it does predictions right, I get an anxiety disease
And the second question would be: I’m like 80% through my game code-wise. Finish the game and bolt on networking or do it now? I mean it’s too late in both cases, but I’m leaning towards finishing first to at least have something. For Motivation and to not have to worry about how the systems should work when doing the networking code.