This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
After watching the way humans work for far too long, a team of robots are looking to start their own world on a distant planet, in an attempt to be human, in The Colonists.
Inspired by the Settlers games and the Anno series, The Colonists give you a team of robots to control and become human. Through building various paths, roads, and structures, you can start to make your own bit of land for your colony - all which will work towards being self-sustaining.
These robots tend to follow the best paths automatically, fulfilling tasks, moving resources, and generally trying to be more human than robot. Looking for peace and to become more like the humans they use to live with, you will need to help these robots follow their dreams.
I got the chance to interview Richard Wallis, the developer behind The Colonists via email about creating and designing this cute yet challenging game.
UI is one of the most important elements for any strategy game and like most, The Colonists has a lot of number crunching and statistics driving the game behind the scenes.
Figuring out what to show the player, and how to show it, is a tricky balancing act as you want important information to be easily visible or accessible to players but you don’t want to overwhelm them, especially as it’s generally quite a laid-back game.
One principle was to try and minimize the information, particularly numbers, that is on the screen by default. The game is designed so a lot of what is happening can be read visually within the game world in that you can physically see each resource moving about: you can watch a Lumberbot chop down a particular tree and you can see an angry carrybot emoting if their road is being blocked by too much traffic.
Once you’ve noticed an issue that you might want to dig into more, then there are various panels that you can open and there are various numbers and graphs telling you such things as whether you’re making a surplus of a particular resource, how productive a building is, or what route a resource is taking across your colony. But again, these panels are designed not to intrude too much and can be kept open as you continue to play.
One of the core concepts of the game was to have all the resources one-to-one, as in they all take up the same physical space and that you could always see where every resource is all of the time, whether it’s being carried by a bot, it’s on a boat or train, or in storage.
And the same applies to the robots: each of their jobs is focused on either moving, collecting or consuming these resources and taken on their own, each robot’s job is quite simple. Carrybots just take one resource from one road post to the other. Stackbots follow paths and only bring in and drop off resources. Lumberbots just go and chop down the nearest tree. If you watch any bot for a minute, it’s quite easy to follow what each one is up to.
There are two types of main routes in the game: roads and paths. Roads are connections between two road posts. Road posts act as temporary storage nodes and can hold four resources. Each road has a carrybot who moves resources between these road posts as required and this kind of mechanic will be familiar to anyone who played the early Settlers games.
The second type is the path, which connects a building to a road. Each building has its own stackbot who will use a path to collect incoming resources from road posts and drop off resources that the building has produced. This path system give you two extra benefits when laying out your colony.
Firstly it gives you more freedom and allows more creativity in your town planning and secondly, if two buildings share the same path, they will be able to deliver resources to each other directly, rather than having to collect from a road post. This gives you some really interesting optimization options where you can group shared economic buildings together to reduce traffic on your road network.
But there is a fine balance to be had as if your interconnected paths are too long, the productivity of your buildings will suffer as the stackbots will have too far to travel and building production will back up.
The Energy system was one mechanic which ended up changing several times during development. It began as an abstract global number which was automatically distributed across all the production buildings in your colony.
This didn’t scale up particularly well, so we went through a few other stages, including a happiness system for the robots and delineated ages which you had to progress through. Ultimately we went with Energy being a physical resource like everything else and limiting it to only being required by certain collection buildings and it ended up working pretty well. In hindsight, something can seem quite obvious, but it often takes a journey to reach that point.
Another mechanic which went through several iterations was the road and pathing system. We tried various combinations of limited and unlimited road lengths but sometimes you just have a mechanic where, whichever way yo go, there is always a trade-off between flexibility, ease of use and integrity of the mechanics. Eventually you just have to go with your own instinct on the best balance.
It’s definitely useful as a way to gather a consensus on the types of features players might like to see added. For example co-operative multiplayer is much more requested than competitive multiplayer and that can inform the direction you take when working on future content.
It also acts a bit of a roadmap in that as a developer you can indicate that you are actively adding new features and players get to see which ones are being worked on next and know there are going to be updates in the future.
You get a whole range of ideas coming in. Many of them will be things you’re already considering or have on an existing wish list, some others will be really cool but would just take too much time to implement, while some just might not fit in mechanically or have unintended design consequences. But again, it’s a handy way to formalize and collate player feedback.
We had several private beta rounds during development and, especially as a solo developer with a game of this scale, getting fresh feedback during this time was incredibly useful and I’m grateful to every single tester who sent in bug reports and kept playing new builds of the game.
But you also have to be quite judicious when looking at player feedback. You need to remember to be super objective when filtering what people are saying, and determining the root cause of their issue and whether it’s valid or not.
For example, if a player is angry about their roads getting clogged up, is it a symptom of unfinished UI or the lack of a polished tutorial or whether it is actually an underlying issue with the game. Ian from Mode 7, the game’s publisher, had a good take on how to parse feedback: http://www.mode7games.com/blog/2013/11/09/indie-advice-how-to-respond-to-beta-feedback/
One tip I would give is to get gameplay video from testers where possible, especially in early builds. Watching how a player behaves and interacts with the game can often give you different, and often much earlier, pointers compared to the conclusions players draw themselves.
We’re still in the beta phase of the map editor as we test and refine the features but there’ll be a straightforward way to save and share maps and we’ll be leveraging the Steam Workshop system so players have a way to player and rate everyone’s maps.
Map editors are always a feature that only a minority of players will use but, if you’re like me, you can spend a lot time in them creating scenarios and setting your own specific challenges.
So once the map editor goes live I’m hoping there will be a subset of players who are going to really get into sculpting the hills, seas and cliffs, and figuring out where to strategically place resources around their maps, and that other people are going to enjoy playing them and the different optimization puzzles that they’ll create.
One of the aims from the start was to have enough depth to the systems that players who like to dig deep into a game can really get into micro-optimizing their transport routes and production chains and it’s been great to see all the different colony layouts people end up with and the competition on the time-based leaderboards.
Ultimately though I always wanted the game to have a peaceful and relaxing atmosphere, where you can play at your own pace and I think a lot of players simply enjoy watching the little robots go about their business.
It’s always fun to see reactions when players realize they can click on an idle carrybot and they give you a little wave! Huge credit goes to the artist, Joe Sutton, who did an awesome job in creating an endearing set of robots and a lovely environment for them to inhabit and also to Nick Dymond, who created some awesome chilled out music and cute robot chatter to match the aesthetic.