Skip to content

Refactor orders workflow #17

@Bgeninatti

Description

@Bgeninatti

ATM, the data structure for player ordes is a tuple of three values ('action_name', obj_id, target), where:

  • obj_id is the object that performs the action (planet or ship)
  • target depends on the action, it can be an amount of mines, a ShipType, level of taxe, etc.

All the orders are executed under the scope of the Game class.

With the final purpose of make the code more testeable a few refactors are required.

  1. Implement the BaseOrder class:
class BaseOrder:
    name: str
    obj: typing.Union[Planet, Ship, Galaxy]
    target. typing.Union[int, ShipType, Position, TransferVector]

    def execute(self, galaxy, context): # Yes, same arguments as `player.next_trun`
        obj = self._get_obj(galaxy)
        # do something with obj and/or changes the `galaxy`  state somehow
  1. Implements different type of orders: ShipOrder, PlanetOrder, GalaxyOrder.

GalaxyOrder will be a special type of order for those actions that always happens independently of the player orders. Those are:

  • Changes in resources
  • Resolve planet conflicts
  • Resolve ship to ship conflicts

Can this orders be defined in the GameMode scope? 🤯

  1. At least two classes needs to be implemented as dependencies of Game.
  • PlayerOrdersExtractor: Extract and validates player orders.
  • OrdersExecutor: A class that receive a set of orders of certain type and execute them for all players

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions