Various unimplemented stuff

[Joramun]

Ok, I don't know of which value it is, but I put some thought into
some "missing" features of DSB :
*Truly missing :
1- endgame pad
2- setting the randomseed ... (that would be useful to me at least)
*Somewhat cool but unecessary :
3- game stats
4- make new adventure
5- game log I/O feature
6- replay

1- I would just add a special function dsb_end_game() that would close the game.
Any custom ending could be done by hand anyway now, it just requires this function,
and maybe a default endgame_pad trigger object, that simply ends the game
(or display the blue endgame screen as seen in other clones, without the "restart" option )

2- setting the random seed : it would allow for some debugging.
I suggest dsb_randseed([seed]) and a nil value would set it back to whatever default value it has right now.
(I know it's more or less always the same, because I've experimented with it )

3- I know it is probably already possible using the dsb_export(string) to implement a recording of game stats (like monsters killed)...

4- For this, I think a game flag (like for GAME_CSB_REINCARNATION) called GAME_NEW_ADVENTURE would allow two things if specified :
(maybe) A special "SAVE PARTY" button, that saves only the main party stats (the ones entered in dsb_add_champion() ) in a special party.dsb file
A special "MAKE NEW ADVENTURE" screen that allow to load any party.dsb file into the dungeon, or maybe only the party stats from a given normal savegame.
This feature seems really complicated to do though, in front of what it really adds to the game.

5- I would really like to be able to record some log of the game into a text file, (e.g with the basic lua I/O library).
Of course, some people will want to do devious things like modifying the .lua files
but this can't alter the game since they are precompiled anyway.

6- Well, this goes along with both previous ideas : it looks very complicated.
- Recording all the sequence of system functions calls seems like it will generate a HUGE replay file.
- Recording the log of the random generator and player input is a rather weird solution, too...

[Sophia]

I've added dsb_game_end in DSB 0.21.
I'll come back to the rest of this later on.

[Paul Stevens]

Recording the log of the random generator and player input is a rather weird solution, too...

I have done this for two games. Dungeon Craft
(A UA Clone) and CSBwin. In both cases it was
added to a game that was 90 percent completed
without any prior notion of providing such a feature.

Both were 'Windows' programs....event
driven. All the events were funneled through
a common interface. That made it easy to simply
write down the events as they arrived and then
to play the game back by feeding those same
events in the same way to the same program.

A DOS-like program would require you to find
all the places in the code that test for input
and modify each to write that input down.
But even that complication should not be
prohibitive.

[Joramun]

Recording the log of the random generator and player input is a rather weird solution, too...

Both were 'Windows' programs....event
driven. All the events were funneled through
a common interface. That made it easy to simply
write down the events as they arrived and then
to play the game back by feeding those same
events in the same way to the same program.

Well, the problem in DSB, is that a dungeon is script that is precompiled, so if you play a log, you need the exact same version of the script, but instead of using the normal version of dsb_rand() (random function) and of the input functions, it should use the log.

I suppose that it possible to get a roughly equivalent thing to the CSBWin feature, but I don't know for sure. For that, I would have to program a game myself and see what are the troubles...

And I've not programmed a game since I made a tiny Zelda-equivalent on my TI-92... in BASIC with *ugly* *design* (read with *goto* *label* structures ) about 8 years ago...

[Remy]

2- setting the randomseed ... (that would be useful to me at least)

There is a way to do this already, but it doesn't involve a dsb_* function - just straight Lua. DSB exposes (at least part of, I haven't really tested for all of it) Lua's math library, so you can use math.random() and math.randomseed() to generate random numbers.
math.random() can take the following parameters;

math.random() = random float between 0 and 1
math.random(number) = random integer between 0 and 'number'
math.random(number_1, number_2) = random integer between number_1 and number_2

math.randomseed() just takes a number and uses it as a seed for any further calls to math.random.

Well, the problem in DSB, is that a dungeon is script that is precompiled, so if you play a log, you need the exact same version of the script

That's not quite correct - what you'd need to do is record all the functions that actually pass information back to the core - which are currently only the dsb_* functions, I think. All the various Lua scripts do, in the end, is send messages to the engine by means of those functions, so those are all you'd need to do a replay.
Not that I'm calling it easy (this is the same method for doing 'Undo' functionality, and notice the distinct lack of that feature in DDM )- I'm just saying you don't need the original uncompiled script.

[Joramun]

2- setting the randomseed ... (that would be useful to me at least)

There is a way to do this already, but it doesn't involve a dsb_* function - just straight Lua. DSB exposes (at least part of, I haven't really tested for all of it) Lua's math library.

Thanks ! Then dsb_rand() must be a copy of math.random(int1,int2)

Well, the problem in DSB, is that a dungeon is script that is precompiled, so if you play a log, you need the exact same version of the script

That's not quite correct - what you'd need to do is record all the functions that actually pass information back to the core - which are currently only the dsb_* functions, I think. All the various Lua scripts do, in the end, is send messages to the engine by means of those functions, so those are all you'd need to do a replay.
Not that I'm calling it easy (this is the same method for doing 'Undo' functionality, and notice the distinct lack of that feature in DDM )- I'm just saying you don't need the original uncompiled script.

In fact, that's what I proposed in one of my solutions above... well that's what I meant by recording all "system function calls". They need to be timed though, and you can't really take over the command and start to play by interrupting the replay because it's not really the game replaying, just the raw engine without the script (ie the game rules & content).
The other solution : replay with a log of the random seed and the player's input, requires the original script though, but it has the advantage of allowing the player to take over the command when he wants it, because it's not just the engine, it's a sort of "bot" that is playing the same game as him again

[Sophia]

DSB exposes (at least part of, I haven't really tested for all of it) Lua's math library, so you can use math.random() and math.randomseed() to generate random numbers.

Thanks ! Then dsb_rand() must be a copy of math.random(int1,int2)

No, it isn't. Use only dsb_rand or your dungeon will break severely if/when recording and playback is ever added.

what you'd need to do is record all the functions that actually pass information back to the core

This is ok in theory, but it won't work at all in practice. Firstly, as you mentioned this would work only for watching it; the gamestate would be useless. No exvars would be properly set, for example. I think that might sort of ruin the fun... also, sometimes the engine directly queries various system variables. That would cause a problem if the dungeon is not actually loaded, unless it logs all that, too. Also, don't forget the massive amount of dsb_bitmap_* etc. calls that would be logged any time you bring up a subrenderer. It would be awful!

The second idea you posted, where it logs input and such, is more what I was thinking of doing.