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."

Comments

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.

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. :)

OSS MMORPG

[7Ghent]

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

Anyone? Anyone? Bueller?

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 and , both of which are also also free and OpenSource.

Disclaimer -- I contribute to OpenPlay.

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: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...