A lot of talking the talk, but not walking the walk, so let me add my two cents here.
I’ll just pick one quote but it’s been repeated several times:
First of all, you somehow seem to be fixed onto this whole idea of client prediction. While this is fine and dandy, and certainly required for fast-paced applications such as FPS or action games in general, it’s not the only way to do proper netcode. A popular example would be Factorio (albeit them having published a blog post just today stating that their netcode kinda sucks, for different reasons), where you can have literally thousands of entities moving around the map with little to no lag, even with high latencies. The key here is a lockstep simulation: Each client is simulating the whole world. In order to process a command, it sends it to the server, which validates and executes it and sends the results to the clients. Previously, Factorio did this P2P but switched, or rather is switching, to a more traditional server-client model. There’s a few more examples, such as StarCraft 2, League of Legends, WarCraft 3… I guess most of the “old” RTS did it that way. I have my doubts as to DOTA2 as it’s running on Source, a FPS engine that definitely uses prediction but then again, it’s possible that this Source is working differently. There’s a good reddit post giving some more insights into HotS’ networking code, where prediction isn’t exactly required either.
Anyway, the fact that each client simulates the whole world at any given time means you just have to assure that the code is deterministic at all times, especially with random() and what not. After that, it doesn’t matter how many entities or AI are around; all that matters is that the simulation is kept synchronised and to do that, you’ve just got to exchange the commands from each client.
This also avoids the racing condition (“both players pick up an item at the same time”), because first in, first parsed; so whose packet is received first/parsed first will have the item. The clients themselves won’t see the item pickup until the server acknowledges it. They can, if they feel fancy, add some prediction to that; as long as you do a proper rollback in case things don’t work out your way.
Point being: There’s many ways to do proper multiplayer and there’s quite a few which don’t involve prediction. I would even go as far as saying that for Stonehearth, prediction would cause way too many issues to be usable. It’s not impossible and theoretically could be added already by modders, but there’s zero reason to.
Stonehearth is separated into three parts: the client lua state, the server lua state and the GUI. Each of these parts are completely disjunct and can only communicate over a (HTTP) interface. The client side lua is handling things such as effects rendering, general rendering and GUI callbacks, while the server side is doing all the simulation. The GUI is a CEF application that can communicate with server and client using some magic HTTP API.
While this is, of course, no “true” multiplayer experience, it’s already the required separation for later on. It’s not a monolith where server and client have to be painfully separated (like for example Minecraft).
The communication works over some proprietary RPC protocol which allows the GUI, server or client to call functions in the server or client domain. The whole thing works with futures/promises and every function (“command”) does not only get the parameters, but only the caller/client.
On top of that, there’s already code in place for the whole “player” thing, although it’s hardcoded in some places. As the development of races goes on, so does the code. In the first Alpha, players were literally just a string called “localplayer” or “player1” or something like that. Meanwhile we have (proper) factions and objects and there’s nothing stopping multiple players from being present in the simulation, to my knowledge.
So saying that there’s absolutely zero preparation, just because it’s not featuring the prediction that it doesn’t need and won’t get anyway, is a bit unfair.
That’s an assumption if nothing else. There’s a dozen reasons why some units start moving and others don’t, this starts with “they have to find a path” to “the AI is currently busy with another task and cannot deal with your request immediately”. For example, if you added a 30 second idle animation to your units, it would be possible to delay every single action by up to 30 seconds, because that action might not be aborted. This is much more an AI/pathfinding issue if anything else; although of course, the CPU is the “final frontier” on those issues as well. I doubt that even with more CPU cycles available, your units would start to move earlier.
This is assuming that
A) there is already prediction implemented, which doesn’t make sense giving that the only client is a local one and latency is expected to be non-existent.
B) the client actually has an idea of what the command does, i.e. the AI is running on the client side too (which, with the current definition of server/client, it is not).
Once again, client side prediction isn’t required for multiplayers. It’s merely smoothing the experience because of the issues you’ve mentioned (latency/bandwidth). If you’re fine with units jumping around like crazy, prediction isn’t required. I wouldn’t expect prediction in the few iterations of multiplayer anyway - it would be wasted resources.
Well, so far your predictions (excuse the pun) have been somewhat off-road and wonky at best, so this statement is kind of weak.
So you patch the binary itself, that’s not impossible. There’s been worse programs/games that have been patched, including multiplayer. It’s a completely different difficulty level than doing it with the source code, but saying that nobody is ever going to do it is quite an assumption.
To be bloody honest, I don’t see much more in these posts than “Ten Reasons why games need client prediction to have multiplayer - #3 will blow your mind!” mixed with a bit of "Twenty failed Kickstarter projects". I have my personal doubts that Stonehearth will have an awesome multiplayer, but I doubt that it will not have one at all. I’ve been doubting them wrongfully in the past, so I’m always happy to be surprised with something I didn’t think was possible.
