[Ohrrpgce] run game ideas

Ralph Versteegen teeemcee at gmail.com
Thu Nov 3 20:58:31 PDT 2016


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-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/20161104/8819ce26/attachment.htm>


More information about the Ohrrpgce mailing list