Previous Blog Next Blog
Prev/Next Blog
by date

A Thought on Saving the Game

A Thought on Saving the Game
Name:Greg Tedder 
Date Posted:Dec 31, 2007
Rating:Not Rated
Public:YES
Comments:YES
RSS Feed:GarageGames Blog feedor Subscribe with .
Profile Page:View profile page for Greg Tedder

Blog post
The power of a scripting language is a beautiful thing. While you can stand to loose a few FPS, the flexibility that comes with a scripting language versus that of a compiled language is in itself powerful. Take for example, naming multiple gui components in the gui editor and then accessing them as an array from the engine. While treating the names exactly as an array will throw an error, simply concatenating the numbers in the proper place will render the variable name in real time. So when trying to come up with a way to save the game, I have decided to go with the obvious. While this has yet to be fully tested, it should give enough theory to help anyone get started on saving a game.

Writing out a file has rarely been a problem. It is reading the file back in that tends to carry the work load. In any language, reading a file back in line by line can be a tedious process. The last file I remember writing a reader for was the AC3D files format, which is one of the cleanest file formats I have ever seen, but still not a joy to work with. Even using XML and their parsing API's can put more work on the plate than any one programmer could want.

This brings me to a solution I imagine many developers use. Since I am writing my game in TorqueScript, why not save the game into a TorqueScript file. My thought is to write out a TS file with single line commands that can be evaluated line by line when loading the game. All of the needed save variables will be contained within a series of four or five global sets which will make loading and saving easy. A lot of the repetition can be written in set functions rather than saving it all out to the file each time.

There is also the possibility of compiling the written cs file in order to preserve data integrity in multiplayer games where cheating effects other players. Of course, there are many that feel it is important to keep cheating out of single player games, and I am unsure of how I feel on the topic at this point. Before this week is over, I hope to have this fully tested.

Recent Blog Posts
List:09/14/08 - The constant tweak of an RPG
05/25/08 - Flat Tile to Isometric
03/04/08 - Will Macintosh Intel Graphics Work for TGB
03/02/08 - Aeges Road Alpha Testing
12/31/07 - A Thought on Saving the Game
11/04/07 - As it is with Aeges Road
08/26/07 - Aeges Road, The Time Draweth Nigh
07/23/07 - Finding My Way Around

Submit ResourceSubmit your own resources!

Ramen-sama   (Jan 01, 2008 at 02:50 GMT)
I overcame this issue by writting out script commands into the save file itself.

stuff like this.

%player.health=100;
%player.hasitem[sword]=true;

and then you can exec the whole file, or just one line at a time to overwrite any variables in use.
Edited on Jan 01, 2008 02:52 GMT

You must be a member and be logged in to either append comments or rate this resource.