Potential Games

Looking for exciting new gameplay? Sorry, this month is a busy time. I have managed to implement some transaction processing improvements. Consequently, watch out for new client behavioral anomalies!

Specifically, I’m testing the client with non-blocking transactions. Previously, client processing would block (stall) to complete a transaction with the server. A transaction (round-trip client-server request-response message) is needed for almost all game interaction (walking, inventory control, combat). Transactions are designed to be quick, but interaction could become choppy under high network latency (lag).

Non-blocking mode allows the client to perform transactions concurrently and without waiting for the server. This prevents stalling the client, but has the side effect of delayed updates. For example, when dropping an item, blocking-mode would fully complete the transaction before the client became responsive again (the item would be removed from inventory and show on the world surface). In non-blocking mode, you can drop an item and keep right on playing, but the item may linger in your backpack a bit before appearing on the ground.

User interface smarts could hide some of this out-of-sync behavior. For example, when you drop an item to the ground, the client’s user interface could shade (and block use of) the item in your backpack until the transaction actually completes. In the event the transaction fails (e.g., something blocks the drop location), the user interface would relinquish control over the item.

These timing issues bring up stability and security concerns. In Part 2 of this article, I’ll discuss how the server deals with transactions to ensure stability and prevent cheating exploits.