Times, trials, and turbulence.
Lesson Learned(tm): Game synchonization
Tonight’s testing session was a most illuminating one. I managed to get up to five players on total at once, which is (surprisingly) the most that the game has seen at this point. The networking engine seemed to handle the multitude of players pretty well, and there no were visible lag spikes. We had a couple of overseas players that suffered from a fairly unavoidable latency addition.
(As always, massive thanks to tonight’s host of testers (Knarkles, Rip-Off, Prinz Eugn, and Danger))
The lesson: following the rules can be “bad”.
The session was going pretty well overall, when some “strange” things happened. Really peculiar things like players sometimes being unable to throw their weapons away, or players claiming items were on the ground in spots that the server saw nothing at, and the ilk. In a nutshell: really weird synchronization bugs.
As you may know, Skirmish has a lot of logic dedicated to propagating changes in props across the network to other players in an attempt to keep the game simulation looking and behaving the same on all of the clients’ computers. The problem is herein: the server sends out messages to clients dictating what events are to transpire. However, there is a fair bit of client-side logic that prevents seemingly impossible things from happening.
For example, there is a restriction that the player can only have a certain number of certain items in his possession at once. Such as only 1 Assault Rifle at a time. What happens if a client has 1 of these items, but receives a message from the server saying to add another to their inventory? Huh? What does the client do? Allow this should-be impossible action to occur anyways (on the basis of, “the server said so”), or stop it outright, knowing that it’s just not sensible?
The current logic is set to work such that client-side logic wins the battle in the case of an argument between server commands and illogical actions. The problem is, this causes some pretty nasty synchronization problems when the server tells the clients to do something that is (from the server’s perspective) totally logical, but the state of the clients says that it’s just plain silly. Normally it’s not a problem, but even tiny slips in client-side logic can lead to all of the nasty bugs that I mentioned earlier.
All of that said, the lesson is that there needs to always be a very clear course of action for any significant event that can occur. And when there isn’t, the client needs to keep a verbose log of whenever local client-side logic prevents a server command from being carried out. For anyone else embarking in any online game projects, I beg you to keep this in mind. If you don’t, some of the nastiest to track down bugs will rear their ugly heads. 🙂
Artistic talent climbs aboard!
By some chance, I happened to be low on testers and invited him into a short Skirmish testing session. Nothing fancy, certainly, but soon after he expressed his interest in doing some sprite-work for Skirmish. He’s not contracted or anything to the project, but has agreed to do some art (specifically, firearms and player sprites) on a as-he-has-time basis.
I’ve recently plugged some of his revamps of the existing weapons into the game, and I’m liking them a whole lot. It’s hard to tell when you have sprites so small, but overall just the look and feel go a long way in making things look more professional. I was practically oozing with anticipation when he mentioned the reloading animation he was working on.
Anyways, a huge kudos to Mark for his interest in Skirmish and the stuff he’s working on. I’m looking very forward to plugging more of his stuff in! 🙂