LogIn
Survival games are pretty big right now, so we’ve decided to talk with Michael Hutchesson about the template of such projects for Unreal.
Survival games are pretty big right now, so we’ve decided to talk with Michael Hutchesson about the template of such projects for Unreal.
Introduction
Sure thing. My name is Michael Hutchesson. I’m from Adelaide, Australia and I am currently trying to make my way in the world as a developer – my end goal is to be able to freely develop the many game ideas I have stored away in my brain, but in the meantime I’m making a living by trying to work out what other developers most need, in terms of ways to fast track their own development, and create those things within the Unreal Engine. To date, I’ve released three asset packs on the Unreal Engine 4 marketplace – “Survivor Vision”, which is a kind of vision effect that can be used to highlight things in the world (think of detective vision from the Batman Arkham franchise, or the many variants of this effect), “Quest Map and Navigation System”, which makes it a lot easier for people to plug in a world map system to their game and the “Multiplayer Survival Game Template” (UE Marketplace, Gumroad), which, as the name may suggest, is a template for making multiplayer survival games!
It’s been a pretty long ride to get to the point where I am able to live off of these sales, which started back when I was a kid in school (I’m 30 now). I was hanging around after school and came across two teachers making levels for Quake. I was pretty interested straight away, and within a few weeks have acquired my first ever computer and was elbows deep in making levels and mods. Eventually, real life came along as I grew up and I had to put game design in the background for less interesting jobs, becoming a department manager at a supermarket, then assistant manager at a pizza bar, and so on. Things really changed when I met my (now) fiancée though, who encouraged me to pursue things I actually enjoyed, rather than things that I did just for money… And with her support, a little over a year ago we cut down on spending, I dropped work and jumped back into UE4 (I had dabbled with it from time to time before) and here we are. Now I’m living off that (as well as contract work here and there), and whilst I certainly could do with a bit more income, I’m on my way to being able to support development of my own projects in due time.
To date, I’ve worked on a handful of game projects as a contractor, but most of these are not yet out, and I’m not really in a place to reveal them as they aren’t my own projects. I am still pretty new on the scene though, so my name doesn’t belong in any credits on anything big… not yet anyway!
Survival Genre
Survival is hard to define. On the one hand, you have your everyday survival game which is all about being thrown into an unforgiving environment (usually wilderness or a destroyed city), trying to scrounge together the supplies you can to stave off hunger and thirst, whilst battling it out with other players, zombies, or whatever other random things the developer has thrown into the mix. On the other hand you have other games that don’t fit that mold at all – games like Minecraft, which might have a lot of those things, but definitely isn’t about surviving at it’s core. Or even games like This War of Mine, which does away with most of those things, but puts players in a 2D experience that is all about just trying to get through a series of awful events.
In my mind though, when most people are talking about survival games as a genre, we are looking to games like Day Z, Miscreated, H1Z1, Rust and Ark. Games that really put the player’s needs right up in your face and make the core gameplay loop almost a grind. Whereas traditional games are all about player power fantasies, survival games tend to be more about just trying to not die. Everything is geared towards making you fail and a good survival game, at least in my experience, tends to be more about how long you can avoid dying more than anything else.
Hunger, thirst, stamina, and a whole slew of different player stats really feed into this, and often are interrelated in interesting ways. Maybe your game has a heat mechanic, and if your players start to overheat, they get thirsty quicker. Then once they are dehydrated, that means they can’t run as far, or for as long. This then presents a situation where your player needs to move about the world to find resources to stand a chance of surviving, but their ability to do so is increasingly hindered. It can really present a lot of interesting challenges. With that in mind, I put as much of this stuff into the template I built as I could, including systems for player health, hunger, thirst, blood level, oxygen level, body and world temperature and more. I really think that, despite the onslaught of clones always hitting Steam Greenlight in this genre, there is still a LOT of space to grow in survival games.. it just takes the right team of people to find ways to make it more compelling.
To me – survival games are in the same place that MMOs were in the early 2000s. There were a couple of largely successful ones, and a lot of ones that were very similar to one another. But we hadn’t yet seen the true gems that really shook things up and broke away from the WoW style formula. Games like The Secret World and Star Wars: The Old Republic, which really moved focus away from the generic xp grind of classic RPG gameplay towards other mechanics (the complicated puzzles in The Secret World and cinematic story telling in SW:TOR being the examples I mentioned). I think that we are all waiting for that big runaway hit to come out of survival games that really turns the industry on it’s head and makes us reassess the limits of the genre.
Choosing UE4 for Survival Experience
Unreal Engine 4 is honestly a very easy-to-learn engine. I think Unreal also still has this certain following around it that really like the engine from it’s earlier days, and just having the Unreal brand associated with your game can, in some circles, make it stand out against Unity or CryEngine. It’s also free. That last one alone makes it a compelling choice for any developer I think. But there is definitely more to it.
UE4 has a great visual scripting system called Blueprints, and anyone who hasn’t checked them out already that is looking to get into the industry, or trying to pick an engine, really should take a look at these. Sure every engine tends to have some sort of answer that allows non-programming-centric team members to set up some simple logic, but blueprints are really a huge difference to other solutions to this problem. I know entire teams of developers who are 100% art-orientated, but are still able to put together well-flowing game mechanics simply because of the accessibility of blueprints. They also don’t lock out programmers, because, inevitably, there are things that require actual coding, but blueprints can be used in conjunction with traditional programming, or blueprints can be used as a sort of psuedo-code replacement allowing for fast iteration of prototypes before moving to actually writing the game proper.
A good example of how versatile they are is my own survival game template. This template is 100% written in blueprints, and realistically, you could very easily take the template, and not touch any of the gameplay logic, instead only adding in your own art assets, UI elements and so on (ie. all the art/visual/audio side of things) and pump out a huge variety of ready-to-play survival games that could be very different from each other. Honestly, while I think blueprints could benefit from little more work on Epic’s side of things, I won’t be surprised if they are the industry standard for development in the near future.
Main Systems
Aside from the player statistics management I talked about earlier, the other systems do tend to vary a lot from game to game. But as you mentioned, combat crafting and world exploration are all pretty important to the genre, and building them within UE4 really comes down to exactly how you want your system to work. Everything in game design can be done in so many different ways, and people are always coming up with new spins on the pre-established systems in place. The best thing I can advise anyone to do with trying to implement anything into a game is to take the time to think about it ahead of time – flesh it out on paper with psuedo-code, flowcharts, or even just bullet points. Think about the use case scenarios of each system and how they may be broken by players.
In terms of UE4, there’s not really anything particularly unique to developing systems like this in the engine over others. The engine does come with templates covering most of your standard game types (first person, third person, vehicle, etc.) and there is a heap of very high quality content available on the marketplace already made by members of the community to use or even just learn from. My advice to people would honestly be to plan your project out and just jump in and start working on it. Again, blueprints really encourage this because they are so quick – you can easily have a new gun up and running in minutes, and iterate on the functionality of that gun every few minutes thereafter until you have what you like. If you really want to push the project into C++ coding, rather than blueprints, then you can take the prototype you built in blueprints and use that to write your code from. It’s honestly so incredibly simple – I wish I’d had tools like this when I was a kid!
Environments
Honestly, I think that environment design is somewhat of a lost art in survival games now. Most survival games rely very heavily on their players to do the work of making the game interesting, which isn’t necessarily a bad thing, but as someone who honestly enjoys playing games, even survival games, as a single-player experience, or at most with a small group of friends, I really wish that more developers would spend the time on making more interesting world designs. I also think that this might be one of those areas that could really mix things up a lot in the genre.
In most survival games – the world that players occupy is pretty straight forward. You might have a few different biomes or themes running through parts of it, but generally it will stick to fairly realistic conventions. You have a world, often surrounded by water or some other impenetrable barrier, a densely packed area with low visibility – either a thick forest, or dense city, a more open area – usually plains or wide streets, and a few other variations in between the two. There is nothing fundamentally wrong here at all, and for the most part a world that complies with these designs will work well in a survival game. But that doesn’t mean it can’t be mixed up in interesting ways.
I worked with a team on a game that, sadly is now cancelled, were planning on having dynamic flooding in their survival game. The flooding would force players to move to higher grounds as the waters rose, or bunker down into underground tunnels that were designed to provide refuge during the floods. I thought it was a great idea, and it presented a very unique gameplay element to an otherwise fairly standard survival game.
Minecraft is, of course, another great example with world design. Whilst not strictly a survival game, the world generation in Minecraft has so many interesting things – villages, caves, mines, etc. that all give you a reason to explore beyond just looking for resources.
I think that there’s a lot of opportunity being missed by developers who just want to make “the next Rust”, or “Day Z but with….” game. Those games can be great, don’t get me wrong – but I think we need more games like Subnautica, GRAV, and so on that really try to mix things up and combine element often absent from the genre.
Content
It’s very important in game development not to overextend yourself. This is one area that we see a lot of teams have issue with, and it often leads to games being cancelled or rushed out at the last minute with bugs and missing features. If you are a single person doing all the programming, art, marketing and such for your game, you can’t be planning to make something that realistically can compete with a game by a huge team, nor do you need to. In my mind, the best approach is to pick something that you know you want to be a defining characteristic of the game. Maybe you want to make a melee-heavy zombie survival game where your players have to think very carefully about every single combat attack they make. That’s great – forget all about the level design, voice acting, etc. and focus entirely on getting that melee system down exactly how you want it. Is the main focus of your game about how an astronaut from Earth just crashed on Mars and has to survive by growing potatoes? Great. Focus on getting the game feeling like you are on Mars before you focus on getting that potato farm to a point where Matt Daemon would be proud of how beautiful it looks.
It’s also important to work out early how you want to extend things, or at least have an idea of how you might add in new functionality as you go. It’s no good building a full survival game that is a singleplayer experience, then deciding you actually want it to be multiplayer – it’s not as easy as flicking a switch (trust me, I know – my Survival Game Template was originally single player only… took me the better part of 6 months and completely rewriting the entire thing from scratch to get it to a point where it was multiplayer ready!). Likewise, having a beautifully rendered apocalyptic world, complete with corpse-munchers shambling about, amazing atmospheric soundscapes and perfectly executed weather effects won’t do much if your core gameplay loop is awful and you haven’t allowed for a way to iterate on it.
I’m not suggesting that the artistic side of things should be secondary – indeed there are plenty of games where the art style, or voice acting delivery alone make for amazing experiences. It’s just incredibly important to work out what your game is about, get that right and move from there.
As for adapting assets to the freedom players have… always realize that you can never, ever predict everything that players are going to do. You could spend your entire life trying to think of every single scenario a player may come to in the game, and you still won’t get even close to covering them all. Players will always do crazy things that you never even considered. That’s actually one of the best things in the survival genre – the emergent gameplay that comes from sandbox freedom. Embrace it, and plan to find creative ways to control it post-launch.
Multiplayer
Making things multiplayer really complicates things. Even something as simple as shooting a gun has to be completely re-worked to work properly in a networked environment. And it’s very easy to do it in a less-optimal way. Something that a lot of people don’t seem to think about is the sheer amount of data that is required for a survival game. You have every players’ name and location, their inventory items, their stats (health, hunger, thirst, etc.), anything they have built/own in-game, and a heap more. It’s a lot to cover! This means that it is insanely important to make sure you have done things as optimally as possible, which sadly there’s not set of magic rules to work by that I’ve found yet – you just have to try and think of every bit of data you can save and go for it.
An example of this is the inventory system in my template. Inventories are very complicated – you need to be working with quite large amounts of data (how much does this item weigh, what does it do, what information do we show the player in the UI, etc.) and it’s very easy to have this data build up to levels that bring even the best networks to their knees when you have a few players running around with large item counts in their backpack. In a singleplayer game, you can be handling this data all the time – it’s just text and binary data for the most part, so it’s very low level for your processor and memory to handle. But when you are working online, you need to find a way to minimize this all. As such, I built all of my inventory around a data table system where designers can make all their weapons, consumables, armor items, books, etc. in a single spreadsheet, and rather than needing to know every single bit of info on each item, all you need is the name of that item’s row on the data table. This has the added bonus of future proofing the network optimization of the inventory system – want a new item? That’s easy, just add a row to the data table. Want to add feature x to weapons? Easy – add another variable to your data table. It doesn’t impact the network bandwidth at all. It’s all about finding these little shortcuts wherever you can and making sure they are reliable and easy to expand upon.
Balance
It’s not going to be the most popular answer – but testing is really all that you can do here. Get as many people to play your game as often as you can. Get your friends involved asap, but make sure they know it’s early and that they can’t go showing everyone. As much as we might all hate the early access systems in place on platforms like Steam, they really suit genres like survival games. There’s usually no narrative to spoil, and most of the game mechanics come down to simply interacting with the various systems the developer made work with other systems. As I said above, be prepared for players to do crazy things and try to find creative ways to work with that.
Time Costs
Something that a growing portion of game designers don’t seem to understand is that game design now is easier than it’s ever been. You can jump online, get a heap of tools and content without paying a dollar, and have something playable up and running in minutes. That’s great! But it doesn’t mean that designing something like a complicated multiplayer survival game is something that three guys can do over a couple of weekends. Not usually anyway (there are exceptions to every rule).
Given the inherent complexity of a game built upon many, many systems that all interrelate, such as is present in survival games, you need to put a huge amount of time into just testing to make sure that something you’ve done in one system doesn’t completely break another system just because you didn’t account of that change in the maths. There’s a bit of rule that I’ve seen a number of developers quote – when allocating time for game design, work out how long each task will take, then triple it. That’s the minimum you want to start from. This is definitely something that rings true in my experience.
As for cutting down on costs and time – again systems such as Early Access on Steam are perfect for this genre. But I do think it’s very important to make sure that you have something already decent before you release publicly. A lot of games that launch in beta stages really have a lot of trouble ever rising above that first launch, so if they didn’t start off in a good space in the public eye, they never manage to shake those shackles. Personally, I don’t touch games in early access unless the developers have made it pretty clear that the majority of the gameplay systems and mechanics are in place, but the artwork and balancing is what is still needed. This can often still be a huge amount of work still required until the game is “finished”, but at least work done in the meantime won’t become useless when another feature down the line is implemented that wasn’t planned.
Advice
Plan. Plan things out before you do them. Plan to be stuck and angry at things not working. Plan to be surprised at what your players do if you do manage to get that far. And plan for everything you planned to go differently. I cannot stress how important it is to be able to adapt to things when they don’t go how you expected. Make use of pre-existing knowledge, assets and products (such as my template). Even if it is just for the purpose of testing and prototyping different id eas, you can always go back to it for reference and see how others have done things. And above all, be honest with your audience. Don’t promise features and functions you can’t deliver, don’t announce things before you are sure, and if you are going to claim that you want input from your player base, make sure you take that input on at least in an advisory capacity. Your players are the most important resource you have – so treat them with appropriate respect, yes even that one guy!