Screenshot Saturday #3
Most of the work I’ve done on Lenna’s Inception this week has been related to saving and loading games, and as such is invisible. New screenshots are here regardless.
Saving and loading
Selected parts of the game model are serialized into XML with XStream, and zipped up into the “save file” when saved. If I was not being so strict about the MVC design, this would be a real mess.
An aside about the game model
Like in Zelda games, the current map and current room’s state is not saved, which means enemies come back to life when you load a save (or re-enter a map).
But it is still possible to make permanent changes to the map data in-game. Examples from Zelda would be blowing up a cracked wall with a bomb or defeating a boss enemy. The wall stays blown up and the boss stays dead, even after you exit and re-enter the map.
In Lenna’s Inception, this is handled through having multiple levels of persistence, which I’ve implemented as a hierarchy of mirrored game models. Essentially, changes from higher mirrors propagate to lower mirrors, but not the other way. The highest persistence levels are saved, but not the lowest.
The same technique will also (hopefully) lead to easy client-side prediction in networked games.
I might post more about this another time.
I added the status bar to the bottom of the screen, which contains the tools the player has equipped to the Z, X and C keys, the amount of money the player has, and their current health.
There’s space for more things on the status bar, but I haven’t decided what to put there yet. Maybe that 48x16 pixel space could be used to display the keys the player currently holds.
Health and damage
Mobs now keep track of how many hearts they have, and are erased from the scene upon reaching zero. Except in the case of the player. There is no player-death yet, because I haven’t implemented the view components and menus for it yet.
At present, only the player can take damage (by touching orange or green slimes). The code is all there for all kinds of mobs to take damage, there just aren’t any weapons to inflict the pain.
I’ve done some more thinking about procedurally-generating dungeons, and I think it is possible to add on-off switches to dungeons by keeping track of two preconditions for each room: the set of symbols the player definitely must have to get there, and the set of symbols the player might have when there. No SAT-solver necessary.
Consumable keys are more difficult because they actually modify the environment, not just the player (you can only pick up a key once).
I’ll post Part II when I have more concrete information.
blog comments powered by Disqus