see Plugin Module Overview for a detailed list of available modules within the Horde Framework.
Since three months I’m working on a horde based game with Unreal Engine 4 and I really like the process. Moreover, I already learned a lot about game development and I never thought that it would be so complex.
Everything started with this small game project. I followed a small C++ tutorial from raywenderlich.com, which explained how to implement a physics based ball rolling game. It was the perfect starting point to get started with Unreal Engine 4 and it’s development environment.
I quickly moved forward and realized a physical based bullet simulation component with reloading and three weapon types, integrated ALSV4_CPP, implemented a small inventory system and currently I’m working on the zombie ai. The zombies are animated with mixamo animations, which are configured with root motion. To move those AI characters I’m using a customized pawn controller and perception implementation, which is implemented in C++. I will definitely give utility AI a try to see where it can go. Somehow I was not happy with the behaviour tree maybe I was using it completely wrong…
I’m quite happy with the latest state as I do have controll over everything, which is great for fine tuning. With the default settings the horde did not perfom very well so I optimized everything and ported almost the entire zombie character implemention from blueprints to C++. The result was a huge performance gain, I really hope that I can optmize the horde even further that should allow me to process even more zombies or getting better FPS.
Interesting project. I am not having performance problems with the crowd controller, however it has some limitation, which we need to overcome for our project in the future. Would be interested in your plugin, if it does not have these limitations. Especially working with multiple capsule sizes. Dont know if you are aware of it, but unreals detour crowd controller can only handle one capsule size. Pawns with different capsule size, which should pick a different nav agent, can’t move at all, because detour crowd controller only works with one nav agent.
Also for performance checks, always make a shipping or test build for that. You will get very different results than in editor.
Hi [USER=“1840444”]CatBit Thorium[/USER],
thank you already that you like my project!
So far I didn’t had issues, I only use small variations in size (90% or 110%) currently. But the HoidAI plugin already takes care of it as it is needed to draw same debug shapes. Moreover, the equation for obstacle avoidance will need the size of the obstacle so I will take care of it while implementing it.
I would be highly interested if you saw more limitations. Thanks a lot for that hint!
I don’t know if you can see this limitation here: Horde Game | UE4 Devlog #1, I’m using root motion animations and a derived class from the detour crowd controller so far all agents seem to move.
How many agents do you process at once? My goal is 500 visible on the screen .
Yes I was experimenting with this yesterday and it makes a huge difference if you use the development and the shipping build compared to the editor build. Moreovoer, I saw a minor difference between the shipping package and development package.
Hi, we are using much less on screen than 500.
The problem can’t be seen on your video because you only use one nav agent. I dont speak about agents in the sense of pawns/characters registered to the crowd controller. I speak of nav agents. You can define different nav agents, which use different nav meshes. This is usefull for different size of characters. For example very small characters which can go where medium characters can’t go and large characters, which can’t go where mediums go. You only use one nav agent. The detour controller only ever uses one nav agent. Agents which use a different nav agent can still be obstacles but can’t be part of the controlled crowd and if they are registered as such, can’t move at all. You can test that out by creating a second nav agent in navigation settings. For example a larger one and make a character with larger capsule, which will pick the new nav agent.
Only thing to workaround it is to derive from detour crowd controller and expose properties to blueprint or change in c++ to make it register as obstacle only. But then bigger characters will not avoid smaller characters. Only the smaller avoid the bigger ones.
Root of the problem is that the detour crowd controller only ever supports a single nav agent.
Plugins HBalistics
This plugin will provide physical based projectils, which can be used for any weapon. ToDo: add links
HAbilities
This plugin will provide a base to implement abilities like teleporting, fire balls, telekinesis …
HPlayers
This plugin provides the interfaces that makes it possible to use any ability or attack, which will be controlled by the player. Additionally these interfaces can also be used to integrate existing implementations of weapons or abilities from other packs like Character Interaction, Character Skills, Third Person Shooter Kit…
HoidAI
Hoid AI is a plugin, which is based on the boid equations from Craig Raynolds. The implementation is done in C++ for performance reasons to simulate a huge crowd of enemies (goal is 500 AI agents at once). The first implementation will be used for zombies with root motion animations but I’m pretty sure the base system can be extended to further enemy types likes flying bots, other melee based creatures … ToDo: add links
HLocomotion
This plugin will be open source as it is based on Advanced Locomotion System and will integrate the neccessary extensions to provide a nice horde player controller. ToDo: add links
HHealth
Will be the plugin, which takes care of the health (armor, stamina, health, …) of the game characters like the player, enemies or anything else that needs health. ToDo: add links
HStealth
It’s obvious that every survival game needs stealth abilities right? So this will be the plugin, which brings this ability into the framework. ToDo: add links
08.01.2021
Today I got the boid based steering behaviour prototype working with root motion based animations. Still not optimzed yet but I already get ~25FPS with 500 Mannequins on my rig (Skylake 6700K, 32Gb Ram, 980 Ti). More updates will follow.
.