Big discussion : CSB in DSB ?

[Joramun]

When translating CSB from RTC to DSB
( with my tool RTSB - soon to come - it's in the end stages of the last annoying feature implementation )

(how do you like all those cryptic code names ? )

*I noticed that the portraits of csb characters were missing, and upgraded portrait from DM characters also.

Discussion for everyone, not only Sophia (though she is the judge in term of what's possible/ what she will do ) :

*Do you think it is possible/necessary/impossible to have the "save and make new adventure" option (within the same dungeon)

*Is it possible to import characters from other savegames.
I think it can be very tricky because there is no insurance that the dungeons use the same mechanics, and therefore the same character system.

*If not, how can we modify the CSB dungeon so that it doesn't break the mechanics and the feeling of the game ?

[Parallax]

I'm feeling bad so that this 'big discussion' thread has not yet gotten a reply, so here goes.

I don't think importing is going to be practical, or even desirable, considering how versatile (read, unpredictable) formats are in DSB. Who's to say that the characters you are importing are coming from a dungeon where the attributes, levels, stats, etc have the same meaning as in CSB?

One thing I would love to see in DSB and that would solve the problem of going from the CSB prison to the CSB dungeon, would be triggered events on special conditions.

What I mean by that is having a series of special triggers that get activated when the game is saved or reloaded, and when the party goes to sleep (3 triggers then, no biggie, right?)

In the case of CSB, only the reload would need to exist. Here's how it would work: Whenever the game is loaded, the level in which the party is at is examined. If it is one of the two prison levels then all party inventories are emptied, all spells currently active (light, shields, etc...) are cancelled and the party is placed on the worm trigger tile at the dungeon entrance.

From a player standpoint what happens is that they save in the prison and upon reloading find the party teleported to the dungeon. Since the prison is completely isolated from the rest of the game the reload trigger would only be doing something once per game (although it will be activated at every reload.)

This precludes importing DM parties or changing portraits, which are two pretty cool feature, but since you can actually do that by editing the dungeon anyways I'm not sure it's that big of a deal.

[Joramun]

It looks rather complicated.

I was thinking of a "make new adventure" but restricted to only one dungeon and it's corresponding savegames.

I suppose it requires an internal tag to tell DSB it is in fact the same, and not an updated dungeon.

I think a simple tag written on compile, that use the dungeon name, version and maybe a random number, that is copied to savegames, would do the job.

( or an "export party" function ? )

But that limits the functionality a lot, so I really wonder if it's necessary to make the thing at all.

Of course people could try to hack the .dsb file, but hell, that's their problem if they mess everything up.

[beowuuf]

I would make the DM dungeon you are creating have a hook to pull characters to the CSB dungeon, and that's it

You could also have the DM dungeon end and have a teleporter to go to the CSB dungeon, or you can plahy the CSB dungeon fro mthe beginning

Whuile it breaks the pure DM/CSB engine feel, we have currently two clones that do exactly that, so why not just admit that the scriptable engine makes this feature, unless intentionalbetween campaign dungeons, very tricky and not worth it since most people abuse it anyway I guess and would carry on parties to other dungeosn that have nothign story wise or balance wise to do with them!

[Parallax]

That's an interesting idea. Could you possibly have both dungeons in the same file and, upon completing fusing Chaos, trigger a little series of events of the kind:
-display the end sequence and the blah blah
-freeze the game
-empty the party's inventory, cancel all spells, resurrect and fully heal everyone, teleport the party to the CSB worm room.
-save the game
-exit or do whatever you'd normally do upon winning.

When the game is reloaded the party is already imported and ready to start CSB.

[Joramun]

beowuuf : the problem, is if people try to use it on incompatible dungeons, (where the modules have been modified beyond simple layout) it won't work as soon as there are changes to characters.

Of course cheating is always possible (it's very easy in RTC to make an uber character and import it to DM) but in RTC and CSB, at least the code is constant.

The problem is tagging dungeons which have similar character pattern, and also emulating CSB prison in a CSB-ish way.

And your "hook" would be an additional lua file with some characters, using the export function ?

[beowuuf]

I was saying you shouldn't can't by default use importing - only on dungeond designed by the same person or people. ie the designer figures out how to transfer the party, not the engine.

Perhaps the dungeon hasa function, as you say, that exports a text file. The next dungeon i nthe series can read this file. Or soemthing.

[Joramun]

No for export i was saying dsb has a function to export variables to a dungeon. but that requires recompiling the dungeon, so there is no gain here. (it's the same as putting the char by hand in the dungeon.

[Sophia]

One thing I would love to see in DSB and that would solve the problem of going from the CSB prison to the CSB dungeon, would be triggered events on special conditions.

This may be the most elegant way of doing CSB and maintaining the CSB "feel."

The question is how important importation of characters is to people... there is really something to be said for the fact that the extreme flexibility of DSB means that two dungeons may be so dissimilar that importation is completely meaningless.

That said, the default DSB engine runs much like DM and I suspect that people will also want to create more "DMish" custom dungeons with it, too. Not everyone is going to want to rewrite all of the code... I think.