So I’m working on a game that has a lot of switches/doors and that type of puzzle. Maybe a few more complex where there are multiple switches that need to be opened, in which case there will be multiple doors.
When it comes to the events and puzzle logic, two solutions have been proposed, and I’m wondering if anyone can tell me which they think would work better.
Assuming that the switches/doors are already in the level:
-
Create a child blueprint for each switch or door combination, and just put the logic in their event blueprint (ie, in the switch “activated” event blueprint call the relevant doors “open” fn).
-
Create a separate logic actor, and place it in the world. Give it vars that correspond to the switch/door, so that it will subscribe to the switch events and then open the door.
I guess the tradeoff will be that for 1) You will have a child blueprint for each piece of puzzle logic, while for 2) you will have an actor for each one.
I think they can both do the job, but I’m curious to see which people prefer?
Hey AusPaco,
The best answering I can think of to your question is “depends” and I know that is a terrible answer when you are looking for good feedback. So I will expand on that some to see if my thoughts may spur an idea to help you find the best answer for your situation. I say depends because I think the best direction to choose has a lot to do with what you may have going on between your doors and switches. If you have simple relationships and dependencies, each door has a dedicated switch that acts like a flip flop for instance, then I would go for keeping it simple and wire them up with references to each other. On the other hand you spoke some about puzzle logic and if you are controlling your doors with a complex set of game logic or dependencies to determine if any given door will respond to a switch event then I would want to think about a controller to hold that logic. The controller could listen for the switch events, process game logic, and then signal the doors accordingly. To me that helps keep a clean separation of concerns and gives you a central location for you game logic processing door switch signals. Which can save you a lot of time and headache if you need to change that logic or hunt some bugs. Just my thoughts and I hope it may have helped. Good luck!
Thanks , appreciate your advice. I guess the system need to be able to handle puzzles that haven’t been designed yet - so a lot may be quite simple single door/switch combinations, but others may be a lot more complex - ie, need several triggers to be active, or maybe pass floats and other structures, not just a straight event to coordinate things.
I must admit, I really like the general nature of a child blueprint, but it’s not popular among my colleagues…