View source for Roguelike Tutorial, using python3+tdl, part 10

<center><table border="0" cellpadding="10" cellspacing="0" style="background:#F0E68C"><tr><td><center>
This is part of a series of tutorials; the main page can be found [[Roguelike Tutorial, using python3+tdl|here]].

The tutorial was written for tdl version 3.1.0.

</center></td></tr></table></center>


__TOC__


<center><h1>'''Main menu and saving'''</h1></center>


== Tidy initialization ==

Now that our game is bursting with gameplay potential, we can think about those little things that die-hard fans will surely miss during their long playing sessions. One of the most important is, of course, a save/load mechanism! This way they can go to sleep and dream about your scary monsters between play sessions.

To choose between continuing a previous game or starting a new one we need a main menu. But wait: our initialization logic and game loop are tightly bound, so they're not really prepared for these tasks. To avoid code duplication, we need to break them down into meaningful blocks (functions). We can then put them together to change between the menu and the game, start new games or load them, and even go to new dungeon levels. It's much easier than it sounds, so fear not!

Take a look at your initialization and game loop code, after all the functions. I can identify 3 blocks:


* '''System initialization''' (code between ''tdl.set_font'' and ''panel = ...'').
* '''Setting up a new game''' (everything else except for the game loop).
* '''Starting the game loop'''.


The reason why I chose this separation is because I think they're the minimal blocks needed to do all the tasks. The system initialization must be done just once. Thinking out loud, here are outlines of all the tasks:


* '''Create a new game''': set up the game, create map, start game loop. (This is what we have now.)
* '''Load game''': load data (we won't deal with this block now), create map, start game loop.
* '''Advance level''': set up new level (we won't deal with this block now), create map. (The game loop is already running and will just continue.)


Hopefully that will make at least some sense, it's not very detailed but gives us something to aim at.

The system initialization code will stay right where it is, it's the first thing the script executes. Now grab the rest of the code before the main loop and put it in a new function. The lines ''objects = [player]'', ''fov_recompute = True'', ''player_action = None'', and mouse_coord = (0, 0) will go elsewhere:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def new_game():
    global player, inventory, game_msgs, game_state
    
    #create object representing the player
    fighter_component = Fighter(hp=30, defense=2, power=5, 
                                death_function=player_death)

    player = GameObject(0, 0, '@', 'player', colors.white, blocks=True, 
                    fighter=fighter_component)

    #generate map (at this point it's not drawn to the screen)
    make_map()

    game_state = 'playing'
    inventory = []

    #create the list of game messages and their colors, starts empty
    game_msgs = []

    #a warm welcoming message!
    message('Welcome stranger! Prepare to perish in the Tombs of the Ancient Kings.', colors.red)</syntaxhighlight></div>


We have to declare some variables as global, since we're assigning them inside a function now.

Finally, the game loop, ''player_action = None'', and ''mouse_coord = (0, 0)'' belong to their own function now, along with another instance of ''fov_recompute = True'':


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">
def play_game():
    global mouse_coord, fov_recompute

    player_action = None
    mouse_coord = (0, 0)
    fov_recompute = True
    con.clear() #unexplored areas start black (which is the default background color)

    while not tdl.event.is_window_closed():

        #draw all objects in the list
        render_all()
        tdl.flush()

        #erase all objects at their old locations, before they move
        for obj in objects:
            obj.clear()

        #handle keys and exit game if needed
        player_action = handle_keys()
        if player_action == 'exit':
            save_game()
            break
            
        #let monsters take their turn
        if game_state == 'playing' and player_action != 'didnt-take-turn':
            for obj in objects:
                if obj.ai:
                    obj.ai.take_turn()</syntaxhighlight></div>


That was a lot of shuffling stuff around! Ok, just a couple of tiny changes left. Since the objects' list represents objects on the map, it makes sense to initialize it on map creation, so put it in ''make_map'':


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def make_map():
    global my_map, objects
    
    #the list of objects with just the player
    objects = [player]</syntaxhighlight></div>


Finally, after system initialization you need to call the new functions to start playing:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">new_game()
play_game()</syntaxhighlight></div>


That's it! The code is much tidier. If you don't care much about that, though, and prefer visible changes, then the next section is just for you!


== The main menu ==

To keep our main menu from appearing a bit bland, it would be pretty cool to show a neat background image below it. To do this, we'll have to borrow a function from libtcod-cffi. Starting with tdl version 3.1.0, libtcod-cffi's image functions can be used in tdl. It's one of tdl's dependencies, so it will already be installed on your system. Have a look at all the image-related functions
[http://libtcod-cffi.readthedocs.io/en/latest/tcod_ref.html#module-tcod.image here]!

Of course, since tdl emulates a console, we can't directly show arbitrary images, since we can't access the console's pixels. We can, however, modify the background color of every console cell to match the color of a pixel from the image. The downside is that the image will be in a very low resolution. However, Jice came up with a neat trick: by using specialized characters, and modifying both foreground and background colors, we can double the resolution! This is called subcell resolution, and [http://roguecentral.org/doryen/data/libtcod/doc/1.5.1/html2/image_blit.html?c=false&cpp=false&cs=false&py=true&lua=false this page] of the original libtcod docs shows some images of the effect (at the end of the page).

This means that, for our 80x50 cells console, we need a 160x100 pixels image. [http://roguecentral.org/doryen/files/menu_background1.png Here's the one I'm using], just download it and put it in your game's folder if you don't want to draw your own. I searched for real dungeon photos with a Creative Commons license using the advanced search in [http://images.search.yahoo.com/images/advanced Yahoo Images] (I tried it on [http://www.google.com/advanced_image_search Google Images] too but didn't get as many results), then fired up [http://www.getpaint.net Paint.net] to resize it and modify it as much as possibly to give it the feel of a fantasy setting: torches, no natural light, a guy with a sword, that sort of stuff. I found that stacking layers and using a brush with an extremely low alpha (a value of 3 or so) lets me draw things very gradually, since I'm not exactly an artist! It guess it's OK to spend some time with this since it may be the only actual image in the whole game.

In your imports section, let's bring in libtcod-cffi's image_load function:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">from tcod import image_load</syntaxhighlight></div>


Right, after that small detour, it's back to coding! Let's create a function for the main menu interface, and begin by loading and showing the image:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def main_menu():
    img = image_load('menu_background.png')

    #show the background image, at twice the regular console resolution
    img.blit_2x(root, 0, 0)</syntaxhighlight></div>


It's really easy. Notice the file name is a bit different from the image I linked earlier. We can now take advantage of our reusable ''menu'' function to present 3 options: start game, continue, or quit. Since the function also returns if the player presses a different key (canceled), we need to wrap it in a loop to present the menu again in that situation.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def main_menu():
    img = image_load('menu_background.png')

    while not tdl.event.is_window_closed():
        #show the background image, at twice the regular console resolution
        img.blit_2x(root, 0, 0)
        
        #show options and wait for the player's choice
        choice = menu('', ['Play a new game', 'Continue last game', 'Quit'], 24)
        
        if choice == 0:  #new game
            new_game()
            play_game()
        elif choice == 2:  #quit
            break</syntaxhighlight></div>


Let's test this out! In the main script, instead of starting a new game right away with ''new_game()'' and ''play_game()'', call our new function:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">main_menu()</syntaxhighlight></div>


The main menu is working now, apart from the "continue" feature which we'll get to later. Now it's time to add some fluff. Before calling the ''menu'' function, I want to show my game's title and, of course, the author's name! You will probably want to modify this for your own game, of course.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">        #show the game's title, and some credits!
        title = 'TOMBS OF THE ANCIENT KINGS'
        center = (SCREEN_WIDTH - len(title)) // 2
        root.draw_str(center, SCREEN_HEIGHT//2-4, title, bg=None, fg=colors.light_yellow)

        title = 'By Jotaf'
        center = (SCREEN_WIDTH - len(title)) // 2
        root.draw_str(center, SCREEN_HEIGHT-2, title, bg=None, fg=colors.light_yellow)
</syntaxhighlight></div>


You'll notice that the menu rectangle itself starts with a blank line. This is because the header string is empty, but this empty line causes the header to have a height of 1. To make that line go away, we need to check that condition in the ''menu'' function, between the lines ''header_height = ...'' and ''height = ...''.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">    if header == '':
        header_height = 0</syntaxhighlight></div>


Another detail is that the player may want to switch to fullscreen in the main menu. However, we only check that key during the game. It's fairly easy to copy that code to the ''menu'' function too, right after asking for the key:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">    if key.key == 'ENTER' and key.alt:  #(special case) Alt+Enter: toggle fullscreen
        tdl.set_fullscreen(not tdl.get_fullscreen())</syntaxhighlight></div>


Finally, extensive testing shows that starting a new game, going back to the main menu with Escape and starting another game results in a bug! In the second game, parts from the first are still visible. For the screen to always start black we need to clear the console in ''play_game()'', right after ''fov_recompute = True''.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">
    con.clear()  #unexplored areas start black (which is the default background color)</syntaxhighlight></div>


There it is, a neat main menu, and with only a handful of lines of code! 


== Saving and loading ==

If you've tried it before in other languages, this probably sounds scary. It usually means tracing every last bit of state information in your game and cramming it into a raw stream of bytes. Not in Python -- the Pickle module is capable of doing that with only a few function calls!

But we can do even better by using the Shelve module: its interface is a simple dictionary. If you haven't used dictionaries before, check the [https://docs.python.org/3/tutorial/datastructures.html#dictionaries Python tutorial on the subject]. They're extremely useful, replacing lists in situations where you wish to index elements not by their position on the list, but by an arbitrary name, number, or any other key.

A Shelve allows you to store any object in a file, indexed by a string (for example, the original variable's name). So to store the map tiles and game objects in a file called "savegame", we only need to call:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def save_game():
    #open a new empty shelve (possibly overwriting an old one) to write the game data
    with shelve.open('savegame', 'n') as savefile:
        savefile['my_map'] = my_map
        savefile['objects'] = objects
        savefile.close()</syntaxhighlight></div>


I bet your jaw just dropped over how easy it is to save a game in Python; mine sure did the first time I learned this! Just rinse and repeat for all your game state variables, and don't forget to call ''close'' at the end. The Shelve module will recursively find everything referenced from these variables onwards, so tile instances referenced by the map will be saved, as well as components referenced by game objects, which in turn are referenced by the objects list.

The only quirk to keep in mind is when more than one variable references the same object. For example, the objects list references the player object, but the ''player'' variable also references it. Normally this doesn't present a problem, but the Shelve module doesn't keep track of shared references between different dictionary entries. So if you try this:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #FDECEC"><syntaxhighlight lang="python">         file['player'] = player</syntaxhighlight></div>


You'll get two player objects when you load! Because one instance will be saved by ''file['objects'] = objects'' and another by ''file['player'] = player''. To avoid this we'll just save the index of the player in the list:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">        file['player_index'] = objects.index(player)  #index of player in objects list</syntaxhighlight></div>


Here are a few more variables to keep. Also, don't forget to ''import shelve'' at the top of your code.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">        file['inventory'] = inventory
        file['game_msgs'] = game_msgs
        file['game_state'] = game_state</syntaxhighlight></div>


To automatically save when the player quits, call the new function in ''play_game'', right before the ''break'' line:


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">            save_game()</syntaxhighlight></div>


That's all for saving. Loading follows the same procedure, except we assign to our variables the contents of the Shelve dictionary. Since we're assigning values to global variables, they need to be declared as such. The ''player_index'' we stored lets us assign the ''player'' variable to the correct object in the ''objects'' list. Having completely restored the core variables of the game, we can initialize the FOV map based on the loaded tiles.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def load_game():
    #open the previously saved shelve and load the game data
    global my_map, objects, player, inventory, game_msgs, game_state
    
    with shelve.open('savegame', 'r') as savefile:
        my_map = savefile['my_map']
        objects = savefile['objects']
        player = objects[savefile['player_index']]  #get index of player in objects list and access it
        inventory = savefile['inventory']
        game_msgs = savefile['game_msgs']
        game_state = savefile['game_state']</syntaxhighlight></div>


We can now add new functionality to the ''main_menu'' function, so the player can actually continue a previous game! It needs to be wrapped in a try-except clause, because Shelve will throw an error if loading fails somehow (file doesn't exist, is corrupted, etc). If something goes wrong we just display a message about it and carry on. I also defined a new handy ''msgbox'' function for important messages like this.


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">        if choice == 1:  #load last game
            try:
                load_game()
            except:
                msgbox('\n No saved game to load.\n', 24)
                continue
            play_game()</syntaxhighlight></div>


And ''msgbox'' relies on the ''menu'' function entirely. We could call it directly instead of this ''msgbox'', but in my opinion this makes code more readable by clearly conveying the intent (a message box instead of a list of options).


<div style="padding: 5px; border: solid 1px #C0C0C0; background-color: #F0F0F0"><syntaxhighlight lang="python">def msgbox(text, width=50):
    menu(text, [], width)  #use menu() as a sort of "message box"</syntaxhighlight></div>


That concludes the code for the main menu, saving and loading. A nice side-effect is that if the player quits after dying and then tries to continue, the character will still be dead! (Because ''game_state == 'dead' ''.) So by saving to different files you could easily create "mortem" files so the player can remember previous lost games, which is pretty cool.

You can easily use the main menu as a template for other screens, like game options or character creation. And as you continually upgrade your game you'll sometimes have to add more state variables to the save/load functions; but hopefully with the Shelve module it won't be too bad. Keep an eye out for the quirk [http://roguebasin.roguelikedevelopment.org/index.php/Complete_Roguelike_Tutorial,_using_python%2Blibtcod,_part_10#Saving_and_loading I talked about earlier], if you ever get duplicated objects or strange behavior after loading.


The whole code is available [[Roguelike Tutorial, using python3+tdl, part 10 code|here]].

[[Roguelike Tutorial, using python3+tdl, part 11|Go on to the next part]].

[[Category:Developing]]