Dungeon Master Construction Kit (working title)

[Cycl0ne]

Hey,
since i already wrote this in the other part of the Forum, i started to learn JS/TS 5-6 Weeks ago and to have a small project, i thought about myself: do it with DM.
The whole game is written in TS (Typescript) and OO/Modular, so it can be easily extended. My WIP is here:

https://dist-cycl0ne.vercel.app/

Give it some time, it needs to load all 300 assets into the browser one by one (will change this at the end to load only some pics and extract the data then). I will move it to someday to another server since vercel sucks at the moment. It runs on Mobile/Tablets/PC.
I included a tool called: eruda, this is just to implement the devloper debug things on mobile. Because sometimes i switch to tablet to see if it still works and hates to not see any debug output.

When on PC, you can use: QWEASD, Cursor or Mouse, the other devices just Touch.
Pressing "M" (on Pc) opens a Map

Implemented:
Wallornates
Floorornates
---- >Floor/Wallornates are placed random on cells if allowed (like original DM), but can be also set manualy.
Walking/Turning
Walls
Stairs
Pits
Doors/Doorframe/Doorbutton
Eventmanager/Tickmanager
SendMessages
Fontmanager

-> Wallornate: Champion Mirror, im at the moment here. Coding now the Resurrect/Reincarnate Screen (aka Inventory Screen +).
-> biggest Issues i can forsee: the items on floor/touching them moving them around etc., still thinking about how i can solve this.


----
Heavy Technical Info about the Engine itself:
Im not sure if someone is interessted in the design of the code or not, i can explain some thoughts about it here. The drawing routine for the dungeon is only 22 lines of code, since all objects know how to draw themselves. Behind those objects is a Spritesystem/Manager/Sprite class, which handles all the drawing itself.
In the end i just say: Sprite(ON)/Sprite(Off). Like a pseudo 3d Popupcard you know from letters.
Example Update Routine from FloorOrnate Class:
update(cell:MapCell, dir:number, alt:boolean) {
if (cell.subtype != enum_FloorItem.FLOORITEM_ORNATE) return;
if (cell.subsubtype < enum_FloorOrnate.INVALID)
{
this.floorornate[cell.subsubtype].setVisible(true);
}
}

As you see, if i find an ornate at the position im called, i just set the sprite visible
This makes live and extensible quite easy, since i can add a feature on the fly without changing alot of code. There are 2 methods per class (Wall, Floor, FlOrnate, WOrnate, ...) which gets calles by the game engine in a loop: Update() and Render(). But 99% the render() is not used by the class, since the sprites are precreated with all x,y and just need to be setVisible(true) or (false) and rendering of the sprites are done by the SpriteSystem.
In Worst Case i got from about 600 Sprites im using, only 16 visible. And the spritesystem also handles priority on drawing: D3 has lowest prio and gets drawn first and then we go to D0 as highest priority, with Far Left/Far Right, left /right/center the prios in the prio of the distance.
To make thinks even more charming, the spritesystem support many spritemanager in itself, so i have one for the Dungeon, one for the UI-Cursor, one for the Inventory,... each also with priority in itself.

With this heay differentiating between "Logic" and "Gfx" you can later switch the GFX to whatever you like. So yes, first DM1 should run, then it could be more an Engine for own games.
The logic part are just cell class, which are also heavy Object Orientated:
cell -> WallCell -> ChampWallCell
\-> FloorCell -> DoorCell
\-> StairCell
\-> PitCell

Cheers
C.

[Cycl0ne]

I just changed my "testing" level to Level0/Level1 of the DM original to show progress.

[Sphenx]

Done till last stairs. Though I am more used to numpad for moving around.

-> biggest Issues i can forsee: the items on floor/touching them moving them around etc., still thinking about how i can solve this.

Predefined rectangles coordinates/dimensions tell the different clicking zones; and you would use the "timers" (events) that handle what happens when something is moved in/out of a place, or when actuator triggers.

[Cycl0ne]

I will add Numpad for you BTW: Key: N or B (cant remember) jumps to the first stairs

The actuators is not the problem.. the "moving" sprites blitting to screen. Im more the UI Developer with static gfx And it has to be compatible with touch/browser.. so let me think about it.
i finished today the Champion/Inventory Screen, now need Food/Water display and hack this into the gfx engine properly (at the moment im hijacking the renderer from dungeon for my purpose)

[Cycl0ne]

Done till last stairs. Though I am more used to numpad for moving around.

Ok did that too.. never done that You are crazy!!!!

ohh and i have a question:
why do the extra inventory screens have this colorborder? 0020 0023 0024 0025 0027 0040....Do i need to do something special with it?

[Sphenx]

You lost me, what precise # asset is this ? inventory or menu panels ?

[Cycl0ne]

You lost me, what precise # asset is this ? inventory or menu panels ?

Panels, they are called:
0025.IMG1.PAL009 [Panel - Open Container]
0024.IMG1.PAL009 [Magic Map]
0020.IMG1.PAL009 [Panel - Empty]
0023.IMG1.PAL009 [Panel - Open Scroll]
0040.IMG1.PAL009 [Panel - Resurrect Reincarnate (English)]
0027.IMG1.PAL009 [Panel - Rename Champion (English)]

They all have in common that left is a grey block and below is an intense color, RED, GREEN or SYSTEMBLUE (Turquoise). At the moment i just cut them, wonder why the developer also didnt cut this and saving some space on disk. so i thought: maybe something special?

And another question on your approach:
do you store all "actuators" in a DB with unique ID?

Im hasitating on this approach. but it seems RTC/DSB do it like this, otherwise they couldnt send messages to actuators. (at the moment im sending msg to x,y,z and the cell accepts this, but if you have more than one function in the cell, yes this could be trickery in my version if i want to explicit ask one of the 3 to activate something).

[Sphenx]

OK I see now; the flashy color is certainly for transparency. I think its index is normally defined in the binary data of the image ?

About the actuators, I am not sure to understand very well by "unique ID"; do you mean having several times an activator with the same ID ? (a duplicate one ?) If so, that would normally not happen.
Else, it is common that several different actuators are stacked on the same cells, and there, I would say that all actuators will receive the message, but there could be exceptions or more subtlety in the original code. A message generally targets a location, not a specific actuator. That part can be tricky.

[Cycl0ne]

OK I see now; the flashy color is certainly for transparency. I think its index is normally defined in the binary data of the image ?

I dont care about the index, the question i got, is why? you can also cut away the left part and blit it to screen. No hassle to make it transparent and blit it. Question, what was the intentions that the developer also didnt cut the images (and even saving maybe 500bytes of space. So I ask more the question: Why was it done, like it is done.

About the actuators, I am not sure to understand very well by "unique ID"; do you mean having several times an activator with the same ID ? (a duplicate one ?) If so, that would normally not happen.
Else, it is common that several different actuators are stacked on the same cells, and there, I would say that all actuators will receive the message, but there could be exceptions or more subtlety in the original code. A message generally targets a location, not a specific actuator. That part can be tricky.

yeah, DSB and RTS use UID for their actuators:
DSB
[398] = { target = 311 },
[399] = { target = 318 },
[400] = { target = 319 },
RTC
1017 FLOORITEM_TRIGGER 1 3 0 OPBY=(PARTY) ACTION=(ACTIVATE) TARGET=(1018,1019) OPTIONS=(CONSTANT_WEIGHT)
1018 FLOORITEM_TRIGGER 1 3 0 STATE=(INACTIVE) OPBY=(STAFF_FIRE,ON_AND_OVER) ACTION=(DEACTIVATE) TARGET=(1011)
1019 FLOORITEM_TRIGGER 1 3 0 STATE=(INACTIVE) OPBY=(STAFF_FIRE,ON_AND_OVER) ACTION=(ACTIVATE) TARGET=(1020) OPTIONS=(DELAY:4)

--
See -> TARGET = UID;

was just curious if you do the same.. at the moment everything is dynamically created in my engine. thus i cant say:
CreateTrigger(Where:x,y,z, DEST: UID, Action: SET)

since the UID is something i may only know later when creating another trigger.. Yeah just thinking about how i could solve this, without breaking the objectorientated approach.

[Sphenx]

You can have several passes to get first the UID and location of all actuators, then set the targets by referencing these UID.
Anyway, internally we always need UID for these objects.
The activation method is different.
Personally for DCS I have kept the DM behaviour, that is sending a message to a location -- with keeping track of the source of this message -- then check at the destination what can happen. You may have the same actuator command action to either open a door, a pit, or trigger another actuator because it is not targeting a specific UID, but a location.
Since you design your own engine, somehow, you decide how you want to handle these actions, then the dungeon initialization will translate original actuators commands to your engine.

[ChristopheF]

My comments:
- Panel images: all bitmap images are rectangles. There is no easy way to "remove" parts of an image. The developers simply used one color for transparency: when drawing the image, pixels of that color are ignored and not drawn on screen. The images cover the whole part of the inventory screen where panels are drawn, to make sure drawing one panel image would overwrite anything previoulsy present on screen, avoiding the need to clear that location first: memory bandwidth was quite limited at that time so that a "clear then draw" operation would have been slower. Finally, in the original game, images are stored in compressed form in memory before being blitted to the screen, so even if they had implemented an undoubtedly overly complicated way to "remove" pixels from an image, the benefit would most probably have been insignificant in memory savings.

- Sensors (which is the actual name the developers gave to what is usually called "Actuators"): as Sphenx said, each square in the dungeon can contain multiple sensors. Some actions will also change the order of sensors on the square (for example, only the first sensor in the list may show an image on the screen so changing the order is required to show/hide a wall decoration).
Sensors are quite tricky and the original dungeons (DM and CSB) make use of many special cases. So if you plan to implement the full dungeons in your engine, I would advise that you carefully study the source code to understand how sensors are implemented and managed before designing your own way to to so (or implement something very similar so that you won't take any risk). Otherwise you may later find yourself with particular cases that your design cannot handle.

[Cycl0ne]

You can have several passes to get first the UID and location of all actuators, then set the targets by referencing these UID.
Anyway, internally we always need UID for these objects.

yes but this for my personal kind not a good design by going many passes. As real world example: sending a DHL parcel to a house, you first go to the house, check who lives there (5-10 people) then you go back and put the proper name to parcel.

When you have an editor, this behavior is better, since the editor knows alot and thus can later save a file with: target-> t1, t2, t3

Maybe im overengineering it. what i saw, most of the actuators/triggers are only targeting one thing:
PressurePad -> openDoor
PressurePad -> WALLITEM_SHOOTER
button -> opendoor
keyhole -> opendoor

etc, etc, .. so i will continue with that and check how i can create the dungeon on the fly.

[Cycl0ne]

My comments:
- Panel images: all bitmap images are rectangles. There is no easy way to "remove" parts of an image. The developers simply used one color for transparency: when drawing the image, pixels of that color are ignored and not drawn on screen. The images cover the whole part of the inventory screen where panels are drawn, to make sure drawing one panel image would overwrite anything previoulsy present on screen, avoiding the need to clear that location first: memory bandwidth was quite limited at that time so that a "clear then draw" operation would have been slower. Finally, in the original game, images are stored in compressed form in memory before being blitted to the screen, so even if they had implemented an undoubtedly overly complicated way to "remove" pixels from an image, the benefit would most probably have been insignificant in memory savings.

ok first didnt ask to cut the image on the fly. the question was more: why dont use a rect image without the transparent color and thus storing this in graphics.dat saving some bytes later in memory and on disk. but this could explain it, you mean those two which could be deleted:
0019.IMG1.PAL009 [Eye For Object Description]
0018.IMG1.PAL009 [Arrow For Chest Content]
On the other hand a small "patch" graphic in the color to delete the object, would it have been so intense to "delete", ok it would have been: One blit operation vs. 2 smaller ones.

But nevertheless: there was no real purpose why they did it, like they did. I understand.

- Sensors (which is the actual name the developers gave to what is usually called "Actuators"): as Sphenx said, each square in the dungeon can contain multiple sensors. Some actions will also change the order of sensors on the square (for example, only the first sensor in the list may show an image on the screen so changing the order is required to show/hide a wall decoration).
Sensors are quite tricky and the original dungeons (DM and CSB) make use of many special cases. So if you plan to implement the full dungeons in your engine, I would advise that you carefully study the source code to understand how sensors are implemented and managed before designing your own way to to so (or implement something very similar so that you won't take any risk). Otherwise you may later find yourself with particular cases that your design cannot handle.

yes, but here is already the difference between my version and DM. the whole dungeon is in the logic part of the game. so moving player, mobs, doing something, doors opening etc. is all handled by the logic part, wihtout anything doing in the gfx part.

so from my logic (in my head at the moment), as example the Full Torch Holder & Empty Holder. In original you do this swapping with the sensors. In my OO version, the user clicks on the VP -> the sprite registers this touch and sends a message: Ive been touched to the logic engine. the logic engine sees: MESSAGE FROM WALLORNATE FULL TORCH, changes the cell the Wallornate belongs to EMPTY TORCH and puts the Torch into the hand.
GFX engine loop just iterates again through the ViewPort Cells and displays what it "can see" -> EMPTY TORCH.

Reverse same: User touches the ViewPort again, the sprite (empty torch) gets the touch -> Sends message: "Ive been touched EMPTY TORCH". and the engine checks hand, if nothing there -> ignore touch, if torch in hand -> remove from hand, change cell from empty to full torch, done.

---
So overall for the engine:
the graphics part is just picking up the logic part and checks if something is there and displays it (Another Example would be Doors: the logic part changes values of the door when a button is pushed every 1/60s .. the gfx engine just picks up the values dumb and displays them. ) so the graphics part is never involved in the game mechanics. and with this, im already different from the orginal game(i think?) and completely different from RTC/DSB implementation.
Another example could be from a Tabletop Game: you have one Guy who puts all figurest etc. on the table and the other guys making pictures and displaying them to the Audience. If Audience want to move a figure on the table, it just says to the "PutterGuy" : Move please this figure and the "PutterGuy" does it and checks if something happens.

---
And to this i want to stick. So yes, i will see how i handly "multi sensors"

[Sphenx]

Sensors ? that sounds weird to me after all these years

yes, but here is already the difference between my version and DM. the whole dungeon is in the logic part of the game. so moving player, mobs, doing something, doors opening etc. is all handled by the logic part, wihtout anything doing in the gfx part.

so from my logic (in my head at the moment), as example the Full Torch Holder & Empty Holder. In original you do this swapping with the sensors. In my OO version, the user clicks on the VP -> the sprite registers this touch and sends a message: Ive been touched to the logic engine. the logic engine sees: MESSAGE FROM WALLORNATE FULL TORCH, changes the cell the Wallornate belongs to EMPTY TORCH and puts the Torch into the hand.
GFX engine loop just iterates again through the ViewPort Cells and displays what it "can see" -> EMPTY TORCH.

Reverse same: User touches the ViewPort again, the sprite (empty torch) gets the touch -> Sends message: "Ive been touched EMPTY TORCH". and the engine checks hand, if nothing there -> ignore touch, if torch in hand -> remove from hand, change cell from empty to full torch, done.

Isn't it the ... DM behaviour ? I mean the UI events are checked if any, logic processed, then gfx displayed, that's how it works. I am not sure to get what you describe here is different from the original here ? (or am I reading it wrong ?)
The effect you describe is the swap/rotation of "sensors", each holding different gfx (torch holder empty / torch holder full) triggered by a specific item (which is "torch"). They simplified this in DM2 by making multi-states "gfx" like for the torch holder (full / empty), but that prevent effects like "small details" i.e. swapping a brick button to an alcove.
The DM1 engine here is allowing more interesting effects.

[Cycl0ne]

Isn't it the ... DM behaviour ? I mean the UI events are checked if any, logic processed, then gfx displayed, that's how it works. I am not sure to get what you describe here is different from the original here ? (or am I reading it wrong ?)
The effect you describe is the swap/rotation of "sensors", each holding different gfx (torch holder empty / torch holder full) triggered by a specific item (which is "torch"). They simplified this in DM2 by making multi-states "gfx" like for the torch holder (full / empty), but that prevent effects like "small details" i.e. swapping a brick button to an alcove.
The DM1 engine here is allowing more interesting effects.

No from my point of view, the DM code is absolute straightforward c functional code. you have lots of arrays which are traversed etc. like the sensors. in oo view the sensors know who it is (torch sensor) in functional c -> you say the sensor what it has to be.

functional:
Sensor(source, target, action);

OO:
source.sensor(target).action;

so while in functional you would just change loop and code etc. to modify it for new things (making code look more and more ugly over time), in the OO world, you just create a new sourcecode file .cpp with a new class which implements the Interface Sensor.
And when you dont want the OO sensor anymore ->just delete the .cpp file, code should still run. While in functional you need to modify the code of the sensor removing the code you dont want to use anymore.

here picture i created for a friend of mine for the way the gfx engine works the oo way:


the wall_ornate is just a class which gets called (through a standard interface) from its manager.. i can just kick out its source file, and the whole engine is still working without it.. same is for the other drawing classes.

lets say, i want to implement a poison cloud someday, which is a floorobject, i just need to create a new source file:
poison_floor.ts

class floor_poison extends floor_object {}

the class has at least 3 methods:
constructor()
update()
render()

constructor loads the graphics it needs for its position into memory.
update() checks if the graphic is needed and sets its visual to true
render() is used when you need to render something out of the sprite system to screen (mostly not used)

in the mgr_floor you then add just a single line:
this.initClass(INIT_POISON, (data) => new FloorOrnate(data));

only one parameter (but can be upto 3):
1: where can this class be all seen? looks like this:
2: User Data if needed by class (example: Coords for the graphics)
3: User Data2 if needed by class (example: name of the graphics files to load)

export const INIT_POISON = [
{ distance: Distance.D3, position: Position.Center },
{ distance: Distance.D2, position: Position.Center },
{ distance: Distance.D1, position: Position.Center },
];

this INIT_POISON is also delivered to the constructor of the floor_poison class.

after this line, the poison is available in the graphics system for the game. if you notice: oh i dont need it anymore -> just remove the line from manager and delete the source file.

--
hope i could explain my OO way.

[Sphenx]

Ah I was not focusing on procedural vs OO differences but rather on functional way of handling stuff.
I do get that; my own engine DCS is OO too.
I just wanted to get you to think about how you will handle the sensors and theirs actions.
What happen to a defined sensor that targets an empty tile ?

[Cycl0ne]

At the moment nothing. This is where JS/TS is better than C++ you have NULL and UNDEFINED giving you much more flexibility and code robustness.

Whts also nice, it took me just 2min coding + searching in google to add a shadow to items i move around with.


its fascinating how fast one can progress here in this JS world. As i said in a previous post. I started JS/TS 6 Weeks ago, after so many years of just watching what happens here in JS World

but back to the sensors. Yes, i will see when i get to them and code them, i can imagine i will have another 5-9 iterations until im happy with them. Like mirrors:
1. Iteration:
mirror: bool -> Gfx Engine -> WallOrnate Manager -> True = show mirror
2. Iteration
mirrorchamp = class champion -> Gfx Engine -> Wallornate Manager -> Champion there? show mirror and get portrait out of champ.
3. Iteration
Thinking of creating an logic ornate class which inherits a logic class. this ornate class will be inherited of a mirrorornatelogic class handling the touch of the gameengine on the mirror, so i can create a vialtar ornatelogic class, a switchlogicornateclass .... all with code which handels itself.

4.iteration, then i notice, ahh too complex? or not enough -> then i do another iteration

[Cycl0ne]

Uploaded a new version to vercel:
- the pad now only triggers if you have real champions in your party (non ghost mode), so no escaping to level 1 at the moment.
- the mirrors work, you can now click on them and they show you the info of the character
- eye can be clicked (not showing the stats, but they are there
- mouth can be clicked
- cancel can be clicked

next is; reincarnate/resurrect with the keyboard. the status window above not showing the char profile pic..

[Seriously Unserious]

This looks promising. You enjoying making this, and making games in general?

[Cycl0ne]

Nah, its just a hobby to relax and i wanted to learn typescript/javascript. At the moment im on hold, cause i got 3 + 1 Jobs and we are in the end year rally (2 IT Jobs, 1 regenerative Energy/Battery Job i need to code something + 1 Family with 3 kids So busy as allways.
Hope i can start again in mid december again, after i installed 2 battery packsand moved 200 servers to windows 2019 from 2012.

---
For the current status: im still thinking about the placement of the objects on floor and how i store them in memory. at first i did some array with ne/se/sw/nw. but im afraid this will make thinks on mobile awful. (assuming 4* 4bytes * 32 * 32 = 16kb of Zeros per level).

Im not sure if i uploaded my current version to vercel. But you can now resurrect upto 4 chars from the mirrors, magic menu working + the attacks are there but not working.

[Sphenx]

For the current status: im still thinking about the placement of the objects on floor and how i store them in memory. at first i did some array with ne/se/sw/nw. but im afraid this will make thinks on mobile awful. (assuming 4* 4bytes * 32 * 32 = 16kb of Zeros per level).

Have you figured out something for this ? Are you just talking about the first references for each ground item, then still using linked list for browsing a list (stack) of items ?

[Cycl0ne]

Have you figured out something for this ? Are you just talking about the first references for each ground item, then still using linked list for browsing a list (stack) of items ?

Nah still thinking about it how i can solve this programatically fast.. first detect FOV -> Groundtile (NE,SE,NW,SW) and then a better memory wise way to look this up.

For the lookup table i had the following idea:
hash the level+x+y and lookup this hash in a table -> no entry -> nothing there (should be fast) . If there -> its a link to a list. (Class here).

oh and updated the vercel. was a very old version online.

[Cycl0ne]

I uploaded the source code for the moment to make a snapshot:

https://github.com/cycl0ne/DungeonMaster

[MasterWuuf]

I went to your demo of the first few floors. It worked well with the keyboard.
Ha. Much faster and easier with no monsters and buttons on every door.
I actually found myself disappointed when I couldn't go down the last set of stairs.

I don't know about the 'map' feature.
It's nice, yet I think getting lost all the time was part of the fun in my earlier attempts in DM.

Thanks for the time you've spent. Good luck as you continue.

[Prince of Elves]

Very smooth.

I agree about the map though. It's probably a lot harder to make but a good compromise would be a map like in Etrian Odyssey, showing only the parts you already visited. That way you still have to explore but it takes care of drawing a map on paper as most people used to newer games find that tedious and immersion breaking.

And while I had fun back then getting each part of the map down on paper, I actually prefer games that do it for me these days.

[Cycl0ne]

hey thanks you too.

at the moment its halted since im on a editor like adge. to get the data for the game.. the two maps i just imported from the csbwin editor through the ascii dumb and the data quality is complicated.

the map feature is just for debug because i come from C and was now in a more OO Language and arrays are a bit different in handling and allocation.

Hence the name Dungeon Master Construction Kit, the goal will be a dungeon master as example but you will be open to enhance it as you like it. thus also the map will be more an auto map like in etrian odyssey with the option to mark special things

what i also like to see is some frames for a more story driven approach like in etrian.. when you meet someone a window with a portrait should pop up etc.

and the best: all is open source. i uploaded already the TS/JS Game and the library i wrote in python for the extraction of data so anyone can change/learn/extend it later