Online Game Development Experience (server) (1)

Bromon originality, please respect copyright

A multiplayer online chess and card online game project is coming to an end. I participated in the entire design process of the project and completed 90% of the core code. There are many things worth chatting about this project. This series does not plan to elaborate on how detailed the project will be. It should be described in the design document. I plan to only talk about some worth noting.

 

A special feature of this project is that the client is a mobile phone, and the user communicates with the server through the mobile network. Compared with PCs, mobile phones have weak processing capabilities and are expensive in terms of network traffic. In addition to some common online game problems, these two issues need to be fully considered in the design.

 

The first is the selection of development languages. Since the server is a Linux environment, Ms technology is directly excluded. As for mono, I am not at ease. The options are c ++ and Java. Java is better than the powerful network capability and short development cycle. It supports many frameworks and open-source libraries, it is not easy to write unacceptable code; C ++ is faster than speed. Based on various factors, C ++ makes it easier to turn this project into a bunch of code nightmares. We chose Java.

 

I. Network

The first problem for online games is, of course, how to communicate over the network. The first thing we should consider is the HTTP protocol. Because all the mobile phones of the agent support this protocol, we certainly want to be as compatible with users as much as possible. In addition, HTTP protocol encapsulation is already very high, so you don't need to consider threads, synchronization, status management, and connection pools. However, HTTP protocol has two unpleasant aspects:

◇ The protocol is stateless, which has plagued many people many times. The solution I have considered is to transform the HTTP protocol and do not close the socket after the data transmission is complete. However, the workload is very heavy. in the project cycle, it is basically mission impossible, not considered. Then, the customer can only request data from the server through polling.

◇ Excessive network traffic. For this project, only commands are transmitted between networks, but a bunch of useless HTTP headers need to be added for each transmission, and the client needs to perform polling, this traffic is terrible for mobile phones. After a simple test, according to the 0.03 RMB/k gprs network fee calculation, a Board card actually consumes more than 1 RMB (polling per second ), it is unacceptable. Maybe we can use the traffic and monthly charges, but this topic has nothing to do with technology.

 

The above problem leads us to select socket, which means we will not have a web environment and many things should be implemented by ourselves: thread management, customer status monitoring, Object pool, console ..........

 

The Network part is intended to be implemented using Java NiO, which is a new network listening method. Event-based Asynchronous Communication can improve performance. After each client is connected, an independent socketchannel will communicate with it. This socketchannel will exist throughout the user's lifecycle. If the user disconnects, the server will get-1 and throw a Connection Reset exception. By capturing these two features, you can clear related resources after the user accidentally disconnects. Since NiO is an asynchronous communication, there is no complicated thread management.

Next article: communication protocols