Tell that Factorio, or StarCraft 2 (which, after all, is an E-Sport, and I doubt that most players play SC2 with a LAN connection). I’ve had quite enjoyable sessions with five people and even when one had to restart his router repeatedly, the worst that happened was a very short slowdown every few seconds. Annoying, but not an end-of-the-world condition.
Which is a problem you can’t solve. Forget it. The overhead required to even consider such a thing solvable is ridiculous, plus… Just, why? Stonehearth isn’t Quake, it’s not competitive-to-death. I don’t consider it a game where being faster will actually have any influence whatsoever on your success in the game. The very, very rare situations where two players intend to access a mutual resource will be so rare that I can’t even fathom how often they will occur during the whole lifespan of the game.
I think it’s quite astounding what all seems obvious to you. The server side is doing all the calculations, that is correct, however, this is the current case. 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 parts synchronise each other, while the clients do the client stuff. My guess is about as good as yours, although it tends to be in the opposite direction.
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. That code isn’t going to be five lines of lua.
Plus, we have literally no idea how the code behind the scenes actually works. We only know that there are two separate lua states that communicate with each other - but how the data is actually transferred, i.e. how an entity is rendered, or positioned, or updated, is way beyond our scope - and rightfully so. It’s something the engine must handle. 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).
It would be an utter waste of resources to have the whole network protocol implemented in lua. 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’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. We can’t know. I tend to believe that there is some sort of separation in place already, but I’m not sure to what extent. 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”.
Call it a theory if you like, but the fact that the client is a lua state and the GUI is a CEF process, which runs in a different thread, knows nothing about lua at all and doesn’t even have JavaScript functions that are able to directly call into lua and vice-versa, I would call them “separated in practice”.
If you don’t believe me, feel free to kill or freeze one of the Stonehearth.exe processes. If you get the right one, it will be CEF and your simulation will continue as expected. I think even the camera can still be moved, which is done entirely client-sided.
There is also no separation between “overlay” and “GUI”. Everything you see in the game is either rendered by the engine, which is everything 3D, i.e. the world (plus effects plus particles), or CEF. The overlay is CEF, every menu is CEF, every dialogue box or conversation is CEF. It’s all HTML/JS.
Yes, yes it does make sense. Read up on embedded HTML rendering engines, such as CEF, or Awesomium. They’re technically own processes running inside a host process, interacting with it through various APIs. They’re pretty much sandboxed otherwise and as I’ve said before, CEF doesn’t know lua, and lua doesn’t know CEF. For all they care, they could replace CEF with Awesomium or even an external rendering of the GUI and it wouldn’t make a difference.
By that logic, is there actually any kind of application or game that is fulfilling your requirements to be internet-proof? Plus:
I think you’re still forgetting that, at this stage, it’s a singleplayer game. 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). That’s a wrong assumption, especially when they have plenty of other construction sites going on. Rome wasn’t built in a day either.
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. 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. This has absolutely zero to do with network, although - without you noticing it - it actually went through a network interface. It just happened to be some magical loopback-into-the-process one.
For an Early Access game with a note on it saying “We’ve just added multiplayer in this update”? Yes. I think there would be quite a few people that, assuming it’s stable, would be pretty happy about MP. There would be a few complaints, of course, voiced by a very loud minority, as is always the case.
At this point, I’ll just leave “Euro Truck Simulator 2 Multiplayer” in the room and quietly leave. That game did not have MP, nor was it ever intended to be MP, nor had it anything even remotely related to MP - but a few guys patched it, added a client/server model, even a prediction so it seemed smoother. It wasn’t perfect, but for what it’s worth, it was amazing. I think there’s still a few thousand people playing today, simultaneously. It’s jumpy and far from perfect, but people like it for what it is: A trucking experience with others, even if there are inconveniences. And trust me, there’s a lot of them.
That’s not what I was saying. I was saying I don’t expect an awesome multiplayer, which is to say, a completely stable, lagless, 60 FPS smooth experience with up to 64 players, preferably from the other end of the world. In all honesty, latency is not as much of a big deal as you point it out to be. I’ve believed for a long time that networking was technically impossible due to the fact that it takes forever (read: 15ms) for a packet to get to my computer to another computer. And what if the packet is lost in-between? Or corrupted? Or taken by the government and filed, instead of being delivered?
Then I’ve started to play lots of online games, some from big developers, some from small developers, and I’ve figured out that sometimes, AAA can’t do networking even if their life depended on it (hello, SimCity 2013) and sometimes, it’s amazing how well a small development team can get it right (hello, Factorio, even if you currently dislike the current state of affairs, you’re doing well). It’s not predictable to say what will work and what won’t, but judging by the fact that there are so many games with multiplayer nowadays, it’s hard to imagine that Stonehearth won’t get any, considering their team lineup.
People will like multiplayer to play with friends, this is a gain. Of course, there might be things like stability (hello, Anno 1701 or newer), or the game is slower than in singleplayer, those are costs. In the end though, there are going to be plenty of people that will say that the advantages outweigh these flaws. Unless, of course, the implementation is a complete disaster, which is always a possibility, but I wouldn’t necessarily expect here.
