[Ohrrpgce] run game ideas

Ralph Versteegen teeemcee at gmail.com
Sat Nov 5 03:16:41 PDT 2016


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-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/20161105/3e0fa903/attachment-0001.htm>


More information about the Ohrrpgce mailing list