Subscribe cloud computing RSS CSDN home> cloud computing

Game engine network developer 64 to do and not to do (one): client side

Published in10:23 2015-07-18| Time reading| sourceHare IT| ZeroArticle comments| authorIgnatchenko Sergey

Abstract:Throughout the last 10 years of the game field, stand-alone network development has become a very big trend. However, there are a lot of challenges in the process of adding network support for the game, here we will reveal the game engine network developer's 64 do and do not do.

[editor's note] Nowadays, the game network has been irreversible, therefore, for game developers, to master the skills of the network engine is also inevitable. Recently, Industrial Systems Engineering GmbH Research security researcher Ignatchenko Sergey (with more than 20 years of engineering experience) in theHare ITOn the author, in-depth sharing of the game engine network development related experienceOneAPMEngineer translation.

The following is a translation

Throughout the last 10 years of the game field, stand-alone network development has become a very big trend. However, for the game added network support in the process there are a lot of challenges, and according to in recent years work experience (not only participate in the evolution. Also, to a large number of developers to provide information support), many game developers even violate the "build a excellent network application" should adhere to some basic principles. Therefore, the application will often face a "UIs" frozen, inexplicable disconnection (in other programs, the Internet access to normal), the occasional crash, and the peak period of the server overload and other issues. There is no doubt that these issues will directly affect the player's gaming experience, while its direct extent also far beyond the imagination of administrators and graphics developers. Fortunately, these problems are not complicated, some even a little on the.

Therefore, there will be a series of blog posts to the development of some of the ideas of the network, most of which are game engine developers have not been aware of. Of course, some of the views of some friends may be that you have access to, but there is no doubt that it is valuable to a large number of game developers. As a result, it is worth reading for developers who are expected to create such highly interactive applications, such as games or securities trading.

As the first article in this series, it will focus on the development of client applications that do not involve protocols. This series of articles will include:

  • And APIs Protocols
  • And APIs Protocols (Continued)
  • Server-Side (Architecture Store-Process-and-Forward)
  • Server-Side (deployment, optimizations, testing and)
  • TCP-vs-UDP Debate Great
  • UDP
  • TCP
  • Security (TLS/SSL)
  • ......

Range determination

In general, support network game engine is a very big topic, so this series of posts will be delineated a range of focus with the client application of game, and not the game based on browser-/AJAX. Although the two games in the design have many common points, but the difference enough let discussed separately. This series will try to cover the common concept of the game network layer development:

FirstWill not only focus on a certain type of games, such as MMORPGs. There is no doubt, MMORPGs do in the scope of discussion, but also there is no lack of social games, multiplayer strategy (including real-time and turn based), gambling games, securities trading and so on. Surprisingly, these games have a lot of common ground when doing network support. (although much of this depends on the time control problem, this will be described in the TCP-vs-UDP Debate Great section).

SecondlyThe same is not limited to a particular platform: in fact, here is more recommended developers to write cross platform engine, which contains the network engine. In practice, the author has written a network engine, it can be run on more than 5 completely different platforms, this point will be described in sixth.

Again,Because based on the game engine developer's perspective, there is a background to the game developers often need to develop the game engine for their game. In this case, most of the recommendations are applicable.

LastAlthough similar to "which engine or network engine is the best?" Such a problem has gone beyond the scope of the discussion, but this series of blog posts also help to answer this question. There is no doubt that the answer depends on the specific needs of the game, so please read in detail. In other words: if your game engine or framework provides a support network, the posts can be as a tool to consider and understand the network achieve whether benefit of a particular game.

OK, in the end the discussion after the direction of general account, well below.

1 please use event driven programming model in client side.

Moment, most client UI framework contains a so-called "main thread" (or "main loop, running in the" main thread "), and the" main thread "is, in essence, will deal with some specific events (the original UI events). This model exists in all client framework, from GUI Windows, X Cocoa and Direct, to 3D Android, Unity and iOS. At the same time, there is also a good reason to drive everyone to do this: because the other programming models can only give you a nightmare. In fact, in practical work, I only met the framework of a "special", namely the original Java AWT, and in the AWT written app pain also known (in view of this, AWT from beginning to end is also not popular; in fact, Google also really need for Android development new GUI framework).

So, after adding network support to the application, the event driven model should be how to change? In fact, there is no need to change. In actual production, all network communication game logic are by message sending and receiving constitute; and each received the news of the network should be as game event driven logic (removal of traditional UI events, such as mouse and keyboard input) of another event. Typically, this operation can be passed to thread message's "queue main" into a message easy implementation. For example, in Win32, this operation is usually done by the PostMessage () or PostThreadMessage () method. If you do not support the idea of a graphical framework, you may need to build up your queue and conduct polling for simulation (for example, Unity3D2012). Contrast in a single thread to deal with all the events (both UI events and network messages), the event as the data (Win32) or callback such a problem is not important. NB: if using unity, this technique is rarely needed, because unity's built-in network has used the unity of event processing thread) is very suitable in the "real world simulation (real-time world simulator game; however according to the specific characteristics of the game, using unity network UDP transmission is no best way -- especially those and real-time simulation has nothing to do with the game.

In some cases, event processing thread and selection framework of "main thread" a far cry from, but here you need to keep in mind is that all events related to logic processing into a single thread. However, the pure communication related (and the game logic completely unrelated), such as marshalling and en/decryption and (DE) compres can (whenever possible) in the "main thread" external processing and thread isolation are discussed in detail in the following section 3.

2 do not call the application level callback outside of the event handler thread

I can still remember that year. The author also "very silly very naive". At that time, responsible to a securities trading business development network framework (PS: don't ask me why so important a task will give an inexperienced engineer, I also no solution). Beginning, new network library written really quite smoothly, but here, I committed the same a mistake of principle -- at the application level is called a callback (it should be is a callback to response sendMessageOverTheNetworkAndCallbackOnReply () style function). This is a bad mistake once to follow the use of the framework of the colleagues took a lot of trouble. First, the interaction (and potential races) makes it difficult to understand the use of its colleagues. Second, it brings a lot of trouble to bugs and races tracking. Finally, although there is not much bad effect, and the framework of the overall operation is good, but if there is no this callback, the development will become more smooth.

A few years later, the author has been a large number of players in the game development network engine - at the same time online players 500 thousand, the number of daily news 500 million. And after the learned prior experience, to avoid the similar thread callback, all the work are organized, also in the multi platform switching also abnormal smooth.

Summary: if you need from the network layer to realize a callback to the application layer, the first thing you need to pass events to the event handler thread (usually case is the main thread), then through the network layer library calls (originated in the event handler thread) to handle events and if necessary call application level callback. In other words, the following is a perfect way:

Thread Network - > event-processing - > thread > network-library-call - > inter-thread-communication - > application-callback - > no-thread-sync-needed

While the following is feasible, but is not conducive to long-term use of others:

Thread Network - > network-library-call - > application-callback - > thread-sync-required

In the perfect way, the callback only exists in the event processing thread environment, which will significantly simplify the application development. All application level processes are strictly identified, thus minimizing the possibility of the emergence of races, and reducing the required synchronization of the application level. The process may sound more cumbersome, and the operation is cumbersome, but it can effectively reduce the developer's subsequent trouble.

3 don't call a function that can block the network from the event handler thread.

This is one of the biggest mistakes that network developers can commit to. As stated above, you need to handle all events in a single thread. The proper operation and convenient, but the trouble is resulting, for example: in an event handler do a simple as gethostbyname () call, this operation in small range does not exist any problem, but in some real world players is therefore block a few minutes for a long time! If you call such a function in the GUI thread, for users, in the function blocking, GUI has been in the frozen or hanged state, which is from the user experience point of view is absolutely not allowed.

Therefore, all functions should be a non blocking, or in a different thread, to do network interactions by GUI. In this case, you need to make the event state machine more complex (you can efficiently obtain similar "waiting for DNS resolution" such a state. At the same time it also needs to avoid the "frozen" GUI, and can allow you to network delay, including:

  • Notify user when required. For example, after waiting for a second or 5 seconds, you know there is a problem, the user also need to know this thing. So you'd better let the user know that you have found this problem and begin to deal with it.
  • Stop action and try again when needed.
  • Allows users to gracefully terminate requests or applications, rather than forcing them to use task manager.

It should be noted that this seems to be contrary to the first and second, but in fact it is not the way it is. For "Hey, so should I do it single-threaded or multi-threaded?" such a problem, the answer is: system level network calls or is non blocking, either from a non event processing thread; at the same time, all processing must be in the event processing thread. This means, if the use of multi threading, you need in a non event processing network processing thread to call blocking recv () function is similar, will then call the conversion to an event, and through the form of a queue (such as the one above in the introduction) will be the event passed to the event handler thread. Strictly speaking, decryption/decompression to such a treatment, although the need to do to avoid event processing thread becomes a bottleneck in the process, but it is usually better than the encryption/compression thrown into the network processing thread comes more price.

The network thread of another alternative is non-blocking IO, there also exists some need to pay attention to the place (including gethostbyname () and getaddrinfo () in the mainstream platform does not exist version of the non-blocking IO). At the same time I also don't think the client to use non-blocking bring trouble less. Server side will be another scenario, the details will be discussed in the third part of the series blog server.

4 do not take the user as a free error handler

In game engine development, many developers have used an unusually simple network error handling approach. That is, they simply put the wrong in front of the user, leaving only a few problems, please try again". This approach is very annoying, and will not bring any effect (of course, easy to developers, but the damage to the user). In addition to the developers are too lazy, there is no reason not to solve the problem in the internal. After the problem is generated and to the user, there is no reason not to automatically retry and require the user to operate again. In order to notify the problem, you can display a significant position on the screen, or a pop-up dialog box (no ok this button, only close), and will automatically disappear after the problem solved. In this way, when the problem arises after the user leaves, if you can solve the problem in a short time, you will not have any impact on the user experience.

Some people may argue that it will cause network congestion, but as a developer, you have the responsibility to make the user experience becomes simple. Of course, you can also set a critical value, such as 5 minutes to close the retry, and prompted, I'm sorry, we have tried, but the problem can not be repaired in a short time".

Integrated above 1-3, you usually need to detect problems in the network processing thread, and it is converted into 1 events, and in the event processing thread processing events, such as the display of a dialog box.

5 to provide users with valuable error messages

From the end user's point of view, "the network is not available", "connection refused" and "termination" without distinction of any kind; if possible, you may want to tell their cable is not plugged in or server failure or some problems between the two, but only because of some professional terms so that users can not determine the truth is completely unacceptable. A worse approach is to try to hide the technical details in some ambiguous words, such as "the server has a problem" and "you lost the connection".

In short, remember to convert the error message from the statement you can understand to the user can understand the prompt, rather than let the user can not identify the difference between the various tips - so that all messages look exactly the same.

6 support multi platform

Throughout the current game field, single platform games are no longer attractive. Even if the engine only for a game to build, but you really can determine the future of the game will not be the transition to other platforms? In practice, it is not difficult to make the network code cross platform, so you have no reason not to do more than the platform to prepare. The author's personal network covers the Windows, Linux, OS X Mac, FreeBSD, iOS and other engines.

6a. on the client side using Sockets Berkeley

If your game engine is based on C or C++, and the application is defined as a Windows platform, it is possible to try some of the Windows specific functions (those with the WSA* prefix) to communicate. Please do not do so, instead of using sockets Berkeley (those /connect () socket () /send () /recv () () function) to replace; on the use of details, please Google. For others to provide a cross platform APIs programming language, select a suitable network library usually does not have too many problems.

7 provides a way to automatically upgrade APP

Normally, automatic upgrade does not take into account a part of the game engine. However, individuals feel that there will be some of the corresponding benefits to the network layer will be automatically upgraded, the reason is that:

  • Users may expect more options (from topics to DLCs).
  • If you can play while downloading, then they will be very happy.
  • If you download the interference to the entertainment, then they will not be happy.
  • In your network to provide optional download, you can give priority to traffic, the impact of the game will be downloaded to the lowest (in this series of blog posts in the IIb Part section will discuss more skills). Because QoS does not apply to the Internet, two parallel connections are likely to have an impact on each other.
  • If you support the optional download, they also need automatic updates, so the combination of automatic download and automatic updates is a good thing.
  • Therefore, the network engine to achieve the whole automatic update function is a good thing.
  • In addition, users can download while playing, in order to maximize the entertainment time.

The above reasoning is not under any conditions set up, but I saw a similar system to achieve, but also achieved very good results.

Note: Although integration and network library, you also need to need to modify your protocol thoroughly in the HTTP (rather than your agreement to achieve initial update will start before the game starts the application based on); such operations and will not bring too much complexity, but is likely to.

Other operations on the start update are very complex, so it will be a separate article to express,

Be Continued To......

Text link:64 DO Network 'and s DON Ts' for Game Engine Developers. Part I: Client Side(commissioning editor / Zhong Hao)

[notice]The first Chinese artificial intelligence Conference (CCAI 2015)Will be held at the Friendship Hotel Beijing in July 26-27. Machine learning and pattern recognition, the opportunity and challenge of big data, artificial intelligence and cognitive science, intelligent robot four experts gathered. Artificial intelligence product library will be synchronized on-line, booking advice: QQ:1192936057. Welcome attention.

The CSDN compiler finishing, shall not be reproduced without permission, for reprint please contact market#PROG3.COM (@ # replaced)