Greetings fellow Foxhooligans. Adam Here! We got another devblog discussing some of the more arcane aspects of game development. We are examining the little-known skills of Game Moderation, Level-Art, and the nebulous, unbounded task of Game Production. Come take my hand, and we will discover the world of game development together.
Disclaimer: All of the content below is heavily work in progress and is subject to change.
Let me give you a scenario. Jack is an ass. Jack has been yelling at people all day and he just stole your truck because you forgot to lock it and he thought no one was using it. So you kill him to get your truck back and he reports you to a moderator for TK-ing.
Another scenario might be that several people don’t like Jack, so they vote-kicked him right when he logs in today because they don’t like him. He comes to the moderators and we unban him, and then gets into an argument with those same players because who wouldn’t? And everyone vote-kicks him again for spamming the chat.
These aren’t rare scenarios, in fact it’s quite common that our moderators will be torn on the solution, and sometimes that means different outcomes depending on which moderator is handling your case. Here’s how we try to be consistent.
For those that have never done it before (Good for you!), players contact a moderator by Direct Messaging (DM) a bot on our discord server called ‘Mod Mail’, a custom bot developed by our admin Sir#0001. What this does is opens a new text channel on the discord specifically for you, where all moderators can view, discuss, and action it as a team. However, you may only ever receive a reply from a single moderator.
Above Left: I messaged Mod Mail and received an answer.
Above Right: All mods receive the message and can discuss the answer before replying.
Back in the dark ages we used to just log all our moderator action on a separate discord. But thanks to Sir, mod mail handles that now too. All these chats are now logged online so we can always search up past cases.
Above: My history of reports with the mod team (most of them are tests, I promise)
This has been a tremendous help in building consistency among the moderators. There are finer points to it, including the nebulous guidelines spreadsheet, but more important than all of this is that the moderators are working together, as a team, to try their best to help players in the community.
I say help, because the moderators are *not* a police force. Issuing bans is a part of their toolset, but banning itself constitutes only a very, very small part of their responsibility. Almost all cases--even the most difficult ones--can very usually be resolved by asking two parties to separate and play nice. Very rarely does a moderator have to ban anyone when both parties are communicating openly with a moderator.
Above: Red is the number of reports we’ve received, Blue is the number of mod bans issued.
So when it comes to our imaginary ‘Jack’ player who was causing a ruckus at the start of this dev blog, we are not interested in which players were right and which were wrong. That’s really the biggest misconception that we see; whether we decided to ban Jack, or let him off with a warning, players on both sides of the argument will feel like the mods aren’t doing their job. It’s the argument itself which is the job, not the participants in it. Without banning anyone, our goal is to stop the argument.
So the next time you find yourself in an argument with a player that’s quickly spiralling out of control, take a step back and think about it like a moderator--not in terms of who is right--but in what the next step would be to de-escalate the argument. Do that without immediately flying to the nuclear ‘ban-player’ option, and you’ll understand how hard our work truly is, and how truly valuable and unique our mod team is.
Without them, this game you love would not exist.
I know, I know, the port base (now just lovingly called a ‘base’) was something that people feel very strongly about one way or another. So let me tell you about why it had to change.
The purpose of bases was to create a relatively safe space in border regions to allow your faction to not get pushed into a corner, therefore ensuring there was always something to do when you logged on. You could make a comeback from near total defeat, and always have a place to spawn.
Initially, we had elaborate plans but weren’t ready to commit. Early on they were not intended to be so prolific in game. But then, World Conquest is a fickle beast. For those who don’t know, each one of the old port bases was constructed and managed individually by hand (and needed to be identical, as much as possible). They were in ten, growing to eleven maps sometimes with multiple bases per map and required an enormous amount of labour any time there was a change in that region or with a logi mechanic. We changed Word Conquest from east/west to north/south; this required a total re-positioning of every port base, manually. You will remember there were a lot of bugs. There’s no magic button.
Since they’ve become a major part of Foxhole, we decided to stop wasting time with port bases and make them easier to manage. You’d think it would be very simple to just create a pre-fab (A object that has many components within it) and bingo-bango, paste it around the world. So did I—this should be a level designer’s job. Unreal Engine had other plans.
I won’t get into technical details, but we needed to create a grouped reference to each of our structures in the game, and UE4 doesn’t like it when you do that, which led to tons of crashes. So Phil and I spent, about a week trying to figure out the best way to make our base prefab in an efficient way. We figured it out, but it wasn’t without compromise.
On top of that, I wanted to make the layout more convenient. It’s no longer a weird large maze. I know the previous layout was far more thematically appropriate. You guys have told me loud and clear; trust me, I get it. But with some time and practical use, I think you’ll understand why we made the changes we did. Now, hopefully, KFC and I can spend more time actually making maps, instead of fixing port base bugs.
As the Foxhole team has gotten larger of the last year, it's become more and more of a logistical challenge to get Updates released on schedule. With more developers on board, there's a lot more changes, features, and content being added to Foxhole in each update. It's a juggling act that requires both an open mind and discipline to ensure that both cool things make it into the game and ship dates are met. Finding the balance between development fluidity and structure requires constant effort.
In the pre-alpha days, the team used to keep track of update tasks in simple checklists in Trello but as the project and team have gotten larger we've had to expand our toolkit to include a few more things:
1) Trello - We use Trello cards to track major features, game balance, and changes that are to be completed for an update. Each card gets assigned to one or more team member for development and then later on gets transferred to QA for testing. We try our best to break cards down into weekly milestones so features can be completed ahead of time, mitigating the need for a giant QA bottleneck towards the end of an update cycle.
2) Github Issues - We use Github to track all bugs, both old and for the update under development. This is our official means for keeping track of all known deficiencies. Our bug count usually peaks at about 100 during a development cycle and we wrestle it down to 25-50 by the end. We heavily use Github to coordinate bug progression between reporters, QA, and the programmer. For 0.17, you can see 117 bugs/issues were closed off. That's a lot!
3) Release Issues Dump Spreadsheet - When we are nearing releases a TON of issues start arising from dev branch feedback, internal testing, and general discussions among the team. To keep track of all the little bits that tend to get lost in the cracks we lay them all out in a simple prioritized spreadsheet to ensure that everything at least gets looked at before release. In the week leading up to a release, we often get bombarded with DMs, mentions, Reddit feedback, voice chat discussions. While it's a relatively simple tool, it's one of the key tools that helps us sort through everything before ship date. There were so many issues to track in 0.17 that I had to rotate the spreadsheet screenshot below just to fit in the majority of them.
That wraps up another Dev Blog. Be sure to check out our Foxhole Dev Stream for more information about upcoming features. If you have any burning questions you want answered be sure to tweet them to @Matt directly on Discord or Twitter, if your question gets selected it will be answered Live on stream!
Gripping the corners of his Magic Carpet™, Adam races off into the Starry Sky.