Returning to Birmingham New Street station after a few years away feels like being a grizzled old detective finding a murder with the hallmark of a serial killer you thought you put away long ago. It’s a sense of growing despair and concern, and a particular building horror that the dire situation you find yourself in is nobody’s fault but your own. In this case, however, I drew into the familiar cellar-like platforms with enthusiasm, because I was attending Insomnia as an exhibitor, working with other members of Polyfox to show off LocoMotion! Continue reading “LocoMo-Con – Insomnia 2018”
Yesterday – or a few days ago, depending on how long I spend typing this up – I wrote about Flow in first-person games, and about using the shape of the level to guide and control how players move. This post is about how I used those principles when designing levels for Locomotion, which you may notice is not a first-person game.
Recently I’ve been playing a lot of Team Fortress 2 custom maps, and thinking about the Flow of them – with a capital F because it’s a specific concept. There’s a lot of tricks that level designers use to guide players around, but one that doesn’t get talked about much is the “flow” of the level – how a blank layout by itself can direct movement. I wanted to write a guide on how to use that – this is pretty heavily TF2-focussed because I’m also using it as a tutorial at tf2maps.net, but I’ve tried to keep it reasonably applicable to other first-person games.
Hello! You’re probably here because I asked you to download and try out Tactus. The elevator pitch for that is: it’s a pac-man-alike Android mobile game with three different control schemes. I want as many people as possible to download it, play it – it should only take about ten minutes- and allow it to upload some tracking data that I can analyse for my dissertation. A whole blog post about the game is below, if you scroll down, but if you’re not interested in the details you can just click here to download, install the APK as usual, (you’ll need to allow apps from “unknown sources”) and play on. Two things to note:
- The legal details of what I want the data for and why are listed at the start of the app. Legally, you have to agree to them to play it. There’s nothing personally identifiable, but I have to get your permission as if I were sticking electrodes to your head or something.
- If you’re under eighteen, I can’t use your data. Sorry! It’s a legal research thing – I would need your parents permission, and there’s no real way to verify that online. Play the game if you want, but don’t click “Upload” when prompted.
That’s all you need to know if you just want to play – have fun! Otherwise, stick around, read the rest of the post, have a drink. Take the weight off your feet. Continue reading “Tactus: My Dissertation Game”
I finished my painting project the other week and packed my painting stuff away, so I suddenly became in desperate need of things to do instead of working. I started making a videogame about space.
The elevator pitch is Stellaris meets Mini Metro meets Cookie Clicker. Planets appear/are discovered, each with different amounts of resources and habitability, and you can build buildings on those planets to exploit those resources, and setup supply lines between planets to share those resources around. The goal of the game is to maximise your population, which means getting enough resources to high-habitability planets where your cities are. At the moment it looks like this:
I’ve already discussed my general thought processes for Locomotion levels, so in this post I want to do something a little different: today I’m working on a whole level from scratch, and I’m going to go through the whole planning process. Won’t that be fun? Don’t answer that, of course it will be.
The last post i’ll make about Neon Arena for the present: my thinking on the level design.
In some ways I can just rip off Mirror’s Edge etc for Neon Arena, but the difference is in the name: it’s an Arena. Mirror’s Edge is fundamentally linear: not a direct narrow path, but with a few alternate routes that can be taken: on a very basic level, Mirror’s Edge levels look like this:
(Catalyst is an open-world game: on a macroscale you can go anywhere, but honestly, the minute-to-minute gameplay looks exactly like the above. The only difference is that most routes now need to be possible to traverse in both directions.) Continue reading “Neon Arena: Level Design”
This post is mostly about the design of the Drone AI, but there’s a fairly big contextual section first: that ends at the horizontal line break.
Neon Arena isn’t just a parkour game: I also wanted the player to be attacked, or have some light combat element. My thoughts on this went as such:
- Mirror’s Edge just locks you in a room with it’s enemies until you’ve beaten all of them. This sucks.
- Mirror’s Edge: Catalyst has enemies constantly jumping out just in front of you, and if you run away it spawns a helicopter to chase you. This doesn’t suck, but the helicopter chases always felt a bit abstract, just asking you to run out of an area on the minimap.
- What would be best would be AI enemies that could chase you. However, programming AI to use all the clever walljumps etc that the players can do sounds hard (Even Mirror’s Edge’s jumpy-chasey enemies do only minimal actions).
- So, the solution: flying drones.
For the group project segment of our degree, we’re building a train puzzle game called Locomotion. I’m one of the Level Designers, and in the later stages of development I started to make notes on the process. This, then, is another post to clear those up and give an idea of my thought processes, in my own (thankfully) inimitable style.
Firstly a quick summary of Locomotion: players control a train on a track, which they can drive forwards and backwards, with the goal of collecting treasure and reaching the exit of each level – think “Lara Croft: Go” or “Toad’s Treasure Tracks.” Puzzles are built with interactive elements – lifts, wagons, t-junctions, turntables – some of which are activated manually, some by the train passing switches on the track.
Teaching the player
I used to make maps for the Portal games, and be pretty active in the community: i’ve spent far more time working with Team Fortress 2, but Portal was where I learnt my craft. Valve had a simple set of rules for teaching players how to use their mechanics, a three-step process: show the player a mechanic, allow the player to use it, and then reuse it in concert with other mechanics. This was my bible when developing those levels which introduced new puzzle elements: show, try, layer.
This level, for example, introduces the wagons and pressure pads: it needs to show a few things to players. How do they push wagons? How do they connect to wagons? How do pressure pads work? So the first thing that I do with the player is lock them in a confined section of track. They can go left and get stuck, or right (where an enticing reward sits) and push the wagon. The wagon goes onto the pressure pad – which lowers the lift. Players have learned how to push wagons and press pressure pads without a conscious thought or a written instruction. When we tested this level, it worked perfectly – not a single playtester got stuck here.
The later section of the level requires thought. Players can use an automatic switch to lift the second wagon up to the top, and it’s a little more complex to get the wagon onto the button – you can either push it all the way around the upper loop(and through some T-junctions) or attach to it and pull it. Whichever way they do it, there’s more freedom, more scope to make mistakes – but once the second wagon is on the second pressure plate, the route to the exit is clear. Once again, almost all players figured it out easily: the only sticking point was connecting the wagon to the train, and even without instructions a UI hint allowed perhaps three in four players to do that too.
The next level takes the wagon mechanics and combines them with the turntables, putting a new restriction on where wagons can be moved. I shan’t go through in detail, but the pattern remains: players see the turntables and how they can work, use them, and then combine them with the wagon.
This pattern was repeated over and over again, one after another for each mechanic: put the player in a position where they have to use the mechanic, then layer in successively more complex uses, restrictions, and tricks. For our first main playtest, we left in almost none of the planned instructions: I personally wanted to use as few written instructions as possible, and suggested that we run a playtest without any, in order to track which ones were actually needed. In the end only a few were – players caught on to every element without instructions easily, the only sticking points being the keyboard controls.
As suggested by Ghost Town Games (our mentors and patrons), I wrote a “story” for each level – how players were expected to use it, what mistakes they should make each time, and how complicated a solution it should be. An example story below:
Once again the player starts trapped, here right next to a pressure pad: the obvious thing to do is to look around for a wagon, and find it at the other side of the turntables. Perhaps the player will immediately realise – or perhaps they will need to try and fail – that the turntables only operate with a train on, meaning that all three turntables must be lined up to get the wagon and go. Since you can only cross onto a turntable in the right orientation, the next job is to identify – through thought, or trial and error – what order to use the turntables in (the correct order is first, second, third.) Once this is done, the wagon can be taken to the pressure plate and the player can finish the level.
I found this to be a great way of laying out my thoughts, a really clear narrative from a player perspective.
Early on in design, I chose a set of design principles for myself, and to distribute if other people wanted to make levels.
- No bigger than 10×10 unless necessary, and roughly square
Keep levels small and square-ish: not only is this much easier to see with the camera, but it fits the “small and sweet” aesthetic better.
Don’t waste the player’s time or space, but consider reshaping long and thin levels.
Unless there’s a good reason, don’t spread over more than a few height levels.
- As clear as possible
Avoid elevators going down into the ground, avoid “tunnels” if possible.
Players don’t need to see all level functions from any one point, but it should be possible to get an “overview” or general idea of the layout from at least one location.
Make sure that from key angles, scenery pieces don’t obstruct puzzle elements.
- A nod to verisimilitude
Try to avoid completely discarding realistic shapes of buildings and ground, but clarity is far more important.
Sketching out Mountains/chasms/bluffs etc will combine well with the cuboid aesthetic to sell the environments as more than merely puzzles.
- Space tracks
Try and space out tracks when possible, use straight track pieces to spread out puzzle elements.
- Not too much flat space
Conversely to the last, don’t have too many large empty plateaus. Use scenery props to break up these areas.
Remember that all are mandatory: players will have to collect all before completing the level.
Use collectibles to guide players towards solutions – or to guide them away to make simple puzzles seem more complex.
These changed a little over time: we rebuilt the camera, allowing levels to extend to 15×15 and still be visible, and as of writing we’re debating whether collectibles should be optional. (I think they should – we can throw in all sorts of neat tricks to get collectibles that might not support whole levels – or that might be too lateral (or, in another word, too bullshit) to hang a whole level on. Being optional doesn’t stop us from using them to lure players around.)
I hope this has given you an idea of what goes into the level design! Locomotion will be showcased at the Norwich Gaming Festival in June 2017, and we’re hoping for a release soon after that.
This is one of a few blog posts adapted from my Dissertation project about Rotatris, a tetris-like game I made in Swift and SpriteKit. In Rotatris, players try to build “shells” of squares around a central rotating block. You can read my full written dissertation here.
This post is, similar to the last, an excerpt from my dissertation designed to give some idea of how I deal with challenges and design decisions. It’s a bit dry, I’m afraid, since it’s all in the fancy academic format designed to make it dry and unentertaining.