Last week, I left off with a sprite on on hex tilemap. I didn’t feel this really entailed “The player starts in the center of hex field“. There was no actual concept of a player or any other sort of entity in the code. Well, this week I have accomplished just that and this task is done. I’ve decided on a three-part model of any given agent in the game.
- The entity: A collection of transient and intrinsic properties that contain the data of an agent.
- The controller: The brains of the agent. A player controller interprets input from the player to control his agent. A controller issues high-level orders, like move-there and shoot-that, to the agent.
- The actor: Takes orders from the controller and translates them to alter the data in the entity, like position, facing, animation, and whatever else it takes.
This structure gives a strict rules in who owns/modifies what. The entity only contains data and no logic. The controller only reads data and issues orders (temporal data only) and contains minimal state. The actor modifies data and only contains only enough logic to carry those orders out. It does no real decision making. The arrangement is fairly object-oriented, but if I wanted to do a data-oriented design, I think this could swing it later.
Next up is “The player can move to adjacent tiles“. This should be pretty simple and is rated a one-point task. Seeing I have a controller and actor for the player, it’s just a matter of getting input from the player and making and interpreting those orders. I’m also going to take a crack at “The player can see that different tiles have different aether densities“. It’s already mostly much done because I have a tilemap being displayed. This task will just be a matter of iterating through the tiles and building an array of tile info. It is also just a one-point task.