Designing games with data-driven ideas

The game consists of two parts, logic and data. This is an effective division of the game. The logic section defines the core principles and algorithms of the game engine, while the data section provides details of its content and behavior. In the initial game development process, people always like to write logic and data are written in code, such code portability is poor, reusability is poor, but also prone to data disunity. If you want to make some changes, it may even be reaching.

Data-driven design can be likened to an object-oriented game design that stores game data in a file rather than embedded in the code. During the game, the data is manipulated by dynamically loading and reading and writing data files. The following points need to be taken into consideration when using data-driven thinking in game development.

Now a slightly more professional game is the use of data-driven thinking to develop, but the degree is different. And how to limit the system to the use of data-driven thinking to develop the game, so that the game has more custom features, improve the player's participation in the game is the mainstream of the future game.

the core of data-driven programming

The core point of data-driven programming is that humans are better at processing data relative to program logic . Data is easier to navigate than program logic, so we should transfer the design complexity from the program code to the data as much as possible.

(data is more manageable than program logic.) It's a good practice to transfer the complexity of the design from code to data as much as possible.

the core of data-driven programming

The core point of data-driven programming is that humans are better at processing data relative to program logic . Data is easier to navigate than program logic, so we should transfer the design complexity from the program code to the data as much as possible.

Is that really the case? Let's take a look at an example.

Suppose you have a program that needs to handle messages sent by other programs, the message type is a string, and each message requires a function for processing. First impressions, we may deal with this:

[CPP]  View plain copy void msg_proc (CONST CHAR *MSG_TYPE, CONST CHAR *MSG_BUF)    {       if  (0 == strcmp (msg_type,  "Inivite"))        {           inivite_fun ( MSG_BUF);       }       else if  (0 ==  STRCMP (msg_type,  "tring_100")        {            tring_fun (msg_buf);       }        else if  (0 == strcmp (msg_type,  "ring_180"))         {           ring_180_fun (msg_buf);        }       else if  (0 == strcmp (Msg_type,   "Ring_181 "))        {           ring_ 181_fun (msg_buf);       }       else if  (0  == STRCMP (msg_type,  "ring_182")        {            ring_182_fun (msg_buf);       }       else if  (0 == strcmp (msg_type,  "ring_183"))         {           ring_183_fun (MSG_BUF);        }       else if  (0 == strcmp ( msg_type,  "ok_200")        {            ok_200_fun (msg_buf);       }          &nbSP;..        else if  (0 == strcmp (msg_type,  "fail_486"))         {           fail_486_fun (msg_ BUF);       }       else        {           log ("Unrecognized message type%s\n",  msg_type);        }  }  

The message type above is taken from the SIP protocol (not exactly the same, the SIP protocol draws on the HTTP protocol), and the messaging type may also increase. Looking at the regular process may be a bit tired, it is difficult to detect the middle of a message, and, without adding a message, it is necessary to add a process branch.

According to the idea of data-driven programming, this might be designed:
[CPP] view plain copy typedef void (*sip_msg_fun) (const char *); typedef struct __MSG_FUN_ST {const