First Post Redux

My last blog kind of fell apart, mostly because my life really isn’t that interested, and the interesting parts aren’t really safe for public consumption ;) Here is my newest attempt to maintain some decent documentation of what I’m doing, and for a change I’m going to focus it more towards my game development and technology-related thoughts as opposed general life goings-on.

In this issue of the Amazing Spud Adventures…

Networking in Real-Time

This is a topic that’s been on my mind lately. What is the best way to network in a real-time environment? For pab (my, and a couple others’ pet project) multiplayer isn’t exactly a focus, but for completeness and versatility’s sake I’d like to include networking capability into pab’s engine, which has brought up a few interesting points.

Entity Replication

This is a pretty simple thing to do, and is more of a code reduction issue than it is a true networking issue. An effective game engine should not force game-level coders to craft their own replication packets, nor should it expect said coders to invoke entity replication manually. Such low-level shenanigans are better left to the engine itself, both as a way to reduce error and reduce code complexity at the gameplay level. I’ve been thinking about ways to best implement this, but it leads to the next issue.

Tweening, Lag Compensation, Movement Prediction, and Server/Client Precedence

Say a nearby player’s position is updated every 20ms to avoid flooding your connection with unecesarily frequent updates, what happens in the real-time environment between entity updates? Clearly the player cannot “snap” between server updates. The obvious solution here is to have the server update not only position, but also heading and velocity of mobile entities. This will allow the game to tween the movement of said entity between updates. In heavy (or inconsistent) lag environments, though, this breaks down pretty quickly. If the object is traveling along a curved path (most likely), a straight tweening method with heading and velocity simply will not do.

Alternatives including cubic spline fitting, to best predict the movement of the object in the short term, project its course based on historical data over the last 4-5 updates. This will suffice for the vast majority of movement types, but is also not perfect. What if, for some freak reason, the server update indicates a position that is completely off from client-side prediction? Logic will dictate that server updates take precedence and the object will error-correct and “snap” into the new position. But even the best lag prediction methods are far from perfect, and small discrepancies will occur between client side prediction and server update. In this case do we still snap? Or do we attempt some sort of blended tweening to get the entity into the right position without such a noticeable and glaring motion?

Food for thought I guess.