Introduction to the Application of Real-time strategic games in j2s

Source: Sina

--------------------------------------------------------------------------------
StarCraft, Warcraft, civilization... These are well-known names of PC game players. It can be said that strategic games represented by these games are typical representatives of PC games, and strategic game players are also the most loyal players of many PC game types. Strategic games are divided into two categories: Turn-based and real-time strategy. Both of them have a large number of players, and the latter has gradually overwhelmed the turn-based strategic game due to intense gameplay. In recent years, has been dominant in strategic games.

The topic of "Developing online instant strategy games on the j2's platform" is no different from that of most of today's j2's developers. The instant strategy game name "instant" determines complex computing and data interaction, stable and fast network connection requirements, massive resources, and drawing tasks, we all know that the resources and performance of the j2_equipment are extremely limited, and the current GPRS network industry is not satisfactory ...... These seem to have become insurmountable difficulties in developing online real-time strategic games on j2s.

The difficulties are actually in front of us, but the huge potential real-time strategic players in China's 0.3 billion million mobile phone users have prompted us to overcome these difficulties, as long as there is a possibility, we also need to find a way to overcome these obstacles. How can we achieve online real-time strategic games on mobile phones?

In terms of performance and user volume, we chose the Nokia 60 series as the initial development platform.
We do not consider using the HTTP protocol, although it is a commonly used protocol in j2s devices, however, its low efficiency compared with socket and its non-connection protocol determine that it is not suitable for instant strategy. From the table above, we can see that the connection establishment time is much longer than the data transfer time after the connection, and the HTTP protocol requires a lot of additional overhead to establish the connection; the average HTTP data transmission time is much higher than that of socket. We tested most of the 60 models (7650,365 0, 3660,660 0, N-GAGE, N-GAGE qd), all the testing models support socket.

From the table above, we can see that the average round-trip time of socket connection data is 1 ~ In 2 seconds, this may be enough for a turn-based strategic game, but it is too long for a real-time strategic game. Is there any way to significantly reduce the data transfer time?

We can consider the server and the packet protocol.

The servers tested above are written using serverlet, while serverlet is built on the Web server. Therefore, the server response and processing time contained in this data cannot be ignored, to achieve faster response and processing speed, we must redesign and build a dedicated server for the game. The size of the transmitted data packet is also a key factor affecting the speed. Usually, we develop a network application based on j2m's, and are used to transmitting data using text streams. Because most application servers are based on Web servers, It is very intuitive to use text to represent information, which is also easy for the server to process, however, it is still a waste of text that has not been compressed for the j2-based platform and GPRS network.

Simply consider a game server: A host should be able to support one hundred to two hundred gamers simultaneously online; For ease of configuration, the server application should be cross-platform, and the client is also a j2-based server, therefore, the development environment of Server Java is the first choice. The new Java asynchronous communication function after Java 1.4 can meet our performance requirements.

Because the server must be written by ourselves, there is no need to use the text encoding protocol instead of byte stream encoding. Simply estimate that the same information is represented. The ratio of data size in the text and byte encoding modes is greater than, and the data is originally dominated by numbers, saving a large overhead of text conversion. Smaller data also results in faster speeds. In addition, it also saves users a lot of expensive GPRS traffic expenses.

After taking the above measures, we tested the response time of data transmission again, with an average of less than 1 second! In the opinion of many people, this time is still too long to meet the real-time requirements, but it should be known that absolute real-time is impossible to achieve, as long as some reasonable strategies are adopted in planning and development, the latency of less than 1 second can be completely concealed.

A typical PC real-time strategic game, such as starship, does not actually require servers in the Battle of local networks. One or more clients in the battle act as servers, even on the network, the battle network server only performs community management. Implementation on mobile phones cannot adopt this structure: first, two mobile phones cannot be directly connected through the GPRS network (Bluetooth or infrared connection is not ruled out, which is beyond our scope of discussion ), it can only be transferred through the server. In addition, mobile phones have limited computing capabilities. In order for the game to run well, many computing operations must be transferred to the server with more abundant resources, this is in line with the general CS structure and tries to let the client share the server's work so that the server can support more clients. It also reflects the special characteristics of the network application of j2_m2 :)

Let's briefly talk about the architecture of the entire system:

Servers are divided into connection servers, Hall servers, game logic servers, user management servers, and log servers by function. Depending on the number of users, if the number is small, all servers can be placed in one host. As the number of users increases, servers can be moved to different hosts, by adjusting the number of server hosts to achieve load balancing.