Since it's not an action game pings up to 200ms or so are almost not noticeable and I'd say it only starts getting annoying at 500ms or so. The only lag anyone has depends on whatever their own ping is + the ping of the host. Once the stall is over the client that stalled runs the game at a higher speed to catch back up with everyone else again. If a client stalls the game continues for everyone else without them noticing anything. You're also writing that everything needs to run at a fixed frame rate, so the host is basically bound to which ever client has the worst framerate? Say a client would stall, what happens then? How does that work with late joining clients? The host will have replicate the whole world to them anyway no?Ĭorrect, when clients join late the entire game state gets replicated to them once and then they continue from there just as if they had been in the multiplayer session from the start. Since you have this deterministic approach to your networking solution instead of replicating everything. There's also nothing special about saves created in multiplayer mode, so you can simply continue playing them offline in singleplayer if you want to. Still would be somewhere around 3-6 months of work probably.Īny player on the server can save it and load it alone, or will clients not be allowed to save? It became easier now with the multiplayer mode since we could reuse a lot of the changes we had to make for that. I can't find the source right now, but I remember one of the Planet Coaster devs who worked on the undo feature saying it was one of the hardest things they ever worked on and I can definitely see that. It's certainly not impossible to do, just a ton of work and also not as easy as some people make it sound. imagine deleting a shop that had been linked to a depot, you wouldn't just have to restore the shop but also that link). This might sound easy at first since the game can already load stuff from savegames and blueprints, but this isn't the same as what we would need for a proper undo (e.g. But for example the other way around would be harder, restoring something that you have deleted. For a lot of stuff this would be fairly trivial, like if you want to undo building something you only need to delete that, which is really easy because the game supports deleting stuff already anyways. Next we would have to build the undo-actions for everything. It is possible now because we also needed that for multiplayer, that's the part that's the "same work" I was referring to in my previous post. The first problem is that the game would have to be able to record your steps at all, which wasn't easily possible before. Yes, both players need the same DLC if you want to use any (you can select which DLC you want to be enabled when starting a multiplayer session). Not totally sure yet if it'll work with an ARM Mac for example but so far it seems like it should. The main parts where we have to be careful are randomness (both instances need to have synchronized random number generators - they will always calculate the same numbers as long as we request new numbers from them in the exact same order on both instances) and we can't have anything depend on time, so both instances need to run the game logic at a fixed framerate (the rendering framerate can still be different). Guests won't take different paths because they'll calculate the same decisions. The short explanation is that if both instances are in the exactly same state and we're being really careful they'll never deviate, because all computations they do will always give the same results. Yes, both game instances have to be exactly the same :)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |