I have a couple of ideas regarding system defined variables. The first one I would find immediately useful. The second one is more of a request for discussion than for an immediate feature.
- game.name - Would it be possible to add a game.name or game.filename variable so that one could find the file name of the game that is running from within the game. If implemented, the current game's name wouldn't need to be specified by the user. A String containing the file name without the extension would work just dandy.
- gs_globals - The documentation says that these are obsolete and so nobody should use them in a new design. Presummably they are still in the engine for compatibility reasons and because CJ hasn't gotten around to removing them yet. Anyway what would everyone think about making gs_globals "persistent" so that the data contained in the gs_global array would survive RestoreSaveSlot() and RunAGSGame() operaqtions? I suppose it could be an option if compatibility was an issue.
Currently it is nearly nearly impossible to set a flag or state that will be preserved after a restore operation is complete. Even writing the data to a file is a bit tricky because you still need to know when to read the file.
Currently there is an option to retain the values of global ints through RunAGSGame(). The problem is that global ints are in fairly common usage and a module that required them to be used a certain way would be an intolerable annoyance to many wouold be users of the module. Since the use of gs_globals ought to be much less common such a module requirement should be proportionatly less annoying.
Anyhow, feel free to flame away! ;)
For your second suggestion: an alternate and more flexible solution could be if there were some statements that read/write data in the savegame.
AGS could provide an unlimited list of key/value pairs and when a game is saved, the game code would receive a callback to enter whatever data it would want into the list. When a game is loaded back, another script function would be called where the code could read back whatever data it saved.
This way, there would be an unlimited number of entries to save and each module could save/load its own set of values from this list. Here is an example mock-up:
before_game_save ( PropertyBag properties )
{
properties.AddOrReplace ( "MyModuleGlobal1", globalvar1 );
properties.AddOrReplace ( "MyModuleGlobal2", globalvar2 );
...
properties.AddOrReplace ( "MyModuleGlobalN", globalvarN );
}
after_load_game ( PropertyBag properties )
{
globalvar1 = properties.Read ( "MyModuleGlobal1" );
...
}
The PropertyBag object would have members like Add(), AddOrReplace(), Remove(), Count and ItemByIndex() and ItemByKey() to allow the manipulation of the list at save and load.
There could be a global function for the game itself and each module could also implement such a function so every module would have a chance to save its own data.
For the first one, I think it can be a good idea, cooping with other session specific variables, however, you have cases like this:
acwin.exe ac2game.ags
So what should be returned? "acwin.exe" or "ac2game.ags"? Though no matter which they're not very meaningful anyway.
IMO I'd rather game.name returns the name of your game set in the editor, it'd be even better if you can change it in-game so that the window$ info-bar could be changed within a game (not important to me anyway, as I hate window$ and I'd play games in fullscreen more).
For the second, I'm actually quite sad that the graphical script variables were considered obsolete, IMO they're MUCH MUCH better than Global Int's as you don't need to use the hard-to-master-for-n00b Set...() and Get...() functions, anyway, since we can import variables from global script directly now, neither gs_global[] nor Global Ints would be that important now. Personally I don't think making gs_global[] to be persistent a good idea, as it can break old codes and creates hard to trace bugs (though the chance of people still using them is small), I'd rather some NEW persistent variables to be introduced (if they're REALLY that important).
Traveler:
Yeah I'm doing something just like that with a data file that I write and read back which works just fine for the most part but weird situations can still occur. It would just be nice to have a simple way of retaining some state info between these kinds of operations. A better solution is also welcome of course. ;D
Gilbot:
Currently the exe in the compiled folder gets the game name from the game folder. So if the game folder is "MyGame" the exe created in the "Compiled" folder is "MyGame.exe" so I would like game.name to return "MyGame".
I think you didn't get what I meant.
If you compile game to a supported target (currently window$ only for recent versions) the executable would be created as GAMENAME.EXE right.
But in case you didn't want to package your game like that or run a game in that form (or you're using the *nix or MAC port of the engine) the above is not correct. For example you can just package the ac2game.ags file in the game's folder with an engine executable, and you may sometimes rename GAMENAME.EXE to ac2game.ags for it to run under a different version (or different port) of the engine. Seeing that there're so many ways to execute a game, many of which don't corresponding to run GAMENAME.EXE in the command line, retrieving the name of teh executable typed on the command line within a game is not very useful, apparently.
So in that case game.name would return "ac2game". What I want is the name of the game file that can be passed to RunAGSGame(). I can search for the different file types that RunAGSGame() accepts. If game.name could return the name of the game file (exe or ags) then users of the MiniGame module wouldn't need to explicitly specify the name of the game that is calling a mini game.
I suppoise it's not really that big a deal since it's necessary to hardcode the name of the mini game being called; it just seems to me to be a cleaner interface to only have to name the game you want to call and to have the return info done automatically.
Game.Name -- a new property to get/set the game name (ie. the name in the titlebar) is a good idea, should really be in already
Game.FileName -- a property to get the exe file name, I can see how it would be useful for use with RunAGSGame, so I'll look into it.
(Edit by strazer: AGS v2.72 Beta 6: * Added Game.Name and Game.FileName properties.)
QuoteAGS could provide an unlimited list of key/value pairs and when a game is saved, the game code would receive a callback to enter whatever data it would want into the list. When a game is loaded back, another script function would be called where the code could read back whatever data it saved.
But since AGS automatically saves all the script data anyway, I don't see what benefit this would bring. Any data you saved into the propertybag would also be saved automatically by AGS, thus you'd just be duplicating data, surely?
The difference would be, that plugins could use the same functionality, so plugins could save whatever data they want in the save game file and then retrieve it automatically. The current limit is about 5K, which is not too big.
I don't have much experience with AGS scripting, so there may be far easier ways to achieve the same result - if so, just disregard my suggestion, please.
Quote
Game.FileName -- a property to get the exe file name, I can see how it would be useful for use with RunAGSGame, so I'll look into it.
Thanks for having a think. Please keep in mind what Gilbot said; if the game was started by passing the AGS file to the engine then we would want the name of the ags file and not the engine runtime. Pretty sure you already thought of thid but just in case... ;)
Quote
But since AGS automatically saves all the script data anyway, I don't see what benefit this would bring. Any data you saved into the propertybag would also be saved automatically by AGS, thus you'd just be duplicating data, surely?
This came in response to my request or wonderings about being able to have a limited data set that would be unaffected by save/restore operations. The way it currently is, it is nearly impossible to know what was going on just before the restore operation is executed. I was just looking for an easy way to preserve a couple of flag/state variables to keep track of things and thought the now obsoleted gs_global array could possibly be used for this purpose.
[edit]
Btw, I just noticed this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=25216.0) in the Beginners Forum asking the very same question.
QuoteThe difference would be, that plugins could use the same functionality, so plugins could save whatever data they want in the save game file and then retrieve it automatically. The current limit is about 5K, which is not too big.
Well, plugins are pretty much another kettle of fish anyway, so if you're writing a plugin and the save buffer isn't big enough, just say so and I can increase it.
QuoteThis came in response to my request or wonderings about being able to have a limited data set that would be unaffected by save/restore operations. The way it currently is, it is nearly impossible to know what was going on just before the restore operation is executed. I was just looking for an easy way to preserve a couple of flag/state variables to keep track of things and thought the now obsoleted gs_global array could possibly be used for this purpose.
How much data would people generally want to be able to persist across save game loads? If one variable would be enough, I can add that easily enough, on the other hand if you'd want to store reams of data then a more elegant solution would be required.
Quote
How much data would people generally want to be able to persist across save game loads? If one variable would be enough, I can add that easily enough, on the other hand if you'd want to store reams of data then a more elegant solution would be required.
One variable or a small array would work just fine, IMHO. The gs_globals array had originally inspired this suggestion because they are now obsolete and they would have been more than enough for this purpose. Presumably they are inappropiate but anything remotely similar would be just perfect. Thanks.
[edit]
This would also provide an adequate solution to the Save/Restore issues I brought up in this earlier thread. (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24904.0)
The one issue remaining is that when the RestoreGameSlot() operation is executed it forces a screen transition, even if it is in the same room. I have modified the MiniGame module so that the player is restored to the room and position he occupied before the MiniGame call. At this point the transition from the minigame to the main game works like it should. However when the restore game operation runs another room transition to the same room occurs. One work around is to inform would be module users that they must put a dummy black room in their game and explain why. This is a bit hacky and may not work equally well with all transition styles. It would be nice if another solution were easily attainable.
Would it be possible/practical to add some kind of method of eliminating one of these room transitions perhaps by perhaps by allowing RestoreGameSlot() to be run from the game_start() interaction or by inhibiting one of the room transitions, via an optional parameter in the RestoreGameSlot() or ChangeRoom() functions, or anyother means of accomplishing the same thing.
For example:
Character.ChangeRoom(int room_number, optional int x, optional int y, optional int transition_style)
RestoreGameSlot (int slot, optional int transition_style)
game.transition_style
Where possible values for transition style would be:
eTransitionStyleNone - do not change screen
eTransitionStyleDefault - use game setting
eTransitionStyleInstant - instant
eTransitionStyleDisolve - disolve
eTransitionStyleFadeOutIn - fade out/in
eTransitionStyleBlackBoxOut - black box out
eTransitionStyleCrossFade - cross fade
Thanks fo listening
Cheers RickJ
Allowing RestoreGameSlot in game_Start is a possibility, I'll look into it.
RestoreGameSlot() in game_start() would be most excellent, thanks.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=560
Quote from: Pumaman on Mon 20/02/2006 20:06:48
Game.Name -- a new property to get/set the game name (ie. the name in the titlebar) is a good idea, should really be in already
Game.FileName -- a property to get the exe file name, I can see how it would be useful for use with RunAGSGame, so I'll look into it.
Tracker'd:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=562
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=563