Architecture Discussion: Queueable Player Actions

Scripting
1

Alrighty so I have been developing long enough to know there rarely is 1 right answer. Therefor I am looking to have a discussion on how people would go about a task I am faced with.

The Objective:
Design a system where the user can queue commands to robots in the game. Example commands could be Move Forward, Turn left/right, Shoot X spaces in front of you. Each robot can have up to 4 commands. As the user is assigning commands there will preview what is going to happen. Ex. Move Forward will show a ghosted robot 1 cell forward. The user then will click play and all robots will execute their command queue.
More Specific Details \ Desires

  • A command holds some UI presentation details about it. Ex. The icon to show in the command queue.
  • I would be nice if each command was its own entity. Ex. I make the turn left command once, setup its UI icon, then tell Robots A, and C this is one of their possible commands while B doesnt get the Turn Left Command.

Architecture Idea 1 - Data Driven
Use ScriptableObjects to define a command as data. Store things like Name, Robot Rotation, Spaces Moved, Shoot, Then design a Command Monobehavior that takes a SO and based on the data does the correct actions.
Pros:

  • Gives the desired a command only exists once goal.
  • Allows for new commands as long as the data already exists is easy.

Cons

  • As I add new features to the command, the Command Monobehaviour can get gigantic. (this may be solvable by using additional MBs and having Command delegate tasks out)
  • Defining which robots get which commands may require some custom editor work.

Architecture Idea 2 - Monobehaviour Heavy
Design an ICommand Interface which defines DoCommand, UndoCommand ect. Then for each Command I would create a monobehavior which implements ICommand (ex TurnLeft). I then create an empty game object give it the 1 command, configure things like the Icon and save it as a prefab. Then to tell robots their possible commands I add the prefabs as children or just drop them in an array on the robot MonoBehavior.
Pros:

  • Each command is its own Behavior. Which will allow for detailed customization.
  • If 1 command has a bug it is local to that command.

Cons

  • Lots of duplicate code. This can be eased by using inheritance but will still be there.
  • Allows for easier developer error. Making a new command is very tedious and developers may forget steps.

These are just the first ideas that came to mind. I feel Idea 1 better fits the spirit of Unity. But I would love to hear other ideas or how I could possibly alleviate some of those cons.

2

I agree with you that Idea 1 sounds like a better fit. What about offloading the work to the ScriptableObjects? This also makes a cleaner object-oriented design because the object encapsulates data and the procedures that work on that data.

You could name your base ScriptableObject “Command” and create subclasses for each type of command. Or, if you want to make it more component-based, you could assign functional components to each command similarly to the way I assigned attributes to inventory items in this this example.

Then name your MonoBehaviour something like “Program” and just have it run through a list of Commands. Since all the work is done in Command, you can have a single, very simple Program class.

1 Like