To revive and get Dreamcast games back online when the original servers are no longer available, one needs to collect enough information about how the original servers for the game worked, and its important to make the available information public so that others may contribute.
Below are some of my finds:
Developer on SEGA/Nokia SNAP:
The code was compiled using gcc on CentOS and cvs for source control. It
would be good if somebody at Nokia could give you the cvs repository.
Kosaka was probably working on Solaris.
I was directly involved in PS2 and ngage games, primarily the 2k sports
games (Visual Concepts) and a series of Capcom games (Resident Evil
Outbreak, Monster Hunter, etc). Also a bunch of games by RedLynx on the
rUDP was in the version of the code I started with, so Kosaka wrote the
first version. File it under “those who do not understand TCP are forced
to reinvent it”
The bootstrap server was a load balancer/authentication server. It used
the same UDP transport as the KICS (game router) servers. The bootstrap
basically took a request, built a challenge reply containing where the
client should connect to KICS and encrypted it using blowfish and the
password as a shared secret. One wrinkle here is that each client got its
own UDP port on KICS — most people were used to game servers using a
particular port, SNAPcom didn’t do that.
188.8.131.52 according to legend was Kosaka’s desktop Sun workstation.
The ops people were extremely annoyed that he didn’t use DNS (rightfully
so). Getting around this may be a serious problem.
The differences between the games, at very least, is the game class id.
Multiple game class ids can be served by the same bootstrap/KICS.
SNAPcom also allowed game-specific servers to be written (for custom
matchmaking or persistence or…) and you’re unlikely to have any of that.
Developer on Sega’s KAGE and SNAP systems:
[..] KAGE was the proto-SNAP … SNAP evolved from KAGE, but the two are wildly different.
KAGE became SNAP … so yes, the Dreamcast used SNAP, in that it used evolving versions of KAGE.
Developer on World Series Baseball 2k2:
From what I recall, we used lobbying/ranking services provided by Sega, BSI did not write custom servers.
The DC implementations were largely P2P over modem as I recall.
Developer on World Series Baseball 2k2:
If I remember correctly, we used the same Sega lobby tech as Visual Concepts was using for the Sega 2K football series. There might have been some changes to it, but my recollection is that we used it pretty much as-is. At the time, my impression was that it was written by devs at VC and was probably only used for sports. I also remember the server evolving, so it probably had minor changes between WSB 2k2, 2k3, 2k4. Only 2k2 was on DC though.BSI handled the in-game networking which was peer-to-peer, and should still work fine on either a Dreamcast or an emulator once a game has been started by the server.My guess is that the easiest way to get these games running multiplayer would be to ‘fake’ the server, and just pass two consoles the IP of the other so a game can start. That’s what we did during development. However, in the released game you probably have the UI in the way forcing users to go to a lobby, find another player, etc. So you’d either need to hack the game to bypass the lobby and go right to a game with the opponent IP, or handle all the server behavior to support lobby matchmaking.
Developer on SEGAs server infrastructure:
We ran many bootstrap servers. Propeller Arena and Outtrigger were original titles and I believe used the same servers, but for most other games we had clusters of servers including a unique bootstrap server. I want to say the bootstrap server actually ‘redirected’ the client to a particular game server, so it just handled the initial connection and redirection components (not sure about auth). Bootstrap was a fairly ‘lightweight’ process and I don’t believe it acted as a proxy for all the traffic but just the initial ‘handshake’.
Snap was the AFAIK the only game engine used for for non 2k (NBA2KX, NFL2KX, etc) titles, and it was cross-platform. We also ran the online play for resident evil online and monster hunter.
It’s very unlikely those server exist. Most of them were like 5 yrs old when I left, some of them suffering from metal fatigue and bowing they were so old.
Developer on KAGE servers:
There was a bootstrap server which would service the initial request and redirect the client to the game servers. On some titles, the IP address of the bootstrap was hardcoded. This could prove to be an issue. This was what killed certain titles [Daytona USA, Alien Front Online], when Sega gave up a network block that belonged to AT&T after changing ISPs.
Developer on SNAP servers:
So if memory serves correctly they used a proprietary in-house protocol called RUDP (Reliable UDP). When you initially connect to a game you talk to the bootstrap server. Once you’ve gone through the connection process you were assigned to one one of the cluster nodes. In some games these equated to ‘worlds’ but not always. It was highly dependent on the game design.
You might be able to glean something from an old JDK addition:
“This release of the Sun Java Wireless Toolkit includes Nokia’s Scalable Network Application Package (SNAP) Mobile API and the SNAP Mobile Sample Application as part of the toolkit’s External API feature. SNAP Mobile is a combination of client software and server infrastructure that supports the creation of networked, community-enabled multiplayer games. For more information, consult the SNAP Mobile web site at http://www.forum.nokia.com/snapmobile. The Emulation Environment, development resources and support for SNAP Mobile are available from http://www.forum.nokia.com/games/snapmobile. Please see SNAP Mobile Emulation Environment Installation for further information.”
This was effectively a ‘proxy’ for the gaming platform over http.
Developer on Unreal Tournament:
So, UTDC was done at Secret Level… Epic wasn’t involved in the code or anything. In other words, it is not expected to be compatible with normal UT99 PC builds.
I can’t actually remember how the dedicated servers worked – or if we actually had any :)
I would have gotten the server running at Secret Level, and Sega would have been running them.Now that I’m at Epic, I’ll see if I can hunt down any source code (it’s possible I sent it all over to Epic back in the day).ENTRY.DAT… The way we shipped the data on UTDC is not in any useful way that you would ever be able to get it back. All the bytes are reordered to be the exact order randomly read from 100 files, so that the disc never needs to seek when loading a level. It’s nothing like the loose files you would see in a PC build…Without the source content and code, I don’t think you will ever have luck here :(
The online capabilities were in two phases – setting up an online game and actually playing the game once a host and guests had been established. I mostly worked on the first phase which was part of the user-interface at the start of the game. The WormsNet server was basically a standard IRC (Internet Relay Chat) server – as far as I recall, there were no changes to this at all. The client software in the game’s frontend sent messages using the IRC protocol to set-up rooms, chat to others that were also online and set up games. Rather than send plain text in IRC, the messages were pre-encoded so that the clients could distinguish commands (such as host a game, join a game, start a game, etc.) from general chat. All this logic is encoded in the game software so in theory you don’t need to worry about that if you point them to a standard IRC server. Once a game had been hosted and other players joined (using IRC messages to keep everyone in sync), a final ‘start game’ command was sent from the host and the clients received this. The host/client information was passed onto the game code which then handled the communication between hosts and clients to do a network game.I don’t recall the syntax of the IRC commands that were sent, but as I said – you should not need to know this as it is all in the code that extended the IRC client software in the game itself.That’s as much as I recall – it was all a long time ago. Good luck with the project and let me know if you have any success.
I apologize for the delayed response. I did receive your last message and I followed up by asking my studio’s president (same studio we developed Ooga Booga with and same president running things now as back then) about whether I could assist you in any way, and he did not approve. Unfortunately, as employees we’re under NDA and although I have the source code for Ooga Booga still, I do now know who owns the technical rights to it.Reverse engineering the server packet communication would not be an easy feat either considering we used strong blowfish encryption for authentication. In fact, I’m not sure I could even find the server private keys again!Anyway, I’m flattered that you’re trying to revive the game for modern day players. I wish you the best of luck.
I can confirm you we used at that time both Sega and Ubisoft OnLine SDKs.
Yes, both games [Speed Devils Online & Pod: Speedzone] used the same kind of interface and were released in the same timeframe.
dan1234 on Half-Life:
I did a bunch of poking around in half life and found that most of the multiplayer components seem to already be in the game. Made a post at assemblergames about it. Figured this falls under the “research” spectrum for dcserv
Link to post: http://assemblergames.com/l/threads/hal … nts.57318/
[…]There’s been some cool developments over at my half-life thread. Not sure if you’ve seen it or not. But Sizious re-enabled the connect command. Turns out, it looks like it tries to connect which is amazing
I haven’t tested myself yet, so i don’t know if it actually does try to connect. But if it does, that’s a good enough reason for me to believe that all of the other functions for the network do work. With the exception of actually connecting to the network in-game
I looked into the WON version of half-life, and most of the internet functions were handled by WININET.DLL. Or at least it looks like most of them do. Turns out the WININET.DLL in the WindowsCE Dreamcast kit have the same imports/exports as the x86 version of the DLL and half-life
I’m pretty certain Sizious is attempting to inject DLLs into the DC EXE. I’m confident that with a WININET.DLL and likely another DLL or something, the game would be multiplayer capable. If it turns out to work, it’ll be really cool to say i spearheaded that. But the reason i messaged you was there’s probably a bunch of material for your ‘resources’ section
Developer on Worms World Party:
[…]When I left the company, I left behind my PC in the warehouse with all the code on it. So I’m afraid it’s lost unless someone has a backup somewhere.I guess the best bet would be Sascha. Pretty sure it was him who did the eggdrop.Basically, the game itself used a TCP/UDP connection which was formed between the clients and the host. The IP address of that host was passed via the IRC+Eggdrop setup. So the in-game networking is all just normal winsock stuff (originally we had been trying to use DirectPlay then Karl (lead programmer) spotted a huge bug in it, which meant I had to rewrite a directplay-like client using winsock and the same DP method names).So if you can get the eggdrop setup working, there’s no reason the game itself can’t work. I can’t remember if there was anything specific for the Dreamcast though, in terms of IP address stuff. From what I recall the networking stack was pretty much like winsock but without the hWnd requirement. Best guy to ask about that might be Mark Robinson, I do recall sitting with him once and going through the networking issues, so he might have done the winsock->dreamcast network porting.Hope that helps.
Initially when we released Worms Armageddon I think it was, we were using a SQL database written using Microsoft SQLServer for storing the details of games. So we had a stock IRC server and a seperate connection to the games list database.
It turned out that SQLServer was a complete pain in the ass to keep running in its default configuration. From what I recall we pretty quickly had to turn to using just the IRC server. In order to actually propagate games information, from what I remember we used a channel bot which was a modified version of eggdrop to allow the IRC clients to publish/query the running games info (basically just IP address of the host).
I honestly don’t recall the exact details now. I was literally half dead at the end of the crunch for the game, had been trying to keep the SQLServer alive after doing all that crunch, so maybe my memory is a bit clouded. I believe Sascha actually ended up coding the eggdrop version.
So the purpose of the eggdrop was storing and relaying a list of IP addresses for running games. I guess the clients simply used an IRC message to the eggdrop bot to ask for the games list (and add/remove one etc). So that might well be a good place to start. Might want to look and see if there’s a standard bot name required and see if you can make your client look like the bot (I guess it was just a specific name with channel privileges) and see if the game starts sending you messages.
Anyway, anything I can do to help!
Boy you are asking some questions that right now I am not sure I can answer. It was over 15 years ago and I have worked on a lot of games/code since. Yes the matching and lobby server was based on irc but I do believe it was modified. PC one I know was and I believe the one for dreamcast was too to stop cross connections with pc versions. I remember having that working during testing but it was not something to ship. Also the server was hosted by sega for us so was behind their network and I am not sure what authentication was being done there without pulling backups of the code and taking a look. I know I do not have the server code though as that was not done by me, Phil Carlisle was more in charge of that from what I remember. How far have you got in getting it working as that might help me point you in the right direction. Regards
SNAP is familar, but i think in 2k1 days it was very much in its infancy. The sports titles all ran our internal solution built by V. I dont have a binary and i’m away from my old engineering notes until at least the end of the month. I could take a look then but i am 100% sure that i don’t have a server binary. There are two people that are at the heart of the original networking. Most of the early 2k sports used common code bases and philosophies for networking. […] was the main client engineer and that included the networking. He is still employed by VC and is very close to the heart of VC so may be hard to get a response from. I’d say if you get an immediate response they’re probably best left alone for politeness. I believe […] also was involved from the server side. I don’t know him that well as he worked remotely. I’d also ask him. I’m a big believer in keeping old games alive. I made warzone2100 back in the nineties and it’s community is alive and well thanks to eidos allowing us to go open source. I can try and help by contacting others if you get no response. alex.DreamcastTM on Worms World Party:<%c:%s>%d,%d,%d,%d,%d,%d <%c:%s> <%c:%s>%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d <%c:%s> <%c:%s>%d,%s,%s,%s,%s,%d,%d <%c:%s>no And I determined what these do from communicating with the IRC server: <e:pn!hash> (GAME FULL) <q:gn>pn!hash (CALLS GAME ENTER) <n:pn!hash> (EXITED THE GAME) <c:pn!hash> (PLAYER LEAVES A GAME) <d:pn!hash>pn (PLAYER ENTERED) * gn = (game's name) * pn!hash = (player's name)!(8-character hash)