16 replies to this topic

[Manuel777]

Do the game_save()/load() functions where deprecated? they dont seem to work on any platform, and they doesnt show up on the help file as deprecated either..

Edit: To clear any possibilities, Im just using game_save("filename.ext") without any path, maybe now we have to add a path to make it work?

Edited by Manuel777, 08 June 2012 - 05:10 PM.

[NakedPaulToast]

They're gone.

[Manuel777]

They're gone.

Hmmm.. any explanation from the yoyo guys? they where extremely useful functions

[alexandervrs]

They're gone.

Huh? They do work on Windows that I've tested. The working_directory just moved to the local appdata folder.
EDIT: Currently working_directory has a bug with save files

Edited by alexandervrs, 08 June 2012 - 06:10 PM.

[GameDevDan]

I thought they were getting rid of them too. INI files are the way to go...

[titusthreex]

INI files were designed to store settings, high scores or small data. It wasn't designed to save an entire Metroid clone game with hundreds/thousands of object instances, room settings, etc.

[Mark Overmars]

These functions never saved the whole game status, only the most important part of it. But with professional games that is almost always not enough. The designer really needs to determine what to save and what to not save. So it is now left to the designer. And normally it is really easy because you do not want people to save the game at any moment but only at some reasonable points (like end of level). (Remember, saving also costs time and interupts the game.)

Mark

[cotycrg]

INI files were designed to store settings, high scores or small data. It wasn't designed to save an entire Metroid clone game with hundreds/thousands of object instances, room settings, etc.

...why not? It's perfectly feasible.

[alexandervrs]

These functions never saved the whole game status, only the most important part of it. But with professional games that is almost always not enough. The designer really needs to determine what to save and what to not save. So it is now left to the designer. And normally it is really easy because you do not want people to save the game at any moment but only at some reasonable points (like end of level). (Remember, saving also costs time and interupts the game.)

Mark

I suppose that makes sense.

INI files were designed to store settings, high scores or small data. It wasn't designed to save an entire Metroid clone game with hundreds/thousands of object instances, room settings, etc.

I think that you could also make use of the file_text & file_bin functions if you wish to store large data e.g. data structures.
Although I don't think saving those in ini will have any difference, and you can have them neatly stored and accessible in section/keys too like,

[player]
lives=3
weapons=010101000010111100001101010000101001010101...
items=0101010000101001010101101010000101001010101...

etc.

Is there any filesize read/write limit in inis?

Edited by alexandervrs, 10 June 2012 - 03:04 PM.

[Manuel777]

That makes sense, thanks for clearifyng Mark! I've passed my saving/loading codes to .ini files yesterday anyway. ^^

[BorisE]

I think the problem was that the save and load function saved and loaded instances and their variables, but didn't save data structures, runtime generated sprites, or paths. This was compounded by the fact that there was no "on_save" or "on_load" event.

Some years ago I used the Turbo Pascal Objects system, which implemented an object loading and saving scheme. If I recall correctly objects inherited some basic store and load functionality, but it was up to the designer to derive from the appropriate methods and add code to save and reload additional fields or data blocks. Applying this to GM might need some tweaking but the idea would be to itterate through all instances using a "with" clause and only those that had "state" that needed saving would respond by dumping data to a stream. On loading the objects would be recreated from the data in the stream. Any objects with additional data, such as data structures, could either write the structure and reload it, or could simply recreate the structure when reloaded (depending on whether the structure contained game state or simply duplicated other data).

Incidentally an example of a structure that could be recreated as needed would be the wall tile map from a platform game. It is needed for the game to function but can be regenerated from the room data at any time so does not need saving.

[BorisE]

Incidentally is the "Restart game" action on its way out? It seems to do nothing in HTML5.

[Erik Leppen]

INI files were designed to store settings, high scores or small data. It wasn't designed to save an entire Metroid clone game with hundreds/thousands of object instances, room settings, etc.

I think that you could also make use of the file_text & file_bin functions if you wish to store large data e.g. data structures.
Although I don't think saving those in ini will have any difference

In my experience INI files are very slow for anything beyond a few kB.

[alexandervrs]

INI files were designed to store settings, high scores or small data. It wasn't designed to save an entire Metroid clone game with hundreds/thousands of object instances, room settings, etc.

I think that you could also make use of the file_text & file_bin functions if you wish to store large data e.g. data structures.
Although I don't think saving those in ini will have any difference

In my experience INI files are very slow for anything beyond a few kB.

Shouldn't this rely to the parser? Doesn't Studio have any optimization for faster file handling?
Haven't tested the speed but kinda makes me wish we had XML or sqlite support :/

Edited by alexandervrs, 10 June 2012 - 06:07 PM.

[kburkhart84]

I don't think the speed of an INI really matter in this case. One, even saving a few "string-converted" data structures isn' over a few kBs, and even if it was, it isn't something you are doing "real-time" rather something you are doing from a pause menu, or between levels, so it shouldn't matter much.

[Manuel777]

A small hang upon loading has proven to be more than acceptable when playing games, even on Operative Sistems.. just look at Microsoft


Ps: Feels weird when games doesnt have any loading screens tho!

Edited by Manuel777, 11 June 2012 - 03:15 AM.

[cotycrg]

If you're worried about the speed of an ini file you're just being silly.

Just make "save points" and "load point," and let the user know what is going on. I always have a flashing "loading" when loading ini files, no matter the size. This is because some users have slower/faster SD cards in general (when thinking in terms of mobile development). You never know the exact delay, or if there will be one at all.

Just cleverly code.