Importation

[Sophia]

This has been kind of a hot topic for a while, and it's the kind of thing that DSB probably really should support if it wants to call itself "fully functional," if only so people can play CSB the authentic way. Right now, none of what I'm talking about here is actually in DSB, and it's all just a proposal. Opinions/comments/suggestions are welcome.

I think DSB importation should be restrictive, that is, it only happens in pairs/groups of dungeons that will explicitly allow it. I don't want to try to auto-tweak the dungeon's difficulty like RTC does, and I don't even think I could get it working very well. (Truthfully, I don't think RTC's attempt to do so works very well either, but that's neither here nor there)

Portraits will likely not directly import. I just can't see a way that isn't messy. What I'm thinking will happen is that I will add a command something like dsb_party_import_start(import_id, level, x, y, facing, portrait_library), where import_id is a designator to allow importation from a certain dungeon/set of dungeons, and portrait_library is a table containing a list of strings designating the names of gfx table entries that are available as portrait images. I'll add a default one to the base code containing all DM, CSB, and DM-Enhanced portraits. This means that if the two dungeons make sure to make the same portraits available, the appearance that everything goes smoothly will still be preserved.

The code is the easy part, actually. The thing I'm struggling with is how to fit it inside the DM UI in a way that doesn't completely break the user experience nor create huge amounts of extra work for me. CSB did it with a separate utility disk, which is an option-- but probably not necessary given the greater capabilities of modern computers in general. I could do it like RTC does and give you the option when you click on the scroll, but then you'd have to choose where to import from, and since DSB uses the Windows API to render its dungeon chooser, I'd probably have to dump you back to Windows to avoid doing a whole lot of ugly work. The "utility disk" would run in Windows API anyway and wouldn't have this problem. Another option would be to add an "export" button (somewhere... I don't know where) which would explicitly create a file for exportation, that you'd save in the directory of the dungeon you wanted to import to. That dungeon could then load the import file like a savegame file from the normal resume button. It feels a bit clunky, and might be the best or worth of both worlds, depending.

Of course, we could always just declare the whole CSB approach to importing a thing of the past anyway and do nothing.

[Joramun]

It's more "immigration"

I thought a bit more about what i suggested on the chat, and I think a "text" transfer is not good, because it allows cheating too easily.

Here is my last thought, though the more I think about it, the less I'm PRO-import and the more PRO-nothing:

Of course, we could always just declare the whole CSB approach to importing a thing of the past anyway and do nothing.

But my solution would be the following:
- A flag that says if parties are exportable from a given dungeon (set to "true" for CSB and DM)
- A flag that says if parties are importable in a given dungeon (set to "true" for CSB and DM)
- An additional button "import party" that would be able to import the party from any savegame from a dungeon which allows export, to a dungeon that allows import.

Now, there is always the risk that some dude will make an import-export allowed dungeon to train it's characters.

[ian_scho]

In the long term the 'importation' idea is a good one as it allows dungeon designers to create chaptered stories... So I guess that you don't need to prioritise this work yet!

Joramun's "flag" idea is a good one. I'd say that all party members should be exportable though - who cares otherwise?

As to how to do it....

Code: Select all

c:\dsb\>dsb_import.exe \dm\dungeon.dsb \csb\dungeon.dsb -cHULK -cDARO -cSTAM -cGOTH

Maybe we don't even need the "\dungeon.dsb", tbh.

The utility will import each into each portrait in order of item id so the dungeon designers should be aware of this when they set their "importation_flag" to true.

Code: Select all

OBJ_007=dsb_spawn("mirror",0,16,8,SOUTH)
...
OBJ_013=dsb_spawn("mirror",0,13,2,NORTH)

[Sophia]

I'd really rather not go command line. That seems like the worst of both worlds, and will probably inspire T0Mi to say something impolite about coders. And he'd have a point.

[Parallax]

- A flag that says if parties are exportable from a given dungeon (set to "true" for CSB and DM)
- A flag that says if parties are importable in a given dungeon (set to "true" for CSB and DM)
- An additional button "import party" that would be able to import the party from any savegame from a dungeon which allows export, to a dungeon that allows import.

Now, there is always the risk that some dude will make an import-export allowed dungeon to train it's characters.

Why bother with training? One could just create a dungeon with ultra-powerful chars, export them, and import them in the original dungeon. Of course, as long as DSB is single-player only, I'm inclined to say: "Who cares?" After all, cheaters only cheat themselves. Nevertheless, I like Sophia's original description of the dungeon allowing imports from a limited set of dungeons much better. I feel it would give incentive to the creation of serials.

[Joramun]

Why bother with training? One could just create a dungeon with ultra-powerful chars, export them, and import them in the original dungeon.

That's what I was thinking about. 'Training' was just a generic word for the kind of cheating involving pumping up champions.

PS: does this mean you're into a serial ?