Game Engine BASICS (7) (network and connected game environments)

Part 1: Network and connected gaming Environments

Online Games
I remember some years ago, at the GDC (Game Developers Conference), I heard a speech titled "drowned in the Internet" from the developers of X-wing vs TIE fighter, it's all about making online games work on the Internet in real time. How correct is the question they chose. When it starts to process packet loss, out-of-order, latent (the time spent by a packet to its destination), and so on, it is indeed drowned. However, it is possible. Internet requires some intelligence and experience, but it is certainly possible. Check out a large number of connected games today, from Quake III, Unreal Tournament, counter strike to EverQuest and Ultima Online.

Today, most games that really have long-term vitality have at least some components of the link. The most pure single player game is easy to play once, maybe twice, or even three times if it is a very good game, but once the game ends, it will be shelved. If you want to have any long-term vitality, multiplayer connected games are at the core of the situation, and that means dealing with the Internet opens the Pandora box for the coders.

So what does it mean to deal with the Internet? First, we need to understand how the Internet works, and quickly discuss the point-to-point and client/server architecture. Point-to-point means that you run the game on two machines and share input between them simply. Each single game assumes that it is correct, and only merges the input from another machine in the refresh of one player after another. A client/server is a machine that effectively runs a game. other machines are just a terminal that accepts input from players and renders anything that the server uses to render.

The advantage of the Client/Server is that each machine will show the same game, because all the processing is done in one place, not across multiple machines, you don't have to worry about the synchronization between each machine. The disadvantage is that the server itself needs some important CPU available time to process each connected client and a suitable network connection to ensure that each client receives updates in a timely manner.

UnderstandingIP
We have heard of TCP/IP (Transmission Control Protocol/inter-network protocol) and UDP (user data packet Protocol). There are a lot of profound technical information about these protocols on the Web network. In fact, there are some excellent TCP/IP guidance on the Cisco website. At a higher level, we will introduce some basic TCP/IP knowledge to help you better understand the challenges faced by network game designers who use these standard protocols.

TCP/IP and UDP/IP are two-layer communication protocol systems. The IP layer is responsible for transmitting Internet data packets. The UDP or TCP layer transmits large packets to the IP address. The IP address divides the packets into small sub-packets, adds an envelope to each packet, and computes the IP address of the destination. How should we get there, then, send the packet to your ISP, or connect to the network in any case. It is like writing what you want to send on a postcard, adding a stamp, writing an address, and inserting it into a mailbox, and then sending it away.

UDP and TCP are high-level protocols for receiving data packets from your coders or games and decide how to handle these data packets. The difference between UDP and TCP is that TCP ensures the transmission and ordering of data packets, while UDP does not. UDP is a path for direct interaction with IP addresses, while TCP is an interface between you and IP addresses. It seems that there is an administrator assistant between you and your email. If you use UDP, you can type your messages and put them in an envelope. By using TCP, you will only send a draft to your administrator. The Administrator will do all the work and send the confirmation letter to the Administrator.

However, all these amazing work done for you comes at a cost. To ensure that a packet is sent to the target in good condition over the Internet, TCP expects to send a response packet from each packet sent by the target (the Network term is ack ). If it does not receive ack within a certain period of time, it will stop sending any new data packets, resend the lost data packets, and continue to do so until it receives a response from the target party. When you access a webpage, we can see this situation. The download stops for a while and then starts again. It may be where a data packet is lost (assuming the problem with the ISP from time to time) and TCP requests to resend it before any more data packets are sent.

The problem with all of this is that there is a delay between the sender realizing an error and the packet actually being delivered. Sometimes it takes several seconds. If you only download a file or a webpage, this is not a problem, but if it is a game package and there are at least 10 times per second, so you are in trouble, especially because it stops everything else. This is actually the problem, so almost no game chooses to use TCP as their main Internet Protocol, unless it is not a real-time action game. Most games use UDP-they cannot guarantee orderly or reliable delivery, but it is indeed fast-or the result is at least usually faster than TCP/IP. Now we know this. What about next?

Client Prediction
Because UDP is obviously a fast response to the game, we must handle packet loss and out-of-order. Edge. I don't have to say too many code secrets, so I can say there are methods. At the beginning, a client predicted that a word was quite talked about. When you connect to a large server as a client, but you cannot see updates from the server in a coherent manner, the client prediction starts to take effect. The game part running on your computer looks at the input you are giving it, and in the absence of any rejection information from the server, make 'best guesses about what it thinks will continue '. It will display the data to be guessed, and then correct itself when it gets the latest status from the server's world, if needed. You may be surprised by the effectiveness of this method. In general, most of the time data packets are not easy to lose-most of the time is a fraction of a second, in which case the game does not have much time to deviate from what the server actually thinks is happening. The deviation will indeed increase over time. In most games, there is a timeout function, and the game is stopped when there is no contact from the server for a long time.

The type of game you are creating is related here-the first-person shooter game does not need such an effective client prediction, because it generally only processes "where am I, do I want to fire? ". In a third-person game, you must be more precise, so that you can correctly predict the animation that your role is playing and be smooth. In this case, smooth animation is absolutely necessary. Heretic II has a big problem in this regard, and it is one of the most difficult things ravend has to deal with when it starts Network encoding.

Of course, if you have a good network connection, such as a broadband connection, this issue is far from that important. There is a wider channel for large data packets, and the network connection time is faster. In fact, the main advantages of broadband for games are no more than the fatter pipeline, but it greatly reduces latency, especially your first hop to ISP. For a 56 K modem, the typical latency of the first hop is 100 ms, which has significantly increased the potential connection time to any game server on the network. For broadband connections such as DSL, the latency of the first hop is mostly 20 ms. In Windows, you can use a command line program called traceroute (tracert. EXE) and specify a target IP address or domain name to find the connection time of your first hop. Take a closer look at the first hop, because it is almost always your network connection time to your ISP. And observe how many hops you use within your ISP network until you see a different domain name listed on a given hop.

Please note that broadband does not always solve the latency problem. You are still subject to the slowest Number of hops (or vice versa) between routers, servers, and data packets from the server over the network. One broadband connection is indeed easy to mitigate, but it is impossible for them to disappear. Of course, if you want to run a certain server, you will need a bandwidth with sufficient fast upstream data rates, because only one modem cannot handle the load generated by one server.

It is worth mentioning that if you want to play online games on PS2 or Xbox, you will need a broadband connection because both of them do not support modem.

Package Size, smart data transmission, and anti-cheating
The other thing that must be processed is the size of the data packet. If 64 people are running around to attack each other in a game, data packets sent from one machine to another can become quite large, to the extent that some modems do not have the bandwidth to process the data. This is particularly related to games with large surface systems. The problem added here is that because you have a good surface system, you can see a lot of other game players, so that the amount of data from the server you need to accurately render increases rapidly. What can we do?

Well, first of all, it is necessary to send only absolutely necessary things to any given client, so he just gets to observe what the game needs from his perspective. The data sent to people outside of his vision makes no sense-he will not be able to see this. At the same time, you 'd better ensure that only the data that actually changes between shards is sent. If a guy is still playing the same animation, it makes no sense to resend the data. Of course, if data packets are lost, this does bring about some problems, but that is why good network programmers are paid a lot of money to deal with such things.

There are other things to deal. A large number of annoying Online scams are happening recently. This is where some people modify the game to give them illegitimate benefits. Although it is not strictly part of the network, it does happen. Sometimes people create modules that allow them to immediately aim at anyone entering the field of view, simply allow them to see through the walls, or make other game players invisible to themselves. Most of the time these tasks can be handled either inside the network layer or on the server. Anyone with a 100% hit rate is simply kicked out of the game, because it is impossible within the range of manpower.

Game Developers must do everything they can to stop cheating, but unfortunately, what people do can be broken through. All you can do is make cheating difficult and try to discover it when it does happen.

Okay, it's now. In part 2, we will take a look at the interesting world of the game script system, rendering or enabling pre-defined scenes and behaviors based on events that occur during the game, and assisting in the narration of stories.