Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter
View All     RSS
May 26, 2019
arrowPress Releases
May 26, 2019
Games Press
View All     RSS








If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter


September 3, 1999 Article Start Previous Page 6 of 6
 

Conclusions Drawn

The conclusion is obvious: the Internet sucks. We were pretty disappointed in how our game performed over bad Internet connections. But looking back on it now, I believe we did as good a job as anyone else, given the style of game we were building, and the constraints we were forced to deal with.

The lack of a dedicated server turned out to be a huge problem. In cases where the "lost connection" phenomenon lasted more than a few seconds, it was clearly easier to send the entire state of the world than it was to re-send all the packets that had been lost. This was not practical, however, because the computer that would have to do that would be one of the players', and could not spare the bandwidth. A dedicated serer could have addressed this problem, and doing so would have been equivalent to allowing a player to "join" a game that was already in progress. "Late join" was a feature we really wanted to have in the game, but we felt it just wasn’t practical without a dedicated server.

I can't think of anything clever

A dedicated server would also have made it easier to support more simultaneous players. The latency would be cut nearly in half, because messages would not have to go through modems before being re-sent to the other players, as they do with the "host" player. In addition, a dedicated server would make it significantly easier for a player to evaluate the quality of their connection to the game, since they would only have to worry about their connection to the server. With a player acting as a host, the other players must be concerned with the quality of the host’s connection to the Internet, as well as their connection.

One of the biggest problems we faced with our network model was the requirement that packets be processed in order. Out-of-order packets could be used to improve the predicted copy of the world, but in XVT they are not. Even if they were there would still be a significant performance problem. The problem is that when the in-order packet finally does arrive, we must process it, and all the out-of-order packets that have come since. This can be time-consuming because the simulation must be run on each packet.

Both of these problems would have been much easier to address if we had started from scratch. But because we were modifying an existing engine we were limited by its capabilities. If the engine had been able to simulate large time steps more efficiently, that would have helped a great deal. We were effectively required to use a fixed time step, and this made simulating a long time step very inefficient. In addition, if the engine had been able to use out-of-order data to improve the predictions, then the long lag for a re-sent packet would have been much less noticeable.

One of the advantages of our approach to the problem is that it is pretty much completely independent of the game’s content. The packets we send only contain data about the player’s input device, and this technique could work virtually unchanged for almost any kind of real-time game. The really nice thing about this aspect of the model is that we did not have to worry about changing the content of the game, requiring us to change the network code. The fact that no game-specific data is included in the packets also makes it much more difficult for players to cheat by using "bots". In order to give an advantage, a "bot" would have to be able to create a stream of input data that is more effective than a human player and I think this would be extremely difficult.

Currently, Peter Lincroft is President and Lead Programmer at Ansible Software. He graduated with honors from the University of California in computer science. His first title was Pipe Dream, which he programmed single-handedly in just seven weeks. He went on to program his first 3D graphics engine for Lawrence Holland on the Secret Weapons of the Luftwaffe project. Peter continued to work with Lawrence, helping to create the game software development company that would eventually become Totally Games, Inc. Peter was the lead technical programmer for Totally Games until April of 1998, when he left to form his own company, Ansible Software, Inc. His list of published titles includes Pipe Dream, Secret Weapons of the Luftwaffe, X-Wing: Star Wars Space Combat Simulator, X-Wing CD, TIE Fighter, TIE Fighter CD, and X-Wing vs. TIE Fighter. These titles have sold over 3 million copies, and won numerous "game of the year" awards. TIE Fighter CD was recently named the "best game ever" by PC Gamer magazine.


Article Start Previous Page 6 of 6

Related Jobs

Gear Inc.
Gear Inc. — Hanoi, Vietnam
[05.25.19]

Technical Director
Dream Harvest
Dream Harvest — Brighton, England, United Kingdom
[05.25.19]

Technical Game Designer
Pixar Animation Studios
Pixar Animation Studios — Emeryville, California, United States
[05.24.19]

Animation Tools Software Engineer
Disbelief
Disbelief — Chicago, Illinois, United States
[05.24.19]

Senior Programmer, Chicago





Loading Comments

loader image