[Ohrrpgce] run game ideas

Ralph Versteegen teeemcee at gmail.com
Fri Nov 11 04:39:39 PST 2016


On 12 November 2016 at 01:36, Ralph Versteegen <teeemcee at gmail.com> wrote:

> James had suggested that it should check for both .rpg and .rpgdir, but it
> sounds as if he might have already forgotten :)
>
> I'm not sure whether to:
> - only accept the filename without extension
> - accept with valid extension and check that extension first before trying
> others
> - accept with a valid extension, but discard it and check in predefined
> order
>
> I was planning to do the third one.
>
> As for .zrpg, I guess that's one alternative. I had been thinking about
> doing lump-by-lump compression instead using zlib/gzip, indicating a
> compressed lump with a .gz extension. (All three default to exactly the
> same algorithm, DEFLATE, but .zip also supports a number of other
> algorithms in recent versions.) For example, there's no point compressing
> .ogg files.
> Note that there's no compression benefit to zipping the whole .rpgdir
> folder, because .zip files compress each file individually. On the other
> hand if you .zip an .rpg file (in the existing lumped format), you can't
> efficiently seek to any of the lumps, you would be forced to unlump it to
> play it. We're very close to supporting playing .rpgs without needing to
> unlump them, which will be great for Android.
>
> Advantages of .zip format:
> - can use different compression methods for different file formats,
> including no compression for audio files
>
Should have gone in the "Both" category, since both can do this.


> - possible to use better compression algorithms supported by .zip, like
> LZMA, if we find a zip library that supports it; we won't care about these
> formats only being supported by a subset of .zip implementations.
> - no need to check for multiple lump names with different extensions
>
> Advantages of explicit per-lump compression:
> - possible to just keep using .rpg extension while showing an appropriate
> "unsupported version" error message in old versions instead of "corrupt
> .rpg", by not compressing .GEN and ARCHNYM.LMP lumps
> - zlib is a small, very popular and very stable library to read/write
> gzip/zlib streams
> - we can switch to any better compression algorithm in future (e.g. LZMA,
> brotli) by changing an internal lump name, and with a single library for a
> specific purpose instead of a possibly bloated zip library supporting many
> algorithms
>
> Both good or bad:
> - deprecating the lumped-file format (at least for .rpg files) and
> switching to a standard one, vs. continuing to use our existing lump and
> unlump tools
>
> I don't even know what the popular libraries for reading/writing .zips
> are. A little searching suggested Info-ZIP, libzip and 7zip. zlib was
> actually split off Info-ZIP. Info-ZIP supports DEFLATE and bzip2 only.
> libzip supports DEFLATE only.
>
>
> On 11 November 2016 at 07:10, Michael Kidder <mkidder at gmail.com> wrote:
>
>> yeah, i mostly bring it up because i was thinking about it and "best
>> practice" would always to be to write  a check for both .rpg and .rpgdir -
>> so might as well push it up into the engine so it's done automatically
>> every time, and if the extention changes later for new games then it just
>> keeps working.
>>
>> On Thu, Nov 10, 2016 at 10:27 AM, James Paige <Bob at hamsterrepublic.com>
>> wrote:
>>
>>> 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-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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20161112/144683d2/attachment-0001.htm>


More information about the Ohrrpgce mailing list