Implement initial game loop

[matthewjwhite]

Implement initial game loop

[matthewjwhite]

Regarding battle:

• Could be handled by a Battle class, for example, which contains a battle function (two inputs: player, opponent). As the user is affected, the database is updated to reflect changes in health, etc. User::save should be further fleshed out for these purposes to effectively dump a snapshot of the user account to the database.
• As to the amount of damage done, this would be based on the user's statistics, and for damage received the monster's stats.
• For the purposes of an initial loop, a very simple random damage calculation is suitable (#7 should enable this to be more complex).
• #6 will enable further development of the battle stage.

Regarding exploration:

• The user is presented with a number of options, likely a N/S/E/W-type option.
• This requires some sort of spatial representation of land masses, such as via boundaries in a grid.
  • As are the possible user attributes (ex. class), these could also be driven through config files, specific to maps.
• Monsters would be associated with certain areas, so that exploration into more difficult areas, for example, yields more difficult opponents.
• For the purposes of an initial loop, a non-functional N/S/E/W, and a handful of monsters associated with the entire map, is suitable.
  • #8 will enable further development of the exploration stage. For now, the world can be a single, endless area.

[matthewjwhite]

Location

I think a perfect place for the initial game loop is GameSession::run; as currently written, GameSession represents a single user's interaction with the server, and run is effectively the "main" method for that session.

Algorithm

1. Get or create user account (already implemented).
2. Enter loop on GameSocket::get (note reference via self.socket in GameSession).
3. If input from user is exit, then save the user's state and kill the connection.
4. Else, there should be a set of additional possibilities which the user is either presented with or tossed into.
   • As part of this initial implementation, there will only be two possibilities, battle or explore.
   • It seems suitable for this initial implementation to not present a menu of options, though it should be
     extensible enough to accommodate that at a later point.
5. If battle, carry out battle. Choose from the available list of monsters randomly.
   • It seems suitable at this point to create a battle method in the User class, which accepts an input monster.
6. If not battle, then explore. Choose a direction.
   • It seems suitable at this point to create a move method in the User class, which accepts a direction.
   • When legitimate region boundaries are implemented, logic should be in place to determine whether a certain move is allowed or not.
7. Continue to next iteration.

[matthewjwhite]

⬆️ is being implemented here: https://github.com/matthewjwhite/crystal-skull/tree/initial-game-loop.