Always incredible to read about how problems were first solved. Things like<p>Lesson Two: TCP is evil, don't use TCP for a game...<p>Lesson Three: Use UDP...<p>and the like are all "of course" solutions now, but they weren't then. How do you build something fast and reliable over something slow and creaky? Who knows.<p>The shoulders of giants have gotten a lot taller since then.
I loved the series, I remember in X-Wing there was a complete campaign where you start with hit'n'run tactics against some containers (!) and end in an ambush and the first kill of an ISD. This storyline made you feel hopelessly outnumbered and you just stood (flew) there in awe whenever something bigger than a Nebulon B arrived at the battle scene. Your AI wingmen just panicked and ran and so did you, possibly directing all your shield and weapon energy to your engines if you were unfortunate enough to fly a Y-Wing.<p>Later on you could count on corvettes and cruisers that reinforced your side (though they were always late) and you
felt the tide of the war turning.<p>I never got that feeling again, maybe because I am older. Or maybe because DX 11.1b support is much more important for a game and story is considered overrated.
There is a whole generation of people who haven't played XVT and that is a real shame. XVT has aged well over the course of time. I once dreamed of the day LucasArts was going to release XVT for the 21st century. Once they hosed that studio I gave up on the dream.
XVT had a two fold problem, half was the poor internet implementation but the other half was that the product didn't fulfill the genre's expectations.<p>Its predecessors (Tie Fight and X-Wing before it) had large, complex and well written story lines which following engaging missions paths. This was 80% of the game, as the graphics were relatively poor compared to sprite-based shooters of the time.<p>I remember the deep disappointment of booting XVT for the first time and realizing it had no story, and a terrible UX. I was launched into an offline lobby and only had the option to play some very uninteresting and un-engaging missions.<p>Put that on top of a completely unplayable multiplayer mode, it ended being a poor decision to make a game based on a technology they couldn't support -- when a perfectly valid offline story mode would have made up for it fine. So instead they charged another 49.99 on top of 69.99 for an add-on (and people complain about IAP) that gave the features the original box promised.
This is timely as I have been replaying X-Wing lately (specifically, the Collector's Series version that uses the XvT engine, aka xwing95). X-Wing was one of the first PC games I played when it first came out (I was in middle school) and thus I have an endearing love of space sims. (I have high hopes for Star Citizen and Enemy Starfighter.)<p>I think an interesting project would be creating a modern graphics engine that can parse and run the various X-Wing game data files. The XvT and X-Wing Alliance engines run ok on modern Windows but still have some compatibility issues (graphics glitches, etc). If a modern graphics engine (written in Unity or some such) could capture the look and feel of the X-Wing games, that would be great. It would be even better if it was an official game and not someone's open source project that never gets finished :(
Single page version - <a href="http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?print=1" rel="nofollow">http://www.gamasutra.com/view/feature/131781/the_internet_su...</a>
LOL! I wrote that for a presentation at the Game Developers Conference way back when. It was really a post-mortem, where the point is to show others what mistakes we made so that they wont repeat them. Anyway, its kind of flattering to see it come to life again... like some kind of Frankenstein internet cat. Thanks to all the positive commenters, and all you haters can fall into a timewarp and have to suffer through 28K modem hell all over again. ;) Or worse yet, be forced to watch Titanic...
It took the video game industry nearly a decade for most games to come out with network code as effective as X-Wing vs. TIE Fighter's and QuakeWorld's at hiding latency, packet loss, and bandwidth limits. Even recently, many fighting and RTS's games struggle on poor connections.<p>Until I played Killer Instinct, the only decent fighting games that I've run across have been based on the GGPO. Judging from my own and others experience, KI's network code is this generation's equivalent of QuakeWorld. I hope the developers of KI publish a paper like this one, detailing their technique.
If you find this interesting, you may want to take a look at a series of articles and a live demo I wrote on the topic of client-server networking for games (<a href="http://gabrielgambetta.com/fpm1.html" rel="nofollow">http://gabrielgambetta.com/fpm1.html</a>) which is very often cited on gamedev.stackexchange and similar places. It's more about First-Person Shooters, but most of it applies anyway.<p>X-Wing, Tie Fighter (and its mission packs) and X-Wing Alliance were awesome. XvT not so much :(
The article says (paraphrase) that<p>> On some connections one in five packets are dropped<p>And then shortly afterwards that<p>> This would only fail if two consecutive packets were dropped, and this seemed unlikely.<p>Hrm. I think I'm beginning to see the problem here, and it isn't the internet. Still, fun to read about the battle scars of remote gaming's early days.
I realize this is about game development, where missions and what-not are a major chunk of development. But still, I think most of the problems here are basic engineering failures: if you have a big infrastructure issue, <i>get that issue right before you go crazy on other stuff</i>. From the article:<p>"<i>We actually used the 'synchronous' version for quite awhile. It was good enough to test with, so finishing the network code was considered a lower priority than the other issues we needed to address at that stage of development.</i>"<p>And the result was, rather predictably:<p>"<i>When we finally came back to the network code we were behind schedule, and that affected some of the decisions we make later in the process. And it meant we were absolutely committed to the complexity of the missions, and the user interface.</i>"
For anyone interested, this is also a great article about multiplayer networking:
<a href="http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php" rel="nofollow">http://www.gamasutra.com/view/feature/3094/1500_archers_on_a...</a><p>Currently working on an iOS project using a similar system, which so far works great. A challenge I am facing right now is pathfinding in conjunction with synchronous multiplayer. Pathfinding can take a decent chunk of cpu time on lower-end devices, but you can't really multi-thread it since you need all players to calculate the same paths on the same simulation ticks lol... so might come down to rate-limiting the amount of units that can re-path on a given sim-tick.<p>Making multiplayer games is fun lol... :)
it makes me wonder if there's a way of encoding some kind of extremely compressed lossy version of the entire game state that can patch each player's state to be incrementally more "correct". Then on slow connections you're still keeping positions broadly where they should be, while faster connections will bring the game state to a more precisely correct state. How would you create such a packet without knowledge of each player's differences?<p>Just a thought experiment I was having. What if the game state was represented as a very large N dimensional vector. The most significant bits are sent until the players report that they match. then the next significant bits. then the next after that. Adapt the granularity of an update to the current throughput. If a player disconnects for 10, 20 seconds their game state re-syncs smoothly and gradually instead of in a jump cut?
<i>It was quite common for a re-sent packet to be dropped, and we saw several cases where the original packet and 4 or 5 re-sends of that packet would all be dropped. We were re-sending so many packets, we were starting to exceed the bandwidth of the modem, and then the latency would start to climb, and all hell would break loose.</i><p>That is exactly why TCP has the "slow start" protocol. I am sympathetic to their problems, though. I understand that the implementations of TCP they had access to had way too much latency, and that back then, there probably wasn't much tuning one could do on the outside. What they did is a clever hack (message <i>n</i> has a copy of <i>n-1</i>) that takes advantage of the fact that they don't have to send much data in total.
As well written as this article is, I do have a problem with its tone. The writer seems willing ignorant of <i>why</i> the Internet “sucks” for gaming; it was not designed for real time small packet transmission. Most of TCP’s design, in particular, was intended to facilitate the transmission of comparatively sizable files over FTP, NNTP, and SMTP. Even stuff like IRC was designed not to be so concerned about timeliness that the chatlog on each end would match up exactly.
I remember making a PC game in 1998 with multiplayer.. we had to handle 500 ms lag in an action game! Later I worked on a game that kept three versions of the simulated in memory (the old confirmed world, the new confirmed worlds, and an interpolation) to deal with lag while keeping in sync.<p>You don't know how easy you have it now!
Their implemented solutions at the end remind me of Halo 2, where players would slide and warp around if they were too laggy and where a bad enough connection would boot you out into a blue screen until it recovered (or kicked out the player with the worst connection).
> <i>When we started the X-Wing vs. TIE Fighter project, our goal was to create the first multi-player space combat simulator to be playable over the Internet.</i><p>They obviously hadn't heard of Netrek, the third multiplayer internet game ever, first released in 1988. <a href="http://en.wikipedia.org/wiki/Netrek" rel="nofollow">http://en.wikipedia.org/wiki/Netrek</a>