Torque Network Gaming Library Released Open Source

An anonymous user writes "GarageGames launched the Torque Networking Library under the GPL today - this is the PC game networking technology behind Tribes and Tribes 2. It's also available under indie and commercial licenses for closed source projects, but OpenTNL.org is the home for the open source release, which also has an official FAQ online. Along with the library itself is a master server implementation for game tracking, a graphical test app, Zap and a retro-styled space shooter."

Awesome news!

[TempusMagus]

I've been using the Torque engine for sometime. And I gotta say, these guys are doing it right! People still play Tribes 2 and it can handle 60 (yes six-zero) players on a beefy box with little lag. Props out to them.

OSS MMORPG

[7Ghent]

Great! Now, who's gonna extend this and built a P2P open-source MMORPG?

Anyone? Anyone? Bueller?

Re:Linux Games

[TwistedSquare]

Given that Doom, Quake and Quake II have all been GPLed, presumably it literally is a matter of time until Quake 3 goes the same way.

Re:OSS MMORPG

[ShadeARG]

Actually, if it can handle high-speed gaming with an assload of players really well, I bet it would make a beefy P2P backend. (P2P + TNL) * Users * Bandwidth = Extremely beefy high-speed file distribution.

Other good network layers

[ezavada]

I've looked at the torque network layer while it was still part of the torque engine. It's well suited for developers who want a small scale (32 players or so) network game, particularly if its a first person shooter.

I wouldn't even consider it for a mid-size or larger multiplayer game, as it lacks important security features and IMO doesn't give enough control over the actual network protocol due to the emphasis on RMI.

Other network layers to look at are OpenPlay [sourceforge.net] and , both of which are also also free and OpenSource. [libsdl.org]

Disclaimer -- I contribute to OpenPlay.

Re:Awesome news!

[Lux]

That's certainly impressive, and it is related to the network, but in a kind of round-about way. The box being beefy helps, because processors scale so well. But the reason MMORPGs charge per month isn't processor consumption. Network bandwidth is much costlier, and doesn't scale as swiftly.

If you take the naive approach to implementing state synchronization in a real-time system (like a video game) your server consumes upstream bandwidth proportional to the number of updates per second, times the number of participants, times the number of items synchronized. In a game, you have to synchronize each player at least, so we're talking quadratic bandwidth in just the players. That's how I did it when I had to, and we scaled to at least six players with plenty of breathing room. (Our dev team had six players. I don't think we ever brought in more testers to push it harder. :)

If you take a less naive approach, you can get that from quadratic to n*log(n). And you can get a lot of constant-time and common-case improvements (the above is all worst-case.) You can find that approach somewhere in "Game Programming Gems," IIRC.

I don't know if that has been proven as a lower bound, but I'd squint hard at anything that claims to be faster.

Can it handle 60 players who all have line of site to each other? That's a tough stress test. :) I'd be blown away if they can do that over the Internet, and probably still impressed on a LAN. (I'm feeling too lazy to break out my calculation-envelopes. :)

Re:id is not being generous

[king-manic]

Carmac is a believer in OSS. although it's good business to ensure your engine has good penetration, by the time ID releases the code, the next generation looks nothing like the code GPL'ed. The benifit is much smaller then you imply.

Quake 2 c code looks nothing like Quake which both look incredibly different from Doom.

Re:Strange licensing fees? Anyone undestand?

[alexandyr]

A number of new features have gone into TNL. But more importantly, it would take a lot of work to rip the networking out of Torque and abstract it for general use. By getting TNL, all this is done for you, and documented. The added cost is largely for the time and effort all of this will save you. If you just want to start a game from scratch rather than adding networking to an existing project, the full Torque engine is probably a better option. Of course if you are doing an open source project, there is no added cost :) Disclaimer: I am a GarageGames employee

Re:Multi-platform, what about languages?

[Vaevictis666]

I was actually thinking about this very thing - how hard would it be to write a wrapper for this using Ruby?

With a cursory look at the docs, it looks like it wouldn't be too bad - it looks to be fairly OO at the moment, so you're just looking at a translation layer implementation. OTOH, it might be tricky to get all the efficiency on it, since it will do ints and floats to *bit* precision, and I don't know how well Ruby would interface with that...

I'm not trying to be cynical

[AHumbleOpinion]

I'm not trying to be cynical. The original post seemed to suggest that id was being completely altuistic, that was naive. That's all I wanted to say. As far as your suggestion of "it's the right thing to do" that is not quite right either. In an old Game Developer Magazine article id was quoted as saying that Linux versions make no sense from a business perspective, that they just do it "because it is cool". Well, they can afford to be cool. Other developers can't.

Re:Other good network layers

[Elbeno]

While 128 players is a great achievement, it's not all about the network model.

The reason why most FPSs do not have such large numbers of players is less to do with the network bandwidth and more to do with a) the CPU cycles devoted to rendering and/or running collision models for N detailed player characters in complex environments, and b) the content generation: maps are specifically designed to be good for a smallish range of players, and it's usually not worth it to design 128-player maps.

This is clearly a good network engine. But the other FPSs of the world aren't failing to support 128 players because the TNL programmers are technical geniuses by comparison. They are undoubtedly good, but they're solving a different problem.

As an FPS network programmer, you use the available bandwidth to provide the best experience for the player. You stop optimising when you don't need to optimise any more. If all your maps aim to provide a good experience for 4, 8, 16 players, you don't design the engine to go up to 128 just because you think it would be neat.

Re:I've been working with Torque

[ImpTech]

Also working with torque, and definitely second those comments. Its high-quality, fantastic code for FPS gaming, but if you try to extend it too far you run into all kinds of problems, presumably since the designers never had intentions of extending the engine for anything other than Tribes2. I, for instance, am trying to make a small, fps-ish MMORPG, and the hardcoding of their terrain management and rendering code is driving me around in circles because its only designed for the very small Tribes2 maps. That said, you won't find an engine for anywheres near the price thats half as good, and cross-platform to boot.

Concerning the network code, I haven't delved into it much, and don't expect to have to since its already well known that the Tribes2 netcode was superb.

Now if someone smart...

[bruthasj]

Can give me a triple punch of an architecture including the best of:

* Twisted [twistedmatrix.com]
* ACE [wustl.edu]
* OpenTNL [opentnl.org]

Any other neat ones you can think of?

Re:Awesome news!

[The Evil Couch]

damn right. I was probably on the same server. I don't remember too many 100+ servers for tribes 2, and I was on a 56k at the time, too

the game handled the unheard of at the time amount of players extremely well. I had even slightly better performance as I was even able to duel people one on one, I just enough lag that I couldn't snipe.

the truely miraculous thing about those servers is that they were public servers, which naturally means having people stretched out from all over north america and likely all over the world, all with very little lag.

I only wish I knew more about network protocols so that I could take a peek at the source for it and get a true appreciation for tribes 2's power.