Dev Diary #1 : A patchwork quilt and a save/load system.

Alrighty, so the fundamental structure of my game world is a series of areas, you can travel between areas by walking through certain triggers. Think Neverwinter Nights or Baldurs Gate. If you are in the forest, walking along the path, at one point of it you enter a trigger which loads up the next map. Similarly with leaving the city gates, dungeon entrances etc. So my game world is somewhat like a patchwork quilt, the areas are patches, sewn together by these "paths", which transition the player between them. This was easy to set up, theres an excellent resource on this site about "Mission Portals", which gives you this functionality.

I am now working on a save/load system. When I was last developing (months ago), I decided to leave this feature for later, mainly because I thought it would be difficult, and not really exciting to work on. This time round I am working on it first. If I go ahead and develop other features, when I decide to implement it later I would need to build it around how I've implemented all those other features. Fitting a square peg into a round hole. Far better to build the system now, then when I do the rest I can build them with this save/load framework in mind.

I was at first going to do the file io myself, using fileobjects, doing the parsing etc by hand. But there is a much, much, MUCH better way. I can't claim credit for this one, its something I read on Clint Brewer's site, www.unearthedGames.com, in his dev diary.

Basically, if you look at the missionfiles, torque already has the ability to write and read simgroups. It writes the simgroup, and recursively writes all members of that simgroup. Then, you can exec the file to get all that data back. If you want to add fields to the objects, you can make use of the dynamic fields in TorqueScript. Awesomeness. Not only that, all the parsing is handled for you. Want to save some vectors, strings and matrices? No problem, just refer to these fields by their names, Torquescript will do the rest for you. Double awesomeness.

So , for example you can do something like this (note this is not the actual code, just a general idea of what it'd be like) :

function save(%player, %savefile)
{
new Simgroup(SaveData);

new Simgroup(PlayerInfo);

SaveData.add(PlayerInfo);

PlayerInfo.name = %player.name;
PlayerInfo.health = %player.health;
PlayerInfo.mana = %player.mana;

new Simgroup(PlayerInventory);

PlayerInfo.add(PlayerInventory);

// dummy vars for now...
PlayerInventory.LeftHandSlot = "longsword";
PlayerInventory.RightHandSlot = "tower shield";
PlayerInventory.HeadSlot = "Helmet of Sheer Awesomeness";

SaveData.save(%savefile);

SaveData.delete(); // since the info is safely on file, no longer need this object floating around.

}

function load(%player, %savefile)
{
 exec(%savefile);

//you can now get values from the objects that you created above. Execing the file creates all the objects again. :D
// initialise your game objects from the save info

%player.name = PlayerInfo.name;
.
.
.
//free up the memory once you no longer need it.
Savedata.delete();

}

This is very easy to do, and lets you use all the functionality built into simgroups/simobjects. I am really gaining an appreciation for those sim-type-objects, they've got nice search abilities built in, the dynamic field capabilities, the saving/loading, the parsing stuff. Very flexible. Booya.

So I've got a basic implementation of that done, it saves out some playerinfo, mostly dummy variables for now, but also the mission and player transform. Combine that with the patches/mission portals stuff I talked about earlier, it means you can wander from region to region, save the game, and when you load it up again it loads you in the right mission, at the right place, facing the right way. As simple as going %Player.setTransform(PlayerInfo.transform); . Nice.

Which brings me to where I am now. That functionality is nice, but I need this to be able to handle saving all the NPCs, monsters, quests, game state flags etc. The way I see it, there are two types of save info. General saveinfo, that is pertinent to any region you are in (gamestate flags, player info, quest/journal flags etc), and region save info. Region save info is all the save info pertinent to a specific region, NPC data, monster data, container data etc. Ie, stuff you need to know while in a region, but there is no need for it to be floating around in memory when you leave it. Say you have 100 monsters in a region, all with health/mana/position etc that need to be saved, and 20 regions, it could add up to a bit of memory.

So my current idea is to have a "temp_data" folder, which is used while the game is running. This, using the above save/load method, keeps track of game data. When you leave a region it saves a file representing that regions data (SpookyForest.dat for example) to the "temp_data" folder, and when you enter a region it looks for a file corresponding to that region in that "temp_data" directory. If it finds it, it loads up the saved data from it, otherwise it initialises the defaults for the region from the mission file, ie creating NPCs at spawnmarkers etc.

When you quit your game, all the files in "temp_data" are deleted. If you save your game beforehand, it copies all these files to your save directory (might pack it into one file and encrypt it while doing so, but that is something to think about later). It will also save out an additional file, "general.dat", which contains all the general info I talked about, player stats, quest flags etc. When you load your game, it copies all the files in your save dir into the "temp_data" directory, and uses them to setup the game. If you start a new game, it will simply run a script to setup the default "general" info, and then when it loads the initial region, since there are no files for it in the "temp_data", it will load the defaults from the mission file.

So this method allows me to only have data pertinent to the region I am in loaded. I haven't implemented it yet, but it doesnt seem to hard. I am interested to see if anyone thinks that this is unneccessary. Am I just making work for myself? Perhaps I should just have a big structure, with all data for all regions, floating around in memory, and save/load it as needed? Am I just making unnecessary work for myself? Or perhaps someone has a better method? Would be great to hear about it ;).