The problem with Arena First Person Shooters in 2018

(And a non-first person solution)

Six or so months ago I had an idea. I had been playing the old school first person shooter Unreal Tournament quite a bit in the evenings (read: a disturbing and shameful amount for a manchild of my age), as well as learning how to create levels and modifications for the game.

In the modern era, Unreal Tournament has a problem: it’s almost prohibitive. You need a keyboard and mouse to play, and a decent computer, and on top of that, a spare year or two to build your skills so you can compete with those who have been playing for decades. Something I learned the hard way.

Some of the fun of Unreal Tournament is undeniably the first person action experience, but other than that it’s mostly the mix of using reflexes in the moment, while strategising over time. So you’re playing on two levels. What if those fun elements were translated into a format you could play from the couch? Or the train?

This question was answered by Frag Forest, which is (will be) a 2d translation and simplification of the area first person shooter (“Frag” is the term for scoring a point by killing a player AFPS games). I started the design document to work through the concept, with the input of a long-term competitive Unreal Tournament player. We reduced the meta game to it’s bare essentials and a settled on theme that clicked (that’s the “forest” part).

I sat on it for six months while I learned more about Unreal Engine. I had just finished my jetpack modification, which raised my confidence a bit, and a few weeks opened up during which I could dive right into Frag Forest. It has been a mad three weeks. I didn’t know what I was really doing when I started out, and the learning process has been thrilling and frustrating. I’m pleased to say I’ve got a lot to show for it though.

The footage you see above is some earlier testing footage. The game is in a bit of a different state currently, but it’s the same basic idea. A more detailed video is forthcoming. At this point I’m working on setting up easier network games, and when this happens, I’ll post the Alpha version.

Design Methods

Because we had a clear problem to solve, and randomly decided on a cute theme, we had clear design direction from the beginning. After having discussed the possibilities at length and created our game design document, we were basically ready to make a game.

Of course, once work actually started, a few things changed. Although I’m pleasantly surprised how much as made it through from the design document, weapons mechanics are different, in particular the slingshot.

Following conventions from mixed genres

We had also not really considered the interface in our document, which is a vitally important part of any game as it helps the players understand their situation, and hence react to the best of their ability. Our idea draws on many different genres, so we are taking standards from the most appropriate one for the given consideration, translating where necessary. For example, in console fighting games and platform games, health is often represented by the colour red (blood/heart), however in first person shooters it is often a medical blue. We went with red because it best represents health in the destination format — a console fighter.

But unlike many console fighters, taking from the arena first person shooter genre, a player isn’t shown their opponent’s health. Guessing what kind of situation the other player is in is part of the game. This means the typical top-screen layout for each player’s health bar won’t work. Because the gameplay most relates to AFPS games, the information presented onscreen, and the layout, is similar. A very important element is the clock, which allows players to time the respawning of items on the map, so this is top and centre, winged by the scores and player names. Health, armour and ammunition values and a weapon bar sit along the bottom edge. These also roughly follow AFPS conventions.

Visual style

The theme demands furry creatures jumping through atmospheric woods, but for the Alpha release, which is really just to drum up interest, this is unachievable as animating the characters and drawing the sprites is as large a task as coding the game.

But instead of releasing something rough, we’ve opted to stick with a minimal flat design, which makes the game feel designed, even in its’ unfinished state. This means we aren’t including elements for reasons other than gameplay, aside from making things as aesthetically pleasing as we can through colour and basic geometric shapes.

A few things just fell into place. Seeing which way a 2d character is facing would usually be easy even if roughly drawn. But what about our featureless blue ball? I added an arrow to the circle in oder to signify direction, and incidentally it began to resemble a mouse. Together with a tail it really creates a character. In oder to visualise speed (or rather potential speed), we added two rotating circles as feet, which topped it off.

Scale and balance

One of the hardest things to get right in a game is the scale, and that’s because almost everything else in the game relates to it. How the weapons work, how the character moves, how the health and armor work, these things are directly related to the map.

We started by getting fun movement in place. This really helped design the weapons and their damage values. We tested the game on one level, and tweaked the level as we tweaked the weapons and movement going. With the movement as the basis, everything gradually took form.

I think it’s good to change as little as possible between tests, to really see the changes in isolation. We also noticed that we might change one thing, then change others in reaction, and end up in basically the same place (like increasing the size of the map, then increasing the speed of travel, two changes which worked to weaken weapons and make the game play out longer). I guess before making changes, you have to spell out the desired result for yourself.

And of course sometimes you just can’t tell what will happen, and you try stuff. Plenty of testing and honest feedback is required, which is the essence of any good experience design really.