[vanishs]

Take the recently popular actor model as an example. Each player is an actor, which can not only ensure the simplicity of development, but also ensure the atomicity of the player's data in one operation. But if a player-to-player transaction system is designed, it is difficult for this actor model to achieve the atomicity of this transaction.

But Lockval Engine can easily do all this. Because Lockval Engine is data-oriented programming. It provides a pair of APIs: GetAndLock and PutAndUnlock. You lock the data when you fetch it, and unlock it when you complete the modification.

And this pair of APIs will also synchronize the modified data to the front end. In this way, you don't need to worry about how to send data to the front end when designing functions. Other frameworks or codes need to complete this function by themselves.

Other advantages include but are not limited to: In this distributed architecture, the atomicity of hot update code and configuration. It won't happen that half the system is an old script and half is a new script.

[flashgordon]

Can you elaborate on an example with games that have some form of "fog of war"? Or rather only some state is seen by X players?

[vanishs]

In Lockval Engine, a player data pair is on UID. A map block data can also be mapped to a UID. Or an observation point data can also correspond to a UID.

Lockval Engine provides a Watch function. Players can watch the UID of a certain map block or the UID of a certain observation point, so that a function similar to the fog of war can be realized.

This demo can be viewed in "Prepare a globalChat struct" and "send A message to globalChat" on the apidemo page. This demo can evolve a variety of similar functions.