We are making good progress with multiplayer. Today’s video features snippets from the dev team’s test session this week, which shows both overall progress and some new bugs arising from parallel development of a new physics/collision system by Tommi and Mikko’s work on multiplayer movement.
I asked Mikko to summarize some of the core challenges in WolfQuest multiplayer development. Here are his thoughts:
While Mikko works on multiplayer, Tommi is focusing on Slough Creek, so we’re making progress on both simultaneously. Which will be released first? Whichever one is ready first!An unfortunate fact of multiplayer games is that due to network latency things can never be synced quite perfectly. It gets worse the faster motion and more sudden changes there are. My principle here is that appearance is more important than accuracy to an extent. That's why I developed the movement algorithm which, while not 100% accurate, attempts to produce pleasantly smooth movement paths for animals. I prefer syncing things at a higher level, because knowing the intent of an action in advance makes it easier to reproduce the same action on other clients.
That movement algorithm is probably he largest single piece of work in WQ multiplayer so far. I guess another challenge which is constantly present (to my detail-oriented brain at least) is various performance aspects. C# does a good job of hiding memory management, but unfortunately it also hides the costs incurred by it. Various APIs like BitConverter will happily return dynamically allocated arrays without concern for performance. Closures are another thing where it's easy to accidentally allocate memory. Not to mention various Unity APIs - did you know that the Vector3.zero property creates a new Vector3 every time it's called?
One multiplayer-specific thing is making sure that things get synced in the right order. Animals need to have a flock, so the spawn event for the flock should be sent before that of the animal. Carcasses need some data from the origin animal, so the spawn of the carcass needs to be sent before the despawn of the animal. When a new player joins the game, care needs to be taken that various events regarding pre-existing objects are sent exactly once. That last one still needs a bit of tuning; if there are already at least two players in the game and another one joins they will get a duplicate spawn message for their own wolf (but the duplicate gets safely ignored, so it's mostly just an annoyance for me).
And then there's the actions which require some kind of confirmation from the other party. Like picking up a chunk from a carcass needs a request to the host to spawn the chunk. The existing code expects that it can get a result immediately, and at least in the chunk-spawning case there's no suitable special value to indicate that it's not yet ready. So I created a network future system where a request is sent over the network and a future object is returned which encapsulates the result together with the readiness state. The caller can then poll that object for readiness and continue with the operation once the result is available.
______________
We have released the first episode of WolfQuest 3: Anniversary Edition (Amethyst Mountain) for PC/Mac on Steam and itch.io, as Early Access. While in Early Access, we are updating the game frequently with more features, multiplayer, and ultimately the Slough Creek episode with pups. The mobile version will come after the game is completed on PC/Mac platforms. We’ll then resume development of the next episode, Tower Fall (DLC).
