#tribes2

[bigbabarob]

The year is 2000. The game is #Tribes2. I was what they called a “farmer”. I setup intricate flag / base defenses and sensor network. Protect the flag, defend the generators, repair equipment, setup stations, stay alive. Folks would actually reach out to me when they needed a farmer. One of the best #videogames I’ve ever played. A massive online futuristic #capturetheflag #firstpersonshooter. Jet packs, “skiing”, Spinfusors, deploy-able bases, armor classes, sensors, turrets... oh so much fun. #OldSchoolgamer #gamer #gaming #pcgamer #pcgaming #onlinegaming #sierrastudio #gaminggeek #gameon #cleanupday https://www.instagram.com/bigbabarob/p/BuHI5ZZhrRP/?utm_source=ig_tumblr_share&igshid=hndo6s37uuxp

[theshazman999]

Going old school after finding some I'll screen shots from #tribes2. #pcgaming #gamersoflouisiana #gamersunite #gamersriseup (at New Orleans, Louisiana) https://www.instagram.com/p/B_1lEsOg8rr/?igshid=1a1o0z0j4rzg6

[certifiedhypocrite]

Sigh. Still wish a Tribes 2-like game was made. There are the remakes like Tribes Ascend and MidAir, but they keep seeming to miss the point of what made those games really fun.

I am suspicious that they’re concerned with making a popular e-sport and holding tournaments that are chasing cashflow since the games are conspicuously careful with how available vehicles are...

But I want a game like Tribes 2 where you can create secret bases in the wilderness, deploy radar to expand your team’s sensor network, have a “commander view” that shows your radar coverage across the landscape and plonk down personal waypoints for your skii route. Not only that, but place beacons and plan where you want to ditch your get-away vehicle and attempt silly heists in medium armor with a sensor-jamming pack on.

If none of that made sense to you, then whoops oh well, but the game was more involved and deep and weird. It combined base building elements with the combined arms of Battlefield, but gave everyone high speed jetpacks, too.

The modern incarnations don’t want to stray too far from a simpler, more deathmatchy feel to the gameplay. Like I feel like there’s a reason the Miami Vehicles server lasted as long as it did in T2.

[kyred808-blog]

Leveling and Big Numbers

Tribes 2 has a problem when it comes to big numbers.  After a point, the engine starts to represents the numbers in scientific notation.  For example, 2.86543+e08.  Unfortunately, decimal precision is thrown out the window when this happens.  Typically, this is fine, because the difference between say 2,000,000 and 2,000,000.01 is insignificant in the grand scheme of things.  But for some applications, the precision is needed.  Determining EXP for levels in TRPG is one of those applications, where a precise and consistent value is nice to have.

This has an impact on calculating exp required for the next level in Tribes RPG.  I think Tribes 1 had this problem too, because the code defines an OldGetLevel() and OldGetEXP() methods which are similar to the methods used in T2RPG.

I’d rather not have the max level be 110, which is where the old method breaks down.  So I ported over the new method to T2RPG.  The difference is that now all levels require 1000 exp, but the exp received from bots rapidly scales down as you pass them in level.  This helps keep the numbers small.

Edit:  Tribes Next has created a workaround for the big number issue (more info here http://www.tribesnext.com/forum/index.php?topic=2359.0;wap2) by packaging their patch with a Ruby interpreter.  Problem is that calls to this interpreter from Torque Script occur on the order of milliseconds.  Which is slow compared to microsecond time span that Torque normally operates.  While this isn't that big of an issue for calculating levels, it is far from ideal.  I’m afraid of someone writing a script that checks their level every second and then 20 people use it and slow down the server.

[kyred808-blog]

The Smell of Zones

One feature from T1RPG that I found neat was the “lastScent” data that the server stored for each player.  The idea is that every so often, the player will leave a “scent”, which is used when other players are trying to track them (with the #track skill).  But the higher a player’s SenseHeading skill, the less likely you are to leave a new “scent.”  The idea is that you are better at covering your tracks, since you are an experienced tracker yourself.  And if the player is actively hiding, then they never leave a new scent, regardless of their SenseHeading skill.

The server only stores one “lastScent” value per player.  So the #track ability only locates the last scent a player has left.  So if someone was trying to hunt you down, you could try to deliberately leave a scent somewhere (using #track on yourself to check) and then use #hide to stop leaving scents.  Sending the pursuer on a wild goose chase.

I added this functionality back into T2RPG.  In doing so, I found that T2RPG did not make calls to ZoneUpdate() (but has comments saying that they didn’t use it because they couldn’t get it to work), which is where the storeData for “lastScent” occured.  So, in order to get “lastScent” to work, I ended up implementing the RecursiveZone() function, which called ZoneUpdate() on all players ever 2 seconds.  Yay, scope creep.

ZoneUpdate() in Tribes 1 performed several things:

Update the player’s current zone

Perform environmental damage to player

Decrease ticks for temporary stat bonuses

Check to see if the player has moved, and potentially leave a scent

For Tribes 2, I left out 1 and 3.  Setting the player’s zone is now handled by entering and leaving trigger boxes around zones.  I think this is better than the old method.  And stat bonuses are handled be a work around, which was created because ZoneUpdate wasn’t working.  I’ll have to see if that method is better or not.

In the past few days (before starting this blog) I’ve made quite a bit of progress.  Once I get the backend fixed up, I can start work on the more obvious bugs.

[kyred808-blog]

Mission Area Alert

One of the neat things about Tribes 2 is the (theoretically) infinite map size.  The terrain of the map will repeat itself indefinitely.  Tribes 1 also had a repeating map, but it would eventually come to an abrupt end.  However, the repeating maps were generally large, which is what made large TRPG worlds possible. Most non-rpg maps have a set Misison Area which alerted players that they had left the boundaries of the map.  TRPG disabled this, because the whole map was used.

For T2RPG, the Mission Area is still there in map data, but it doesn’t alert the player when it has been crossed.  This posed a problem for potential new players, who could go out exploring for zones, but get lost in an infinitely repeating map.  So I added the alert back in with an audible beep, a chat message, and if those two weren’t enough, a zone change notification suggesting they turn back.

In the future, I’d like to make use of the extra map space to hide discoveries out there, which is why I’m leaving the ability to exit the map area open.

[kyred808-blog]

Hidden Fixes

The first thing I had to fix was the #hide skill.  It was ported over from TRPG incorrectly.

The way #hide works in Tribes 1 is pretty simple conceptually.  Check to see if there is anything (say, a wall or object to hide behind) within a 25m radius of the player, and if so make the player invisible.  To check around the player, GameBase::getLOSInfo() is used (LOS - line of sight).  This function is used a lot in Tribes 1 to check to see what the player’s crosshair centered on.  But it also has a lesser known parameter that let’s you override the looking direction.  So to check around the player, a for loop is used to count from 0 to 2pi in pi/4 increments.  Then for each step, getLOSInfo is called, rotating the looking direction around the player’s head.

The issue was with the fact that Tribes 2 does not have the GameBase::getLOSinfo() function.  The coders for T2RPG were clever and added a getLOSinfo() to save time porting, but they didn’t include the last parameter.  This meant, that hide would simply use the player’s line of sight 8 times, and check to see if there was something in the 25m range.  As long as something was in front of your face, you could hide.

It turns out, the player is less than 25m tall (meters is a misnomer here.  I’m referring to 1m as the distance from “0 0 0″ to “1 0 0″.  I should really say Units, but Tribes uses meters in their lingo.).  So the player can just look at the ground and hide.

I fixed this by adding the last parameter into getLOSInfo().  When the 25m radius check is performed, the Cos() and Sin() of the pi/4 increments is passed as the X and Y values of the last parameter, while keeping the Z value 0.  Then I override the GetEyeVector() call in getLOSInfo() with the new parameter, if present.  This is slightly different from how Tribes 1 handled it (it just passed the increment to the Z value), but it’s good enough.  Hide now works just like it did in trpg.

[kyred808-blog]

Tribes 2 RPG - Ironsphere

I’ve decided to start work on improving RPG for Tribes 2 known (aka Ironsphere).  I was a huge fan of Tribes RPG for Tribes 1 and used to work on making content for a few servers back in the day.  I’ve known about T2RPG, but it has always seemed unfinished.  So I’m taking up the torch and finishing it.

Really, this is more of a personal project.  There are no more dedicated servers for T2RPG.  I hope that may change with this effort.  But, I’m not going to get my hopes up.  If anything, I have something to play with friends on occasion, that can modified to evolve and grow to fit our interests.

But if anyone has an interest in this project, let me know.  I welcome the support.  I’ll be using this blog to post progress and journal my accomplishments and challenges.