Inside Warp Pipeby Howard Wen
Warp Pipe Makes GameCubes Party Together on the Internet
Nintendo's game consoles have been well regarded for their excellent multiplayer titles -- Mario Kart and Mario Party immediately come to mind. Now owners of the Nintendo GameCube can connect over the Internet to play together and against one another by using Warp Pipe, a networking application that requires a GameCube connected to a LAN with the Nintendo broadband adapter card. Created by Nintendo fans and developed under Linux, versions also run on Windows and Mac OS X.
Warp Pipe is not officially sanctioned by Nintendo. The company appears to have been reluctant to launch an online service that brings GameCube players together for gaming sessions, such as Microsoft's Xbox Live. "We haven't had any contact with Nintendo at all, but I hope they see what we are doing in a positive light," says Chad Paulson, the originator and project manager of Warp Pipe. "We simply want to create that bridge between GameCube gamers, extending the LAN capabilities."
From Open to Closed
Warp Pipe has had a major point of controversy in its short lifetime. It started as an open source project, but after the alpha release, Paulson and his team elected to close subsequent versions. (When this article was originally researched and written, Warp Pipe was still open source.) Essentially, the Warp Pipe team appears to have misunderstood the ramifications of releasing their code as "open source." However, they insist that, technically, the code in versions since the alpha are new rewrites. The original, open source Warp Pipe alpha version remains available (.zip file of Warp Pipe alpha version), but no longer receives any official updates by the Warp Pipe team.
"We all agreed that the alpha was a good release and that a lot of improvements were needed. At that point, it was brought up that we should go closed source, and there was a general consensus to do so, as long as the software remained free," says Tushar Singh Quack, developer of Warp Pipe's Windows GUI. "The earlier code is still open source. However, as soon as the change occurred, I started fresh and recoded the GUI in a different manner. The 1.0 release development was also started from scratch. Thus, all releases after the closing are fresh starts."
(Quack and Paulson both discuss this delicate matter further in follow-up interviews below. The rest of this article specifically addresses the development of the open source alpha version of Warp Pipe, and the technology behind it.)
Extending the "Nintendo Experience"
The core code of Warp Pipe alpha was written in C, with its GUIs in C and C++. Some XML parsing was necessary. Quack wanted to use XML absolutely everywhere for Warp Pipe, but the rest of the team rejected this suggestion, being more comfortable with C and C++.
The Warp Pipe team has four development groups. One team works on the network code, a second on the server side code, and the remaining two handle the GUIs for the Mac OS X and Windows ports.
Paulson got the rough idea for this project when he first learned that Nintendo would be releasing LAN-based games for the GameCube. "I am a huge Nintendo fan, and I love what they bring to the table in the ways of innovation, so I really wanted to extend that fun and overall 'Nintendo experience' over a wide-area network," he says. "I thought that it would be interesting to see how the connectivity and interactivity of the Internet would affect Nintendo's multiplayer games."
Paulson imported a copy of Kirby Air Ride from Japan the day of its
release. With his GameCube and Linux computer both connected to a LAN, he ran
the game on the Nintendo console and initiated
tcpdump on his Linux system. By gathering all of the packet data from the GameCube during both the connectivity
and gameplay sequences, he was able to collect enough information to write a
specification showing how the GameCube connects and relays packets. He
discovered that the GameCube uses the UPnP (Universal
Plug-N-Play) protocol .
Bringing Warp Pipe to realization laid in deciding the best way to make remotely connected GameCubes appear to one another as though they were sharing a local network, and minimizing (as much as possible) the inevitable lag in communication between the GameCubes. "Getting a solid design that everyone can agree on has been the biggest challenge, thus far. It took a couple of weeks just to decide how the actual proxy would work," says Aaron Yemm, who wrote the server code along with Courtney Falk.
Unfortunately, most of the developers had no way to test their code during the early stages of development. Only one LAN-enabled GameCube title existed at the time, the aforementioned Kirby Air Ride, and it was only available for purchase in Japan. It took a fair amount of guesswork to put together a working prototype.
Designing a unified user interface for the Warp Pipe client across different operating systems was also tricky. "We want the OS X and Windows GUIs to look alike, but users use each system differently. So designing the Windows version to work like the OS X version, or vice versa, just won't work," says Quack. "The solution is that we tried to make the same sort of interface with everything in roughly the same positions, but everything reacts differently. As somebody mentioned during one of our meetings, 'OS X morphs and moves.'"
Not the Only "Game" in Town
Warp Pipe has a competitor, in a sense. A Japanese team has created another GameCube-over-the-Internet project. However, it has a significant technical difference: the Japanese team's implementation requires a direct connection between a GameCube and a PC (with a second Ethernet card installed) via a crossover cable. "Our solution does not require anything that Nintendo already requires for a simple LAN game. Simply plug your GameCube into a router, plug your PC into the same router, and you're done," Paulson points out.
So far, the two teams have shared neither code nor personal communication, and the two techniques are incompatible. Besides any language barrier and hardware-usage differences, is the fact that the Japanese team has never released their work as open source.
Paulson guesses that his team and their Japanese colleagues have been "about neck and neck as far as progress goes." The Warp Pipe developers expect both methods of Internet playability to be similar in the end, when it comes to frame rate, speed, and other factors related to online gameplay performance.
Overall, the Warp Pipe team sees others' efforts to bring GameCube players online not as competition but a great sign of just how devoted, and technically ingenious, Nintendo fans are. "Since Nintendo lacks the huge support base for a system like Xbox Live, I think that grassroots efforts such as this will increase the popularity of online console gaming," says Falk.
An Interview with the Developers
Chad Paulson is the originator and project manager of the Warp Pipe project. The 23-year-old is currently completing a degree in management at Indiana University in Bloomington, Indiana, USA.
Aaron Yemm handles the server code of Warp Pipe. The 22-year-old works as a programmer in Waterloo, Ontario, Canada.
Courtney Falk, 23, is a masters student at Purdue University in West Lafayette, Indiana, USA. He contributes to the design of Warp Pipe.
Nathan Ford, 21, a recent computer engineering graduate from the University of Maine, lives in Orono, Maine, USA. He wrote the network proxy code for Warp Pipe.
Tushar Singh Quack, 23, is a biology student at University of Waterloo in Waterloo, Ontario, Canada. He's in charge of the GUI for the Windows version of Warp Pipe.
What are the inherent difficulties in getting the GameCube's LAN capability working over the Internet?
Chad: Getting the packets back and forth, and back again, in less than roughly six milliseconds has been quite a challenge. Latency has become the issue, even between high-bandwidth connections.
Tushar: We require the absolute fastest speeds we can get. Once the game starts, we have to minimize network clutter, and some of the features being added have the potential to create problems.
Nathan: The Cubes find each other by UPnP multicasts and then talk directly. So the first challenge was to bridge the UPnP and game traffic. Second, the Cubes use the IPs of each Cube to figure out who becomes the "master" of the game. This means that the Cubes must have an IP unique on every network that is proxied together. To do this, we look for ARPs from the Cubes and push them to the other proxies. If a IPNERF comes back, we fake that we own that IP, forcing the Cube to try and find another.
Aaron: There is one interesting challenge: educating kids and adults as to why this software is required. "The GameCube has a network card in it, right? I should just be able to connect to someone else." I don't think a lot of people realize why GameCube over the Internet is harder than GameCube over a LAN.
What interesting things about the GameCube's networking capability have you discovered? What's your opinion so far about its design?
Chad: I really like the use of UPnP [that Nintendo] implemented. It seems like a very "Nintendo" thing to do, in my opinion, as UPnP allows very simple networking, so you won't have to configure routers or anything like that. All someone has to do is plug their GameCube into their router at home and the UPnP does the rest. I think it is a good example of Nintendo's commitment to usability.
Courtney: I'm glad they chose the UPnP scheme and not some proprietary mechanism. Its design seems well thought out.
Aaron: I think all console networking should be designed more like a computer. The auto-networking UPnP stuff is cool. But if I had a say in the matter, I'd want to be able to manually specify everything.
For you as a programmer, what are some lessons you have learned working on Warp Pipe?
Aaron: The more people you have providing input into a project, the more feasible the project becomes. That, and the network side of game programming can be fun.
Courtney: Communication as a team, [which is] not something they teach well in schools and is compounded as you work across the Internet.
Tushar: It's very hard to get a clear picture across to each other over [online] chat. There is a limited time frame to do anything, especially since people are moving and working. Overall, we just keep talking and coding, and most problems iron themselves out.
Also, we have to reach a consensus on the GUI, and there was quite a bit of discussion on what things should look like, and there were disagreements. In the end, we went with something that was quite simple. Basically, we looked at what sort of user would be using [Warp Pipe]. We're guessing that since this is Nintendo, the interfaces have to be as simple as we can make them.
Chad: This is the first project I have managed where I have no direct contact with any part of the rest of the team. It has taught me that communication is key and that remote motivation is a challenging thing.
Overall, we've got a great group of developers, and they have done very well with the specifications and information I made available early on into the project.
In separate interviews, Tushar Singh Quack and Chad Paulson explained their decision to close the source code and addressed the controversy that erupted over their decision.
What issues did you guys have to deal with when deciding to close Warp Pipe's code?
Tushar: We had to make sure we were all on the same page, and thus Chad, Nathan, Matt, and I had to agree to the basic premise of keeping [Warp Pipe] free. One of the reasons for going closed was so that there wasn't a large team of people to manage.
What reactions have you received from the open source community?
Tushar: There's been some anger; however, there've been many people who've not minded it too much, as we've emphasized keeping it free. One of the nice things is that there were some who decided to push ahead with their own projects related to Warp Pipe. We're still very much in contact with the community and our forums have remained a very positive place.
Why did you guys even decide to first release Warp Pipe as open source? Was it a mistake, in retrospect?
Tushar: I think it was a great idea. Starting out as open source allowed us to get the team we currently have. The original team was 12 people, of whom eight didn't have anything to do. It wasn't really that they didn't want to do anything -- at that time, it wasn't a big project. A few months later, though, when there was work, most just didn't have the time. The main developers remained and everybody else just didn't respond.
What's your feeling about the open source philosophy now?
Tushar: There was a time when I was fanatical about everything I wrote being open source. That has worn off a bit now. Open source still has an edge in terms of getting ideas and concepts out there. However, closed source is easier to manage. At this point, management is much more important for Warp Pipe. I'd rather have Chad managing just the three of us, rather than talking about having code approved and dealing with the emotions and egos of other developers. We're programmers and we all get a bit emotional when a patch isn't accepted.
What advice do you have for others who are considering developing their projects under open source?
Tushar: You'll have a lot of people to deal with initially. Over time, though, fewer people will want to contribute, until you make the news. The code will kind of maintain itself as long as you have good management. Make sure you have a good manager, as he will allow you to concentrate on the code.
Are there any plans to open the code once again, sometime in the future?
Tushar: I think we're keeping it closed. However, I want other people to be able to contribute in their own ways. I've been talking with the team about enabling plug-in support within Warp Pipe. We can provide the base, but others can work on making enhancements they like.
What advice do you have for others who are considering releasing their project as open source? What issues should they be aware of?
Chad: That's one of your questions I didn't like.
Could you explain why?
Chad: I've been a fan of the open source movement for a long time, personally. I still am. There are many advantages and disadvantages on both sides of the court -- open source, closed source.
I asked that wondering if there are things one needs to be aware of before going open source -- a "checklist," perhaps. Tushar mentioned that organizing the Warp Pipe team under open source would have been a problem.
Chad: Well, let me respond this way. When starting a software project, you've got to look at all angles: who your audience is, how short the development cycle is, how is your current development team structured and balanced, etc. Warp Pipe started out as an open source project in the sense that I did some research and released a specification that detailed how the GameCube worked over a network. I published my initial thoughts. Soon after, the document was Slashdotted, and we had upwards of 30 developers on the team at one time.
Organization was very, very challenging. We couldn't get our wheels off the ground, and dealt with many flaky people along the way. Even with an established project manager -- me -- it was very hard to establish a shared vision among the team.
So organizing people under the open source model became a hindrance in itself?
Chad: I think open source projects fare much better when there is a shared vision. Given my experience, I know the importance of a solid development team that believes in the product at hand. It took us months to weed out the flaky people, and just move ahead on our own for any real innovation to occur. The major reason we chose to stay closed source was to keep the direction of the application under our control. By then we had a very tight, diverse, and well-managed team. We were cranking out new features and had a very clear and concise giant chart that paved the exact future of the application.
During the open source status of Warp Pipe, was there a conflict over what its "vision" should be?
Chad: There was much conflict over shared vision. So much back and forth about what the featureset would be, how it should work, etc. It came down to myself stopping all conversation and sending a game plan out -- a very basic strategy where we would focus on pure tunneling and add more features later on.
As for shared vision, a pre-existing project like Apache or even MySQL benefits greatly as an open source project. They are both projects with huge followings and a huge userbase.
With Warp Pipe, as an application that would tie into a central server, we saw total control of the end product as a must-have. It was important to us that all clients remain uniform for many reasons, mainly support. The last thing we wanted were a bunch of forked Warp Pipe projects out there.
It sounds like maybe there was a backwards approach with Warp Pipe's initial development. For example, Mozilla or OpenOffice.org originated from closed source software. Then they opened up their code. By then, the vision for these projects was already defined — there was a basis for others to start from.
Chad: With projects as large as Mozilla, open source is the way to go, no doubt.
Right now, closed source makes sense because [for us] we have enough development resources to accomplish our planned featuresets and enough management resources to make sure they are executed, tested, and properly released. If there ever came a time that development was lacking, or we needed more support on one particular platform, we would look at going open source again.
This, however, would shift our priorities. Further core development resources would have to be exchanged with checking CVS commits on a daily basis, and management resources would have to be exchanged with constant meetings and more levels of error checking. In some cases, going open source would require a lot of layers of communication and bloated bureaucracy that would slow down our dev cycle.
In retrospect, might it have been better for Warp Pipe had it begun as closed source? Start it closed, define its vision, then after a while, when most of the principal work is done and development has slowed, consider opening it up for others to contribute and help debug?
Chad: Well, I think open source served us well in the initial stages. I was able to recruit the best team of developers I've ever worked with. We were able to recruit a large number of developers off the bat, had the ability to share information up front, and weed out the people who were no longer interested. You can't do that under a closed source structure.
I suppose the touchy issue here is: it could be said what you guys did was use open source to recruit, but not to develop. How do you respond to this?
Chad: Everyone who contributed to the project decided to close source. Nobody's work was used while we were "officially" under an open source status. I think open source played a good role in distributing the initial GameCube data out there, but it hindered our development efforts.
What would the difference have been in simply inviting others to join the team if the project started as closed?
Chad: There is none. We haven't shunned any interested developers.
So would you say it boils down to a new project needing to clearly define its "vision" early on, and how much control the project leader(s) wants, as the factors one must consider carefully?
Chad: Exactly, and it has nothing to do with source code for the sake of source code.
The short answer is there is no correct answer. Both open source and closed source are very viable development models. Anyone who sees computing as a "religion" obviously has a very limited point of view. You need to look at every project with a clear perspective and go from there.
Return to the LinuxDevCenter.com.