Dungeon Master Forum

Hi,

I'm currently planning on making a new DM clone on portable consoles, and I'm still studying how the DM data are organized.

By looking at the DM encyclopedia, I see that there is a separate list of doors, with several properties (like for example the "bashable" or the "destroyable" attributes). Later in the dungeon.dat file, there are the maps definitions themselves, specifying the type of every tile.

If a tile is a door, some local informations are also available here (like orientation), but I don't see how you can link this tile to the corresponding door in the doors list. Is it done via the list of objects on this tile?

Thank you for your help!
Michoko

Yes. A door is an object. Just like
a dagger or Screamer. Doors are type 0.

You might find the source code for
CSBwin or CSBuild interesting.

Ok thank you Paul, I'll have a look at it!

Oooh, we're getting more Lone Wolf crossovers. Lovely!

Welcome!

Sorry, off topic!

Hehe yes Gambit, I had recognized your avatar too

Are you on any LW sites like TotS or PA?


Note that teleporters are also like that - a tile is designated 'door' or 'teleporter' and it therefore uses the first object to get all it's operational information from. The tile type simply says the state of the door object - open, closed, bashed, north-south facing or left-right.

This is different to pits, stairs and false/illusionary walls, where every single state is a different tile type ad there is no additional object required

beowuuf wrote:Are you on any LW sites like TotS or PA?

Check out the signature man! LW DS dev!

FredC??? LMAO, sorry, i thought he was just advertising a cool game he liked, not making it, i never hovered the mouse to see the link

Maybe they aren't the same person... enlighten us Michoko!

Yup, I'm LoneWolfDS' author (also known as FredC on Project Aon forums).

Oh and thanks for the info, Beowuuf

I don't have a DS, but your proggle looks way cool!

Thanks! You can still try with an emulator (the second book should work on them, but the load/save feature would be disabled). You would still have to turn your screen (or your head) 90° to read, which should not be very pleasant! ^^

A map is an array of tiles. Each tile contains a pointer to its first object. Okay. But I don't understand why tiles are also holding information on the first object. Is there a reason why this information (e.g. "door state", "door orientation"...) isn't stored in the object as well? Wouldn't that be more... intuitive?

It's impossible for a tile to hold more than one field type objects at the same time - e.g. a "door" AND a "pit", or a "pit" AND a "teleporter" - , isn't it?

Is there a reason why this information (e.g. "door state", "door orientation"...) isn't stored in the object as well?

Yes. And the reason is that DM had to fit
into 512K of memory and a floppy disk.
Remember that the display memory
came out of that 512k, too. Try it!

The designers put bits wherever they
could be found. They could not afford
to add another word to the object
representing a door but there were
unused bits in the byte representing
the tile. This lack of space explains
a LOT of what made Dungeon Master
what it was.

So can you say or can#t you say that this lack of space and the resulting restructuring of the code would make a difference in overall speed of the game? (compared to a straight forward code I mean)
After all, an interpreter (computer) just reads the bits and has to do loops anyway, it is not like a harddisk or CD that gets slower if it has to collect the information(bits and pieces no pun intended) all over the place I guess...
surely for understanding of the code for humans it would have greater (negative?) impact than for machines.
maybe the loading itself does not matter that much but the actual live program(in memory that is) that waits and does its thing is the critical part where the speed loss or speed gain (overall performance) is determined!

And the reason is that DM had to fit
into 512K of memory and a floppy disk.

Yes, just as I thought.

Remember that the display memory
came out of that 512k, too.

Could you tell me how much memory is needed to store all the graphics at the same time? How much memory would I have to provide if I wanted to load only the graphics into memory needed on a specific level of the dungeon? Is there a significant difference at all? (Sorry for asking. I haven't read the entire technical documentation yet.)

So can you say or can#t you say that this lack of space and the resulting restructuring of the code would make a difference in overall speed of the game? (compared to a straight forward code I mean)
After all, an interpreter (computer) just reads the bits and has to do loops anyway, it is not like a harddisk or CD that gets slower if it has to collect the information(bits and pieces no pun intended) all over the place I guess...
surely for understanding of the code for humans it would have greater (negative?) impact than for machines.
maybe the loading itself does not matter that much but the actual live program(in memory that is) that waits and does its thing is the critical part where the speed loss or speed gain (overall performance) is determined!

In my humble opinion, it doesn't have any impact on the speed. It seems to be only a trick for saving some of the valuable memory.

Speed.....on the Atari the CPU was
definitely pushed to its limits on
many occasions. But the extra
few dozen instructions to decode
a door's properties once every several
seconds was insignificant. It was
the graphics and the monsters moving
about all the time that consumed CPU.

But.....remember how slow those
floppy disks were? Anything that
reduced the number of bytes transferred
between the floppy disk and memory
made a big difference in your playing
experience. The designers did a
whopper of a wonderful job balancing
all these pro/con, give/take, plus/minus
trade-offs in every part of the program.
There is evidence of compromise in
every corner of the program.