Dungeon Master Construction Kit (working title)
Posted: Mon Sep 11, 2023 7:45 pm
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.
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.