Brief Introduction to game logic and editor Abstraction

Original article: http://www.windameister.org/blog/2010/05/16/a-simple-approach-to-logic-and-abstraction-for-online-game-editor/

Recently, I have been involved in the development of the company's next-generation game editor, so as to have the opportunity to make some simple thoughts on the editor design-how to design better abstraction, so as to achieve on the client, server, and how much code can be reused in the game editor? How can we shorten the workflow of game designers (Planning) and Art Designers (3D/2D scene art) as much as possible? The excellent engines on the market are often accompanied by the income editor. How should we design such an editor? What can I learn from the online game editor?

I will not summarize the cost Text of the mature thinking results. My skills are limited, and many mistakes may not be fully considered. If you have any ideas about the problems described in this article or have other articles related to them, please join us.

Reuse of client Logic

The game client can be disassembled as a system with input, output, and internal logic loops. The player uses the mouse keyboard to send a message to the client, and the server sends the message to the client through the network interface. Then, the client draws the current performance to the screen at each frame.

Client input includes Windows messages (keyboard, mouse, other messages for Windows, shortcut keys, timers, and joystick) and network messages (messages sent by servers or other players ); the output includes: screen display and network messages (responses or requests sent to the server ).

In fact, a game editor can also be viewed as a system similar to the above. Its input includes Windows messages (keyboard, mouse, other Windows messages, menu shortcuts, and timers ); the output includes the screen display. Normally, the editor does not need to accept or send any network message (here, it refers to the logical communication with the server, instead of synchronizing data through the version control system ).

In fact, the editor and the client actually have similar input interfaces (Windows messages), but the same messages lead to different logics-here we can abstract the input interfaces, different implementations are used to implement the logic separately, so that the editor has the ability to switch the editing status and game status logic hot. (Many well-known game engines have functions similar to the above which can switch the editing/Game status in the editor, such as the crysis sandbox editor and runicgames torchlight editor ).

Specifically, you can design an interface similar to the following (only in a Single Window ):

class Operation{public:    virtual bool OnLButtonDown(POINT pt, UINT uFlags) = 0;    virtual bool OnLButtonUp(POINT pt, UINT uFlags) = 0;    virtual bool OnMouseMove(POINT pt, UINT uFlags) = 0;    virtual bool OnKeyDown(UINT nChar, UINT nRepCounts, UINT nFlags) = 0;};

(This only serves as a signal, so all interfaces are not listed)

In the actual program, we will hand over the windows message received in the message processing thread to this interface. What is the implementation behind this interface is the editor logic? (Is left-click an object in the selected scenario, dragging its location, etc.) or the client logic? (If you click an NPC or monster with the left-click button, the next action is triggered and the attack starts? Dialog ?) Our front-end programs do not care about the implementation logic behind the interface. In this way, we can achieve the purpose of Dynamic Replacement logic-in the editor, a key to switch the running mode.

What are the benefits of doing so (what you see is what you play? There are many benefits-if you cannot immediately see the game effect in the editor, then the game editors (usually planners in China, and many foreign game developers are level designers) you must first place all kinds of objects, objects, and events in the editor, export data, find the corresponding scenario in the game client, and test the objects set in the editor one by one. Compared with the design that is immediately visible (edited as you play) in the editor, this method adds intermediate links and increases the possibility of errors, when the problem is different from the expected results, it takes more time to locate the problem, thus reducing game development efficiency. In addition, due to the needs of game development and design, many of the data edited by the editor is not directly used by the game. Therefore, the editor needs to export the edited data because of the data exported by the editor, the client program needs to load the exported data, and there may be errors in exporting and loading (for example, the editor has added a new feature (version increase, file structure change ), the client must add or modify the corresponding code for support. Errors in these links will reduce the game development efficiency ).

A good design architecture encapsulates the logic behind a set of predefined interfaces, so that the same client/server logic can be reused in the editor, it can also be used in client/server programs (there are two levels of logic code reuse-the code level and the binary level. If there is no platform difference, then in a reasonable design, we should achieve binary-Level Reuse-that is, a designed binary dynamic Runtime library is used for loading by different processes; some logics may only be reused at the source code level-such as the server-side logic; of course, if you use the scripting language to write the logic, we can ignore the difference here ). When we switch the editor mode and the program is transferred from the editing status to the game status, the implementation behind the interface is replaced with the client logic, and finally the client operations and logic are forged in the editor.

In addition to the benefits of what you see is what you play, this abstraction of the input interface also has an additional benefit-the video replay function. The design of the game as an input and output system allows us to record all input events in chronological order (through the mouse and keyboard events of the input device, system/Timer messages, network messages, etc ). If we save all input events according to the time record, and then re-call the corresponding interface as input in chronological order, we will get a replay of the entire game process. StarCraft and other games have video functions, which allow you to record the game process and play it back. It should be based on similar technologies.

Furthermore, most of the logic in online games is running on servers. For example, what is the reaction to interaction with the NPC? What does the NPC say, What Optional tasks are provided, and what services are provided by the NPC, how the NPC acts, how the monsters act, what rewards the monsters get when they are killed, what skills the protagonists have, and what they can do (move, cast skills, and kill monsters, pick up items ). Such logic is not the client logic, but the server logic. How can we simulate these things in the editor?

Reuse of server Logic

Unlike standalone games, where the game logic runs on the machine, most online games often run on servers. This causes problems in game development-the edited scenario, the NPC and monsters cannot immediately see the actual situation, and the game designers often do not know whether the NPC is normal. The designer needs to export the scenario created in the editor to the server program. The server may need to restart the server once, load the data, and then the designer starts the game from the client, connect to the server and test the new content. (The process includes exporting data from the editor to the server, restarting the server, reading new data from the server, starting the client, and connecting to the server. Other factors may cause errors in each step, reduce development efficiency. Similarly, it is difficult for game designers to locate problems when the situations are different from expectations ).

Since I have not compiled server code, I am not very familiar with the architecture of the online game server. Therefore, the following analysis only refers to the integration of server logic in the editor from the perspective of personal idealization. The game logic running on the server end mainly includes the player logic (requests sent by the client to allow players to do things, status broadcasts of other players, status changes of players, and gamer data changes ), monster logic (actions, skills, AI, drop, rewards, etc.), skill logic (time of skill, damage, status, etc.), reachable location determination (where can I arrive, cannot go anywhere ). The server logic can also be simply seen as a large loop. On the one hand, events are created through messages received by the network and internal trigger mechanisms, and on the other hand, events are continuously processed cyclically (during this period, you may need to read the database, read server data, etc.), and finally make the output-send messages to players through the network, or write the database.

Splitting the server: We get a read (from data files/networks/databases), a logical loop (processing events), and an output (writing files/writing databases/sending network messages). Data files are often the data edited by game designers in the scene, or skill data, or other templates in the game (such as items, characters, monsters, and NPC, the database often stores gamer data, character skills, character levels, attributes, and items.

After thinking about it, we found that the game data files, various data templates, timers, and triggers required by the server logic are exactly the data owned by the editor. For network access and database access required by the server, a network layer and database layer can be forged through the proxy mode, run the server logic in a non-Real Server Environment (although the server logic runs itself in a server environment ). This provides the possibility to run the server logic in the editor environment.

Finally, to reuse the server code, the first is to require that the logic Code itself have no platform relevance-you should avoid calling linuxapi or windowsapi-the idealized approach is to use cross-platform languages such as Java/python. (In communication with colleagues working on the server program, I learned that the bottleneck of the server program is not CPU computing, but network I/O. Therefore, non-platform-related languages are used, it may not increase the efficiency of running, but lead to the convenience of code reuse. In other words, even if we do not use platform-independent languages to write server logic, for example, you can use C or C ++ to write the server logic, as long as the logic code is not contaminated with any platform-related APIs .) This is intended for cross-platform reuse of server logic.

Existing Problems in Design

The goals mentioned above are good, but in fact there are still many still uncertain points. Next, let's briefly analyze the issues with the above practices that have not been fully considered:

1. inconsistent data formats. The client logic needs to read data (Art-produced models, convex packets, scene terrain, etc.), and the server logic also needs to read data (planning and setting triggers, skills, NPC, blame, etc ). Although the data is provided by the editor, the data in the editing stage may be completely different from the data in the actual running stage for many reasons. How to dynamically convert data into data recognized by the client and server at runtime is a problem. In particular, if you use technology such as lightmap for rendering, the editor also needs to perform time-consuming lightmap computing when exporting data. Similarly, it also uses graph computing, it is also a time-consuming job. It is important to carefully consider how to enable the server and client in the editor to get the prepared data in a short enough time.

When talking about the management of game data (creation, editing, storage, and reading), we can discuss it separately in another article. Previously, I read the article "thinking about game data management systems from the beginning" by miloyip's boss, it mentions a lot of thoughts on game data management, which has benefited a lot. Here, I would like to recommend to anyone who is interested.

2. The client logic is not just the input logic. In fact, there are also player logic, animation playback, dynamic resource loading and release, and interface logic. They are all complex modules. How to reuse these logics and how to design interfaces is not detailed.

3. Due to my lack of understanding about the structure of server logic, the reuse of server logic may cause many unconsidered problems. Although it was mentioned that the proxy mode can provide a virtual runtime environment for the server logic, it is believed that there are still many practical difficulties.

Brief design drawing

I have summarized the above ideas and provided a brief design overview:

Assume that the server is running on Linux, and the client and editor are running on Windows.

The overall architecture depends on three abstract interfaces: the database interfaces that the server editor depends on, the network interfaces that the client editor relies on, and the user input interfaces. With these three abstract interfaces, we break down many coupling operations so that the server logic and client logic are independent into separate modules, which can be used not only in server programs or client programs, it can also be used in the editor again, so that the editor has the ability to forge a server and client, through this method to achieve the purpose of editing.

(Furthermore, by replacing the fakenetwork layer in the editor with the RealNetwork network layer, you can directly connect the editor to the actually running server, so that we can directly start a client program in the editor)

When developing based on the above architecture, developers avoid repeated code writing in many places (for example, the server logic determines the NPC behavior, the editor writer does not need to write any code that spoofs the NPC behavior in the editor. We can directly obtain the actual server-side NPC performance-the server-side logic code written by the actual server-side logic writer; similarly, the client logic determines the interface and message response, which can be used for both the actual client and the simulation of client behavior in the editor)

Postscript

This article is actually an immature idea designed for the online game editor. If you do this, there are still many details that need to be considered and enriched, as well as the difficulties to be overcome. However, from the perspective of shortening the game development process and improving the code reuse rate, I think the direction described in this article should be the trend of online game development in the future.