An interface system design solution suitable for online games

Speaking of the interface system, anyone who uses C ++ programming on the Windows platform will know the MFC, and I have also developed a single-host game interface system following the design of the MFC. However, most people now think that MFC is a poorly designed, complex, and difficult to use system. It takes a long learning process to program using MFC. The interface logic is dispersed into various window classes. To implement a complex interface, you have to create a derived class for almost every window in the interface, and embedded the interface logic into these window classes. The entire interface forms a tree structure consisting of parent window, Child Window, controls, and other objects. Many messages in this tree structure find their processing functions through broadcasting. To manipulate a child window or control, you have to find the parent window that contains them first, and then access the child window or control through the parent window function or member variable. These features force the interface logic to understand the organizational structure of the interface, and even rely on this organizational structure, it is difficult to achieve the separation of logic and the interface structure and layout.

The game interface has its own characteristics. For example, the game interface is often relatively simple and does not need to be too complex in structure and layout. It can meet the needs of specific games, it will not be used to implement various applications like MFCProgramIn the face of a large number of different needs, and even to achieve unexpected needs, this requires a system such as MFC with great flexibility and customization. In addition, the game interface system is often implemented in C ++, and its users may be various scripting languages. This cross-language interface is more concise and clear, the interfaces between modules implemented in the same language can be complex and take full advantage of the features of special languages.

Therefore, our goal is to create an interface system that is different from the MFC structure and is suitable for game features to avoid the disadvantages of the MFC. We use the wow interface system as a reference and hope to implement a similar system. It should be noted that I have never played wow, and of course I have never used its interface. However, I have heard a lecture about wow Interface System and read the operation demonstration, therefore, I do not guarantee that my understanding of the wow interface system is comprehensive or correct. If there are any errors, you can reply to the discussion. In addition, this design also references QT, and I have a preliminary understanding of QT. It is just for your reference. In addition, this design is still a concept and has not been implemented yet. Many details may still be discussed. You are also welcome to reply to the discussion. The following describes the specific design scheme.

The interface system is divided into two parts: C ++ and script language. C ++ implements various window classes, controls, and various managers and auxiliary classes. During runtime, the C ++ module stores various window and control class instances. They are organized into a tree structure based on the layout. The parent window contains its subwindows, the Child Window contains the controls on the Child Window. This tree structure is hidden in the C ++ module and invisible to the script module. It is used to maintain the creation, destruction, and movement of the interface system, for example, the parent window is used to create its child windows and controls. When the parent window is destroyed, the child windows and controls are destroyed, the parent window moves the Child Window and controls following the movement. The hidden, displayed, and stacked behavior of the parent window also controls the corresponding behavior of the Child Window and controls, the essential behavior of tabs, scroll bars, and various buttons is also completed by the C ++ module. After the C ++ module is complete, all interfaces created for the system are completed in the script module, and the C ++ module does not need to be rewritten.

From the perspective of the script module, the interface system does not see the tree assembly structure inside the C ++ module. Instead, it is replaced by a flat list structure, all windows and controls in the interface system do not depend on their layout. An Interface script package can be considered as an interface plug-in, which implements one or more windows. When the script package is loaded, the system will call its initialization function. In the initialization function, you can load an interface configuration file, or create an interface object through a set of script statements (the system assigns a globally unique ID for each interface element, this ID can be obtained by adding the Control ID in the package to the basic ID assigned to the script package by the system), and registering the Event Response Function of a group of interface elements, which can be like this:

// Controlid: Control ID
// Eventid: Event ID, such as the clicked event of the button and scroll event of the scroll bar.
// Function: a script function that responds to the eventid event of the control whose ID is controlid.
Registeventfunction (controlid, eventid, function );

When the control whose ID is controlid generates an eventid event, the system calls the response function registered by the script package. When responding to a control event, you may need to manipulate the control behavior. For example, you can set the text content on a button as follows:
// Controlid: Control ID
// Text: the string to be set
Settext (controlid, text );

You can see that both the Response Control event and the control action are performed by the Control ID. Similarly, you do not need to know the position of all controls in the tree structure, you do not need to know who the parent window is. You can also use the function to query the parent window of the control if logic is required. In the script language module, you do not need to generate corresponding objects for each interface element, nor copy the tree structure in the C ++ module. All you need to do is register a group of event response functions.

The Game System also provides a number of internal game event notification messages, such as timer messages, player lifecycle changes, and player attacks. In the initialization function of the script package on the interface, a group of functions are also called to register all system messages that you are interested in with the system, which can be as follows:

Registinterestedsystemevent (syseventid );

When an event is opened to the interface system, the system checks all the script packages that have been registered for this event and calls the System Event Response Function corresponding to the script package, for example, onsystemevent. When the script package receives the timer message, it can query the system status and update its display. when it receives the message that the player is attacked, it can flash the interface to prompt the player. Multiple interface packages may be interested in the same system event and respond in different ways.

Next we will end this article with a picture.