[Ohrrpgce] run game ideas

Sun Nov 6 06:53:59 PST 2016

I guess you could also call them meta variables, or cache variables..

On Sat, Nov 5, 2016 at 5:16 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

> I didn't really understand what you meant by session variables. Sort of an
> 'overlay', that while active causes commands to read data from the save
> instead of the current game? That would be a possibly practical way to read
> data from a different rpg file (but can't deal with interdependencies
> between files, and you have to watch out for caches). Applying the same
> idea to saves sounds like what I suggested for loading only part of the
> data from a save, because that data needs to go into the relevant game
> state globals to be accessible, overwriting the previous state.
>
> One thing to think about is that it would be nice not to require the game
> 'sending' the data to cooperate by encoding the data into globals or
> whatever. For example, if you later publish an expansion or sequel to an
> earlier game, you might want to be able to pull stuff out of the save files
> without having to have planned ahead. (Plus, hijinks like save file
> inspection tools (but if you want that, you can use ))
>
> On 5 November 2016 at 03:01, Michael Kidder <mkidder at gmail.com> wrote:
>
>> That's why I like the idea of session variables or globals that you can
>> customize what data they transport and read it, since chainloading games
>> would definitely be an advanced feature in the first place, and what each
>> game wants to 'transport' would also be custom in the first place, so it
>> wouldn't be that far of a stretch to ask the scripter to make their data
>> transport on their own
>>
>> Also as a random idea, I could do a tech demo of this for April Fools..
>> do a parody of Sonic & Knuckles but with Bob or someone else in a bunch of
>> other games if you "lock" them on to Wandering Hamster (&Knuckles)
>>
>> On Thu, Nov 3, 2016 at 10:58 PM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> Yes, you could and would only transfer a save file to another game based
>>> on the original .rpg with largely the same data, a sequel or extended
>>> version basically. I don't see many other cases in which you would want to
>>> transfer a save file. You can remove and replace some parts of the original
>>> .rpg, though.
>>>
>>> Not long ago I fixed a crash that occurred when loading a save from a
>>> different game (which I did by accident, and didn't realise until
>>> afterwards) that put you on a non-existent map. It shows a visible error
>>> when that happens, but we could add a bitset to handle it silently. Then as
>>> long as you have a loadgame script to put the hero in a sensible starting
>>> location, you can just delete all the maps from the original game and
>>> replace them.
>>>
>>> Don't forget that NPCs still aren't saved/loaded (actually, they are
>>> loaded, but not saved).
>>>
>>> You also missed slice lookup codes, sprite and palette ids in the hero
>>> data, and gameover/loadgame script triggers.
>>>
>>> So the things you should preserve are mainly tags, items, spells, hero
>>> walkabout/battle sprites and palettes, shops, sprites palettes and lookup
>>> codes for any saved slices, and heroes.
>>>
>>> But you can easily replace (if you wanted to reduce the file size) maps,
>>> almost all graphics, enemies, formations, music and sound effects, and
>>> scripts. That seems quite practical to me.
>>>
>>> Alternatively we could have a command to load a saved game, but not end
>>> the current game (so the script continues running), with a bitmask to
>>> select certain data:
>>> -tags
>>> -globals
>>> -map data (currently just location; the normal settings for what gets
>>> loaded could just be respected)
>>> -heroes
>>> -maybe some bit to recompute certain hero data, e.g. stats or spell
>>> lists, from the current hero definitions
>>> -inventory
>>> -shop inventories
>>> -slices
>>> That should be very easy to implement. If you want to load heroes from
>>> another game there are quite a few dependencies on other data.
>>> But as far as I can see, the only use of this command would be when you
>>> want to transfer a save from an earlier version of the game,
>>> but want to wipe some of the data that's no longer compatible.
>>>
>>> On 4 November 2016 at 07:18, James Paige <Bob at hamsterrepublic.com>
>>> wrote:
>>>
>>>> I think the biggest issue with loading from other games save slots is
>>>> that saves have a lot of fixed id numbers, and those can't be expected to
>>>> be the same for other games
>>>>
>>>> I went through the RSAV documentation, and tried to make a list of all
>>>> the id numbers
>>>>
>>>> * current map state stores map id number, and stores NPC definition id
>>>> numbers
>>>> * tag state is all id number based, so are onetime npcs
>>>> * saved hero party state saves both slot id numbers and hero definition
>>>> id numbers
>>>> * spell lists are full of attack id numbers
>>>> * inventory state is full of item id numbers
>>>> * shops are also full of both shop slot id numbers and item id numbers
>>>> * saved slices might be full of sprite id numbers.
>>>>
>>>> Unless the other game that you are importing a save from is an almost
>>>> exact copy of all these things, I don't really see how loading a save is
>>>> going to be useful.
>>>>
>>>> a version of import globals that can read stuff from other games will
>>>> be very useful for scripting fun... and commands for importing more
>>>> specific data from other game's saves (or other save slots in the current
>>>> game) are reasonable (and wouldn't be too terribly hard to do)
>>>>
>>>
>>> Well aside from globals would other data would you want to load? There's
>>> a huge amount of possible data that could be loaded, translating to a huge
>>> amount of possible script commands.
>>> I guess the main things you might want to transfer another game are
>>> tags, heroes and inventories. If your new game isn't save compatible then
>>> you can't
>>> import any of those anyway, and we would be stuck creating individual
>>> commands to read hero level of party slot X of save Y of game Z...
>>> Quite a lot of stuff (who is in the party, what items you have) would be
>>> covered by reading tag data.
>>> One solution is to just (eventually) let people load an .rsav as a
>>> reload document directly, since loading from other saves is an advanced
>>> feature anyway.
>>>
>>>>
>>>> I think we need to look more carefully at how this should work--
>>>> especially at exactly what game authors want to accomplish with a
>>>> save-import feature.
>>>>
>>>> Just importing and loading some other game's rsav file is going to be
>>>> messy, and it isn't clear to me that it will be very useful.
>>>>
>>>>
>>>>
>>>> ---
>>>> James
>>>>
>>>>
>>>>
>>>> On Thu, Nov 3, 2016 at 10:39 AM, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>> Yes, we need a way to share saves. A fancy way would be commands to
>>>>> load/save a save from/to some other game,
>>>>> which would allow the sort of one-time conversion you suggest,
>>>>> but a simpler solution is just a setting to specify the name of the
>>>>> saves folder. (That sounds a lot like
>>>>> the packagegame for the game (used when distributing)). However I
>>>>> guess that would be bad
>>>>> if you went back to the original game and tried to load a save from
>>>>> the sequel/expansion; ideally you'd want saves
>>>>> to be marked as incompatible or something. Maybe this isn't a simple
>>>>> solution afterall.
>>>>>
>>>>> There are also some config files associated with each game (hidden
>>>>> away in the OHR's settings folder), and maybe those should be shared too.
>>>>> There's
>>>>> almost nothing stored in those settings currently, AFAIR just in-app
>>>>> purchases and whether to fullscreen.
>>>>>
>>>>> On 4 November 2016 at 01:53, Michael Kidder <mkidder at gmail.com> wrote:
>>>>>
>>>>>> This actually makes "DLC" / expansions more feasible now since if you
>>>>>> wanted to do it before, you have to tell people "oh yeah, just go in, copy
>>>>>> the file... rename it to gameexpansion.r .. okay, enable extensions, and
>>>>>> then go to.."
>>>>>>
>>>>>> Now you could just run a check to see if the user has installed the
>>>>>> .rpg file and modify an in game menu or NPC's dialog or whatever
>>>>>> seamlessly, that'd be pretty cool.
>>>>>>
>>>>>> Only thing i can think of is power users may want the ability to
>>>>>> bring the save from the original game to the called game. It would be up to
>>>>>> the developer to make sure both games stay compatible save wise. If this
>>>>>> causes too many issues, then making "session variables" that GAME preserves
>>>>>> only for the duration of being loaded would likely be enough for people to
>>>>>> bring data over from one game to another. Something to think about, anyway.
>>>>>>
>>>>>> On Tue, Nov 1, 2016 at 7:00 PM, Ralph Versteegen <teeemcee at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, I was planning to add a command like "check game exists" to
>>>>>>> work around this problem.
>>>>>>>
>>>>>>> Checking for both .rpg and .rpgdir is a good idea too.
>>>>>>>
>>>>>>> On 2 November 2016 at 04:26, James Paige <Bob at hamsterrepublic.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I was looking at the run game implementation.
>>>>>>>>
>>>>>>>> I saw this comment in the source:
>>>>>>>>
>>>>>>>> PRIVATE SUB run_game ()
>>>>>>>>  ' Not being able to load the game should always show an error (use
>>>>>>>> serrError for everything)
>>>>>>>>
>>>>>>>> I would definitely like to have the option of running a game with
>>>>>>>> the error silenced.
>>>>>>>>
>>>>>>>> For example, At the end of Quest.rpg I might have code that runs
>>>>>>>> Quest2.rpg even though the sequel does not even exist yet.
>>>>>>>>
>>>>>>>> One way to get this effect would be an argument to run game to make
>>>>>>>> it silent. (I don't really like this one.)
>>>>>>>>
>>>>>>>> Alternatively another command "run game if exists" that just does
>>>>>>>> the same thing without the error
>>>>>>>>
>>>>>>>> Finally, maybe an "is other game available($0="othergame")" check
>>>>>>>> that returns a boolean.
>>>>>>>>
>>>>>>>> Next, I was wondering if you do:
>>>>>>>>
>>>>>>>> run game($0="gamename.rpg")
>>>>>>>>
>>>>>>>> and gamename.rpg does not exist, should it automatically check for
>>>>>>>> "gamename.rpgdir" and nice-versa
>>>>>>>>
>>>>>>>> ---
>>>>>>>> James
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ohrrpgce mailing list
>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>> amster.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>> amster.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>> amster.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20161106/af32d4f2/attachment-0001.htm>