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
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.
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.
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.
These are some of the key algorithms for the game – it should give you an idea of my thought process when developing a game. My original dissertation has a few more, but i’ve cherry-picked some cool ones here.
Mirrors Edge, and it’s sequel, are some of the most natural successors to the Half-Life series. Given that Half-Life is held up as perfection in shooter design, and Mirrors Edge is a) often not considered very good and b) not even a shooter, this is perhaps a contentious statement, but it’s one that makes more sense to me as I think about it.
I’ve been replaying the Mirror’s Edge series, you see: for my next coursework project i’m building a similar free-running game, and there’s a lot to understand in how and why Mirror’s Edge does what it does. As such, apologies if this post is a bit of a ramble, but I wanted to talk about the design and level design of Mirror’s Edge, if only for the purposes of marshalling my own thoughts. Continue reading
For the purposes of this article, I’ve been playing a lot of Symmetra, Overwatch’s least-played character. I’ve come to a couple of important conclusions about her.
- She isn’t fun to play.
- She isn’t competitively effective.
I hope i’m not leaving anyone behind when I say that gameplay should be at least one of those things.