[Ohrrpgce] run game ideas

James Paige Bob at hamsterrepublic.com
Thu Nov 10 08:27:37 PST 2016 

That is true! We probably do want to have rungame take the filename without
extension-- either that or make it check all alternative supported
extensions if the requested one doesn't exist. ".zrpg" might indeed be a
thing someday.

---
James


On Thu, Nov 10, 2016 at 7:10 AM, Michael Kidder <mkidder at gmail.com> wrote:

> Also, this may be running a bit far ahead, but would it be a good idea to
> make some sort of futureproofing by only having scripters call the game's
> filename minus it's extension?
>
> To use WH an example, just call it in via checking for "wander". The
> engine would internally look for the .rpg first and then the .rpgdir . This
> would futureproof for future extension changes or engine branches without
> having to add logic catches later. For example, if someone wanted to add
> .zip loading support, they could make the engine check .zip then .rpg then
> .rpgdir and every game would immediately be made compatible without
> backwards compat shims . This would also let people easily change between
> .rpgdir and .rpg without having to recompile scripts or litter scripts with
> an OR check for both.
>
> It would be consistent with the OHR abstracting most gritty system details
> from the end user, as well, and has other benefits down the road that would
> leave the engine code cleaner and easier to maintain.
>
> On Sun, Nov 6, 2016 at 9:08 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>> 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-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/20161110/c0cfdac7/attachment-0001.htm>

More information about the Ohrrpgce mailing list