[Ohrrpgce] run game ideas

Sun Nov 6 19:08:41 PST 2016

Ah, OK. Once dicts/hashmaps/tables are implemented you could put all your
session variables in one table, and pass that back and forth, either by
putting it in a global, or passing it as an argument to the other game's
newgame/loadgame script. Your scheme is definitely more elegant than those
two alternatives, but right now would require either modifying hspeak/file
formats/the interpreter and matching up session variables by name (to make
them look like globals), or alternatively accessing them only via get/set
commands. In future you would probably be able to implement "load/save
session variables" as scripts.

On 7 November 2016 at 03:53, Michael Kidder <mkidder at gmail.com> wrote:

> 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-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/20161107/6528ad55/attachment-0001.htm>