Hi,
I've started rereading sections of the book that I had trouble with after taking an extended break from game related stuff. If I understand the book correctly, every action that entities can perform should be represented by commands. I like the idea, but am running into a few implementation issues.
1. Should the event system be used for sending commands to the game logic? I think this'd work if the command required no response to the caller (e.g, set accelerator to 80%) but it'd be messier if the sender wanted a response. For example, if the view got a "show inventory" command, it sends this off to game logic and needs a response telling it what the items are. A possible solution is to have game logic send yet another event with the required information in response. This would mean that the game logic must subscribe to every event representing a command that it could accept, and the views would need to register to the events that correspond to the response to these commands. That sounds like a lot of work.
2. Another alternative is to explicitly have a CommandResult handleCommand(Command c) method in game logic. All commands inherit from Command, and all possible results from executing a command inherits from CommandResult. For example,
class GetInventory : Command {
int entity;
}
class InventoryCommandResult : CommandResult {
// data members with item information here
}
Then human view would do a synchronous call like
if (i key was pressed) {
CommandResult inv = logic->execute(GetInventory(player));
// downcast to the right type and display appropriately
}
3. Break the command abstraction for commands that senders need response for by implementing game logic methods for these specific commands; I'd rather not do that.
What are good solutions to this problem?
another related question: is this the right understanding of how I'd implement turn-based combat with this architecture?
1. Something in game logic detects that you're in combat. Human view responds to the InCombat event emited by changing to a combat display.
2. Game logic decides the turn order for each round. When it is either the player's or AI's turn, PlayerTurn/AITurn event is sent. It goes into a paused state while waiting for actions to be performed.
a) If player's turn, human view sends command to logic when player selects option.
b) If AI's turn, run code somewhere to choose an action (probably in AI component for an entity?). Send the same sort of commands human view might corresponding to selected action.
3. If I used event-based approach for commands, Logic wakes up in response, performs the actions, and emits events about the results of that action (e.g, goblin dies). If synchronous approach, logic returns control to human view after its done. Either way, Human view responds by e.g, playing sound and somehow "pauses" only the human view till the sound is complete so that you don't try to show results of multiple actions concurrently. Need to think about how to do this.
4. cycle repeats.
I've started rereading sections of the book that I had trouble with after taking an extended break from game related stuff. If I understand the book correctly, every action that entities can perform should be represented by commands. I like the idea, but am running into a few implementation issues.
1. Should the event system be used for sending commands to the game logic? I think this'd work if the command required no response to the caller (e.g, set accelerator to 80%) but it'd be messier if the sender wanted a response. For example, if the view got a "show inventory" command, it sends this off to game logic and needs a response telling it what the items are. A possible solution is to have game logic send yet another event with the required information in response. This would mean that the game logic must subscribe to every event representing a command that it could accept, and the views would need to register to the events that correspond to the response to these commands. That sounds like a lot of work.
2. Another alternative is to explicitly have a CommandResult handleCommand(Command c) method in game logic. All commands inherit from Command, and all possible results from executing a command inherits from CommandResult. For example,
class GetInventory : Command {
int entity;
}
class InventoryCommandResult : CommandResult {
// data members with item information here
}
Then human view would do a synchronous call like
if (i key was pressed) {
CommandResult inv = logic->execute(GetInventory(player));
// downcast to the right type and display appropriately
}
3. Break the command abstraction for commands that senders need response for by implementing game logic methods for these specific commands; I'd rather not do that.
What are good solutions to this problem?
another related question: is this the right understanding of how I'd implement turn-based combat with this architecture?
1. Something in game logic detects that you're in combat. Human view responds to the InCombat event emited by changing to a combat display.
2. Game logic decides the turn order for each round. When it is either the player's or AI's turn, PlayerTurn/AITurn event is sent. It goes into a paused state while waiting for actions to be performed.
a) If player's turn, human view sends command to logic when player selects option.
b) If AI's turn, run code somewhere to choose an action (probably in AI component for an entity?). Send the same sort of commands human view might corresponding to selected action.
3. If I used event-based approach for commands, Logic wakes up in response, performs the actions, and emits events about the results of that action (e.g, goblin dies). If synchronous approach, logic returns control to human view after its done. Either way, Human view responds by e.g, playing sound and somehow "pauses" only the human view till the sound is complete so that you don't try to show results of multiple actions concurrently. Need to think about how to do this.
4. cycle repeats.
The post was edited 1 time, last by Neurone ().