Wednesday, September 25, 2013

Metagame: The New, The Old, The Community

Discovery vs. Being Told

It isn’t so much a phenomenon as it is a natural occurrence- since the dawn of gaming, a lack of explicit directions to reach the “win” state has been the norm. It happened on our beloved old Atari games, it happened in Super Mario, and it happens now in our shooter games. As it’s been said before, it’s much more engaging for a player to discover what to do rather than being told what to do.

Most people can easily determine Mario needs to get to the right-most point in the level within a certain timeframe. Most people can figure out in CTF that you the objective is to grab the enemy flag and bring it back to the friendly flag while it’s back at home. To many seasoned gamers, objectives come naturally- and to those new to gaming, it doesn’t take too long to figure out.

But at what point should a developer decide something needs instruction? When asking this question, there are two phrases that come to mind: “emergent gameplay” and “metagame”. Traditionally, both of these are products of the society of gamers themselves, not of the developer. 

Metagame and the Community

In competitive games, the metagame is largely decided upon by players through process of trial and error, a bit of max/min, and doing what works the best. This somewhat harkens back to the “Problem of Choice” when choices become problems with tangible solutions- this is the nature of competitive gaming. Players are more involved and care more about the meta game when they are the ones “discovering” it. All of the upsets, pleasant surprises, and feelings of validity while problem solving cease to exist if the players are told exactly what to do. Either way, you need people who care about the metagame.

What keeps any online game alive is people who care enough about the metagame to promote it and establish it as the “way” to play. To many gamers, strategy is what gives their own actions and the actions of others context and meaning. It makes people feel valuable, and gives them a sense of responsibility. As well, a metagame gives people a tangible means of communicating why they are losing or winning. For players of an online game, carrying out the responsibilities, being efficient, and proving their value to others- being “clutch” – is a large part of what constitutes “fun”- it validates the way they play the game. 

The Holy Trinity

Gary Gygex may have had something similar to “the holy trinity” (the healer, the tank, the damage dealer) in his mind when first creating Dungeons and Dragons, just likely not in such simple terms. Of course you had your Priests who healed, and Wizards who altered the vitals of his teammates as well as his enemies. Back in the old days of pen and paper dungeons and dragons, it was up to the dungeon master to craft a unique scenario for the players that would fit their play style and party composition- so choosing a role to play really was a choice.

When roleplaying games rolled over to computer games, there was no such thing as dynamic quests- at least at the beginning. The same dungeons spawned the same monsters at the same locations more or less. Even with random spawn times, there was a predictable way to counteract the encounters when the same monsters spawned. It is much more likely that the concept of the holy trinity was the result of gamers taking the idea of a choice and condensing it into a problem, because there was a pattern players could observe and take advantage of. The choice became a problem, and the holy trinity was born.

No matter how much class-based game developers try to break the holy trinity, it is still going to exist in their game, to some degree. Because no matter what, there is always going to be a class that is better at doing things than others are- if this wasn’t true, there would be no need for classes. Any game with classes can be looked at with the holy trinity in mind- we just gave the concept a tangible name. 

The Metagame of Tribes

The metagame in Tribes was crafted by players when looking at all the various tools and gadgets they had at their disposable, while also looking at the rules of the capture the flag game. The metagame of Tribes wasn’t clearly defined by the developers. Ideas like defending a base, capturing a flag, deploying and maintaining turrets, putting a player with the heaviest armor an the most hitpoints on the flag to guard it- these were all obvious to seasoned gamers and could be learned fairly fast. But the minute details of the metagame that is used in competitive Tribes- things such as timing a grab with a mortar clear from a teammate, or tossing the flag home right before dying, or “spewing” turrets as a farmer- these were much less obvious.

I for one can say personally I’ve had the most fun in Tribes when I’ve played and understood the metagame, as opposed to pubbing about. It’s really where the game shines, where a real sense of urgency and importance takes form. It’s definitely what I consider to be at the core of the essence of Tribes.

If a new FPZ game were to be made, would the older generation of Tribers care enough about the old meta enough to want to promote it and establish it? Would new players come to discover the meta on their own, therefore reinforcing its validity? The people who played back in the golden age of Tribes are now reaching middle age, have responsibilities, and likely don’t play games as often- and you can tell by the number of veterans still playing the game. Of course, trolling and unfaithful sequels hve probably not helped that at all. But in ways, I don’t blame the makers of T:V and T:A for trying to be different…

...Because they needed to pull in a newer generation of players, to mix up the meta a bit, to get people involved- to get people to care about something new and novel. They felt the need to provide new game mechanics so players would need to establish a new metagame. A metagame the community could care about and grow around.

The old gameplay is only cared about by people who had left the game, or by new players who can deal with being smacked around for a good deal of time- the players who put up with this do it for the challenge, and they can arguably find more fun in another game.

13 years after the release of Tribes 2, with just one public server, you have many players who are unaware of the metagame (or just don’t care), strolling about with their own personal agendas and goals (ex. kills by way of bomber)- and then you have the competitive community playing the metagame and actually getting things done efficiently.

Now, there is some grey area here- now and then a random pubber might be clutch by being at the right place at the right time, but this does not mean they knew what they were doing. On the other end of the spectrum, here are pubbers who slowly learn aspects of the metagame, enough to be functional and do a job for a team. And it goes without saying- younger players, and players of newer games can still discover and have fun in the old style Tribes- while they are a minority, they are surely not outliers in the dataset of all Tribes players. 

Final Thoughts

How much of the old competitive metagame should be adhered to in a new game? And how much should this metagame be explicitly told to the player, if it is not already obvious? Should a player discover the metagame for themselves? Should it be taught by the community by having it crammed down their throats by aggravated players? At one point does tutorial end and discovery begin? (Or vice versa.)

Where does this put us? Is a new-old Tribes game even worth it? Is the old Tribes meta too hardcore and too outdated, and too “tried-and-true” to appeal to younger generations of gamers who don't want to be told explicitly what to do? Is the meta game too set in stone and too predictable and not subject to change, to an extent where it is boring? If that was true, why does the game offer so much replayability- to the point where it is still played today?

These are all questions worth thinking about earnestly.

Friday, September 13, 2013

Movement : Skiing

Forward
This is the first part of many I plan to write about the movement system in Tribes. Before getting into the nitty gritty details of movement and skill, I wanted to first give a brief overview of the systems of movement.

Introduction
Skiing played a huge role in what Tribes successful- and as said before, most agree it is at the core of Tribes. Skiing made it possible to achieve very fast speeds in the game- and unlike other shooters that were fast-paced due to the ability to change direction on the ground on a dime, Tribes was fast paced due to gravity, long falls, and raw speed. Redirection was more gradual, and the twitch play was entirely different than what you see in traditional arena shooters- because it was more about leading, and less about quick reflexes.

The Birth of Skiing
How was skiing “discovered” or “invented” ? Many claim it was the players who found it during the beta of the original game. Many claim it was the developers. So really, who was it? I thought it may be helpful to ask Scott Youngblood, the lead designer and mastermind behind Tribes 1 and Tribes 2, to entertain the question.

His response:

Yes, I remember specifically the day the skiing was discovered. Symlink (Dave Moore) was working on the physics of Jet packing one day… and he came into my office and said that he found a bug with our jet packing… but he wanted to show it to me before he fixed it. I went to his office, sat down at his chair and he told me what to do….

“Alright… he said… Jet up over that hill until you’re above a slope going down….”

“Then let yourself start to fall… and right as your about to hit the ground, start tapping space.”

He didn’t tell me what was going to happen… he just told me what to do.

So I Did it…. And before I could get to the top of the next hill I uttered these words:

“Don’t fix this…. We will USE this.”

Skiing was borne...

...We purposely didn’t TELL people about it because we wanted you to discover it. Players have much more fun with things that they can discover than things they are told about.

The Phyiscal System / The Act of Skiing
Player movement in Tribes, if looked at in terms of a physical system, is a rube goldberg machine on crack, pumping out more energy than what it is taking in. At the top of a hill, the player holds down the ski button and directs himself down it- his potential energy becomes kinetic energy as he starts gaining speed. No energy is lost due to friction- so as long as the player is heading downhill, he will accelerate- on a flat surface, he maintains momentum.

On an upwards slope, the player engages his jetpacks- he uses up the jetpack fuel (energy) in order to ascend over the battlefield, losing a bit of lateral speed, but gaining much in vertical speed. There is a brief moment of hangtime, where huge lateral distances can be crossed as the player levels out. The heights the player reaches garners him a lot of potential energy. The player then begins to fall at very fast speeds.

While falling, the player makes fine-tuned course adjustments with by tapping his jets in order to fall into a downhill slope at roughly the same enterance angle as the slope angle, ensuring no health is lost in the energy transaction. The player then holds the ski button before landing, and swoops down into the next valley. The jetpack is constantly regenerating energy when not in use, so while falling and skiing, all of the energy you use on your last ascent is all replenished. And the process repeats itself- it is with the repitition that great speeds can be achieved.

Types of Skiing
One of the many controversial topics Tribes players have discussed over the years is the best form of skiing- it's one of the many reasons the Tribes community has been fractured. Simply put, there are two forms of skiing- “jump skiing” and “smooth skiing”.

Jump Skiing
“Jump Skiing” happens with a jump at every contact with the ground- this makes net prediction and aim prediction a bit harder since the players are not moving smoothly, but changing direction often (after every “bounce”)- player movement has to be extrapolated with the bounces in mind for any prediction to take place. Jump skiing looks silly admittedly- it looks like a bug from an old game. Some people like that though, it feels “glitchy” and part of a finicky player-made experience- much like wall jumping in Gunz or bunny hopping in Quake, it pays an homage to “emergent gameplay”.

A large part of what made jump skiing feel correct was an “elastic” player collision system. In most modern games, a player’s velocity and direction are only adjusted when they are jumping or landing and come in contact with a surface- otherwise, they “stick” to the ground and move along the ground normal (thus making the collision a bit “velcroish”). In Tribes, your collision normal with the ground, and position and velocity changes were made every tick, no matter what. Regardless of whether you were in mid-air, just jumping, just landing, or walking. This made all the player movement feel very elastic in nature. As far as I know, most modern games that use “smooth skiing” rely on a velcroish collision system- I reckon that it makes for less collision computations, and saves on system resources and bandwidth a little bit.

Anyway, jumping gave you an initial upwards acceleration before even tapping the jets, which easily complimented the jetting. As well, jumping allowed use of your side jets much faster- if you jetted before jumping, there would be a lag in the power of the side-jets. For these reasons, it made sense that the jumping key was also the skiing key- it was more intuitive. With jump skiing, the differences between carving from game to game are more subtle and easily adjusted for, since carving is not system-moderated like it is with smooth skiing.

Smooth terrain was not always needed with jump skiing- sometimes a bit of jagged terrain was actually preferred with this system, allowing for quick redirections given you attacked the terrain patches at the right angles. Small imperfections in an otherwise downwards slope could easily be hopped over using jumping skiing- which made some of the more jagged maps a bit more tolerable.

The one major flaw jump skiing had was deadstops. There would sometimes be spots in the terrain or on buildings that, if hit just right, would make the player come to a complete “dead stop” or bounce in an unintended way. I believe this had something to do with the player landing on the edge of a triangle, where the physics engine couldn’t sort between the different verts in the collision octet tree or what have you (I’m not completely sure on the fancy math terms). Some techniques to prevent deadstops from occurring exist- one is to make the player hitbox “pill-shaped”- another is to ensure there is as little flat terrain as possible. Another is to make sure no two floor surfaces rub up against one another too much (very important when working with the .map format when making maps for Tribes and Tribes 2).


Games That Use Jump Skiing:
Tribes 1 was where skiing was first invented/discovered. In Tribes 1, terrain was more blocky, and you needed to know your route to every minute detail, or you could easily lose all your velocity or be sent off a different direction. But side jets were stronger in Tribes 1 than in Tribes 2. In T1 you did most your redirecting while in the air. Snipes and other shots were a bit easier to dodge by strafing at the apex.

You can find a very substantial explanation and dissection of the Tribes 1 physics on [5150] Andrew's blog, found here: http://floodyberry.wordpress.com/2008/02/20/tribes-1-physics-part-one-overview/

Tribes 2 included skiing not as a bug, but as a feature- so it felt more fluid and intuitive. In Tribes 2, terrain was made much smoother. In Tribes 2 Classic (T2C), speeds gained using skiing felt a bit greater than in T1, and the increased tessellation of the terrain object made slopes more gradual. However, in Tribes 2 there was less sideways jetting; you did most of your redirecting on the ground by carving in bowls, not in the air. Snipers more easily countered by hugging terrain, compared to strafing at the apex. In a general statement, most veterans have said Tribes 1 skiing was more finicky and temperamental, whereas Tribes 2 skiing was more soupy and loose.

Legends was another game that used jump skiing. They claimed they had the physics of Tribes 1, which was debatable. It felt more like T1 physics adjusted to feel more like T2- which wasn't bad at all, really. It was easy for both T1 and T2 players alike to get used to Legends.

Smooth Skiing
Smooth skiing where player actually glides along surface without hopping- it feels more natural, looks more realistic, and is more aesthetically pleasing or “correct” to some people. Dead stops aren’t as big of a problem with smooth skiing than it was for jump skiing. However, carving systems are harder to implement with smooth skiing- and differences in carving are more readily noticeable..

Smooth skiing also suffers from a wonky ski/jump, jump/jet system. Jump jetting still needed, and you had to ski, jump, and jet all at some point. This system where two actions happen with the same key, either both on press, or one one press, one on unpress, very wonky, not intuitive.

Smooth skiing also relies on smooth terrain, which in poly land isn’t always the case, especially on maps that had terrain just slapped onto it. With smooth skiing, you feel every imperfection in the terrain. Unless a system is cleverly designed where your player can “roll over” the small imperfections, the tiny pits and bumps will be the bane to smooth skiing. And ultra smooth terrain makes for a very uninteresting map, catering to uninteresting game play.

Games That Use Smooth Skiing:
Tribes Vengeance was one of the first games to have smooth skiing. In T:V you had no carving at all, skiing just simply removed friction from your feet, and was not reliant on your facing direction or directional keys at all. Your redirection was soully at discretion of the terrain, and you had to use jets to hover up and land into hills at a “sweet spot” or tap jets for quick redirecting (carving with jets, as it were). The lack of carve control was offset a bit by having air control while in mid-air without needing to use jets. The old Tribes vets were thrown for a loop. Those who played T:V as their first Tribes game picked it up quite fast. I wouldn't go so far as to call it intuitive- it was more watered down than intuitive, and appeared like an attempt to make intuitive controls met only halfway- the lack of carving really hurt the game.

Tribes Ascend, the next game in the series, used smooth skiing with some form of carve control, which proved quite better at slower speeds, but felt very ineffective at higher speeds. At higher speeds, it was possible to get skiing to “kick in” and work more effectively by tapping the jets a few times- this felt wonky, and unnatural. As well, you lost momentum at an alarming rate while heading uphill- making it so players avoided skiing uphill altogether (in other games, you wanted to ski up at least part of the next uphill before jetting up over it).

There have been plenty of other games over the ears that have used smooth skiing, including Ascension, Legions:Overdrive, and more recently Project Freefall, and Legacy. Legacy in my opinion has the best feeling carving to date. SmoothP claims he has taken a look at Andrew's T1 physics write-up and refactored all of the variables into a smooth skiing system.

Which is Better?
So is it smooth skiing or jump skiing? Both have their advantages and disadvantages. Jump skiing feels more buggy in nature, but also caters to that oldschool arena player nostalgia- and we all want to see some of the fast-paced intense action of the old games come back. Smooth skiing feels more refined, mature, and eye-catching, but it lacks some of the extra mobility features jump-skiing had, had quirky control schemes, and carving is harder to make feel right without spending a good deal of time on it.

My opinion? Jump-skiing is better. Its what I'm most used to, and it pays an homage to the old games, for which we owe a lot to. However, much effort needs to be spent on battling the dreaded deadstops if you plan on using this method.

Smooth skiing isn't bad- and it is easier to appeal to a newer audience using it. If this is used, consider inventing a new control scheme that makes jumping, skiing, and jetting intuitive. Perhaps use a different bind for jumping than what you use for skiing, so you can still jump while skiing to get past those pesky little bumps, and you can still jump before jetting for that extra boost in mobility. Using 3 keys for movement might be a bad... it's one you'd have to feel out.

Saturday, August 24, 2013

The Mission of "FPSZ"

Forward
This is yet another document I found in my archives collecting dust which seems relevant this week, after recently been addressed by another Tribes indie dev who is thinking up something big for us Tribes gamers. It goes into detail of why we picked the name "FPSZ" to categorize our old disbanded game, Ascension. Kinda funny how this term stuck- used when referencing Legions, and used in referencing Ascend. It makes me proud every time I hear the term used, that it came from us at RenWerX. So without further adieu...

Mission Goal
FPSZ wasn't a term we tried to used to "market" Ascension as Amadeus would say- though it did help in that regard when you consider we were trying to rebrand ourselves afer leaving Tribes Vengeance:Renegades behind. We made the switch to creating a full-fledged game. When I coined the term FPSZ it meant to be something tangible for all people who love Tribes as its core could rally behind. The Tribes gameplay was the result of exploiting a bug in the early stages of a game, a mistake many Tribes players would call the most beloved game bug to ever exist in gaming history. The game community that grew up around the game were just as quirky in their nature as the game itself, just like the clumsy beginning of a bug known to us as skiing.

The game suffered from many unfortunate circumstances- it came out near the dawn of internet gaming, a huge digital frontier free from a lot of restrictions there are in games these days. There wasn't as many people playing games then as there are now. During this time games were more easily shared by friends illegally too, so Tribes developed an underground following. And as the community grew the player community became more splintered because different players preferred different "flavors" of Tribes. Most players of Tribes seem to have a very passionate bias for how they played Tribes. It also didn't help that the game was hard to really explain to other people without showing them- the notion of skiing and jetting, and all of the other quirky things about the game. Because of all of these factors, the outward appearance of Tribes was murky at best.

Getting to the point- during of our rebranding meetings. I considered the nature of the community, considered everything I mentioned above, in my stream of thought. And it occured to me- the gameplay ought to be symbolized or represented by something. Something tribals could rally behind. Something short and to the point- and, eureka, FPSZ. The term meant "FPS plus emphasis in the Z axis" (which was the up axis in the cartisean coordinate system, in the engine we were using, and in most engines now a days). FPSZ wasn't meant to be "edgey" or "elite"- as it may have seemed- though many players of other shooters did claim to "graduate" to Tribes, so the "Z" could stand for that, sure. But for us, FPSZ meant a certain, specific thing. Shooters of the FPSZ genre were to have skiing and jetting as main mobility in the game. That's something most if not ALL Tribes players (who are normally unagreeable) can agree is at the core of Tribes. FPSZ was meant to be the umbrella term for all of these styles of play, and obviously be a sub-genre of FPS games.

I slowly became addicted to Tribes when I first started playing it. So it really struck a nerve when people argued "Tribes is dead"- because its game play is so unique, I thought how could people even say that? These days all the games out there seem the same, and Tribes is something different, but totally under-appreciated by the masses. I wanted to make a Tribes game- I made it one of my life's goals, and it's kept me going for quite some time. From a game development perspective, it seemed like a gold-mine: something investors would still be able to get behind if it was explained in the right way and finally showcased to the masses in an appealing light with a name they'd remember. Something tangible.

So that's why FPSZ exists- it was my answer to the problem. FPSZ meant giving the Tribes community something to stand behind. If the community embraced it. If they did, we wouldn't have to call our game a 'Tribes successor' or 'Tribes Remake' and no longer would the game style be shrouded in obscurity. And starting from there, we'd build up.

In ways you can say my "FPSZ" answer is similiar to the answer given to...

"Hey! This bug is really neat to use, but I don't know how to explain it to my friend, what I should call it?"

"...skiing"

I don't know if this will be taken seriously or not- but I want to appeal to everyone who loved the idea of skiing and jetting- and who will be sad if it ever really dies- I want to appeal to you to band together under "FPSZ"- and if a game ever tries to capture the nature of Tribes, call it a "FPSZ". It's a practical way to promote and increase awareness of the gameplay.

That was the mission goal of FPSZ.

Wednesday, June 12, 2013

Vehicles In Tribes 2

Starsiege:Tribes was meant to be an infantry take on what was formerly a mech simulator franchise. One of the talking points about Tribes is that it was one of the first games to offer vehicles in an infantry shooter. And this was a big deal for the game before skiing was “discovered”- vehicles took a back seat after that. In Tribes 2 base, Dynamix attempted to bring the spotlight back onto the vehicles and tactics dealing with them by implementing skiing as a severely nerfed feature. When infantry speed was brought back to Tribes 2, vehicles took a backseat again. Now, during the T2 Draft Tournaments, we are lucky to see 2 or 3 vehicle maps get played during a season. For some people, vehicle maps are fun. For some, vehicle maps suck. Most everyone can agree though, vehicles are not the focus of Tribes- it's all about the infantry.

In other shooters infantry normally walk and it takes them a while to get from point A to point B, and vehicles help them move around much faster. With the skiing, jetting, and disc-jumping in Tribes games, vehicles that aide your speed become negligible. In other games, vehicles have much more armor, can dish out more damage, and can take more of a beating than an infantry could. With the player’s ability to suit up in heavy armor with a mortar and shield pack in Tribes, this reality does not exist- heavies become the damage takers and damage dealers.

Not only could players do many of the things the vehicles could do, but it also often became inconvenient for players to get a vehicle ready. In the amount of time it took for a pilot to fix his vehicle station, order a havoc, and wait for 5 other players to load up into it, 6 fully suited heavy armors could already be at the enemy base with carefully planned routes. Not to mention, many of the vehicles had weird handling.

There needs to be incentives to use vehicles in a Tribes game that are different than incentives in other games. Vehicles ought to augment the abilities of the player, and of the team. Vehicles work the best when they are fill a “support role” in the game, and not distract from the infantry play. Some vehicles in Tribes 2 Classic were better at doing this than others. As well, vehicle weapons need to work in a similar manner to infantry weapons- the skill it takes to use them should be consistently proportionate throughout.

Mobile Point Base (or “MPB”) 
This is the prime example of a supporting vehicle- one that compliments the gameplay in a subtle yet effective manner, adding in another gameplay element without throwing it in your face. The mobile point base is essentially a deployable truck. When deployed, the MPB extends an inventory station, a base turret, and a medium-range sensor. All 3 of these things are powered by the MPB, and independently of the base generator. The ability to roll this wherever you want makes it great for keeping your team going even when your base is trashed by the enemy. As well, the developers of Classic added an additional teleporter function to the MPB. Players could teleport from the vehicle pad to wherever the MPB was deployed- this feature was neat, but not used much. This vehicle needs no gunners, or any other passengers other than the driver.

The MPB had very hefty shields, but it had a weak spot in the back where the inventory station was- damaging the inventory station would also damage the vehicle, so double damage could be done by focusing on the back of the vehicle. The MPB could be taken out in seconds by spamming mortars, grenades, and mines near the back, so MPB drivers would have to be careful about where they deployed it. The only thing this vehicle really suffered from was horrible wheeled physics which made it hard to get into position. But this flaw would be an easy fix for a developer. This vehicle is one that just simply needs to be there, moreso than others. It would not be a vehicle CTF map without it.

Wildcat 
The grav bike of Tribes 2, this vehicle always felt like it needed more of a purpose. The problem with the grav bike is that it wasn't notably a good killing machine in any way, even after a heavy chaingun was mounted to its front. While it was fast, the bike's physics were glitchy, because of the tessellation of the terrain. If you landed on a patch of terrain at the right angle, it could cause the bike to flip without much warning, often killing or fatally wounding its pilot. Experienced pilots knew how to tame the gravbike and pitch it upwards on terrain so this wouldn't happen, but piloting it in this way would slow it down considerably. Only the light armor could use the bike. And honestly, when I think speed in Tribes, I think of a light armor cruising along a route, not driving in a wonky hoverbike.

Players in light armor who were equipped with discs, mines, a chaingun, and a grenade launcher were every bit at dangerous and speedy as the grav bike. The only real role the grav bike served was to add insult to injury during blowout games, where players would stop taking the game seriously and goof off trying to run people over. Sometimes cappers would use gravbikes at the beginning of setup routes to get going fast without using a disc-jump, saving precious health- this was about the most helpful the gravbike could be.

Besides changing the driving mechanics to not be as wonky and tippy, I would likely want to increase the amount of thrust you take while ejecting out of the vehicle. And possibly give it a deadlier but slower gun that doesn’t require having to keep a constant bead on someone (a chaingun and wonky physics don’t really work together well…)

Instead of having the vehicle explode if you capsize it, I would think about simply just ejecting the player at much less damage sacrifice, requiring the player to go and flip the vehicle upright before using it (at a sacrifice of time spent flipping it). This would make the vehicle mechanics more forgiving and enable players to really get a feel for it. In game theory, having players die in order to learn something is generally frowned upon, but unfortunately this was what happened with the gravbike in T2. I mean, dying happens enough in an online game, but it shouldn’t occur on a vehicle because you hit a pebble the wrong way.

Jericho Tank
I can find one or two roles for the Jericho, but there is only one that I really agree with in the overarching metagame.

The Jericho is a powerful hovertank that can really take a beating. Running tanks into other tanks often causes them to blow up and cause Unexpected Errors for players, to the frustration of many- this has actually been exploited in recent tournaments in order to stop flag standoffs. The tank turns fairly slowly, but it can strafe and move in any lateral direction very fast- which is very out of character for a tank. Its shields run off the same energy reserve that is used to power its boosting- but its energy reserve is so huge that the tank is pretty much undefeatable when used by an experienced tank pilot. Missiles don't do much to the tanks when they were shielded- neither do mines, mortars, or shrike blasters. You have to coordinate an attack with one or more of these to take one down.

The tank has a pilot and gunner seat, so it takes 2 men away from battle when used. The guns on the tank are unreliable when the tank is moving, due to the crazy projectile inheritance- but tactics were developed where a pilot would position the tank at an ideal spam location and exit the vehicle and target the spam point with his TL, giving the gunner a bullseye to aim for. This is something a walking heavy and light armor could do already, without the aide of a vehicle.

During a game, people using a tank effectively either find themselves high-arc spamming from afar, or spawn-camping the enemy turf, running them over and mortaring them at point blank, putting them in disarray and making it hard for them to amass an effective strike against them. Neither of these are notably hard to do, but can be extremely effective.

There is one supporting role that I find commendable for the tank, is that is a defensive flag-holding role during heated standoffs- flag standoffs are interesting in that they can abruptly change the pace of a game and help a losing team turn the momentum of the game to their favor if they come out on top during one. To be fair, tank standoffs can get fairly boring for the watchers- nothing can happen for long periods of time due to the difficulty in taking a tank down- this would have to be addressed. However, if the tank was to fulfill a role at all, turtling the flag would be the role most people would be comfortable with (it'd be better than a normal infantry base turtle, at any rate). The discussion lies in how to go about making it interesting.

A possible solution would be giving people the ability to board tanks if they got close, somewhat like Halo. The challenge for the boarder would be doing it without getting run over, and for the tank pilot, it would making sure he was able to maneuver to successfully run a player down without being boarded. Or maybe even make it as simple as making concussion grenades effective on players even inside vehicles. To further emphasize the defensive nature of the vehicle, weapons would need to be switched out to something a little more defense-friendly.

Another possible solution- that would be killing two birds with one stone- would be making the infantry ELF gun more useful by having it quickly drain the energy from vehicles, assets, and players alike. The lock-on feature of the ELF would probably be removed to counter-balance this, but if someone was able to get close enough to a tank, avoid getting ran over, and keep a steady bead on the tank with the ELF gun, a tank could be shield-less and vulnerable in seconds. This would make for a type of interesting standoff game I would like to see.

Shrike
This is the ‘jet fighter’ of Tribes 2- which is a bit of an inaccurate term when considering how it behaves. But to a player new to the game, that is what the vehicle resembles at first. Actually, the vehicle is a “turbo-grav”, which is somewhat a cross between a helicopter and a jet. It can hover in place with vertical jets, and you can use the vertical jets to propel it forward by nosing the vehicle down, or propel it backward by nosing it up. But the second you engage the forward jets, it becomes an agile aircraft, able to fly fast (usually faster than heat-seeking missiles) and take turns rapidly. It has two front-mounted blasters that can slice through players and vehicles rather quickly (again, using the same energy reserve as the one used to power its shields).

Killing enemies is made possible by shooting, or ramming, as with most vehicles. Some shrike pilots have become ridiculously good at doing both. It is not an easy feat, due to its mechanics- the craft is directed very loosely by the mouse, requiring precise mouse movement and understanding of the “directional lag” the ship has. It is easy to miss your intended ram target and instead crash into the ground in a ball of fire. But when a pilot becomes good at ramming, he sways the battle of a vehicle map. Shrike pilots can put a serious dent in the enemy offense by ramming heavys in the midfield as they are making their way to the friendly base. In the midfield, they are also in an amazing position to ram enemy flag carriers- and they can easily keep up with even the fastest of cappers.

Shrikes can also be used by medium armors to get to speed rapidly before ejecting en route to the flag stand. This makes medium flag capping a favored method of flag capping on vehicle maps due to the increased punishment a medium armor can take compared to a light.

There are a few vulnerabilities to the shrike- and these are worth noting because without them the shrike would be horribly overpowered. A well-placed mine-disc will blow up any shrike up instantly. And shock lancing a shrike will send the shrike toppling, often crashing into the ground below if the pilot is close to the ground.

While the shrike is extremely powerful, I would not argue it is overpowered. The ability for a shrike pilot to own the midfield is more of a flaw with the map rather than the vehicle- a well-constructed vehicle map has hills and other various obstacles placed randomly that a shrike pilot will need to avoid, while still keeping lanes open for evading missiles. A wide-open vehicle map just doesn’t fly, because of shrikes, but also because of many other reasons. (I'd use Raindance here as an example of a wide open map).

Thundersword Bomber
The Bomber can hold up to 3 people- a pilot, a bomber, and a tailgunner. While the pilot doesn’t have anything in the way of weapons, the bomber has access to a rapid-firing plasma cannon, and a regenerating payload of bombs, each bomb doing the damage of a mortar round. The bombs can be dropped at rapid succession, but after unloading around 10 or so, there is a cooldown period while bombs are being regenerated. The bomber doesn’t really technically aim the bombs, the pilot does that by adjusting the bomber’s pitch and speed- the bomber just decides when to let the bombs fly, by determining whether a faint bomber reticle on the ground is located over the specified target or not. The tailgunner position on the back is an open exposed position where a passenger stands and can utilize all of their weapons, but is vulnerable to nades, mines, and weapons fire. The bomber is a bit harder to control compared to the shrike, and requires some skill by the pilot. It requires knowing how and when to evade attacks and travel to safety, and requires knowing good bombing routes to give the bomber limited exposure.
If a good bombing team is able to set up a bomb route before the other team can get other vehicles up, the other team is more or less screwed. The bomber is extremely powerful- its only real threat is missiles and shrikes. And if your tailgunner is a heavy armor carrying flares and an ammo pack, you have more than enough flares to evade missiles for half the map, or more. That tailgunner can also launch missiles at enemy shrikes, making all but the most experienced shrikers incapable of keeping a bead on the bomber to take them out. And even then, if a bomber manages to take out the enemy vehicle pad, they can usually keep it down with successive bombing runs. AA turrets and other fire are easily avoidable by the bomber.

You can’t ever really feel like a bomber earns their kills- they aren’t really doing much at all. The pilot does most of the critical thinking, and most of the work- but hardly gets enough credit for what they do.

The bomber is not effective enough for what it does. Sure, it keeps 3 people alive for a good deal of time, and in the process of their lives they can kill a lot of people. But the length of a single bombing run is short, and the time duration between bombing runs is too lengthy- even if a bomber crew was able to take out multiple priority targets in one run, by the time they swing back around most of the damage would already be accounted for. As well, consider the fact that the most important base assets are inside, protected from the bomber. And it takes at least 2 people to run a bomber, if not 3 if they want to survive for any amount of time. If all 3 of those players were instead running as HO on decent routes, they would be able to sustain constant pressure and aide or distort the flag game much longer and much more effectively than a bomber could (and remember, the flag game means everything).

Any good aspects of the bomber- including its emphasis on teamwork- are overshadowed by all of these harsh realities of the bomber. In another shooter game, the bomber would probably fill more of a role. But in Tribes, its role is that of an annoying gnat that occasionally be effective when the stars align. It might be possible to adjust it, but I doubt it…

Havok
The Havok is the aerial transport of the game, and two similar vehicles were found in the first Tribes. The Havok is essentially a heavy turbograv with platforms along its hull for up to 5 other passengers to stand on. There are no weapons. The havoc essentially moves like the shrike and bomber, but much more slowly and gradually. Havok passengers are exposed but are able to use all of their weapons freely, just like the bomber tailgunner. The havoc could be used as an aerial platform, keeping all occupants in the air and firing- but most people quickly learn how ineffective that can be. The havoc in Tribes 2 was mainly used to shuttle HO (or other odd stealth roles) across the map to the enemy base in one payload. However, this was not very effective. It’d take forever for all the spots to fill up, and once HO dropped onto the enemy base, they would get in each others' ways, accidentally mortaring one another to death. A HO in Tribes 2 classic with the right routes could get to the enemy base in a fraction of the time it took for a loaded havoc to get there.

As true as this is, I still think there is a spot for an aerial transport in the game- just not one that allows 5 passengers. In Tribes 1 a light personal carrier existed with only two passenger spots- and I think that is reasonable. It does not imply the pilot needs to sit around forever to load up, and because of its decreased payload, could probably be given a bit more maneuverability and survivability. The havoc is touted by many Tribes 2 base players as being a staple to the series, and that should be respected to some point. A smaller havok does fill my canon of a vehicle aiding the gameplay, and not providing distraction from it.

Monday, April 15, 2013

Tribes 2 Competition Mapping Thumb Guide

Forward
This is more for me and other mappers. Just writing out my thoughts, since I've wanted to do this for a while. This essay delves into the design aspects of a map, rather than the technical aspects. For the technical aspects, I will post up Anthem's mapping tutorial found on GamerHaus (formerly Goon Haven).

Mapping for Competition

Mapping for competitive CTF is a huge give and take of Offensive Features versus Defensive Features. Maps should always be slightly tilted towards O- slanted towards D will make for slow maps. The O are the ones that make things happen. It's still nice to throw a "challenge" at O now and then, but always at the cost of something else in D being removed (add a turret and remove a sensor, etc.) There's no exact measurement of this give and take, it's something you feel out, and it is really an art.

Do not be discouraged if people do not take to your map right away. People in competition can be picky and whiny, and a map almost always play bad on the first run since people are exploring the map and getting used to it more than playing a serious competitive game. It can often take 2 or 3 runs on a map to get a real sense of how the map plays.

Fog/Visible Distance: Starts at roughly 600 meters. This value drops when terrain is wide open, or low, or if there are not many obstructions (buildings, rocks) in the midfield.

Bases: Generally, no more than 2 or 3 rooms away from entrance to gen room. The simpler the base, the better.

Small Bases: At least 2 entrances.
Medium Bases: At least 3 entrances.
Large Bases: No. Do not make them (or if you do, make them wide open).

Smaller entrances create choke points, make for easier turtles, avoid.

Some maps have turtles that are better than others because of these factors. Ex: Pandemonium is much better than No Shelter because Pande has 2 entrances to a 1-room base.

Keep in mind the placement of inventories and gens that are close to entrances. Having outdoor inv mortar spam is bad but passable. Outdoor gen spam is bad, in most cases. If a base is going to have inv spam, consider having invs self-powered (or powered by more than 1 gen) to balance this factor out.

Terrains: Hand-made terrains can take a while. For procedural generated terrains, Multi-ridged Fractal and Voronoi/Worley noise are very good for Tribes gameplay due to their tendency to create bowls and ridges to ski along and change direction. You usually want a hierarchy of detail (big features, little features, small features). Hills that encompass OOB borders are generally desired by the community (Feign, Damnation, Opus).

Flag: Give and take very big here- many things to tradeoff, but always keep slanted to O.

You want at least 2 cap routes available (side to side, back to front). Front to back nice to have. Flag stands that are approachable from multiple angles is considered a plus for O.

Flag stands should be concave. If you make a flag stand convex, consider using higher hills/more fog in the map, but generally do not do it. Flat flag stands can sometimes work, but generally will cause deadstops. There should almost always be spawns near the flagstand (I aim for roughly 50% of my spawns near the flagstand). Do not put spawns ON THE FLAG.

Work with the terrain features to pick an ideal place for the flagstand. The last "uphill" that cappers touch before touching flag on fast cap routes will roughly start 150m away from flag. The hills cappers start out on on set-up routes will be roughly 300m away from flag. Keep this in mind when picking location for flag on procedurally generated terrain, or make sure to build these features in.

List of Gives/Takes for Balancing Offense and Defense
If you add one from the D list, add one from the O list too. But generally keep things slightly O-tipped.

Good for Offense:
  • Smooth Terrain
  • More Fog
  • Inv Spam
  • Gen Spam
  • Self-Powered Bunker
  • Open Flagstand
  • Big Enterances
  • Lack of Plasma on Base Turret (one extra step for D...)
  • Campable Gen Rooms

Good For Defense:
  • Sentry Turret
  • Limited Enterances
  • Multiple Sensors
  • Multiple Base Turrets
  • Limited Routes
  • Jutting Pieces on Flagstand
  • Lava/Water around Flagstand
  • Less Fog
  • Multiple Bases/Multiple Power Sources
  • Plasma Turret Default on Base Turret

Use the lists as just a guideline. As I said before, this is not exact science, it's something you must feel out.