WO2009152731A1

WO2009152731A1 - Game virtual machine and game development system and method for realizing the same

Info

Publication number: WO2009152731A1
Application number: PCT/CN2009/072138
Authority: WO
Inventors: 王彭城; 李国宏; 寇华; 李炯; 汤闻
Original assignee: 腾讯科技（深圳）有限公司
Priority date: 2008-06-16
Filing date: 2009-06-05
Publication date: 2009-12-23
Also published as: CN101369227B; CN101369227A

Abstract

A game virtual machine and a game development system and method for realizing the same, the virtual machine includes a management service thread and a client thread, the management service thread is applied to manage a game user, complete the information alternation with the client thread and a game service end, and applied to load the game service end; the client thread is applied to startup the game client, and realize two-way communication with a game client through calling an interface; the game development system is composed of the game virtual machine, the game client and the game service end, the game virtual machine is fixed between the game client and the game service end, simulates the primary function of a game platform and a game server.

Description

Game development system and method for game virtual machine and implementation thereof

The present invention relates to game development techniques, and more particularly to a game virtual machine and a game development system and method based on reality. Background of the invention

In the current Internet applications, with the rapid development of instant messaging (IM), various applications and services based on instant messaging have been widely used, such as: multiplayer online games, that is, by two A game in which two or more users enter and participate.

In the prior art, game development has some mature solutions, such as the development of casual games in some instant messaging games. A currently existing game development system is shown in FIG. 1, and includes: a game client 10, a game platform 20, a game server 30, and a game month 40. The game client 10 is configured to provide a game interface for the game user and implement game logic. The game platform 20, also referred to as a game lobby in actual application, is used for communicating with the game client 10, and is responsible for the game user entering, Exit the game, realize the function management of downloading, installing, configuring, assembling, communicating, and props purchasing various games. It is also used for network communication with the game server 30, obtaining various states, and performing different processing according to different states; The server 30 is configured to perform network communication with the game platform 20, and implement functions such as game test, game release, user status query, game information forwarding, game account authentication and management, and billing record; and the game server 40 is responsible for the corresponding section. The game logic of the game is loaded and run by the game server 30, and each game corresponds to one game terminal.

In Figure 1, the game client 10 and the game platform 20 are run in a Windows environment, The game server 30 and the game server 40 are operated in a Linux environment; the game client 10 is started in the game platform 20 by a COM standard interface, and the two-way communication between the game client 10 and the game platform 20 is realized through the COM interface; 20 communicates with the game server 30 under the remote Linux operating system through a network communication method such as TCP; the game server 40 exists in the form of a shared library (SO) file in the Linux environment, and the SO file can be called by the game server 30. And loading; the game server 30 loads the game server 40 in the manner of a dynamic link library, and makes an interface call with the game server 40. Here, the SO file in the Linux environment is similar to a dynamic link library (DLL) file in the Windows environment.

During the development process, each time the edited code is self-tested, the game server 40 needs to upload the code edited by itself in the Windows environment to the Linux machine where the game server 30 is located, and then use G++ in the Linux environment. Compile and generate the SO file, and finally start the game server 30 to run the generated SO file.

The existing game development system has the following defects in the implementation process:

First, the development of the game server is cumbersome and requires high debugging. Since the code edited by the game server needs to be uploaded to a Linux machine and compiled into a SO file, it can be run on the game server. Therefore, if the game server runs and expects to be different during the development process, debugging is required. The Linux environment and the Linux debugger are familiar, which is difficult and time consuming for Windows programmers.

Second, during the development process, the game server is in the Linux environment, and the rooms seen on the game platform need to be pre-configured on a specific server, which requires each game to be configured with its own development environment before development. The game server correctly loads the game server, which makes the configuration of the development environment very cumbersome and complicated.

Third, since the compile and run of the game server code needs to be performed on a server with a Linux operating system, most of these servers are internal servers, only in the development of the public The internal division of the company can be logged in. Therefore, the game development can only be restricted to the development company, and the development location cannot be changed at will.

Fourth, in the game client development process, if the game is played by multiple people, it is necessary to start multiple game platforms and multiple game clients, and the number of game platforms and game clients is equal to the number of users participating in the game. , high requirements on the number and performance of the machines involved in the development, increasing the resource consumption. Summary of the invention

In view of this, the main object of the present invention is to provide a game virtual machine, which can reduce the complexity of development, configuration and debugging of the game server, and reduce the requirements on the performance and quantity of the development machine and the occupation of resources.

Another object of the present invention is to provide a game development system capable of reducing the complexity of development, configuration, and debugging of a game server, and reducing the requirements on the performance and quantity of the development machine and the occupation of resources.

It is still another object of the present invention to provide a game development method capable of reducing the complexity of development, configuration, and debugging of a game server, and reducing the requirements on the performance and quantity of development machines and the occupation of resources.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

The present invention provides a game virtual machine, including a management service thread and a client thread;

The management service thread is configured to manage a game user, complete message interaction with the client thread and the game server, and is used to load the game server;

The client thread is used to start the game client, and realizes two-way communication with the game client through the calling interface.

The invention also provides a game development system, including a game client and a game service The key is to further include a game virtual machine between the game client and the game server; the game virtual machine performs two-way communication with the game client and the game service end through the calling interface to realize management of the game user. And load the game server in the form of a dynamic link library DLL file.

In the above solution, the game virtual machine includes a management service thread and a client thread; wherein the management service thread is used to manage a game user, complete message interaction with the client thread and the game server, and is used for loading The game server is configured to start a game client, and implement two-way communication with the game client by calling the interface.

The management service thread includes a main thread and a server thread; the main thread is used to implement management of a game user, and message interaction with a server thread and a client thread; In communication with the game server, load the game server.

In the above solution, the client thread is more than one, and each client thread corresponds to one game client.

In the above solution, the game virtual machine is developed and operated in a Windows environment.

The present invention also provides a game development method, including: setting a game virtual machine including more than one thread between a game client and a game server; the method further includes:

When the game virtual machine is started, the management service thread in the game virtual machine is started and initialized, and the game server in the form of a dynamic link library DLL file is loaded and run by using the management service thread;

When the game user selects the seat required to participate in the game in the game virtual machine, the game virtual machine starts and initializes the client thread corresponding to the game user;

The initialized client thread reads a game identification ClassID and starts a game client participating in the game corresponding to the read game identification, and then communicates with the game client.

The management service thread includes a main thread and a server thread; correspondingly, the Starting and initializing the management service thread in the game virtual machine is: starting the main thread and the server thread, and initializing the server thread; the game server in the form of loading the DLL file is: loading the DLL file form by the initialized server thread Game server.

The invention provides a game virtual machine developed in the Windows environment and a game development system and method thereof. The game virtual machine is set between the game client and the game server, and the game virtual machine is used to simulate the game platform and The basic functions of the game server, interacting with the game client and the game server. Since the game virtual machine runs under the Windows environment, for the game client, the two-way communication through the COM interface is still maintained; for the game server, only the code compiled by the game server is compiled into a DLL file in the Windows environment to be loaded and run. That's it, so even if you need to debug the running game server, it only needs to be very easy for Windows programmers in the Windows environment, which greatly reduces the development complexity and development and debugging. Requirements.

Since the game server is developed and run in the Windows environment, there is no need to separately configure the development environment before each game development; and, because there is no need to upload the game server to the server with the Linux operating system at compile and runtime. Therefore, the development location can be extended beyond the development company, such as at home, and not necessarily limited to development within the development company.

The game virtual machine of the present invention realizes game user management, message forwarding, and interaction with the game client and the game server respectively by starting different threads, and, for different game clients, starts different threads to correspond thereto, that is, Say, if there are N game users participating in the game, only need to start N threads corresponding to N game clients, no need to start N game platforms. In addition, the game virtual machine can also run across PCs, such as: three-player games, the game virtual machine can be implemented on three different PCs, each launching a game client, so that the three game clients play the game normally. In this way, not only can the requirements on the number and performance of development machines be reduced, but also unnecessary resource occupation can be reduced, resulting in significant cost savings. BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features and advantages of the present invention will become more apparent to those skilled in the <

1 is a schematic structural diagram of a game development system in the prior art;

2 is a schematic structural diagram of a game development system in the present invention;

FIG. 3 is a schematic diagram of an implementation effect of the game virtual machine of the present invention. Mode for carrying out the invention

In the solution of the present invention, a game virtual machine is set between the game client and the game server, and the basic functions of the game platform and the game server are simulated by the game virtual machine, and interact with the game client and the game server. Further, threads are created in the game virtual machine that interact with the game client, interact with the game server, and implement game user management and message forwarding.

The game development system of the present invention, as shown in FIG. 2, includes a game client 10 and a game server 40. The key is to further include a game virtual machine 50. The game virtual machine 50 is located between the game client 10 and the game server 40, and is used for simulating the basic and common functions of the original game platform and the game server. The main simulated functions are: game user entry, game user exit, game logic Message forwarding, as well as disconnection and spectator.

In FIG. 2, the game virtual machine 50 is developed and run in a Windows environment. The game client 10 is started in the game virtual machine 50 in a COM standard interface manner, and the two-way between the game client 10 and the game virtual machine 50 is implemented through the COM interface. The game virtual machine 50 loads the game server 40 in the form of a DLL file, and makes an interface call with the game server 40.

In order to simulate the basic functions of the original game platform and the game server, the game virtual machine 50 mainly creates: a main thread, a server thread and a client thread, wherein the main thread is used to implement management of all game users, including games. Users enter, exit, and participate in games Etc., also used for message interaction with the server thread and the client thread; the server thread is used to load the game server 40, and is called by the game server 40 through the set interface; the client thread is used to start The game client 10 implements two-way communication with the game client 10 by calling the COM interface of the game client 10. According to the number of game users participating in the game, there may be multiple client threads, and each client thread corresponds to one game client. End 10. In practical applications, the server thread can also be merged into the main thread and merged into one thread. That is to say, the main thread function and the server thread function are simultaneously completed by one thread.

The main thread and the server thread, or the thread having both the main thread function and the server thread function, are collectively referred to as a management service thread. In other words, the management service thread can be composed of two threads: the main thread and the server thread. It can be just one thread that has both the main thread function and the server thread function. The following is an example of the management service thread consisting of the main thread and the server thread, which specifies the function and implementation of each thread.

For the main thread, when the game virtual machine 50 is started, the main thread first reads the game user information from the preset configuration file, and the configuration file stores the most basic information of the game users, such as: instant messaging number, super The game user information obtained by the game virtual machine 50, such as game users, points, game coins, etc., is used when sending a message such as a game user entering or exiting to the client thread and the server thread. The communication between the main thread and the client thread and the server thread can be implemented through a message application programming interface such as the PostThreadMessage API; conversely, the communication between the client thread and the server thread and the main thread can be through the message application programming interface. As implemented by the PostMessage API.

Generally, the content of the message is stored in the heap, and the pointer and length of the content are passed as parameters. The pointer parameter and the length parameter can be named Wparam and Lparam, respectively. In order to ensure the correctness of the message sequence, the client thread and the service end thread do not communicate directly, and all communication is forwarded by the main thread in a prescribed manner. Here, the forwarding according to the specified manner means that some messages need to be sent to a certain client thread, some need to be sent to all client threads, and some need to be sent. Give some client threads and so on.

Based on this, the main thread can simulate the most important and commonly used functions of the game platform, such as: game user entry, game user exit, game logic message forwarding, and game user disconnection. For the disconnection re-entry function, the main thread first informs the client thread by message, and notifies the server thread of a game user to drop the line by means of message mode or interface call mode, and marks the game user status as dropped, if the game When the user clicks on the corresponding game user avatar on the desk within the specified time, the main thread will notify the client thread and the server thread that the corresponding game user is disconnected. Here, if the main thread and the server thread are two threads, the main thread notifies the server thread by means of a message; if the main thread and the server thread merge into one thread, the main thread notifies the server thread by the interface calling manner.

For the server thread, the game virtual machine 50 starts the server thread, and the server thread is encapsulated into a class. This class can be arbitrarily named according to requirements, such as named CSoWorkingThread, which provides a name named CreateSoWorkingThread. Public method. The server thread needs to be initialized first. The specific implementation is as follows: First, create a CSoWorkingThread object by the main thread, then call the CreateSoWorkingThread method of the object and pass in the necessary parameters to initialize the line of the service. Among them, CSoWorkingThread needs to inherit from the ITable interface and implement its interface, which must be inherited and implemented as a game server.

The ITable interface refers to an interface that the game server provides to the game server 40 to call, and mainly has an interface for setting points, sending game logic messages, and obtaining points. Since the game server 40 does not have network or database operation functions, the game is required. The server provides the corresponding interface.

After the server thread is started and initialized, the game server 40 in the form of a DLL file is loaded by using the load library application programming interface LoadLibrary API, and the game generation terminal 40 is generated using the GetProc Address API. The (CreateGame) interface converts the pointer of the interface into a pointer of the ITable type and passes it as a parameter to the game server 40. After that, the game server 40 can use the converted ITable class pointer to call the ITable interface implemented in the CSoWorkingThread class. . Among them, the game service terminal 40 in the form of the loaded DLL file is compiled in the Windows environment.

For the client thread, each time the game user selects a seat on the game table in the game virtual machine 50, the game virtual machine 50 launches a client thread, which is encapsulated into a class, which can be Name it arbitrarily according to your needs, such as CClientWorkingThread, which provides a public method named CreateClientWorkingThread. The client thread needs to be initialized first. The specific implementation is as follows: First, create a CClientWorkingThread object by the main thread, then call the CreateClientWorkingThread method of the object and pass in the necessary parameters to initialize the client thread.

After the client thread is started and initialized, the client thread reads a game identifier Classld from the preset configuration file, and each Classld corresponds to a game; the client thread starts the participation of the read Classld corresponding to the COM thread. The game client 10 of the game, at this time, the client thread can call the COM interface of the game client 10. When the client thread starts the game client 10 through COM mode, since the COM has location transparency, the startup position of the game client 10 can be selected before starting, for example: selecting the local or other PC, the corresponding current client thread The game client 10 will be launched at the selected location.

The client thread must inherit and implement the IGame interface, and convert the pointer of the interface into a pointer of the IGame type to the game client 10. The game client 10 can call the IGame interface of the client thread according to the set pointer. Here, the IGame interface mainly implements three functions: sending a game logic message, sending a chat message, and sending other messages. Since the game client 10 does not have a network function, if the message is to be sent out, only the call is made. This interface.

When the game user leaves, the game client 10 is closed. When the game client 10 is closed, the game client 10 notifies the corresponding client thread in the game virtual machine 50.

In a practical application, a seat on the game table in each selected game virtual machine 50 initiates a client thread, that is, a game user participating in the game corresponds to a client thread and corresponds to a game client 10.

Based on the above development system, the development method of the present invention includes the following steps:

First, a game virtual machine including a plurality of types of threads is set between the game client and the game server;

When the game virtual machine starts, it starts and initializes the management thread in the game virtual machine; it is only one thread that has both the main thread function and the server thread function;

After that, load the game console in the form of a DLL file and run it;

When the game user selects the seat required to participate in the game in the game virtual machine, the game virtual machine starts the client thread corresponding to the game user, and initializes the activated client thread;

The initialized client thread reads a game identifier ClassID and starts a game client participating in the game corresponding to the read ClassID, and then communicates with the game client to implement entry, exit, and participation of the game user.

FIG. 3 is a schematic diagram of an implementation effect of the game virtual machine of the present invention. As shown in FIG. 3, the game virtual machine may include game user management, game user information, game user operation, and game table settings.

In a specific application, the game user may also be referred to as a player, and the game user management includes an idle player list, a play player list, and a bystander player list, respectively giving the game virtual machine in an idle state, participating in the game, and watching the game. Game user. In an idle state By selecting a seat on the game table, the game user can enter the game user group participating in the game state, or join the game user group in the watch game state; if the game user in the participating game or the stand-by game state leaves the current game The seat will automatically be added to the game user group in the idle state. Through the game user management, the game state of each game user can be known, and the number of game users in various game states can be known.

The game user information gives basic information about the game user, such as: game user's number, nickname, super player, points, game currency, etc., some of the information can be modified and updated, such as: points and coins.

The user operation of the game gives several optional operations. The user can click the corresponding button to implement the corresponding function, such as: let the player drop the line, select a game user and click this button, then the corresponding game user is dropped. The seat on the game table corresponding to the game user will be grayed out. In the preset time, the corresponding game user can be disconnected by clicking the gray seat, that is, returning to the game table to continue the game, if the game exceeds the specified time, the game The virtual machine sends messages to the other game users and game servers that the game user quits. Another example: Dissolve the game, when the table is in the middle of the game, click this button to dismiss the current game.

The maximum number of tables per table can be set in the game table setting, that is, a maximum of several people can participate in the game on a game table. After the selection, the corresponding game table will change, for example: Select 2 people table, only two seats on the game table , choose 6-person table, the game table will become six seats, the most recent selection will be saved in the configuration file. In the game table settings, you can also set the location where the client is started, that is, whether the client starts up locally or on another machine.

The game table in the game virtual machine, clicking on a free seat when the game is not started will start a game client participating in the game on the local machine or other machine according to the selection of the client startup position; when in the game state, click A seat with a game user will launch a game client for a bystander game on the local or other machine depending on the client's launch location. By letting the game table light up, the game is in progress, and the game table is grayed out to indicate the game knot. Bunch.

Here, the spectator game user also corresponds to a client thread, and the main difference from the client thread in the game state is that the game state is different. Accordingly, the logic message of the game is only sent to the game user in the game state, and some are only sent to the game user. By-the-go game users, there are different treatments.

In summary, with the technical solution of the present invention, a game virtual machine is set between the game client and the game server, and the basic functions of the game platform and the game server are simulated by the game virtual machine, and the game client and the game service end are performed. Interaction. Because the game virtual machine is running at

In the Windows environment, for the game client, it still maintains two-way communication through the COM interface; for the game server, simply compile the compiled code of the game server to the DLL file in the Windows environment, and then run it, so even It is necessary to debug the running game server. In the Windows environment, this is very easy for Windows programmers, which greatly reduces the development complexity and requirements for development and debugging.

Since the game development and operation are all in the Windows environment, there is no need to separately configure the respective development environment before each game development; and, because there is no need to upload the game server to the Linux operating system at compile and runtime. On the server, the development location can be extended beyond the development company, such as at home, and not necessarily limited to the development company.

The game virtual machine of the present invention realizes game user management, message forwarding, and interaction with the game client and the game server respectively by starting different threads, and, for different game clients, starts different threads to correspond thereto, that is, Say, if there are N game users participating in the game, only need to start N threads corresponding to N game clients, no need to start N game platforms. In addition, the game virtual machine can also run across PCs, such as: three-player games, the game virtual machine can be implemented on three different PCs, each launching a game client, so that the three game clients play the game normally. So, not only can you reduce the gap The number of machines and performance requirements can also reduce unnecessary resource consumption and save costs. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are made within the spirit and principles of the present invention, should be included in the present invention. Within the scope of protection.

Claims

Claim

A game virtual machine, comprising: a management service thread and a client thread; wherein

2. The game virtual machine according to claim 1, wherein the management service thread comprises a main thread and a server thread;

The main thread is used to implement management of a game user, and message interaction with a server thread and a client thread;

The server thread is configured to communicate with the game server and load the game server.

The game virtual machine according to claim 1 or 2, wherein the client thread is more than one, and each client thread corresponds to one game client.

4. A game development system, comprising a game client and a game server; characterized in that the game virtual machine is further located between the game client and the game service end;

The game virtual machine performs bidirectional communication with the game client and the game service end by calling the interface, realizes management of the game user, and loads the game server in the form of a dynamic link library DLL file.

The game development system according to claim 4, wherein the game virtual machine includes a management service thread and a client thread;

The client thread is used to start a game client, and implements a tour by calling an interface Two-way communication between the client and the client.

6. The game development system according to claim 5, wherein the management service thread comprises a main thread and a server thread;

The game development system according to claim 5 or 6, wherein the client thread is more than one, and each client thread corresponds to one game client.

The game development system according to claim 4, 5 or 6, wherein the game virtual machine is developed and operated in a Windows environment.

A game development method, characterized in that a game virtual machine including more than one thread is set between a game client and a game server; the method further comprises:

10. The game development method according to claim 9, wherein the management service thread comprises a main thread and a server thread;

Correspondingly, the starting and initializing the management service thread in the game virtual machine is: starting the main thread and the server thread, and initializing the server thread;

The game server in the form of loading the DLL file by using the management service thread is: loading the game server in the form of a DLL file by the initialized server thread.

The game development method according to claim 9 or 10, wherein the client thread is more than one, and each client thread corresponds to one game client.

The game development method according to claim 9 or 10, characterized in that the game virtual machine is developed and operated in a Windows environment.