Tribes: Ascend - The Generator Problem

Full disclosure: for a number of reasons I never played any of the previous Tribes games. While obviously this means that I can never be a proski or good at Tribes: Ascend (hereafter T:A), I think this just means that I can view T:A objectively.

There's been a lot of talk on the T:A forums and community sites about the role of the generator in Capture the Flag. Views range from 'the generator is completely useless and anyone who ever goes near it is terrible' to 'whenever we have the generator up we steamroll them; whenever it's down we get steamrolled'. As is often the case in these kinds of arguments, both sides contain part of the truth.

Let's start with the basics. The generator is located inside the base, though in a different place from the flag stand, and powers the base turrets and radar station as well as that team's pack deployables such as light turrets, force fields and jammer packs. It also powers the vehicle station (you can still drive existing vehicles if the generator is down, but not get new ones) and the core inventory stations (ones that have been called in still function without the generator).

All of this makes the generator appear to be pretty important. Without radar, you can only see opponents who are within a certain range and in line-of-sight, which makes spotting incoming flag cappers and other enemies much more difficult. The base turrets can two-shot a light class and most of the time can target enemies actually on the flag stand. Vehicles are cheap and easy to use, and can do a fair amount of damage. Likewise, force fields and light turrets are excellent at defending the flag and  generator, and without the jammer pack the Sentinel can have a really hard time staying undetected, especially if the opposition have their radar up. And for technicians and other defensive classes, inventory stations are extremely useful for replenishing ammo and forcing health regeneration.

The problem is that all these things cease to be true once you and/or your team reach a certain level of ability. If your Sentinel is doing their job and spotting targets (possibly tagging them as well) then you won't be as reliant on radar. Base turrets are too slow to hit a flag capper going at a decent speed, and in any case are easily taken out from the other side of the map with tactical strikes or mortars. Vehicles look like fun, but there is nothing they can do that a player of the right class can't do better (more on that later), with the possible exception of Shrikes - and, of course, they cost credits to use. Deployables are easily destroyed with strikes or shelling, both of which have the advantage of potentially dealing damage to (or indeed killing) defenders. Oh, and if a Sentinel is given away by a downed jammer pack  then they aren't moving around anywhere near as much as they should. Finally, suicide is an excellent substitute for the inventory stations, and can be one of the most useful abilities in the game if used correctly.

At the moment, most of the benefits of the generator being up, such as vehicles, fall under the umbrella of First Order Optimal Strategies, or FOO strategies. Extra Credits, who invented the term, define these as 'gameplay choices or strategies with a low ratio of skill in to power out'. Basically, they're things like the zergling rush or the Protoss deathball in StarCraft II or the noob tube (grenade launcher) in Call of Duty - techniques that are easy to execute but hard to counter. While to an inexperienced player they appear unbalanced, in reality they rarely affect high-level play, because by that point people know how to deal with them and have progressed to more difficult but more effective strategies. An example from T:A would be the motion-detector-turret placement in the generator room of Temple Ruins that I demonstrated in a previous video, which is extremely easy to set up but difficult for new Infiltrators to counter because they're not expecting it. Perhaps a better example is the Beowulf tank. It's extremely good at clearing base turrets and flag defences from a distance (depending on the map), and when one comes out new players are often hesitant to engage, because, well, it's a tank. However, they're not really any better than a Juggernaut at shelling the enemy base, and are much easier to kill because they're slower, bigger, and (this is important), much worse at flying. The difference is that tanks are much easier to use than Juggernauts, and you don't have to spend time upgrading them or learning how to play them. A good player who is not scared of the tank can solo it almost every time, meaning that at higher levels tanks become much less useful. (The exception to this is, of course, parking a tank in the generator room in Sunstar, because that's just hilarious).

That's not to say that these things have no place in the game: FOO strategies are vital for giving new players a sporting chance and giving them something to do other than give free credits to the other side. The problem is that almost everything the generator supplies is used in a FOO strategy, and at high levels can all be replaced by a mixture of the right classes and player skill. At that point, defending and repairing it becomes relatively pointless, and it makes more sense to replace your Technicians (the class most strongly tied to the generator) with Pathfinders or Juggernauts and just play straight-up Capture the Flag.

However, in public games people don't always have the skill level required to counter FOO strategies or replace them, and so the generator is much more important. Of course, what happens then is that one or both sides overcommit to generator play, pulling vital resources away from the flag. You probably never really want more than one, maybe two people attacking it anyway, but there is at least some purpose to it provided that you don't overload on either offence or defence. The problem is that because there's no match-making system, you end up with a huge blend of player abilities, to the point where you can have one Technician holding off five or six people attacking the generator; or alternatively one skilled Infiltrator, Brute or Raider living in the enemy generator room and killing all the Technicians and Doombringers who come to repair it.

This naturally leads to arguments, claims of imbalance, and accusations of bad play: high-level players don't realise the importance of the generator to low-level teams and call them stupid for caring (which they're not); and low-level players don't realise its irrelevance in high-level play and call the high-level players elitist and arrogant (which they can be). The problem is exacerbated by a number of classes (most prominently the Technician, Infiltrator and Doombringer) being balanced to some degree around generator attack or defence. Not only does this imply that the generator is important (I've been given all these tools so presumably I ought to use them), but reducing the generator at high levels to a mere appendix hinting at a depth and complexity that might have been makes large parts of these classes redundant. After all, why would you take a Technician over a Soldier when the latter has more health, more energy and a spinfusor along with hitscan weapons, if the light turrets are always going to be dead and the repair gun is never going to be used?

So, how can this be fixed? From the points above, the obvious plan would be to give the generator some ability that is useful (though not vital), and that cannot be replaced by high-level play. Tribes 2 did this by having the players spawn in the lightest armour and with the default weapons, forcing them to go to an inventory station to pick up their chosen loadout. While this probably can't be carried straight across for a number of reasons (no scavenging and a big spawn-flag distance would mean that losing the generator is basically a game over), it does form the basis for one possible solution, which would be to have players spawn with their chosen class and weapons, but completely un-upgraded. Going to an inventory station, in addition to its current effects, would upgrade the loadout to the level that the player has unlocked. This would actually be more important for high-level players, as they are more likely to have fully upgraded their class, while not impacting those with fewer unlocks to the same degree. It can also be scaled up or down by changing what items are granted by the default spawn (e.g. making the Pathfinder spawn with Thrust rather than Energy Recharge), which allows for more fine-grained control by the developers. There are lots of other solutions, from buffing vehicles to increasing the speed of base turret projectiles, but it's difficult to come up with something that doesn't push the balance inordinately towards the generator or break the game in some other way. Interestingly, a recently released competitive ruleset actually has the players spawning naked. We'll see how it plays out; as has been noted before, Hi Rez's general policy seems to be to implement first and fix later. This is a beta, after all.


Bootnote: This is the generator defence video:

How much energy does scrolling a mouse-wheel produce?

I've seen this image a few times in the last couple of days, and because I'm avoiding writing a research essay on Old English literature I thought I'd work out just how much energy scrolling a mouse-wheel actually generates.

The first thing to do is to work out how many times I scroll my mouse-wheel in a given period of time. To do this, I downloaded the Mousotron 7.0 from BlackSunSoftware, which records the number of mouse scrolls you make, along with a huge amount of other mouse-related data. I then tried to replicate an average use of my computer: I read Cracked.com; checked the news; replied to some emails; and did a little bit of work on my game. I also counted the number of mouse scroll 'clicks' (you know what I mean: the little bumps the wheel makes as it rotates) that were required to make a full rotation. I did this by putting a little highlighter ink on part of the wheel, and then counting the clicks as I rotated it. For my mouse, a Razor Naga, it took 24 LED-illuminated clicks before the highlighter ink reappeared.

After almost an hour of mucking around I stopped procrastinating and looked at the counter:

After 56 minutes the scroll-count stood at 1317, which is 54.875 full rotations - about 1 a minute, or 0.102 rad/s (1rps = 2*pi rad/s). Of course, I don't know if this is a usual figure for everyone, but, as I say, it was a pretty usual hour of slacking for me.

From here on I'm going to be showing my calculations in WolframAlpha, because that gives people a good way to check my maths. So, first of all, rotational kinetic energy:

This requires us to calculate the moment of inertia and the angular velocity of the mouse-wheel. The moment of inertia is

and uses the mass of the mouse-wheel and its radius. The diameter of the wheel is is almost exactly an inch, so the radius would be 0.0125m. I'm not really in the mood to dismantle my mouse to work out exactly what the mass is, but I'm guessing around 5g: a UK 2p coin is about 7g and has approximately the same diameter. It's thinner, but is also made of copper while the mouse-wheel is made of some kind of rubbery plastic. The width of the wheel is about 1cm. Therefore the moment of inertia is about 3.9 gcm².

Therefore the rotational kinetic energy generated by the mouse-wheel in a second is 2.0567*10^-9 J, or about 2 nanojoules. If we scale this up to an hour, that's about 7.4 microjoules, or the energy a mosquito needs to fly for about 46 seconds. To put that in perspective, my mouse requires about a quarter of a Watt to function: that's 0.25J/second, which is around 36,000 times more energy than the mouse-wheel produced in an hour of web-browsing.

Another example: if 9gag.com gets 5.5 million visitors per day, and each of those visitors spends a whole hour on the site, then the scrolling each day would generate around 40J, enough to power my mouse for two minutes and 40 seconds.

In conclusion, therefore, the energy used by scrolling the mouse-wheel is at best utterly insignificant. Yes, I'm aware that I'm missing the point.

Of course, these are all rough estimates. It's also worth noting that I've assumed a perfect conversion from kinetic to electrical energy, ignoring any inefficiencies that would boundless be present in the kind of tiny generator one would have to fit into a mouse to make this work at all. As far as I remember bike dynamos are around 80% efficient at best - I have no idea what kind of efficiencies are possible on such a small scale.

Game Maker Tip #1

instance_exists(obj) is a fantastic function that returns true if an instance of the object exists. You can use a general object index (for example o_player), a specific instance id (e.g. player or 100421) or keywords like all. I use it frequently to check if an instance still exists before executing code involving that instance.


However, be careful. instance_exists(0) will always return true, because it interprets the 0 as being a reference to the first object created. Therefore if you have variables in your create events or elsewhere which will be used to store instance ids, initialise them with name=noone rather than name=0.

Review: Phylo

Phylo is a browser-based colour/block matching game available to play here. Like the famous FoldIt, its aim is to 'recycle' the power of thousands of bored casual gamers to further a scientific objective, but while FoldIt concerned itself with protein sequencing (or manipulation or whatever the term is; I did engineering, damnit, not this namby-pamby squishy nonsense), Phylo has you sequencing (or matching, etc. etc.) genomes. If you're interested in the back-story Rock, Paper Shotgun has an interview with one of the scientists involved, but I'm concerning myself more with the actual gameplay.

The basic mechanics are extremely simple. You are given two rows of coloured blocks, and have to match them up with as few mis-matched colours or gaps in the sequence as possible. You can slide the blocks left and right (not up and down), but they can't change order and so shunt each other aside. As the game progresses more and more rows are added, and so it gets more and more challenging.

You gain points for correct matches, and lose points for gaps or mis-matches. Once you have arranged the rows so as to have more points than a computer-generated par, then you can add another row or finish the level if all the rows have been sorted. In some cases completing the level is easy, and the challenge lies in getting the highest possible score for bragging rights; in others simply reaching par is a challenge.

I found the hardest part of the game to be understanding the scoring. You get one point for every correct match; you lose one point for every mis-match; the first gap in a sequence loses you five points, with every subsequent gap losing you one more point; and you get more points for matching closely related species than unrelated ones. This last part is especially relevant once more rows are added, and prioritising which rows to match becomes important. The scoring is explained briefly in the tutorial, but you can't look it up while playing (thus violating one of the cardinal rules of tutorial design: that all information learned therein should be available at all times), and I couldn't find any explanation as to exactly how much more valuable closely related species matches were, which makes it much harder to work out what you should be doing.

It also took me an embarrassingly long time to understand how gaps work. It's not just about breaking a sequence: if you have one sequence longer than the other, then any space between the ends of the two rows also counts as a gap. So in the example above, the bottom row (the bat) has no gaps, but the top row (the cow) has two: one on the left (above the green bat square), and one on the right (from the orange to the green bat squares). Maybe I'm just really thick, but once I got onto four or more rows the scoring ended up feeling random and confusing, which made for a rather unenjoyable experience.

It wouldn't be so bad if the scores were displayed in real time, giving you some feedback, but instead the score is calculated every five seconds with a little red timer bar and an irritating blip noise, which means that you either have to wait or manually click a button to see if your latest move has improved your score or ruined it. This disconnects the player from any sense of feedback and makes understanding the already complicated system ten times harder. In, say, Bejewelled, this wouldn't be such a problem, but here the score is everything: your only objective is to increase it. I really have no idea why a timed update was chosen over real-time. Maybe it's an optimisation decision, but I refuse to believe that it could really save any meaningful amount of processing over simply having it update each time the player makes a move.

The other big annoyance is that these challenges are timed, which means that a good proportion of players fail to complete the challenge at all, let alone in an optimal fashion. The difficulty curve is what I'd describe as 'exponential with wobbly bits': the basic levels with three rows are absurdly easy; four rows can be pretty tricky, and anything more than that has a good chance of being fiendishly hard, though occasionally you'll come across an eight-row puzzle that can be solved simply by stacking all the blocks to the left. This is exacerbated by the time limit, which, as far as I can tell, is the same for all difficulty levels: I started off doing some basic three-row puzzles, got bored, moved to the next level and ran out of time.

Of course, a lot of these problems are due to the nature of the project as opposed to bad design. The scoring system is odd and confusing, but I'm not a biologist and presumably the scoring reflects the way genomes should be matched. The timer is annoying and significantly detracts from the play experience, but maybe from the designer's perspective it makes more sense to have a lot of people playing a lot of puzzles and finding lots of good solutions, rather than having people play a few puzzles for a long time and finding the best solutions. I just don't know; I wasn't on the design team and I'm not going to be using any of the data produced by the game.

Having said that, there are also a lot of problems that are definitely due to bad design: the intermittent score updating; the way that useful stats are only shown when mousing over a certain button; or that there's no way of abandoning a level once started without logging out. And why the relative values of related species matches couldn't be explained I have no idea.

I'm probably being too harsh. It's a free game for a good cause, and even without the feel-good factor of progressing scientific knowledge and being part of a big, happy crowdsourcing experiment it's more challenging and worthwhile than Bejewelled (though it's definitely more frustrating). I'd recommend that you go and give it whirl, but I wouldn't blame you if you don't play for very long.

Rule #66

Never wear a shirt that's darker than your suit.

Burnout

For the last week or so I've done absolutely no work on the game at all. Why? Because I burnt out on it.

For the last month or so I've been doing almost nothing but coding, drawing and designing, and it had begun to take its toll on me. I'm not a professional; I have other commitments, and, to be honest, I'm an innately lazy person.

The straw that broke my idling, sloth-like back was the realisation (hardly a shocking one) that I have absolutely no artistic ability, talent or potential of any form, and that making background artwork was much harder than I thought it was going to be. To be honest, I still don't know exactly how I'm going to deal with it, but hey, that's a problem for future me, and I hate that guy. If the worst comes to the worst I'll have to go and stand outside the arts building and "persuade" the least irritating person there to do some art for me. That's a sign of my near-negative artistic talent: I don't even know what the verb for making art is: is it "making"? "Creating"? "Doing"? Who knows. I don't even own a beret. Or a Macbook. And I don't smoke, and prefer to be clean-shaven. Terrible.

Anyway, so I took a week off. I wrote an essay on the complexity of Gothic villains, a translation of The Tale of Balin from Malory's Le Morte d'Arthur, and a commentary on the recursive microcosms present in Balin. I also learnt a new card trick, discovered a secret passage in the university, and played a lot of Starcraft II. A lot. I went from Bronze league to Platinum, and then fell back down to Silver, all the space of three or four days. It was fun, but now I'm fed up with it and so am ready to return to the game.

Because I'm making so little progress on the art front, I decided to implement something that I had intended to save for much later in the development cycle: multiplayer. At the moment I'm working on getting support for up to four characters - while more could probably be added without causing too much lag, it's a bit of a balance issue. There's full friendly fire, so it will be sort of self balancing, but that doesn't scale perfectly by any stretch. Once it's done and all the artwork is original (even if it's atrocious: at the moment I'm just using sprites from Realm of the Mad God) I'll start releasing videos.