What would be the best way to handle giving the player multiple states of playstyle that they could switch between? An example would be a ship. In that example, I’d like to design the “grounded” mode separately, where the ship hovers above the ground, and the “flying mode” separately. Another example would be Mariokart 8’s multiple kart states: Road, Water, Air.
What is the best way to go about creating a modular, expandable system like this? Kind of like a mechanics state machine. Should I create an Actor component class as a base to make separate mechanics out of to attach to a Pawn? Or something else?
I’d create actor components responsible for the mechanics / behaviours. Bundles of functionality that can be added (or taken away) from actors. Or activated / deactivated if there aren’t too many.
Eventually you would want a enum such as Ship Movement Mode [Ground, Water, Air] to define its movement. Would make transition and state logic a lot cleaner an easier to work with.
I hope its okay to add follow on question to this, but why is adding a component any different than just switching functionality from a branch or switch? It accomplishes the same thing, and you can still wrap code into reuseable functions. So whts teh difference?
You can add and remove components dynamically. Think about an RPG where Pawns can have a lot of abilities. The Pawns and any other World Entities can gain new abilities and lose others, get temporary buffs debuffs and so on.
Each ability / buff may be complex enough to require several functions, a bunch of variables and callbacks.
You could cram all that functionality into a Pawn; doable but cumbersome, not modular and not scalable. There’s no reason for everybody and their mother to know about everything that could potentially happen.
With components, you get to choose which pawn has what components, and only when they are needed. Actor components also support inheritance.
Just to add a bit to what the others said, you usually want to give a Pawn only basic functionality, things that are always necessary for it to work for your specific use case.
Components are a way to build extra behavior for your Actors/Pawns/Characters and keep it in a separate container.
For example, let’s say we have a racing game. All of our cars would have the driving mechanics built into the Pawn, because every vehicle needs to drive. But some vehicles might also have special abilities, such as driving over water.
Instead of building that functionality into every Pawn even though it might not ever get used in most of them, we can build the water functionality into a component that we add into the select few Pawns that have the ability to drive over water.
This is just a basic example. @Everynone gave a great a good real-life example of how we might use Components. It’s a complex subject, deciding what to use components for and what to put into the Pawns.
So, I like to think of it this way: If a certain behavior/code is required for my Pawn to run, I’ll put in in the Pawn. If I have a certain behavior/code that extends how the Pawn would work, or if I’ll have many different similar versions of that behavior/code, then I’ll put it into a component. It’s also good for performance, like @Rev0verDrive mentioned, since you don’t have nearly as much unused code in your Pawns.
Thanks guys. Very helpful. I’m just getting to grips with the basics of scripting and so far have survived by staying super simple. but this helps me start to think about better ways as my project inevitably gets more complex.
And sorry, didnt mean to hjijack thread, just thought I had similar questions more or less
Not a problem. The best way to learn is to ask questions. This will also be a good thread for others in the future if they need some help with components. Glad to help!
