Dungeon Master Forum

What is the ultimate vision for DSB? Is it planned to match the original as closely as possible in look and feel? Or is there room for GUI changes/additions?

Well, i can provide my own short-ranged view of dsb, but for the "Ultimate Vision" you should ask Sophia. ( Or watch the Eurovision on TV, but then you'd have to wait next year's edition).

DM and CSB are already faithfully reproduced in DSB.
But this is only a side-effect of dsb being the most easily customizable dm-clone :
Most of the in-game mechanics are coded by scripts in text files. It uses LUA as script language, which can be understood by anyone.
You can modify every aspect of the game, by altering the code, or adding your own code in your dungeon.

I'm currently working on one tiny dungeon that should ship soon, and i will probably release some of the little pieces of code i made for it.

I could probably make a tutorial for dsb editing, but as i stated, you can do many things in dsb, so i'll probably stick to one aspect of the game, and then people should be able to transpose the ideas to other aspects.

Kain wrote:Is it planned to match the original as closely as possible in look and feel? Or is there room for GUI changes/additions?

Well, to be honest, both.

Right now, DSB is trying to match DM's look and feel. Some aspects of this look and feel are already customizable, and some aren't, but I'm always open to the idea of increasing the amount of customizability/expandability.

Anything that's hardcoded is hardcoded to do things the DM way, or at least, as close to it as I could get. If I expand the possibilities and make it customizable, then the Lua code that I put in base to replace the hardcoded function will still try to do things the DM way, but now it can be edited by anyone.

So, basically, I myself will keep it as close as possible, but I'm certainly not opposed to other people doing whatever they like, and I'm open to adding means to make it easier to change aspects of the game.

What I had in mind was some changes to the actual GUI that would expand it in unDMmy ways, such as adding a couple ring slots, inventory stacking of similar light items (a dagger should not take as much space as a breastplate), change one of the belt slots to a coin pouch and the other to a keyring. The last two can already be done by containers, but adding them to the inventory interface would allow for quicker access than moving pouches/boxes to the hand icon.

Another idea is to be able to select a 'tool' view in place of the navigation keys. The nav keys would remain as a tool of course, but a user can switch them out to a live updating map for example, which would be available if one of the characters is holding a map with the right hand (for balance reasons).

Interesting ideas

You might want to look at this thread:
http://www.dungeon-master.com/forum/vie ... hp?t=26535
It has a bunch of thoughts for possible ways of changing the inventories around. Though this thread has languished somewhat, I do want to say that I've not forgotten about it-- adding much more flexibility in changing the inventory around remains something I'd like to do.

Multiple objects in one slot is another matter. Though from the standpoint of data structures, with the way DSB is designed it truthfully wouldn't be that horrific, from one of user interface, I wouldn't know where to begin, not to mention telling the engine how existing objects would fit in such a scheme. This is not to say I don't like the idea...

As for the "tool" view, it seems like the best approach would be to allow some sort of subrenderer/canvas/whatnot for the various GUI elements... do you see these "tool" views as allowing interactive buttons, or being simply static graphic displays?

Sophia wrote:Interesting ideas :)

You might want to look at this thread:
http://www.dungeon-master.com/forum/vie ... hp?t=26535
It has a bunch of thoughts for possible ways of changing the inventories around. Though this thread has languished somewhat, I do want to say that I've not forgotten about it-- adding much more flexibility in changing the inventory around remains something I'd like to do.

Missed that thread. Some nice ideas there and that would account for setting aside a couple slots for "rings". The interface itself only has room for one more slot (next to the right arm), so object stacking would be very handy for expanding the maximum inventory.

Multiple objects in one slot is another matter. Though from the standpoint of data structures, with the way DSB is designed it truthfully wouldn't be that horrific, from one of user interface, I wouldn't know where to begin, not to mention telling the engine how existing objects would fit in such a scheme. This is not to say I don't like the idea...

I've done something like this in the past. Here are some ideas for the mechanics. Let's assume arrows for this example.

-a number would be superimposed somewhere in the slot indicating how many of an object are stacked. You can fit 2 digit number there, maybe 3.

-each object would have a new field "max_stack" which keeps track of how many a particular item may be stacked. For our arrows, 12.

-Placing arrow on another arrow merges the two up to max_stack. Otherwise, swaps them... one arrow goes in slot, stack of 12 arrows goes into hand.

-merging stacks: let's say stack of 6 arrows in hand is clicked on slot with stack of 8 arrows. Lower slot goes to 12 arrows, hand stack contains 2 arrows.

-right clicking on a slot removes 1 object from stack and places it in hand. right clicking anywhere else closes inventory as usual.

-left clicking picks up entire stack. creates messy pile if dropped.

-objects with charges can be painful logic to program, so a good rule would be: object has charges? no stacking.

-for automatic inventory equipping, logic can search for existing stack to add to or failing that, chooses a new slot.

As for the "tool" view, it seems like the best approach would be to allow some sort of subrenderer/canvas/whatnot for the various GUI elements... do you see these "tool" views as allowing interactive buttons, or being simply static graphic displays?

This, I think is something that would be hard-coded into the engine since (not knowing lua that well) I don't think a dynamic map display would be doable in script and the tool views would have to have both static (map is pretty much static) as well as interactive buttons for the navigation.
Other tools can be added to the engine as needed for special object abilities or spells/spell effects.
Perhaps small icons on the right would select the active tool-view.