The last post of this series has laid the ground for a small roguelike game - the main character @ was added on the screen and the user was able to change his position using the arrow keys. Now it is time to add more interactivity to our game by creating a test map on which the character is allowed to move freely.
We’ll start by refactoring a bit the code for the screen initialization part implemented last time, we could put all this code in a Screen class, we show here only the definition of the Screen class:
A game character is currently defined as having an ASCII symbol and a position, in the future we could add more properties for a character like color, speed etc … Having all this in a class, that can be extended in the future, sounds like a good idea:
A game map is usually bigger than the player’s screen and at a particular moment only a part of this map should be visible to the player for a bit of frill. We could use an ncurses WINDOW for storing the game’s map and a subwindow of this for what is actually shown on the screen, in other words we’ll need a window and a viewport.
We could create a Frame class to define our game map (a window) and the viewport (a subwindow). A Frame object could be initialize by specifying his width, height and his position, for a viewport we’ll also need to specify his parent window:
The fill_window method from above is useful in the development phase of the game, we’ll need a dummy game map on which we could move our main character. The viewport will follow the main character movements with the aid of the center method from Frame.
Using the above elements we can define the main function or our game in a much cleaner way than before:
Currently the game loop contains code for moving the character on the screen and centering the viewport:
Let’s try the new version of the game:
Initial screen:
Game starts and the main character, @, is shown in the middle of the game map:
Moving @ down, left, down we could see the viewport moving with the main character:
@ is near the down left corner of the map:
As a side note, the character is forced for stay on the map versus the previous version of the game were it was possible to move the character outside the screen.
Next time we are going to test a few algorithms for terrain generation.
If you have any improvements in mind feel free to drop me a comment.