It’s only natural to avoid game crashes, make sure to not forget that!
So I’ve been busy trying to fix potential memory leaks in the lobby and have reduced most of them. Crashing might actually bypass this however. This is probably something I won’t be able to fix with the help of blueprints as the execution priority sometimes isn’t perfect.
Earlier in development we noticed a problem where leaving a session as a client didn’t notify the server of that. So in the server browser you could see that two players were connected to a session, even if one of those two had left the session. That problem seems to have disappeared, but I’m afraid it might still happen if a client crashes.
When working with changing levels in an online session, blueprints might not be a good option all of the time. You get two blueprint nodes to change level with: Open Level and Execute Console Command.
Open Level Open Level with its default settings would make a server disconnect all its clients, as it calls on a function that’s made for single-player. While you get a text bar for adding additional commands, that won’t change the fact that the node calls the wrong function.
Execute Console Command Execute Console Command should theoretically work with Server Travel, but is really a bridge of thin glass in a shipping build. If it works one time, it’s not guaranteed sure to work one other.
Server Travel I made my own Server Travel node to avoid the problems the nodes above have. This node also allows us to have more control over parameters necessary for the ServerTravel function.
As for choosing an in-game-name, I left that to Joel who took that task of my shoulders when I was working on some memory leaks.
After this blog I will move on to working on Client-Side Prediction. What is Client-Side Prediction you might ask? It’s the reason players with bad connection rubber-band, in short.
How this work is that when a client doesn’t receive a desired input from the server, let’s say the position of another player. The client starts to predict the position of the other player based on the last received input from the server (Position, speed, acceleration, direction of force, etc).
The next time the client receives an input from the server, that input will completely override the client’s prediction, if the predictions were right, you wouldn’t see much of a difference. But if it was something like 10 meters of the mark, you would experience rubber-banding.
Some might now think, then why use prediction? Doesn’t it create more lag?
No, in fact that would reduce lag significantly. If a game had no prediction, we would only see players lag forward instead of a smooth movement and experience input delays if the host’s and clients’ internet weren’t flawless. I will do my best to have a preview of this for the next blog.
That’s all for today, be sure to check out my dev blog next week, which will be my last blog during this project.
0 comments