First version of Horde mode in 4.0! More interesting than Devlog #025.
Basic wave survival is now playable in the 4.0 private beta / demo, and while barebones with essentially two test maps, it’s still fun to hop on for a few rounds. Primarily it served to work on a few features:
- It’s a fun break! Horde will be expanded on to further become a proper gamemode over time.
- Playing as zombies (survival mode turn into zombie after death?), and bringing the 3.0 zombie into 4.0. Note that future enemies will be further departed from the classic zombie.
- Team-based gamemodes e.g. bullets pass through friendlies, team and enemy outlines, doors can only be trespassed by zombie team.
- Where Blastlane and Firing Range were experiments with making the game moddable from blueprint, Horde is taking steps towards C++ modding and making the base game code more moddable from C++.
- Deciding what to do about AI.
Items marked “priority” on the roadmap are candidates for being focused on next, but the most likely contenders are melee (no more T-pose), analog stance and speed (e.g. scrollwheel to walk slower or faster), and a survival map.
The main reasons for delay on a proper survival map are to decide how best to plan ahead for large-scale destruction, and to decide how best to improve the building tools. Destruction-wise one interesting option in the further future is Unreal’s upcoming “Chaos Physics” system, so I’m planning to experiment how well it plays with Unturned’s models – though unlikely to be integrated yet because they’re still polishing it.
Satisfying impacts are a big part of what makes combat fun, so I wanted to do a much better job here than with 3.0. In 3.0 there is an impact particle effect to show that you hit someone, and a general splatter of decals in all directions.
Edit: Unfortunately the ragdoll impact effects had to be disabled for the beta version due to a physics-related crash, but it looks like the fix is in Unreal 4.23 so I’m planning to expedite the engine update.
Now the effect is split into several pieces:
- Quick hit flash like a 3D hitmarker which will eventually be part of a “low blood” option.
- Passthrough particles following the bullet.
- Outward chunky particles similar to 3.0.
- Bullet impact flesh sound (also low blood).
- Streaking splatter decals aligned with the bullet trajectory.
- Nearby splatter decals forming big puddles.
- Further splatter decals as small flecks.
- Splashes and decals from ragdoll physics impacts.
- Meat slap sounds from ragdoll collisions.
In particular I think the outward chunky particles need further revision. I’m looking forward to designing different effects for melee weapons as well, e.g. katana should have more arcing particles.
When working on the variety of decals I realized there was opportunity for a handy trick here: we can put multiple images into the decal texture, and choose a random sub-image in the shader by hashing the decal’s position. This helps save on the number of materials (otherwise was 1 per texture).
The option to change language is in-game now, with the defaults being English or Pirate Speak. Maintaining pirate speak will help ensure everything works properly with localization, and in the future I’d like to convert it into a mod so that modded translations will be well supported. As part of that I intend to eventually allow anyone to submit pirate text to a git project for it. Thanks to Yarrrr for coming up with the current text!
One problem with spawning items in 3.0 is that the only parameter to how to initialize an item’s quantity, ammo, fuel, etc is whether it was spawned by an admin or found in the world. In 4.0 I wanted something more moddable (not a struct or enum), and have eventually decided on “tags”.
This way mods can easily use custom tags, and the initialization tags are easily built for a given context e.g. Horde wallbuys can choose some base tags, and then allow the gamemode to modify them before initializing the item. Right now there are tags for a few simple cases like “No Default Attachments”.
One big part of getting Horde mode playable was deciding what to do with AI, and getting a grasp on what Unreal does out of the box. Right now I’m inclined towards using Unreal’s navigation systems, but taking a “Utility AI” approach towards AI decisions and custom systems for environment queries.
My current thought process is that some middle ground between behavior trees (BTs) and utility AI will be the end result. Using huge BTs is difficult to think about, whereas utility AI tries to separate each task and rank them independently. This also makes utility AI more extendable and moddable, for example a custom weapon adding more utility options when equipped.
Since zombies now share most of the same code as human survivors (Denizens), there’s a lot of common behavior. Zombie arms are a (simple) melee weapon similar to how fists will be, and they’ll benefit from future features. Once mantling and vaulting are added for Denizens in survival mode, the future Denizen bandit AI should be updated to use it, and then zombies will be able to vault through the windows rather than jumping.
In the previous update Steam servers were enabled, however they could not be joined directly. Unreal’s default Steam implementation does not support directly pinging game servers, so I’ve extended it to add some features similar to 3.0. Now querying a hostname will resolve the IP and ping the server directly for Steam details – this works for LAN as well. In the future I’ll make similar changes for the join via friend and browser query types (history, favorites, LAN, friends).
Working on this update I realized that I’d unfortunately broken a few side features in the past update, so it was time to re-investigate the automated testing. In particular I’ve focused on making it easier to simulate in-game scenarios, and covered more of the inventory actions. Next I’m hoping to automate testing some gameplay actions like using weapons.