2
\$\begingroup\$

I'm having some conceptual difficulties understanding an efficient and clean way to implement multiple object selection behaviour in game. Think of an RTS in which you can select different kinds of units and do different things with them. My preliminary thoughts are that maybe I should create an interface ISelectable and implement it on each of my units and buildings. Basically, I'm pretty sure I should avoid creating a bunch of bools like marineIsSelected, medicIsSelected, yetAnotherUnitIsSelected, etc., and setting them to true when I click on the appropriate colliders. But, I've also never used interfaces and don't really know what that would look like or if it would be any simpler.

Suppose I just have a blank project with 3 different kinds of objects which I want to be selectable in it. When I select Object A, I want to be able to then click somewhere and have that object move to that location. When I select Object B, I want similar behaviour to occur. When I select object C, I don't want to be able to move it, but build other objects from it (for example). Are interfaces what I'm looking for? Is there another way that's simpler and that I'm overlooking? I want to avoid using a bunch of conditional logic where I can since there will be lots of different kinds of objects.

\$\endgroup\$
1
\$\begingroup\$

There is always more than one way to solve a software architectre problem. But this is how I would approach the problem:

Create different MonoBehaviours for different features. Have a behaviour Unit which you add to all units, no matter what side they are on and if the player can select them or not. This should handle the main combat mechanics and store the unit stats (which you might want to manage with ScriptableObject assets, by the way, but that's a completely different topic). Have another behaviour Selectable which just does that: handling the user selecting and unselecting the unit and handling the gizmos which appear when a unit is selected.

When it's a unit the player can control, add a behaviour Commandable. This behaviour handles things which are common to everything the player can control, like set up the UI Hud for showing the unit status (drawing the data from the Unit component).

For everything more specific, add additional behaviours.

When a unit can receive move orders, add a behaviour MoveCommandable. When such an object is selected, have it listen to click mouse events and make it move around. When it can attack, also give it a behaviour AttackCommandable which processes attack click commands. When it is a building which can build units, give it a UnitFactoryCommandable. Each of these behaviours should also communicate with the general Commandable component by telling it what icons the player sees in their UI Hud regarding the actions the unit can perform.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.