As background for non Smurfy Fortress regulars, Smurfy Fortress was one of the last Australian TF2 communities.

After 3 years, and with increasing personal & work commitments, I decided it was time for Smurfy's run to end and on 20 November 2015 I announced that Smurfy Fortress would shut down a month later.

Smurfy Fortress was recognised as having possibly the friendliest TF2 community whilst also being a somewhat serious pub server renowned for communication and teamwork so as we close I thought it would be valuable for future communities to learn from our experiences.

In previous posts I have discussed our reasons for starting Smurfy as well as why community is so important. TL;DR anyone can start a game server and players are always free to leave any time they feel like it so the only thing that differentiates one game server from another is the community.

In this post I detail the thinking that went into shaping the Smurfy Fortress community. It is no exaggeration to say that tens of hours went into planning every major feature of Smurfy Fortress.

As an aside, due to my personal interest in business, psychology and economics you'll find random parallels drawn to those fields. One of my side goals in the way Smurfy operated was to provide exposure or experience that would be useful to Smurfy players in other parts of their life.

Culture is key

We begin with the basic belief that community culture is key. The reason for thinking so abstractly is that we need a simple compass to guide all our decisions.

The idea that culture is important is not new or original. Throughout my professional life and the past 20 years online I've observed that all organisations fundamentally succeed or fail based on their culture. Hence I believed that Smurfy's success or failure would hinge on our ability to adopt and reinforce an appropriate culture.

Smurfy's culture was best embodied in the one simple rule that we had. "Have fun. Be nice."

These four words ended up reflecting our approach to everything so it's worth dissecting them.

"Have fun."

Above all else, gaming is about having fun.

Fun means different things to different people but broadly speaking it boils down to two things:

1. Players enjoy themselves when they feel like they are having an impact on the game. It's not fun to be steamrolled, and equally it's not much fun to smash the other team, though most players would feel that's a better option than being steamrolled. For most people the ideal game is one where the teams are balanced, where newbies and experienced players alike feel challenged but not overwhelmed.

2. Players don't enjoy being abused. Without necessarily expecting the other extreme of sunshine and rainbows, if we could measure the vibe in game along a scale of hostile to friendly, we should at the very least be in the friendly half of the spectrum. This leads us to "be nice".

"Be nice."

Fundamentally you can't force people to be nice. And nice is itself rather vague. Certainly there is no comprehensive list of nice behaviours that we could point players to and say "do this" so the best way to build a nice culture was to behave in the way we wanted others to behave.

In psychology or behavioural economics circles the lingo used to describe what we did would be establishing "norms" and providing "incentives".

It's impossible to overstate the value of seemingly unimportant behaviours. Small things like saying hello to each other or congratulating an enemy player if they get a good shot on you go a long way towards establishing norms.

I was fortunate that I'd met enough nice players over 4 years of TF2 that I could start Smurfy with enough founding admins that would behave the way we wanted our community to behave. That planted the seed for our community's culture.

As the community grew and we added admins, existing admins were given the ability to veto new admins. Since we didn't all play at the same time it was important that if a candidate had been seen behaving in less than ideal ways that they could be immediately ruled out. I felt that it was worse to have a bad admin/representative than to not have the admin at all. Businesses refer to this as hiring "B" or "C" players.

Adding admins was one way to entrench our culture but the most impactful method was via our Elder Smurfs.

Superficially the Elder Smurfs program recognised friendly players with an in-game greeting and provided them the power to !votekick and !votemute troublemakers.

The design of this was not an accident (although certainly the success of the program went far beyond my expectations!). We knew we needed more eyes to police the servers as admins could not be present 24x7. But I also knew that by publicly recognising the Elder Smurfs with the in-game greeting other players would see that there was a benefit to behaving well (besides not being banned). Essentially we provided an incentive for good behaviour, and importantly via a mechanism that could not be gamed which is a problem with most reputation systems.

At a more abstract level there was an underlying design goal that whatever mechanisms we came up with should always encourage desirable behaviour so that good behaviour drowns out bad behaviour, as opposed to solely playing whack-a-mole with bad behaviour.

There's an element of the broken windows theory at play, essentially that if the servers are ever unpoliced and bad behaviour reigns it would encourage others to behave badly, as well as attract further bad actors as a norm of bad behaviour is established. On the other hand, by entrenching good behaviour as our norm, we attracted players looking for servers with well behaved players and created a self-reinforcing cycle of good behaviour.

At a philosophical level, my belief is that although there is a lot of horrible behaviour online, many of these bad actors are not fundamentally "bad" people. The vast majority of anti-social behaviour online occurs because people see others behaving badly. One player yelling "rekt" on every kill incenses others to join in with their own "rekt" or "get on my level". It takes cooperation from everyone to keep the peace yet only one person to start a war.

Our experience with ban appeals bears this out. 99% of the ban appeals we received were sensible in their tone – even those players who were extremely "trollish" in their prior behaviour – and the vast majority were observed to behave pleasantly in-game once it was explained why their behaviour was unacceptable. Only a handful would misbehave and be rebanned.

Furthermore, our ban appeal system was designed to maximise the possibility of bad actors "coming around". Our admins were strongly discouraged from interacting with abusive players in-game, with all appeals handled exclusively via email.

The idea was to separate the misbehaving player from their in-game mindset, giving them a chance to cool down and think about why they were banned. It's also much easier to be more verbose in email than via in-game chat, where everyone generally tries to be terse so they can get back to shooting things, leading to much miscommunication.

The language we used in our replies was chosen to convey the idea that we take bans (i.e. misbehaviour) seriously but at the same time we were keen to give players a second chance as long as they acknowledged their misbehaviour and agreed to play nice in future.

It's worth considering the alternatives to our "Have fun. Be nice." setup.

Many communities explicitly list bannable behaviour.

With this approach troublemakers take it upon themselves to look for creative ways to violate the spirit of the rules without explicitly breaking them. i.e. if you ban swearing they might then refer to others as a bundle of sticks. Typically this ends up in an arms race with an ever growing list of rules.

Furthermore it allows troublemakers to chew up your admin time and brainspace as not only do you have to try to come up with a rule set that won't be worked around but you also end up in arguments with such players about whether their behaviour is bannable.

Guiding principles

At a conceptual level the above decision is one of whitelisting vs blacklisting. Smurfy chose to (very crudely) whitelist good behaviour. Lists of rules with bannable offences are essentially blacklists. Wherever possible, whitelisting is usually better than blacklisting.

In general, if you're going to spend time or resources on a gaming community it should be focused as much as possible on enhancing the community rather than fighting bad actors. If you reach a point where the majority of time is spent on negative aspects of the community then it may be time to reevaluate your entire approach.

In particular, if your approach to problems is take feature X away from everyone, both good and bad players alike, then I posit that your design thinking is fundamentally flawed. That approach leads to bad actors dictating the direction of your community.

Mini-rant: This is the approach that Valve took when they essentially blacklisted all community servers in response to a few community operators doing Bad Things. By tarring all community servers with one brush they allowed the bad operators to dictate the future of the TF2 community.

Valve could have blacklisted the bad servers or, since those bad servers would likely have reappeared in a different form, they could have whitelisted good community servers.

As another example, some % of Steam users get phished so Valve gradually escalated trading security requirements. First you had to confirm all trades via email, then they added trade holds such that if you don't enable their Mobile Authenticator your trades will be held for up to 3 days.

Essentially they let phishers/scammers dictate the level of (in)convenience for all Steam users.

Summary

Running a gaming community is really no different to running a business. Start by understanding what your players/customers want, figure out what's important to them, then do everything you can to achieve that.

Culture gives you a framework within which to operate. If your culture is strong and you work to constantly reinforce that culture then you can do away with formal processes and rules and keep things simple.

On the other hand, if your culture is weak, you'll find yourself spending increasing amounts of time writing rules for people to follow.

I realise this post paints an overly glowing picture of Smurfy's approach. In future posts I hope to discuss further details of our operations and highlight both the positives and negatives as everything we did involved some tradeoff.

A few weeks ago we introduced SmurfPowder™, a system that assigns players to team based on rankings derived via TrueSkill. The goal of this system is to pick balanced teams so that games will be challenging for all. Specifically, we wanted to address the issue where our previous (random) assignment system would sometimes produce hugely unbalanced teams, resulting in one team steamrolling the other.

gsan and I spent several days building, testing & deploying SmurfPowder™ and it is running well but how do we know if it's actually improving things?

We need a way to identify bad games so that we can see if the proportion of bad games decreases over time.

From experience, a couple of examples would be:

• Blu failing to capture point A on Badwater, or failing stage 1 on Goldrush
• Blu literally steamrolling Red on Badwater or Frontier by pushing the cart from start to finish without pause

We could try to write down every bad game scenario but this is tedious, error prone, and limited by our imagination and personal experience.

We have the logs from every round played since Smurfy Fortress began so we decided to do some log crunching and use visual tools to help us identify features that define bad games. A link to the raw data is provided at the end of this post.

Initial Exploration

Although we had some ideas of the sorts of features we were looking for we weren't entirely sure so I went looking for a visual tool that would make experimentation quick & easy. I had heard good things about Tableau so downloaded a trial.

Tableau makes it very easy to visualise data. You simply drag & drop dimensions and measures, and with a few clicks you can try out different charts to see what patterns emerge.

The two examples listed earlier led us to consider Round Duration and Kill Difference as possibly significant features of bad games. The intuition is that unusually short durations probably indicate a Blu steamroll. For longer durations it's not clear whether one team was overly dominant so for longer durations we need to take into account other metrics such as the Kill Difference.

Initially we plotted Average Round Duration vs Time, and Average Kill Difference vs Time but these graphs were uninspiring and rightfully so. Both Round Duration and Kill Difference vary greatly by map so averaging across all maps produces a meaningless statistic. Fortunately Tableau makes it easy to dissect data by any dimension so we were quickly able to replot the same data by map/stage, as well as experiment with varying time windows (i.e month, week, day etc).

Let's start with Round Duration. Clickity, click, here we have Round Duration vs Winner for Payload maps summarised by week.

Note: I recommend opening these graphs in a new tab as we will provide some commentary below so you'll want to be able to flick between this post and the related graph.

Across the graph we have partitioned the data by map, and stage where applicable. Within each map/stage each vertical set of points represents one week of matches. Vertically we have the Round Duration, and the colour of each point indicates the Winner of that particular round.

Immediately we can see some patterns. For example in Badwater and Frontier (first two columns) we can see horizontal red lines that correlate with Red wins (successful defence) at each capture point.

We can also see that on Goldrush the density of the Blu dots (Blu wins) in the lower region indicates that Blu often wins stage 1 and 2 very quickly but stage 3 is more challenging. Regular Hoodoo players may be amused by the stray Blu win at the 100 second mark – that's the runaway bomb bug.

This graph confirms some of our intuition but without futher information we can't tell whether games were balanced. Short duration Blu wins on Payload may indicate a steamroll but with so many short duration Blu wins on Goldrush were they all bad games?

Let's look at the same games but plot Kill Difference vs Winner for Payload maps.

Note that in this graph the vertical axis is Red Kills - Blu Kills so negative values indicate that Blu had more kills than Red.

Intuitively we would expect that Blu wins would correlate with Blu having more kills and Red wins correlate with Red having more kills and this is mostly the case but not always. We can see several cases on Frontier where Red wins despite having less kills, and many cases where Blu wins despite having less kills. Overall it seems that for Payload maps Red needs to out deathmatch Blu in order to win.

What's interesting about this graph to me is the vertical spread. Intuitively we would expect close games to have relatively small Kill Differences whereas we may surmise that the Badwater round with a near 150 Red kill advantage was probably very one sided. Perhaps we could draw a line at Kill Difference of 100 and say that all games above this point were one-sided? Similarly we might say Blu wins with Kill Difference below -30 may have been one-sided.

It becomes painfully obvious at this point that neither of these graphs provides quite enough information to decide which games might be bad but there are definite patterns in the data. Before we go on to plotting Round Duration vs Kill Difference by map let's quickly look at the above plots for other map types.

Round Duration vs Winner for Attack/Defend CP maps

Kill Difference vs Winner for Attack/Defend CP maps

These are very similar to their Payload counterparts which makes sense given that both share the format of one team attacking, one team defending.

For the symmetrical maps we get very different patterns:

Round Duration vs Winner for Symmetric CP maps

Kill Difference vs Winner for Symmetric CP maps

Round Duration vs Winner for KOTH, PLR, SD & TC maps

Kill Difference vs Winner for KOTH, PLR, SD & TC maps

As one would probably expect given that the maps are symmetric and the team objectives are also symmetric the plots also look fairly symmetric. SYMMETRY ALL THE THINGS! Blu & Red win in roughly the same durations, and with roughly the same kill differences.

It may be worth noting the spread of round durations for symmetric CP maps, as well as the crazy durations of Hightower vs the other Payload Race maps. I guess people really like Market Gardening.

There's many observations that could be made, comparing maps & game modes but this blog post is already insanely long. :) Please feel free to leave any observations in the comments below!

Map by map breakdown

We then dug into the data map by map, round by round and plot Round Duration vs Kill Difference. We jumped out of Tableau for this part. Tableau is fantastic but I can't afford the $999 license fee and we need metrics that we can monitor over time in order to evaluate SmurfPowder™'s effectiveness.

gsan wrote some Python code to generate plots as we felt by this point that we had a reasonable basis for long term metrics. I'll highlight a couple of examples but the full set is linked at the end of this post.

Note that in this series of graphs we switched from Kill Difference (Red - Blu) to Winning Team Kill Difference. I apologise for this inconsistency but we opted to use the former to highlight symmetry in the earlier graphs but the latter makes more sense when we look at Round Duration vs Kill Difference.

Let's take a look at Badwater, being one of the most popular TF2 maps.

Round Duration vs Winning Team Kill Difference for Badwater

Each point represents the winner of the round as before. The solid blue line and solid red lines mark regions which capture our intuitions regarding features of bad games. The larger dots indicate the games we have classified as bad, based on the aforementioned intuitions as well as other heuristics.

We suppose that, given sufficient game rounds, for particular maps/stages some percentile of the kill difference and duration are bad games. For simplicity, we assume that for all maps, all kill differences greater than 95 percentile and all durations less than 20th percentile are bad rounds. We classify the intersection of these as bad rounds. However, it should be noted that there is correlation between kill difference and round duration.

Furthermore, we also consider those rounds in Attack/Defend maps where Red is able to hold the first half of all capture points as bad games.

For Badwater the Blu line captures 2 intuitions. Firstly, short duration games are almost certainly bad – capturing 4 points in under 400 seconds means the cart barely stops, if at all. The second is that as the game goes on (duration increases) we would expect the kill difference to increase but we can see that across all games the kill difference rarely exceeds 50. The Red line captures the intuition that winning at CPs 1 and 2 at any duration is probably okay as long as the kill difference is not large. Red wins at CPs 3 and 4 with larger kill differences than at CPs 1 and 2 may also be okay since the game has gone on longer.

Exactly where the boundaries should lie is debatable but for our purposes precision matters more than recall so we try to be conservative in that respect. We also expect that we will adjust the boundaries as we further study the data and gain additional insights.

As another example let's look at Goldrush stage 3.

Round Duration vs Winning Team Kill Difference for Goldrush stage 3

Unlike Badwater this graph captures a single stage (stage 3) of Goldrush. Like Badwater, our intuitions here are that Blu steamrolled Red if they won the round super quickly, or if the kill difference is large. If Red wins with a large kill difference then it's likely the game was one sided but we use a graduated Duration:Kill Difference ratio to allow for larger kill differences in longer games.

These are just two examples and the graphs for each map/round look very different so I encourage you to poke around at the full set.

Toward a single evaluation metric

To figure out if SmurfPowder™ is effective in reducing the number of bad rounds we aggregate all of the above into a single metric: percentage of bad rounds over time.

Smurfy percentage of bad rounds

The green shaded area indicates when SmurfPowder™ was active and as yet we do not have enough data to know if it has improved things but we can at least see that it hasn't made things noticeably worse. That's a good start.

What next?

We'll need to wait for SmurfPowder™ to accumulate game results and refine its rankings for individual players, and we'll continue to monitor our bad rounds metric over time.

In the meantime we'll continue to update & further analyse the data that we have and encourage you to do the same.

The raw data produced from log parsing is available here. There are two tab delimited files containing data summarised by server, date, map, and mini-round. Mini-rounds are stages of multi-stage maps such as Dustbowl and Goldrush. all.tsv contains all of the data for Smurfy Fortress beginning October 2012, and all_6month.tsv is the most recent 6 months, both ending 3rd January 2014.

The earlier Tableau graphs above were generated using the 6 month data set but the later Python generated graphs use the full Smurfy set. This was initially because I dun-goofed the processing and didn't want to wait 5 hours to generate the full set but it turns out to be more pleasant for the Tableau graphs as 14 months worth of data for each map would have been too visually dense (or require larger graphs).

The 6 month Tableau workbook is available at Tableau Public.

Please download and play with the data and let us know if you have any suggestions or feedback.

Also, we would love to analyse data from other TF2 communities! If you run TF2 servers and are willing to share your logs with us please get in touch (leave a comment below or email smurfy@mooh.org).

After ~14 months running Smurfy Fortress I thought I'd share some of our experience in terms of building a lasting TF2 community. This post is also, in part, prompted by the many recurring threads on reddit regarding premium or donator perks.

Firstly, I'll say that I don't particularly care what other server operators do or don't do but our own players have suggested various perks at various times so this post seeks to share our thoughts around this.

As I said back in November 2012 the goal with Smurfy Fortress was to host servers that I want to play on. Broadly, this means fair & fun games, free of abuse. Above all else, game play is paramount. This isn't only a personal preference but I think it's the key to the sustainability of any gaming community.

Why is community important?

Well, firstly, multiplayer games aren't much fun on your own.

More importantly, anyone can put up a server for $20/month. It's neither expensive nor technically difficult. The only thing that differentiates one server from another is the players… i.e. the community.

Ok, if community is so important, how do you build a community?

One approach is simply to bribe, or buy, players. You would've seen this approach in many forms. e.g. join our server at for a chance to win Mann Co keys, hats, or other precious items.

This may be okay to kickstart a community but long term this approach is fundamentally flawed as you're essentially paying players to play on your server. Unless you have unlimited funds this is obviously unsustainable, and when you eventually run out of funds your players will migrate to the next "community" offering perks, hats, and whatever else.

Let's think about this another way.

We know that players like to play with their friends. So maybe the easiest way to grow a community is to ensure that the players that we want as part of our community consistently play on our servers. Then, over time, their friends will become regulars, then their friends, and so on. Growing a community this way is essentially free (monetarily, it certainly takes time & effort).

So then the question becomes: what makes players stay on a server?

This seems simple enough. Players leave if they're not having fun.

This brings us back to donator perks. Such perks might be good in terms of fundraising, and are almost certainly fun for the donors, but are terrible for everyone else in your community. If you assume your players aren't completely stupid, the vast majority of players who aren't donors will never play again on your server once they realise they're being raped by players who paid for advantage. Long term, your "community" consists only of donors and new players who don't know any better.

An optimisation of this model is to entice new players to join your servers through giveaways as mentioned earlier. This may be sustainable since the donator perks drive revenue which allows the server operator to continue offering enticements to new players. But this isn't the sort of server I care to operate.

What we've chosen to do with Smurfy is focus on game play.

We started with basic things such as auto-assigned teams (to combat team stacking), and class limits (no one wants to play with 5 snipers, though 12 snipers is hilarious!).

As the community grew abuse became an issue. So we added more admins, and also created the Elder Smurfs. Essentially we give long time regulars some recognition (a server greeting) and the power (!votekick and !votemute) to help us keep the servers clean… for everyone's benefit. Players have asked why Elders don't get other perks, e.g. the ability to have Unusual effects added to their hats. This comes back to our optimisation goal - we want to build a lasting community of friendly players. i.e. we don't want players to play and rack up hours because it will get them perks (any server can offer perks), we want players to play because they enjoy the games & community.

With a scalable way to deal with abuse the main problem we have now is team balance. Although the random assignment we used previously was fair in the sense that no one was allowed to bias the teams, the resulting teams weren't always skill balanced and the game would be one-sided.

A side note – some players are happy with, or think that they are happy with, an easy win. Afterall, a win is a win. But my contention is that what players really want is a challenging win. Consider this – if you play tennis with your best mate and you beat him in straight sets 6-0, 6-0, week after week, how long do you think he'll keep playing? He'll feel terrible, and you don't get any sense of achievement, it's like beating a 5 year old. One of the challenges in making games fun for everyone is remembering that winning is fun but not if it is a walkover.

To resolve this we recently introduced SmurfPowder which ranks players based on whether their teams win or lose, and attempts to pick skill balanced teams based on these rankings. The system needs time to establish rankings so we're unsure how much it will help but we will certainly share our findings when we can.

For the business nerds I see parallels with marketing & product strategy. If your product (games in this case) is shit you'll have to spend a bunch on sales & marketing to sustain your business (community, in our case). OTOH, if your product is good, word of mouth will go far. I think both models are valid from a business viability perspective but I know which one I prefer.

Also, on differentiation – anyone can set up a server and implement any of the technical features mentioned, including the TrueSkill based rankings. Long term, the only differentiator for gaming communities is, unsurprisingly, the community itself.

One of the hardest things about starting a new TF2 server is getting players to play on it. No one wants to join a server with no players, but if no one joins the server with 0/24 players then how does a server ever get started?

Initially with Smurfy Fortress it was up to the core admin group to get the servers populated. We had all played thousands of hours on other servers so were lucky to have quite large friends lists.

The process goes like this:

1. Our intrepid server starters join the server via their Favorites list
2. Friends of theirs join the server
3. A few randoms will join via the server browser
4. Once we get to 12+ players Quickplay begins sending players to the server

The exact point at which Quickplay kicks in varies depending on the server reputation.

The crux of it is that without a few players joining the server manually to begin with Quickplay would never kick in, and the server will never be populated.

A significant problem between steps 1-3 and 4 is keeping everyone entertained as sometimes it can take half an hour to get to step 4.

When there's only a handful of players it's very easy for the game to be one sided. All it takes is one good combo and steamroll ensues, causing players to leave to find a more balanced game. Every player is critical at this point because you need to hit the magic threshold for Quickplay to help fill the server.

Fortunately we've built a friendly community on Smurfy Fortress and regular players have devised a number of silly games to play with low numbers of players.

Here's one example known internally as COD Fortress 2:

Others include combinations of:

• Battle Medic - everyone plays Medic and equips the Blutsauger
• Tickle Fights - Holiday Punch Heavy, no miniguns, just tickle and taunt kills
• Trolldier - Soldier using the Rocket Jumper, aiming for Market Gardener or Mantreads kills only
• Stab Stab Sniper - Huntsman Sniper, going only for Skewer kills
• Flare Pyro - guess what? Pyro, but you can only use the Flare Gun. Whodathunkit.
• Melee only

The point of it all is stupid but fun. It's much harder to kill people with these loadouts, and less biased towards skill/experience, so it's not only fun but also non-rage inducing. And it works with any number of players.

The end result is that the servers populate faster as players stick around because they're having fun. We do lose a few players who dislike the fact that people aren't playing seriously but that is actually beneficial to our community as we want players who don't take the game so seriously all the time.

Today the crafty econonerds at Mann Co. announced that they would retire a bunch of the very first hats introduced to TF2 back in May of 2009.

I remember that day - getting my first Huntsman, arching arrows from base to base in the first stage of Pipeline, and admiring the lucky souls who received the very first Pyro Beanies. Ah nostalgia.

So much has happened in the TF2 economy since - many, many new items, player to player trading, the Steam Workshop, a plethora of 3rd party sites enabling sales of items for real money, and recently the official way to do the same - the Steam Community Market.

But one thing has remained constant - inflation.

With every active player getting 14 new items (0.77 ref) every week by simply playing the game, and a near zero marginal cost of "producing" new items, it's kind of like the Federal Reserve printing money continuously (which, thanks to the "global financial crisis", the real Feds are actually doing). It's the reason why metal prices only ever fall - the price of something given infinite supply is fundamentally zero.

There are several effects of this first step Valve is taking towards limiting item availability. Most traders seem to care about the price effects on these particular items so let's look at that first.

Everyone knows that price is a function of supply & demand.

In the immediate future the demand side for these items will spike due to speculators who feel the price of these items will rise once the supply is limited in future. Also, anyone who wanted these items already has them, or will buy them before they become limited. So one would expect an immediate but perhaps temporary price rise.

But immediately after these items are no longer available I don't foresee any further rise in the price because consumer demand will simply not exist. Very few consumers want these hats which is why their prices are so low, and new demand for these items could only come from new TF2 players.

But there is a more important effect. By cutting off the availability of these items Valve is signalling that it won't allow the economy to debase itself by providing infinite supplies of everything. I think that is more important than the micro effects on the prices of the individual items.

We should see, longer term, that all prices rise due to the implied threat that supply will become limited at some point in future – up til now everyone has worked (read: priced) on the assumption that supply is limitless which is why many items have pathetically low values. There is also the fact that the Mann Co. Store currently sets a price ceiling on every item.

Fun-having players may view this as a negative as the prices of the hats they want will go up. But ultimately it's in everyone's interest that the TF2 economy is strong – Valve relies on it for income to pay the salaries of the engineers & artists who provide game updates, and community item & map makers rely on it for income too.

Having played TF2 for 5+ years I've been involved in my fair share of debates as to what maps are the "best", "most popular" and so forth. I finally got around to looking at some data.

Here's a graph of the top 20 most played maps on Australian servers for the period 26 November 2012 to 3 December 2012. There's nothing special about this period, I simply picked a roughly 7 day period to look at. This data includes only normal TF2 servers - specifically it excludes MvM and all mods that I know of (such as PropHunt, Dodgeball etc).

The full list of (144!) maps is public.

Firstly - over a 7 day period Aussies racked up an astounding 4.4 million minutes of TF2. We played 8.36 years worth of TF2 in one week. Wowsers. And again - this doesn't include MvM, mods, idle & achievement servers etc - this is purely normal PvP TF2.

Given the number of 24x7 2Forts, Dustbowl, Turbine, Goldrush and Badwater servers it's unsurprising that these are the top 5 most played maps. It is staggering though that 2Forts, Dustbowl and Turbine make up almost 55% of the total play time.

I've never understood the popularity of 2Forts but clearly there is an extremely dedicated sub-population of the Aus TF2 community that enjoys it. Goldrush and Badwater often make up the core of popular fixed rotation servers and clearly that role is well deserved.

After that there's a few surprising results, at least to me. I would not have expected DeGroot Keep to be up in #6 – though we should note the clear gap between Badwater at #5 (6.7%) and DeGroot at #6 with less than half that (2.3%).

I'm surprised to see Egypt and Hightower up so high - I rarely see these maps played but that is the whole point of this analysis – it's clear that our own play style preferences bias our perspective on what maps are the most popular.

Doomsday is another surprise at #10 - most folks I know don't seem to like it but again that goes to show the bias inherent in one's group of friends. KOTH Kong King is also more popular than I expected – of all the KOTH maps I would've thought it's the worst hehe.

Double Cross is lower down than expected given that it's regularly voted in on full rotation servers I've frequented, and that there are a few 24x7 servers around.

As with all stats, the more you look the more questions you have. I'd love to understand the diversity of players across these map types – is there a distinct set of 2Forts devotees? – and are there specific factors that make the top 5 so much more popular than the rest of the maps?

Are these results surprising to you?

Methodology: I poll every server in Australia roughly every 5 minutes so we'll miss things like players leaving/joining between each reading but given that we are looking at total play time over 7 days these factors should even out and the relative values should be about right.

Collecting donations is an annoying problem for server operators and players alike.

The most obvious method is to simply collect money via a payment system such as PayPal. However that automatically incurs a 2.4% fee + 30c per transaction which becomes 8.4% (32c) of a $5 donation or 5.4% (54c of a $10 donation). It's pretty inefficient, nevermind the annoying UI.

Some GSPs (game server providers) offer solutions such as Multiplay's Clan Pay. That's a step in the right direction but it should be much easier.

The biggest barrier to donating IMHO is the fact that a player has to do it outside of the game interface. And if you've ever run a server you know there's not many opportunities to nicely remind players to donate - MOTDs are routinely ignored and spamming messages during the game is futile because people are there to play, not to read your spam chat messages.

Ideally players should be able to pay directly from the game. If Valve were to get involved they could implement a Flattr type system where players could nominate an amount they are willing to spend each month (say $5/mo) and Valve could distribute it amongst the server(s) the player likes, or play on frequently.

But foregoing Valve's involvement there is a solution that some motivated hackers could rig up. This solution also has the benefit that players don't have to contribute money but can donate items/metal instead. This has the benefit that anyone can contribute, not just those with credit cards, and people can contribute without spending any money - they only need to play the game to get random item drops. Also, it would mean that truly micro donations would be possible - given a refined metal is worth roughly 55c and 18 weapons go into that, a single weapon is worth roughly 3c.

How could this be done?

The server operator needs a way to automatically accept items from players. The bots implemented by TF2WH and scrap.tf (whose SteamBot code is open source BTW) could handle this.

Some plugin code could make such bots initiate trading requests to players. So a player could type !donate into chat and the player would receive a trading request to accept donations.

The other part of the equation is liquidating metal/items to cash. I don't really know of an efficient way to do this though one possibility might be to sell items into TF2WH, convert to Bitcoin via TF2WHX, then sell the Bitcoin to cash. This could all be (in theory) automated.

The incentive for someone to operate this whole donation bot+liquidation as a paid service is that the service operator could take a cut of the donations.

Someone build it! I'll be your first customer.

Smurfy Fortress is my attempt at building the game server network that I want to play on.

Most of the Australian TF2 servers are perfectly fine from a technical standpoint - their servers & networks are fantastic and ye olde problems of lag etc are no longer an issue.

The things that did bother me on other game networks were mostly configuration and community related.

Playing on other servers I felt restricted in the efforts I could make in making the servers better to play on. It's hard for admins to know who to listen to, and making changes always involves some risk of not only breaking the server, but also alienating existing community members so admins are understandably reluctant to make frequent changes.

There are 3 key things that I hope to make "better" on the Smurfy Fortress servers.

The first is to listen to feedback, observe player behaviour, act quickly, and observe the results. I'm running the servers as a never ending series of experiments. It's clear after playing TF variants for 15+ years and having been involved in my fair share of theorycrafting that there is no perfect answer. Let's just try things out and see what works, and do it in a tight loop so players don't feel like they're ever stuck with a shitty status quo.

My second goal is for the Smurfy servers to be generally pleasant to play on. There's two aspects to this.

One is removing bad actors. I have no tolerance for players who want to grief, troll, hack etc, and encourage our admins to ban such players. My feeling is that there's no shortage of players who will be nice to each other and by banning those who aren't we establish a co-operative community that will hopefully attract other friendly players.

The second is fair games. Team stacking is a huge problem on many servers. Some servers run gScramble and auto-scramble the teams when an imbalance is detected but finding the right thresholds so that it triggers just enough and not too much is really hard. There isn't a perfect solution but so far we've been trialling auto-assigned teams with good success. At the very least auto-assign prevents deliberate stacking so if you get rolled at least you know it wasn't due to malicious intent by the other team.

Lastly, one thing that has always bugged me about some community run servers is the abuse of admin powers. Apart from arbitrary kicking & banning it also extends to things such as randomly changing maps on a whim. Another is the use of reserved slots for either paying members or admins - this breaks auto-diallers for ordinary players and basically says "we don't value you plebs". I think this is a flawed attitude as you need a reasonably large group of co-operative players to make the game fun long term.

Funding & admining the servers long term is a challenge. The sums of money involved are not huge but I would like to get Smurfy Fortress to a point where it is self-sustaining.

It's been almost 2 months since I last posted and that's because I've been working on the Smurfy Fortress servers.

It all started with the release of MvM. Fletcher Dunn from Valve posted a notice saying that a MvM server would require as much CPU as a regular TF server. At that point I had never run a TF2 server so I had no idea how much CPU that actually meant but one thing was obvious - every CPU currently dedicated to a 24 player server could only handle 6 players in MvM.

In other words, at MvM launch the vast majority of players would want to try it out, and unless there was a 4 fold increase in hardware dedicated to MvM Australia wide there was bound to be massive queues for MvM.

The other realisation was that if there's only 6 players and the recommended minimum rate per player was only 30kB/s the peak bandwidth required is roughly 180kB/s or 1.5Mbps. My cable connection is 100/2.4Mbps. Woah, that means it's entirely possible to host a MvM server on my cable!

There didn't seem to be any good guide out there about how much CPU was actually required but keeping in mind that TF2 came out in October 2007 it's fair to assume that one doesn't need to have the most modern overclocked CPU to host a server.

Being a Linux nerd I fired up a KVM on my dev box (a Q9400 quad core) with 1GB of RAM and that was perfectly fine for MvM.

On the network side an MvM server averages around 600kbps, and peaks at less than 1Mbps outbound.

I've written down the full specifications for an MvM server.

I ran an MvM server on my cable connection for about 2 months and continued to play regular PvP TF2 on the games.on.net servers. Unfortunately in early October all of the GON TF2 servers disappeared. It turns out they were doing a massive platform upgrade.

As a regular 24p TF2 server requires more bandwidth than my cable can handle I began looking at VPSes. I managed to get a couple from GloVine and Exigent to experiment with, and thus Smurfy Fortress was born. It's been an interesting experience finding VPS hosts that allow game servers but I'll save that for another post once I have more data.

reddit user Xovaan has created a series of awesome Dilbert-ified TF2 characters:

Dilbert Medic:

Alice Demoman:

Dogbert Spy:

World's Smartest Garbageman Engineer:

Loud Howard Scout:

Elbonian Soldier:

Pointy-haired Boss Heavy:

Wally Sniper:

Catbert Pyro:

They're hosted here, with Xovaan's permission, for posterity since the original images were posted to Imgur where they will eventually expire. Each image links to the original full sized version.

The original reddit threads are, in chronological order, oldest first:

• Dilbert as the Medic didn't exist so I decided to put this together in Photoshop for some reason
• You guys liked Dilbert Medic, so here's Demoman Alice. I don't even know anymore.
• Dilbert the Medic, Alice the Demoman. The next installment: Dogbert the Spy.
• Alice Demo, Dilbert Medic, and Dogbert Spy, SAY HELLO TO LOUD HOWARD SCOUT
• I solve practical problems. Dilbert's practical problems. Here's World's Smartest Garbageman the Engineer
• It costs $400,000 to fund this department for twelve seconds. You requested it: Pointy Haired Boss Heavy (Office '97 Clipart Edition) and a bonus Elbonian Soldier!
• They're finally done. The cast of TF2 recreated as Dilbert characters– with a bonus special guest!
• Hey r/gaming, I recreated the cast of Team Fortress 2 as Dilbert characters and r/tf2 said you might want to see