Gameplay systems update

I am nearly finished with the first pass of prototype functionality. Here is a video of the current system in action:


This still needs a lot of polish and there are a few bugs. It’s possible for the bools to be in the wrong state if you swap parts in your hands while in the collision volume. Also, I can move more a few more things from the child to the parent blueprint so that the child blueprints are cleaner. The whole system feels a bit messy and I’m doing a lot of casting. There is probably a better way to handle the communication between parts but I’m not very comfortable with blueprint interfaces or event dispatchers yet.

The cliff notes of how this system works:

There is a master object that has a bunch of socket locations and a bool for each of socket to indicate if a part is installed. I don’t want to be stuck duplicating all of the functionality for each object so there is also a child class that inherits behavior from the parent. The parent class can’t store specifics about which bools its checking against because the child would be forced to inherit that information. To get around that issue there is an intermediary bool that in the parent class that operates locally and has no connection to the master object. Each child blueprint is responsible for  talking to the master object and checking which parts are installed. That information is then sent to the inherited local bool so that the main loop can allow or deny install/removal without a direct connection to a specific part.

Child blueprint that inherits the parent functionality.



Leave a Reply

Your email address will not be published. Required fields are marked *