Asynchronous (latency) logic difficulties and Lua Solutions

Online GamesProgramFor a while, most programmers know that "Asynchronous logic" is one of the easiest mistakes in the game logic. The potential harm caused by money farming, experience farming, getting items without money, turning off services, getting back to files, deleting accounts, etc. In fact, it is even more interesting to have such problems in the banking system :).

Different teams have different names for such issues. I like to call them "Asynchronous ". This is a type of problem:

When a player meets a certain condition (for example, there are 10 gold coins on his body), a conversation with the NPC triggers a conversation option: spend 10 gold to get a prop. After the player chooses this option, the player loses 10 gold and obtains the item. The problem is: logically, this is a continuous event, but because the player clicks a delayed operation (we call it "Asynchronous"), there must be two entries in the program:

1. dialog between a player and an NPC -- determine the amount of money and open the NPC dialog box.

2. The player chooses the Exchange Option-(judge the number of money again), deduct the gold coins, and give the item

This example is very simple. The key is that the player's money may have changed some time later when it chooses to trade. People who have just started to write Logic Programs often forget the "Judge money again" step, resulting in subsequent logic errors. Similarly, inexperienced testers often miss this step, the risk of releasing this bug depends on the specific logic and is unpredictable.

In most cases, the judgment is more concealed than the above example. For example:

Players use paid items in specific scenarios. Trigger logic: 3 seconds later, summon rock. In three seconds, the main logic will call the implementation function of summoning the rock, and there are several situations when this function is called:

1. The previous player has gone offline, and the function should judge and quit.

2. the player has switched to another scenario. This situation is dangerous because if the scenario is not determined, the player will use the rock fall skill in another scenario. This example is indeed happening in a game :), and such interesting things must spread fast between players.

3. Players are locked and cannot use the rock fall skill. This situation is related to the specific design. If it is to be completely solved, it will be complicated, not just the problem of this item.

After several similar errors, logic programmers complain that such logic is too easy to write. I still feel this way. In fact, Lua, Python, and other languages that support "function re-entry" provide a good solution to this problem. Among them, Lua can use coroutine, and python can use yield and signal syntax. It is useless to say more.Code:

G_condition = 0 -- check function check_condition () If g_condition = 0 then print ('check failed. ') return false else print ('check OK. ') return true end return falseend -- operate a specific operation, which is divided into three steps. If (not check_condition ()) then return end print ('operating... 1 ') Local par = coroutine. yield () if (not check_condition () then return end print ('operating... 2 ') par = coroutine. yield () if (not check_condition () then return end print ('operating... 3 ') return 'finished' end -- The following simulated Master Logic is used to test CO = coroutine. create (operate) print ('test 1: normal procedure ') g_condition = 1 While true do status, value = coroutine. resume (CO, 'hahahaha') print ('ututine: ', status, value) if not status or value = 'finished' then break endendprint ('---------------------------') print ('test 2: The environment changes in the procedure ') g_condition = 1co = coroutine. create (operate) g_condition = 1 status, value = coroutine. resume (CO, 'hahahaha') print ('ututine: ', status, value) g_condition = 0 status, value = coroutine. resume (CO, 'hahahaha') print ('ututine: ', status, value) status, value = coroutine. resume (CO, 'hahahaha') print ('ututine: ', status, value)

Note: operate requires an environment variable (which can be player money, task tag, etc.) not equal to 0. If it is 0, this operation is terminated, and operate itself cannot be executed continuously, for example, a request for credit card deduction is required, and the operation has to be divided into three steps.

The above example demonstrates the entire idea. The idea of writing operator programmers can be consistent, and then insert interrupt yield where necessary, plus the judgment function, a very robust process will be written!

The reality is certainly more complicated than this. The interesting part is:

1. How to abstract a useful judgment function? I believe that many judgments in a project are similar and reusable.

2. Because the return value of the yield function can be sent from the periphery by the main logic, yield can also send parameters to the outside. Then we have an additional internal-external interaction method. With this method, we can implement the time callback interface well. I guess there will be many other magical functions as long as you want to do it.

3. In many cases, when the check fails, it is not a simple return, but a rollback to eliminate the previous impact. This is troublesome. I personally suggest that you provide a standard rollback method in the project, and avoid this situation as much as possible, in fact, most logic problems are easy to avoid rollback (the logic module should not register broken interfaces with upper-layer scripts for organization, instead, we should provide an interface that is as convenient as possible for a successful or failed sales :))

Simple and interesting things should not be mentioned too much. I believe that every programmer who enjoys it will provide different specific solutions. I don't want to worry about it either. I need to write code quickly.