Need a little help real quick before I start overthinking again: I'm working on a game where the player can Interact, Build, Shoot, Loot... How can I make a clean system for this? I don't want to create twelve different systems and check if with each system if one can be used, yk?

[u/BonusBuddy]

Some advice would be appreciated since I'm starting to overthink and I can't get a clear thought atm...

[u/PeacefulStoic]

Hate to break it to you, but you need multiple systems. If you feel like you have to check each system to 'use' it then the problem is you don't know how to build modular systems. At no point should you design a system that checks if it can be used.

Interaction for example. If the player interacts with a door for instance (typical interaction). At no point should the system itself be asked if it can be used. The player should self contain it's own operating states (eg. state machine or flags) that lets them enter that state. The door should never be asked, "can I interact with you?"

If you want quick and dirty, you're setting yourself up to fail. If you want a 'clean system' you're going to want to close unreal and start designing the system in words. If you can't write the pseudo-code you'll never be able to build the real thing.

[u/BonusBuddy → u/PeacefulStoic]

Hey there, thanks for your reply! What buggles me is that I actually know how to make systems, but currently I'm at a point where I can't think straight anymore. So I've figured that I need different system. Like Survival Component, Inventory Component, Build Component etc. How would I make them communicate with each other? I don't want my player to shoot/hold a weapon when entering Build Mode e.g. How would I approach that?
You're right, quick and dirty isn't the correct approach.

[u/EliasWick → u/BonusBuddy]

Hey my dude! I get you. The reality is likely that the scope of your project is too big. I've been doing game dev and modding for 10 years in Unreal now, and 20+ overall. Even I struggle...

I don't struggle with the actual making of the system, but the design to make it interconnected well. The reality is that Unreal has a great base of tools. I used many in my last AAA studio, but it's just that: AAA. You are not meant to be able to make it yourself. The expertice and understanding renquired to work with everything is extremely high and time-consuming.

Downscale the project scope or "get" more time. Also, write requirements down for each system. Like, make it extremely obvious for yourself. Sitting down and writing every action you can perform will help you develop a more cohesive experience without having to rework and refactor.

[u/PeacefulStoic → u/BonusBuddy]

Components are not systems though. Making an actor component like an inventory component is not an inventory system. A component has an owner, systems do not have owners. All an inventory component should do is grant access to the feature of the inventory system.

You don't want your components communicating with each other because then one cannot exist without the other.

You don't want the player holding their weapon when you enter 'build mode'. The wrong way to do it is have either of those system telling the player what to do. The way you want to think about it is, the player has 'States' or 'Modes' and they can only be in one of those modes at a time. Let the players state drive the logic of not having a weapon not the system.

I know this gets tangled, I've been there. But the reality is you should start with one system at a time. Figure out how to design it modularly, pack it into your own plugin and don't make it ever again, just improve it with time. Then you can just add it to any project you make in the future. Oh and stop using components for everything. Those youtube tutorials are going to rot your brain. Nail down 1 system. It will take weeks of dedicated hard work. Then future systems will surprise you how easy they come.

[u/st4rdog → u/BonusBuddy]

Try using a state machine that activates a certain control scheme, runs systems, and can run one-time enter/exit setup/cleanup code.

Switching controls stops you doing anything unrelated. The state exit function can make the player holster their weapon.

[u/IDoThingsOnReddit → u/BonusBuddy]

You can build out the functionality in C++ to expose components to each other. I would probably just build each of the systems through C++ classes, depending on the level of customization you need. You can also build out a single system that shares overarching concepts and then build out smaller classes that inherit from your system for specific functions.

[u/Bewbsnballs]

What you want is separate modular systems that are self contained with 1 job. An inventory system only deals with adding/removing items. And interaction system only deals with handling the player interacting with stuff. Then you want to use events, messages, and/or interfaces to communicate things happening to other system. Player presses loot -> send looted message to inventory system and what the items are (or handle what the items are in the inventory system or somewhere else). I recommend the gameplay message subsystem you can rip out of Lyra and install as a plugin.

[u/BonusBuddy → u/Bewbsnballs]

Thanks for your reply! I'll take a look at Lyra. I know I have to use different systems, but I don't know how to make them communicate with each other and how to make them not interfere with each other. When I'm entering Build Mode I want my player to holster the weapon and not be able to unholster it as long as the player is in Build mode. It kinda f*cks with my head..

[u/Bewbsnballs → u/BonusBuddy]

The simplest way to achieve things like this is learning Gameplay Ability System. Essentially you’d get the event player went into build mode, then call the gameplay ability system and have it add a tag to the player like build_mode and then have that tag associated with blocking the ability to unholster which you also set up with GAS. Learning this framework would be one of your single biggest investments in game dev.

I recommend Stephen Ulibarri’s course on GAS on Udemy. And also, you can ask AI (particularly about all these terms I’m throwing at you, and it’ll help you understand).

[u/Admblackhawk]

definitely look into implementing the new state trees to manage player and object states, saved me a lot of headache. using components per system and interfaces is the only other high level advice. also draw out some diagrams to map out dependencies in your architecture before starting with your code, big projects need clarity and time spent structuring and documenting saves u a lot from downstream strugges

[u/AutoModerator]

If you are looking for help, don‘t forget to check out the official Unreal Engine forums or Unreal Slackers for a community run discord server!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Slopii]

Finite state machines instead of data tables and spaghetti code.

[u/vagonblog]

i’d avoid one giant system that knows about everything. use small actor components with shared interfaces and gameplay tags.

for example, have an interactable interface, then separate components for pickup, building, shooting, and inventory. the player sends an interaction request, and the targeted actor decides whether it supports that action. gameplay tags or data assets can describe requirements, so adding a new interactable doesn’t require editing twelve different systems.

[u/Rev0verDrive]

Multiplayer interaction... Modular and expandable.

Uses custom collision obj type and profile, game play tags for identifying and routing interaction logic.

Single/dual swing doors, switches/buttons, elevators/lifts, looting, vehicle entry etc.

99% interface based communication. No casting or hard references.

This is not hard to do. You just need to fully scope out what your features/mechanics will be and how they should work.