TRIBES gamedev history question
by Russ Dill · in Technical Issues · 11/06/2017 (7:00 pm) · 6 replies
I've been analyzing the BF1942 netcode (Refractor engine) and after searching for other people doing similar work, I ran across a paper by Mark Frohnmayer and Tim Gift describing the Starsiege TRIBES networking code. There are way too many coincidences for the similarities to be accidental, especially since Starsiege was released in '98 and Codename Eagle (first Refractor engine game) in '99. These games were under development simultaneously.
So I'm curious, are the engines based on a common codebase? Was the TRIBES netcode sold to Refraction Games? Was there a developer that cross pollinated ideas between the two game houses?
Starsiege TRIBES netcode paper: http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf
The first similarity I found is that Refractor has a set of stream managers, including a Ghost Manager that syncs the state between client and server object databases. In addition, there is an stream Event Manager. Figure 3 is a fairly accurate representation of the Refractor high level packet structure. At the lowlevel, there is a BitStream class that packs and unpacks bits using functions like readBool, readInt, etc. Just like the TRIBES engine, it has support for single bit, variable length integers, and variable length normalized floats. The sliding window and retransit system described are also very similar.
Ghost data updates also start with a ghost ID and have a state mask that describes what fields are present. One thing that has struck me as odd is the ghost data contains a 2 bit field which indicates the type of update. If the field is 3, the object is deleted. If the field is 1, it's a normal data update. Values 0 and 2 are not used in the netcode. After reading the TRIBES paper, I noticed that the TRIBES netcode uses the ghost data to create new objects as well. The Refractor netcode uses a Game Event to generate a new object. I can't help but to wonder if value 0 or 2 used to indicate that a new object should be created and the field was never shrunk down after the change.
Another major difference is there is no Datablock stream in Refractor. Instead all the properties of vehicles (max speed, max accel, suspension, etc) as described in the TRIBES doc is stored on both the client and server. The CRCs of the data must match exactly and both client and server must parse them identically. This is because the Refractor engine assigns each template instance (what the TRIBES engine calls a datablock) an ID in the order that they are parsed. When a new ghost object is made, it is constructed using that ID, just as described in figure 5.
I'm sure this just sounds like bizarre rambling to most people, but I'm hopeful that someone is still around from those days and can satisfy my curiosity.
So I'm curious, are the engines based on a common codebase? Was the TRIBES netcode sold to Refraction Games? Was there a developer that cross pollinated ideas between the two game houses?
Starsiege TRIBES netcode paper: http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf
The first similarity I found is that Refractor has a set of stream managers, including a Ghost Manager that syncs the state between client and server object databases. In addition, there is an stream Event Manager. Figure 3 is a fairly accurate representation of the Refractor high level packet structure. At the lowlevel, there is a BitStream class that packs and unpacks bits using functions like readBool, readInt, etc. Just like the TRIBES engine, it has support for single bit, variable length integers, and variable length normalized floats. The sliding window and retransit system described are also very similar.
Ghost data updates also start with a ghost ID and have a state mask that describes what fields are present. One thing that has struck me as odd is the ghost data contains a 2 bit field which indicates the type of update. If the field is 3, the object is deleted. If the field is 1, it's a normal data update. Values 0 and 2 are not used in the netcode. After reading the TRIBES paper, I noticed that the TRIBES netcode uses the ghost data to create new objects as well. The Refractor netcode uses a Game Event to generate a new object. I can't help but to wonder if value 0 or 2 used to indicate that a new object should be created and the field was never shrunk down after the change.
Another major difference is there is no Datablock stream in Refractor. Instead all the properties of vehicles (max speed, max accel, suspension, etc) as described in the TRIBES doc is stored on both the client and server. The CRCs of the data must match exactly and both client and server must parse them identically. This is because the Refractor engine assigns each template instance (what the TRIBES engine calls a datablock) an ID in the order that they are parsed. When a new ghost object is made, it is constructed using that ID, just as described in figure 5.
I'm sure this just sounds like bizarre rambling to most people, but I'm hopeful that someone is still around from those days and can satisfy my curiosity.
#2
https://github.com/kocubinski/opentnl/blob/master/tnl/bitStream.cpp#L397
static U32 gBitCounts[4] = {
16, 18, 20, 32
};
Engine/Io/BitStream.cpp (bf1942):
int dice::ref2::io::BitStream::m_compressionVectorBitTable[] = {32, 20, 16, 12};
They both write a 2 bit value for the bit count entry they used followed by 3 signed ints, each scaled by the square root of the dot product divided by the scale value.
11/07/2017 (12:06 pm)
The BitStream class for certain shared a common history. Both not only has a common concept of a compressed point relative to a certain center, they both use a similar bit counts table:https://github.com/kocubinski/opentnl/blob/master/tnl/bitStream.cpp#L397
static U32 gBitCounts[4] = {
16, 18, 20, 32
};
Engine/Io/BitStream.cpp (bf1942):
int dice::ref2::io::BitStream::m_compressionVectorBitTable[] = {32, 20, 16, 12};
They both write a 2 bit value for the bit count entry they used followed by 3 signed ints, each scaled by the square root of the dot product divided by the scale value.
#3
11/08/2017 (8:06 pm)
It is likely the netcode design came from the same place that Tribes and Refractor engine developers got inspiration from. Either that or a developer that previously worked on Tribes moved on to work on Refractor engine. I wouldn't be surprised to find that the netcode origins, same for tribes/torque script, originated from something much earlier than Starsiege Tribes. Because all that code is pretty impressive to just originate from one game, and not have been used in earlier games/engines to be improved upon leading up to Tribes, in my mind.
#4
The paper indicates that the model described was first implemented in Starsiege TRIBES. Most of the high level and even low level concepts they have in common I haven't seen in any other game engines. Being able to look at the TNL source is a nice help, but it's too bad the original stuff isn't open.
11/08/2017 (9:21 pm)
One dev house is in Portland and the other Stockholm. Don't think they ever shared any talent.The paper indicates that the model described was first implemented in Starsiege TRIBES. Most of the high level and even low level concepts they have in common I haven't seen in any other game engines. Being able to look at the TNL source is a nice help, but it's too bad the original stuff isn't open.
#5
11/09/2017 (10:03 am)
You'd be surprised how much "original stuff" made it into TNL. Hell, even Torque itself. There was Tribes player class stuff that made it into the engine, like cloaking. What you see in Torque and the TNL links I sent you are pretty close, though with some improvements. 
#6
01/30/2018 (7:46 pm)
Wouldn't be surprised if there was some sort of shared inspiration from a white paper or code out there (possibly from a book or on the internet etc) from back in the day. 
Employee Michael Perry
ZombieShortbus
Old Torque Network Library page
TNL on GitHub