So some time ago, I released the Survival Game Template to the Unreal Engine 4 marketplace. At another point not too long after, I made the promise that I would rewrite the entire thing for multi player. Damn that was a bad promise to make XD
Please note – this post will cover more or less the same content discussed in the two following YouTube videos, but with much less rambling and a bit more focus. Choose how you would like to receive this information:
So to begin with – the multi player rewrite is not JUST taking the same system and making it work with multiple players. It’s a number of things, including a new set of features (all the ones from the single player version but with a lot more), a more optimised and well written set of logic, a more modular approach, and yes, multi player support.
The list of intended features to be released are as follows:
- A full set of player-based survival mechanics
- Blood Level
- Body Temperature
- A full set of world-based survival mechanics
- Dynamic Day/Night Cycle
- World Temperature
- RNG Loot Generation
- World Events (Both Cyclic and One-Off)
- Fully functional inventory system
- Icon-based drag and drop interface
- Support for containers/chests
- Item Stacking and splitting
- Optional hotbar
- Movement mechanics
- Falling damage
- Full Save System
- Debugging Tools
- Versatile Player HUD
- Multiplayer Support
- Server Session Browser
- Example pickups
- Example weapons
- Example AI
- Item Interaction
*Please note: Building may not appear in the initial publicly available version of the multi player rewrite and may appear in a later update.
As you can see, it’s quite a big list of features to cram into a single product (if you want more detail on each individual item, please feel free to check out the progression trello for information). As such it has taken quite some time to get it all up and running, particularly given that each system quite often interacts with several other systems and these all need to be tested and adjusted.
Let’s begin with the player controller/character…
The player has been set up in such a way that designers can switch between first person, third person with the camera directly behind, or a third person “over the shoulder” view, much like in games like Gears of War (camera distance from player in both third person modes is configurable). The designer has the ability to toggle between these on the go, allow the player to toggle between them, and even things such as switching the view from left and right shoulders. The player has the ability to “zoom in” to aim (think aiming down iron sights in any popular third person shooter). There is also a built-in death camera mode, where the camera slowly moves backwards away from the player’s body for a short moment before the player can respawn. Cadavers’ have a limited configurable lifespan. Also, the character can be set up in such a way that the head turns to look where the player is looking, if so desired.
Attached to the controller is a number of component blueprints. Each of these house the logic for each particular system in the survival game template. Unlike the single player release, where all logic was placed inside of one blueprint with separate graphs for each mechanic, the multi player release will be far more modular, as if you do not desire to have a system, you can simply not include the component in the controller. Each system can be disabled with a check box for the testing period if so desired (no need to worry about food and water whilst just trying to explore you world for bugs). Each component also has its own set of settings to manipulate the way in which it operates. Below is an outlining of each of the complete systems as it stands at this point in time, with some detail as to the options they have:
Time Of Day Component
This component is used to manipulate the game world’s day night cycle. Aside from the expected settings, such as how long a full day/night cycle should take, what time of the day it should start, etc. there are a number of other settings pertaining to how it acts over a network. For instance, designers are able to specify how often clients should synchronise with the server.
Now you might think that you want the client to always be 100% in sync with the server. This is, of course, ideal. But when designing for multiplayer it’s important to take bandwidth into consideration. Sending the time, placement of the sun, and so on from the server to each individual player every single update, creates a lot of extra network traffic, which will result in increased latency. Imagine sending all that data to say 60 players in a game session!
As such, what I have set up is a mirroring system, where the day/night cycle is run on both client and server, and the client simply ‘checks-in’ with the server every so often. By default, this is once every 10 seconds. What this means is that once every 10 seconds (again – default setting – can be changed), the client checks with the server to see what time it is on the server. If the server’s game time is different to the client, then the client adjusts to the server. This means the server is still in control, but we don’t need to send all that data every update.
One important feature that has been carried over from the single player version of the template is the option to use the template’s day night cycle, but with a custom sky sphere – meaning you can plug-in assets such as the amazing Ultra Dynamic Sky system into the template. A tutorial on how to do this will come out shortly after the multi player release.
Finally, there are also options pertaining to displaying the game time to the player, enabling designers to show a clock using days and hours, with optional minutes and also with an option to show in 24 hour time.
All games need a HUD. Or do they? You can completely disable this too if you like… But assuming you do want to use a HUD, this component contains an on-screen compass, the interactive actor outline system (allowing you to highlight interactive actors, such as pickups, containers, doors, etc. to the player) as well as a couple of styles of presenting player stats visually for game play.
This component manages the, you guessed it, health system! This is a pretty straight forward setup, allowing you to set the maximum health number, turn on and off falling damage, and manipulate a few settings such as the safe fall distance, how much falling damage hurts the player, and so on.
Stamina is another straight forward mechanic. This component gives you the option to define what the player’s maximum stamina value can be, how many times a second their stamina bar (on the HUD) should update, as well as manage the stamina recovery. Recovery of stamina is handled in a number of ways in survival games, and I’ve tried to accommodate all the versions.
To start with, you can control how fast the recovery is. You can also set a delay, so that the player has to stop consuming stamina for x many seconds before recovery begins. Think of a player sprinting from a horde of zombies. They run around the corner, hide and stop to recover for a second. Their stamina will not begin to recover immediately (unless you set the delay to 0), but instead they will have to not consume any stamina (ie. no sprinting, jumping, etc.) for the delay period. To further enhance this, you can also set up a slower recovery rate if the player is moving (walking does not consume stamina by default, but is still movement) so that the system rewards players for placing themselves in more risky scenarios, such as not moving entirely. This lower rate is also definable here.
The stock-standard UE4 movement set is pretty lacklustre, and survival games have a few common movement abilities, so I’ve included some of them too. In here you can define what speed the player walks and sprints at, how high they can jump, if they can crouch and prone, and the speeds they move in those states. There are a few other settings as well, but that’s the bulk of it.
At this point in time there are no working animations in the system for the different movement states (such as crouching with/without a weapon). I am currently trying to source some of these from somewhere.
Power is used by tools, such as flashlights and generators. So I’ve included a system that gives the player a power stat. Along with the expected settings (maximum value, update frequency, etc.) designers can also divide the power stat bar into multiple segments. These segments work a bit like batteries, and can even be set to recharge on their own up to the currently partially used battery. As an example – a player has a flashlight on. Their power bar is divided into 4 segments – 25% each. They use 30% of their total power. This means the fourth segment is entirely drained, but the third one still has most of it. The system can recover power back up to the third full segment and leave the fourth one empty. This system can, of course, be disabled as well.
A sibling mechanic to the power component in most cases (though the two can be used without each other, or disconnected from each other mechanically), this component gives the player a flashlight to use in the game. Players will be able to use flashlights in two ways with this component – by hand or attached to their body.
Attached to their body, the flashlight will illuminate the way ahead. This helps in those sticky situations where you are outrunning zombies in the middle of the night, but need to have your two-handed rifle at the ready. Of course, you wont be able to have much control over where the light is pointing, and you will see the light jumping about as you run. For more specific careful peering into the darkness, you might want to hold that light instead.
Settings for this component allow designers to disable the ability to attach flashlights to the body, set settings on the light itself, change the amount of power it drains, and also configure a low-power flicker effect that signifies to the player they are low on juice.
Thirst and Hunger Components
Whilst this is actually two separate components, mechanically they are identical, just attached to different variables. Both have a level that slowly decreases based on the settings you give in the component settings. They both recover with use of items. Thirst will also go down quicker in hotter temperatures. Both systems have a damage amount that, when you run out of food or water, will begin to slowly eat away at your health. Pretty standard stuff.
There are a couple of components attached for use of the inventory system. One is a manager, that deals with all the logic, the other is an actual inventory. The inventory has no real settings, and functions merely as a container for runtime data. Meanwhile the inventory manager has a number of settings that can be used to tweak your inventory.
Primarily, most settings pertain to the player’s ability to carry a certain amount of weight in their inventory. Along with enabling/disabling weight limits, you can set how much the limit is, and control what happens when this limit is met. Can the player still pick things up but cannot move very fast (such as in games like The Elder Scrolls) or will the game simply not allow the player to exceed their weight limit?
Separate from the components, there is also the default Inventory UI. This is intended to be the basis for your own UI and you are encouraged to change this to suit your needs, but it is set up to be entirely functional as is. Players are able to drag and drop items in the inventory to change their ordering, stack items, drop or destroy items, and use/equip items. Likewise, the mechanics for interacting with chests/containers are present and all tie in to this inventory system in a logical manner.
Inventory Data, which was controlled via loose struct blueprints in the single player release, is now entered in via Unreal Engine’s data table system. This also means you can, if you want, build the inventory data in an external system like Microsoft Excel, for all you database party-goers out there. Whilst this may sound like it is going to be more annoying to do, due to UE4’s interface, it effectively looks the same. But the payoff for this change is massive.
In the single player version, every time the player picked up an item, dropped an item, etc. the engine had to process every piece of information attached to that pickup. That’s fine for an offline game, but in a multi player game where you will have several, potentially a lot more than that even, players all manipulating this data, this increased network traffic would inevitably lead to increased latency. Now, using data tables, all we need to send is a few characters associated with each pickup. The engine then pulls the associated data from the data table row. Easy!
By default, there will be systems and mechanics in place for the following item types that have already been accommodated for…
- Bags (to increase inventory size)
- Consumables (health, food, water, etc.)
- Crafting Resources
- Keys (for locked doors and chests)
- Weapons (melee and firearms)
We even have some awesome models that were made by another member of the UE4 community who has kindly said we can use them. These include a shotgun, machine gun, pistol, the above pictured flashlight, and a sledge-hammer!
Those who follow my work will have seen another system I released not too long ago called Survivor Vision. For those that haven’t, here’s the trailer for it. Basically, it allows you to highlight items in the world for the player. In that pack, it’s tied to an effect the player triggers, but in the Survival Game Template we just want to use it to highlight interactive items that the player is looking at – such as pickups, maybe a door, etc. Regardless, I have taken a stripped down version of the material in Survivor Vision and incorporated it into the Survival Game Template, giving you a lot more options and control. Now you can just outline actors, or you can highlight them with a pulsing effect, or with a texture, or any number of combinations. The Survivor Vision system has literally thousands of combinations – this doesn’t have quite that but there’s a lot of different ways you could use it for sure!
There’s also a hotbar system in the template that is currently mostly finished. Players will be able to drag from the inventory to the hotbar to allow access much more quickly to their favourite items.
Finally, or at least the final feature I will discuss in detail here (as there are a lot of other things already implemented) – there is a full menu system with the ability to start the game in single player, host a multiplayer match via the internet or over a LAN, connect to an IP address, and even search for games with a session browser. The session browser, by default, will search the LAN, but this can be configured to work with any network, including one attached to a Steam ID. This theoretically means the game you are making could reasonably easily be plugged into Steam’s networking systems.
So what’s left?
At this point, there is still a number of core features missing from the template that need to be completed before testing and release can happen. I need to finish off the main survival mechanics (poison, blood level, armor and temperature). I need to make the crafting system (though a chunk of this is already done via the inventory). I need to set up the various post processing effects to supply feedback to the player when they are low on health/water/etc. I need to build the example AI characters and set up example weapons. The RNG loot generator needs to be written and once all that is done, the save and load system needs to be made. That may sound like a lot, and it is – I’m not going to pretend it isn’t. However, for the most part, most of that stuff is just taking the logic from the single player version and tweaking it to run server-side. To date, the inventory system has been the biggest chunk of the work – and during the process of rewriting the entire template I have literally rewritten the inventory system no less than three times, improving and expanding it each time to be a better more reliable and secure product.
The entire system, thus far, is set up to run via server authenticated methods, meaning that all important game-changing logic – picking up and using items, players taking damage, etc. are run on the server, and the client is just told what happens. This was all done to ensure that any games made using the template will be less prone to cheating (as is often the issue facing survival games). Obviously it cannot guarantee it wont happen – people will always find a way – but starting off with a more secure product is definitely the right way to go!
One question I am getting a lot is how I intend to make the crafting system work…
Crafting in survival games usually comes in a couple of different flavours.
Minecraft-style – where you need to arrange items in a specific way to then complete a blueprint. You do this on a workbench for all but the most simple items.
Blueprints – where players need to unlock blueprints for items. Once they have the required materials, they can just craft them. This often does not require any sort of workbench, but some times for more complicated blueprints you may need something like a workbench.
Recipe Lists – where players have all the recipes available to them from the onset and can just craft whenever they meet the recipe material requirements. Again, this often does not require the player to have access to any specific benches.
The crafting system I have planned out will allow you, with a simple check of some different boxes, to configure between the two latter ones, but also limit to workbenches if desired. Obviously, it will depend on how you wish to have your UI setup and deliver information to your players as to how exactly it works – but the mechanical side of it all will work out of the box. A post-launch tutorial on implementing blueprints that require materials to be place in specific shapes on a grid, such as in Minecraft, is a possibility if there is enough interest for it.
Okay okay okay. ENOUGH TEXT DAMNIT! When are you going to FINALLY release this thing?!
Okay so now the million dollar question. Soon.
Fine more specific… At this stage I am aiming to enter testing within 1 month and depending on the testing, release soon after that. PLEASE NOTE that this is the PLAN… sometimes things don’t go according to plan. I am a full-time carer for my ill fiancée, so sometimes I am unable to focus on work for weeks at a time (which is why things have taken so long thus far). That said – as of recently I have had a good 4-10 hours a day working on the template, and this appears to be continuing. Please trust me when I say that I want to get this template complete and in the hands of the community more than anyone wants me to complete it!
Yes. Testing. It’s a multiplayer product. I can test it all I like, using 8921 characters on the same PC at once… that’s still not real testing. When I am near completion, most likely everything but the save/load system completed, I will be compiling a dedicated server build and running that on some server space a friend from the community has kindly offered up. You guys will then be able to download a compiled client build, and jump on to try to break it for me! That’s right – you get to try before you buy! Well… that is, unless you already bought….
The build will be balanced for features, not gameplay, so it won’t be a great game – but it will give you a lot of exposure to all the mechanics and how the play into each other to try to test as much as we can in as short a period as possible. If testing goes smoothly and there’s not a single game-breaking bug, release. If there are bugs, fix and more testing.
That’s about it – that’s where things are at now. I’m working on the template every day. Consistently trying to get it done as soon as possible. If you want to follow progress, there is a number of links here to help you keep up with it:
If you want to be more interactive about it all, you could join the 50+ community members who have joined up to the Dapper Raptor Discord Server. Here you can talk to others who have purchased, or are interested in my work. There are separate channels for support for the Survival Game Template, the Quest Map and Navigation System and Survivor Vision, but there’s not really any strict rules, and everyone there is nice and relaxed. It’s just a little community of like-minded devs. I even ask for opinions on how to implement certain features and so on from time to time, so if you want to be more involved in the development of the template directly, that is certainly the place to do it. All you need to do is click on the link below and make an account (totally free). You can access it via the phone app, the desktop app, or even inside any web browser!
And last but not least. I would just like to take this opportunity to plug the newly launched Patreon campaign I have. As mentioned above, I am a full-time carer for my fiancée. I recently had to resign from my part-time job, and receiving welfare for caring in Australia is really difficult (I am trying to get approved but it’s not easy). A few of my customers from the community suggested that I make a Patreon so they could support me, so I have done it. I won’t go on about it here – it is definitely not expected that you will donate. However, if you have a moment I would appreciate it very much if you could take a look at the campaign and perhaps share it via social media. Any small amount I get is honestly a huge help at this point and helps me to keep UE4 development on the horizon as a viable possibility for income.
If you made it this far – well done! Apologies for the giant post. Everyone keeps asking for more and more info – so here it all is!
One Final Thing…
At the time of this post, the Survival Game Template is on sale on the UE4 Marketplace for 25% off. I will be leaving it on sale until Monday the 19th, and potentially extending that until the multiplayer version launches. I do want to make perfectly clear that the price of the template WILL be raising to USD $49.99 when the multiplayer version launches. It has been a huge amount of work getting this updated to the new version, and the list of additional features is huge. Whilst I could have spent this time making two or more other marketplace packs, I have kept to this update instead. If you want to save the money on it – you are better off buying it ahead of time. You WILL get the multiplayer version as a free update when it launches.
Now if you’ll excuse me… that’s enough larking about… time for me to get back to work!