It just happened to be some magical loopback-into-the-process one.īut extremely fragile and far from trivial when you’re talking about replacing the networking in client and server, and making both handle prediction, and making client aware of everything needed just to make prediction possible all starting with reverse engineering the existing code just to figure out how. This has absolutely zero to do with network, although - without you noticing it - it actually went through a network interface. It’s sending the command to the server, the server is queueing up the AI tasks, which are queued up in the AI component, which at some point gets around to execute them and after the path is found and the whole AI sequence is ready in the pipeline, is executed. In fact, if the client wasn’t “hiding” sending the command, your GUI would freeze up - which it doesn’t, because it’s based on promises. That’s a wrong assumption, especially when they have plenty of other construction sites going on. Yes, there are preparations for multiplayer, yes they are not complete, yes there are bits that definitely won’t work with multiplayer - but for some odd reason, you seem to anticipate, or even expect, to have some (or all) of the multiplayer functionality right away (like, right now, in this instant, or I’ll do terrible things to an innocent orphan kitten-right away). I think you’re still forgetting that, at this stage, it’s a singleplayer game. The behaviour I observed (when moving military parties) is undeniable proof that the client is not doing anything to hide time taken to submit the command to server and get a response. There are, or were, client-sided properties (I believe), which would indicate that at least on some level, the client already has its own “world”. I tend to believe that there is some sort of separation in place already, but I’m not sure to what extent. It’s possible that there’s zero netcode involved right now and there’s just one gamestate, it’s possible that there are two gamestates - I don’t know. It’s a much more sane approach to have it done in C++, which means that we don’t know what’s out there until we try it, I suppose. It would be an utter waste of resources to have the whole network protocol implemented in lua. So for all I care, and all we know, it’s possible that there’s already net-code in development in the C++ part of the engine, but we can’t see it (and we won’t notice it, either, because that’s something lua doesn’t need to know). how an entity is rendered, or positioned, or updated, is way beyond our scope - and rightfully so. We only know that there are two separate lua states that communicate with each other - but how the data is actually transferred, i.e. Plus, we have literally no idea how the code behind the scenes actually works. That code isn’t going to be five lines of lua. I also don’t quite understand how the server code is supposed to show you that it’s not lockstep - why would you expect a smaller server code for that? At some point, the whole simulation needs to be done, and all the input needs to be processed. My guess is about as good as yours, although it tends to be in the opposite direction. The server parts synchronise each other, while the clients do the client stuff. I could imagine, for example, that the server sides of each client (that is, player) are linked up with each other - either P2P or with a master server/server/client system. The server side is doing all the calculations, that is correct, however, this is the current case. I think it’s quite astounding what all seems obvious to you. Fortunately it’s obvious that Stonehearth is not designed for lock-step (if it was the “server” LUA code would be far smaller and very different) and this is all just a distraction - you’ve said yourself that “server side is doing all the simulation”.
0 Comments
Leave a Reply. |