Inside Warp Pipe

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.