As you probably know already, having written games before, the core game algorithm is:
- Create a data structure representing game state.
- Draw the game state
- Obtain an input from the player
- Update the game state based on the input and the rules of the game.
- Goto 2.
This idea is fundamental to computer science; this kind of program is called a state machine.
You've gotten a good start on the first two parts. Once 3, 4 and 5 are in place, we've got a working game loop; the rest will be making enhancements to the rules.
- Write code to capture keypresses from the user and look for the key codes for the up/down/left/right arrows.
- I strongly suggest that you immediately transform the key code into an action object of some kind. It will be easier to write the logic for resolving actions if there is an object representing actions. Probably best to make an
Action base type and a Move derived type with a direction property.
- Once you've turned a keypress into an action, resolve the action. Check whether the cell to the north/south/west/east, as appropriate, is "walkable". If not, ignore the keypress and go back to waiting for keypresses.
- Otherwise, update the player entity to have the appropriate new x, y coordinates.
- Redraw the display. (Note that you can re-use the existing display grid; you don't have to allocate a new one.)
The player can explore the dungeon but that's not much of a game. Next time we'll start thinking about actual game design.
As you probably know already, having written games before, the core game algorithm is:
This idea is fundamental to computer science; this kind of program is called a state machine.
You've gotten a good start on the first two parts. Once 3, 4 and 5 are in place, we've got a working game loop; the rest will be making enhancements to the rules.
Actionbase type and aMovederived type with a direction property.The player can explore the dungeon but that's not much of a game. Next time we'll start thinking about actual game design.