J
Jacob H
Hello list...
I'm developing an adventure game in Python (which of course is lots of
fun). One of the features is the ability to save games and restore the
saves later. I'm using the pickle module to implement this. Capturing
current program state and neatly replacing it later is proving to be
trickier than I first imagined, so I'm here to ask for a little
direction from wiser minds than mine!
When my program initializes, each game object is stored in two places
-- the defining module, and in a list in another module. The following
example is not from my actual code, but what happens is the same.
(code contained in "globalstate" module)
all_fruit = []
(code contained in "world" module)
class Apple(object): # the class hierarchy goes back to object, anyway
def __init__(self):
self.foo = 23
self.bar = "something"
globalstate.all_fruit.append(self)
apple = Apple()
I enjoy the convenience of being able to refer to the same apple
instance through world.apple or globalstate.all_fruit, the latter
coming into play when I write for loops and so on. When I update the
instance attributes in one place, the changes are reflected in the
other place. But now comes the save and restore game functions, which
again are simplified from my real code:
(code contained in "saveload" module)
import pickle
import world
def savegame(path_to_name):
world_data = {}
for attr, value in world.__dict__.items():
# actual code is selective about which attributes
# from world it takes -- I'm just keeping this
# example simple
world_data[attr] = value
fp = open(path_to_name, "w")
pickle.dump(world_data, fp)
fp.close()
def loadgame(path_to_name):
fp = open(path_to_name, "r")
world_data = pickle.load(fp)
for attr, value in world_data.items():
setattr(world, attr, value)
fp.close()
The problem is that the game objects only get overwritten in the world
module. The instances in the globalstate.all_fruit list remain
unchanged, which is not the behaviour I want. I started to write code
to get around this. I figured that with each loadgame call, I could
reset all the lists in globalstate to empty, then reappend each game
object to the appropriate list. But this possibility got complicated
fast, because all game objects belong to more than one list. My apple
instance alone would belong to globalstate.all_things,
globalstate.all_fruit, globalstate.all_items, and perhaps others. Some
of the game objects contained in these lists don't need to be a part
of capturing program state in the first place! But I'm stuck, because
unpickling (so far as I understand it) creates a brand new instance
that doesn't know it used to have references to itself in the
globalstate lists.
Any advice out there? I'm looking for a clean, elegant way to
overwrite the same class instance in two arbitrary places at once.
Perhaps the example code I've provided isn't even the best way of
saving and restoring program state. Perhaps I can easily update my
globalstate lists and I'm just overlooking the simple way. Or perhaps
the solution lies in abandoning the concepts of referencing my game
objects through module attributes and lists. I'm open to any
suggestions.
Thanks in advance for any help!
Jacob
I'm developing an adventure game in Python (which of course is lots of
fun). One of the features is the ability to save games and restore the
saves later. I'm using the pickle module to implement this. Capturing
current program state and neatly replacing it later is proving to be
trickier than I first imagined, so I'm here to ask for a little
direction from wiser minds than mine!
When my program initializes, each game object is stored in two places
-- the defining module, and in a list in another module. The following
example is not from my actual code, but what happens is the same.
(code contained in "globalstate" module)
all_fruit = []
(code contained in "world" module)
class Apple(object): # the class hierarchy goes back to object, anyway
def __init__(self):
self.foo = 23
self.bar = "something"
globalstate.all_fruit.append(self)
apple = Apple()
I enjoy the convenience of being able to refer to the same apple
instance through world.apple or globalstate.all_fruit, the latter
coming into play when I write for loops and so on. When I update the
instance attributes in one place, the changes are reflected in the
other place. But now comes the save and restore game functions, which
again are simplified from my real code:
(code contained in "saveload" module)
import pickle
import world
def savegame(path_to_name):
world_data = {}
for attr, value in world.__dict__.items():
# actual code is selective about which attributes
# from world it takes -- I'm just keeping this
# example simple
world_data[attr] = value
fp = open(path_to_name, "w")
pickle.dump(world_data, fp)
fp.close()
def loadgame(path_to_name):
fp = open(path_to_name, "r")
world_data = pickle.load(fp)
for attr, value in world_data.items():
setattr(world, attr, value)
fp.close()
The problem is that the game objects only get overwritten in the world
module. The instances in the globalstate.all_fruit list remain
unchanged, which is not the behaviour I want. I started to write code
to get around this. I figured that with each loadgame call, I could
reset all the lists in globalstate to empty, then reappend each game
object to the appropriate list. But this possibility got complicated
fast, because all game objects belong to more than one list. My apple
instance alone would belong to globalstate.all_things,
globalstate.all_fruit, globalstate.all_items, and perhaps others. Some
of the game objects contained in these lists don't need to be a part
of capturing program state in the first place! But I'm stuck, because
unpickling (so far as I understand it) creates a brand new instance
that doesn't know it used to have references to itself in the
globalstate lists.
Any advice out there? I'm looking for a clean, elegant way to
overwrite the same class instance in two arbitrary places at once.
Perhaps the example code I've provided isn't even the best way of
saving and restoring program state. Perhaps I can easily update my
globalstate lists and I'm just overlooking the simple way. Or perhaps
the solution lies in abandoning the concepts of referencing my game
objects through module attributes and lists. I'm open to any
suggestions.
Thanks in advance for any help!
Jacob