Single Player Persistence

#1 Finaly, I get to help out one of the users =) Yes you would absoutley have to use an database, that or you can use an textfile to read/write to, but since databases are more dynamic and has much beter security this would definitivly be the best solution. TGE does not support databases by default, so u gonna have to implent this urself, but its really easy, i recomend using this link for sqLite:

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5531

Also, if you never have used databases before, then you should try and read some of dreamers mmorpg articles, since they discus database design alot.

I would not recomend you to have persitceny in wheater if your green to making videogames, unless its crucial to your game design. Much feauturees that look cool on papper are not even noted by the users.

#2 I'm planning an RPG, so persistence is important. I'm not green to game development, as I've used the PG MMO Kit before. I used the PG Kit for RPG creation rather than MMO creation, but the kit doesn't really meet my needs anymore.

#3 And this is relevant to the question in what way? A Database give you all the persistence you need, provided you script it right. Wheter you want persistant weather or not is of course entierly up to you, i would just recomend not to, since i, as a potential user of your product, would not give a blazing fuck wheter the weather remained the same at the time i logged out and logged in again =)

On a side note, i think the link i provided only works on windows platforms.

#4 If it is a Single Player game, the best thing you can do i think is save your MissionGroup wich have almost everything you need... the player position, objects state, weather, enemys position and state and everything else, and you can put ScriptObjects there to hold others variables that you use too... So a MissionGroup.save("./player1.save"); might do the trick.

#5 So missiongroup.save puts all the current mission group data into a .save file or something? Or is there more to it than that?

#6 Yeah, all those objects that you see in the mission editor, that are inside the mission group are saved to a text file with the name you give, so you can easily save all your world state in a file that you can load later.

#7 Sorry, but that doesn't work. It just saves a copy of the mission, but the player isn't actually in the mission group. The player position isn't saved. Is there a way I can add the player to the mission group display? Or is there any easier way to do this? I know theres a command that is somthing like getPosition();, however I'm not sure how to write a script that uses it. By the way, I've got my player set up so its name is player. By this, I mean the name the engines sees it as, not the one you fill in when starting a mission.

#8 MissionGroup.add(player);

#9 My company just recently slogged through savegame stuff this past winter on a first-person adventure game. The easiest solution really is to use Torque's built-in persistance functions. You just need to make sure that all of your dynamically created script objects are stored in a special script group. We named ours "SaveGroup". So you would have a heirarchy like this:

RootGroup
--ServerGroup
----MissionGroup
----SaveGroup

This way you don't need to persist MissionGroup, as it is static and stored in the .mis file. You will most certainly have to heavily modify createPlayer and spawnPlayer in server/scripts/game.cs to check if the Player class already exists and use it. This should be relatively easy for single-player saves, since you could just name the Player "Player1."

The main advantages of saving this way is that you don't need to compile in support for databases, which generally are difficult to get working cross-platform (sqlite being an exception), and you can easily open up and read the files. And you don't need to do any parsing, since Torque will automatically deserialize for you. For an added layer of obfuscation, you can force compile the saves to .dso's and remove the .cs files.

Note of caution:

--If you want to save state variables that aren't already registered via addField, you will need to add them this way. That is the only way they will get written out. For complicated state information like linked lists and vectors, you should use addProtectedField and provide your own serialization methods.

We were able to get really good state dumps, so much so that we were able to save and restore while the player was driving a vehicle.

#10 For single player games one may also find that placing global variables as a pref and saving them with the normal pref's is very useful.

#11 You could always just use the MissionCleanup group for serializing all objects. the only thing in torque which would be a major issue saving is the current animation frame for animated objects.

#12 I don't need to save animation, just the position. Also, I've already got SQLite integrated into Torque using the UAC resource. I've got login/out functions, just not the saving of position. I'm going to mess with the SQLite and see if I can't get something worked out.