🔮What's in for the future ?

NACT is far from finished, and will continue to grow while it is used in more and more gamemodes over time.

This page is a great place to start if some big subject interest you a lot and you wish to get involved!

While NACT is an independant library open source library, it will be used on the Astral project of Nebula Productions, and as such thoose reflections are for a good part our goals to achive interesing encounters, but feel free to suggest anything !

Short term (Beta)

Better tooling for level designers

Currently editing NACT specific data (Cover Points, Territory boundaries, etc...) is done via code or my clunky editor for getting the Alpha together. This is a nightmare on any full scale gamemode for multiple reasons:

• Changes in the map becomes hard to notice.

• You duplicate a lot of positions that are the same, for example, in a said house Static Mesh, all the cover points will be at the same place. Having cover points set in unreal would allow you to add them once and for all and then duplicate your prop, retaining the data.

imo, the best way to do it is via Utility Blueprints that will generate code for the map package, like thoose you find in the ADK. But if you have a better idea, let me know!

More NPC presets

Goal of NACT was from the first version to support different types of enemies to create more challenging encounters. While there is Soldiers and Zombies, they are in different territories. Funnier would be to have different type of soldiers (Rifle, Shotgun, Sniper, Shovel). This required some effort that was best spent in debugging and stabilizing the Alpha. But I am sad they are not there yet.

More behaviors

Similarly to the presets, the NPCs are still quite dumb, mainly because they don't have anorther good sub Behavior Tree (and don't act as squads). To achieve that, more behaviors are required:

• Engage behavior should only be called when the enemy is in good range (a shotgun should be very close before firing)

• Push is the behavior while walking towards the enemy, instead of walking in a straight line, the NPC should plan a route (ideally with it's squad) taking cover along the way if needed.

• Back this is the exact opposite of pushing, when the NPC (or his squad) is in inferiority or in distress, they should move backwards to regroup with the rest of the team in an effort to lost territorial control but hold stronger the positions

Of course, many more behaviors can be envisionned, but thoose seem very very mandatory in order to make the fight aspects funkier!

Moving out of the team system

While the Team system is great for early works, it comes short for more complex interractions you can encounter for an NPC. In NACT alpha, an entity is either ally or enemy, wich is a bit an Hollywood movie style of feelings. The Relationship system of GarrysMod NPC is a better way of handling such relations, where each entity could be seen as hated, neutral, ally or feared by an NPC. The current team system can still be supported, it is just a matter of hating anyone not on the NanosTeam entering the territory, or making an ally of any orther team member.

Squads

Very obvious in NACT_Patrol behavior, each NPC feels like it is alone in the world and will never plan things with it's neighbours, including the Patrol behavior where they will all line to get towards their patrol points. To enable much deeper and interesting scenarios, NACT_Npc should be assigned a squad, and within that squad, decisions should be made and shared to squad members. Anorther great example is the Seek behavior, it is very easy to kill NPCs one by one because they will randomly search the area if you flee. This will be harder if, instead of one NPC, you have 10 of them coming to search for you.

Asking for feedback

Better behavior structure ?

The current implementation of NACT behaviors and the relationship between them might be challenging in the future. The the fact a behavior is responsible for switching to anorther behavior, is kind of a State Machine communication. With Decisions Behaviors enabling some level of Hierarchy. For the alpha, this is plenty enough, but I'm still trying to figure out of it will stay that way in the long term. Aside from behavior trees, Goal Oriented Action Planning seems pretty fun too!

However, the major advantage of this approach is it seems easier to understand and write the code for scripters. But this can lead to complex code when trying to map very complex behavior interractions. Also, they are not mutually exclusive, we don't have to destroy the current behavior organisation to support anorther.

In any case, such a major rework of the lib would probably be worthy of a major version, as it will bring breaking changes !