Pits in DSB

This forum is for the Lua scriptable clone of DM/CSB called Dungeon Strikes Back by Sophia. Use DSB to build your own highly customised games.

Moderator: Sophia

Forum rules
Please read the Forum rules and policies before posting. You may Image to help finance the hosting costs of this forum.
Post Reply
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Pits in DSB

Post by Sophia »

I agree about starting a different thread, so I'll do that now ;)
RemyR wrote:I'm also using spawn_pit, but with no changes (and there's going to be a user setting to turn it off if people don't want it). My question is - it's currently only attached to 'pit's, not 'ipits' or 'fakepit's (I think thouse are what they're called) - should it be attached to all of them? Should there be seperate user settings for each? I imagine not (since 'ipit's are supposed to be invisible, and fakepits aren't really pits, but I thought I'd ask).

And one last question, before I think it's time to start a different thread, since we've veered way off the 'tc' exvar topic - 'dsb_msg_chain': is there another way to duplicate this functionality with exvars, 'cause currently there's no way to attach instances like this within the editor, and it may be neccesary.
The original spawn_pit was kind of a hack. I didn't really think it through. The purpose of it, of course, is to automate the task of having a ceiling pit associated with a floor pit, but it kind of falls short in flexibility.

An "ipit" (that is, an invisible pit) needs a ceiling pit underneath, and, of course, custom pits are also a possibility. How does this version look to you?

Code: Select all

function spawn_pit(lev, xc, yc, pit_type, ceil_pit_type)

	if (pit_type == nil) then pit_type = "pit" end
	
	local pit_id = dsb_spawn(pit_type, lev, xc, yc, CENTER)
	
	if (ceil_pit_type ~= false) then
	    if (ceil_pit_type == nil) then
			ceil_pit_type = "ceiling_pit"
		end
		local ceil_pit_id = dsb_spawn(ceil_pit_type, lev+1, xc, yc, CENTER)
		dsb_msg_chain(pit_id, ceil_pit_id)
	end
	
	return(pit_id)
end
A "fakepit" is just a floor decoration, without anything associated underneath, and doesn't really need any special treatement. It could be generated via this new spawn_pit with:

Code: Select all

spawn_pit(lev, x, y, "fakepit", false)
but a regular dsb_spawn will do the job too.

As for dsb_msg_chain, I'm not sure if there's any need to specify that in the editor. It's mainly used for things like pits where there's a need to create a hard link between two objects directly. The functionality can be duplicated by exvars and a custom message handler (The arch "x_relay" does exactly this) but it might be low enough level that only someone hacking around in custom code would care about it.
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

Okay, after staring blankly at the screen for awhile, I implemented the new spawn_pit. Archtypes of type "Pit" can have any instance of type "Ceiling Pit" spawned below them.

I was staring blankly because something occured to me - that instances inside containers always use dsb_spawn, which means these things that apply to custom spawn functions (namely doors, monsters, and pits), don't apply to them if they're in containers. After deliberating over a cup of coffee, I decided I wasn't going to fix it. If you want to have a Giant Momma Screamer release a bunch of baby screamers when it dies, and you want to adjust the HP of the babies, you'll just have to write your own code for that bit.
That actually sounds rather accusatory, when it was meant to be an apology. Oh well.

I should probably point out, though, that the editor has almost nothing in the way of "safety" checks when it comes to creating instances. You can place a thousand munchers on a single tile, and the editor will happily go about its day. You want to have a chest filled with 'x_relay's, no problem. It doesn't even stop you from putting instances inside walls. It makes the assumption that you know what you're doing. I only bring it up 'cause someone reading the above paragraph might ask "Why would there be a door in a container?"
Because there can be. :)

By the way, thanks for everyone's help and input.
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

Great. :)
I've added that version of spawn_pit to the base code, too.
RemyR wrote:If you want to have a Giant Momma Screamer release a bunch of baby screamers when it dies, and you want to adjust the HP of the babies, you'll just have to write your own code for that bit.
Oh, I think that things like that, especially in DSB, won't be needed, so it's really not a problem at all. Monsters carrying around other monsters was always more of a hack, anyway. The more "DSBish" way to do it, would be to create a special "Giant Momma Screamer" arch, and give it an on_die event that spawns the babies. Some existing on_die events that work similarly can be found in base/monster.lua. A simple example is the one that is called when a skeleton is killed:

Code: Select all

function setup_skeleton_drop(self, id)
	dsb_spawn("falchion", IN_OBJ, id, VARIABLE, 0)
	dsb_spawn("shield_wood", IN_OBJ, id, VARIABLE, 0)
end
The items are spawned in the skeleton's inventory, and are then immediately dropped as the skeleton is killed.
RemyR wrote:I should probably point out, though, that the editor has almost nothing in the way of "safety" checks when it comes to creating instances.
Neither does the DSB engine, so I think they'll get along well. ;)

Edit:
I just thought of one more potential bump.
The DSB engine uses the ability of any instance to contain other instances in order to handle wall sconces, too. In order to specify that the sconce give up the torch when clicked, though, an exvar called release needs to be set to true. It's not the most intuitive thing, but it seems like, for whatever reason, creating sconces with torches is a little weird in every clone engine.
From the test dungeon:

Code: Select all

tmp = dsb_spawn("sconce_full", 0, 13, 4, WEST)
exvar[tmp] = { release = true }
dsb_spawn("torch", IN_OBJ, tmp, 0, 0)
Do you want to handle this any differently in your editor?
Is a spawn_sconce or the like needed?

(Obviously, these on-the-wall containers are much more flexible than this, the test dungeon also has an example of putting two alcoves on one wall, one of those things that it seems like people have been trying to do forever. ;) )
User avatar
Joramun
Mon Master
Posts: 927
Joined: Thu May 25, 2006 7:05 pm
Location: The Universe

Post by Joramun »

Are all the new functions backward compatible with the current DM and CSB dungeons ?
What Is Your Quest ?
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

Yes, they are.
Lua is pretty loose on numbers and types of parameters-- anything that's not passed is taken as a nil. So, the new functions are all set up to treat nils as a default value. :)
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

Do you want to handle this any differently in your editor?
Is a spawn_sconce or the like needed?
I'm leaning towards "No" on this one. Because the next step would be a way to change the charges of the included torch, or use custom torch holders, or custom torches.
Which would be a repeat of the door and pits fixes.
The editor adds the "release=true" exvar for sconces through the Archtype Library, so that parts done. Adding a torch from there is an extra couple of clicks, and the functionality of setting charges (or other exvars, or custom torches, or whatever) is already there, since it operates like any other container. If I were to automate it, I'd do it completely within the editor, 'cause I've just proven to myself it's harder to expose options for Lua scripts than to handle this sort of thing internally.
Does that make sense?
creating sconces with torches is a little weird in every clone engine
It's funny you brought this up, 'cause this very thing is the driving force behind my interface decisions. One of the basic goals I was aiming for was to minimize the number of clicks (and dialog windows) it takes to add a sconce with a torch in it to a dungeon. It's now possible to do so without ever leaving the main screen you saw in the screenshots (though, there is a dialog if you choose to use it -- there's also a 'Containers' listing, similar to the Dungeon Info in the screenshots, for quickly finding a particular container and editting it's contents. Useful if, say, you had a level with 50 mummies in it, and one of them is carrying the golden key that unlocks the door out, and you forgot which mummy it was.)
the test dungeon also has an example of putting two alcoves on one wall

I always loved that, and I wanted to add it to the Archtype Library (or add them, since there are two), but I'm keeping it to the 'base/objects/lua' only, so it's univerally compatible (that, of course, doesn't stop anyone from adding it themselves. In fact, if I ever get around to writing a tutorial, that's exactly what "Adding to the Archtype Library" is going to cover).
But I did wonder why it was that the normal 'alcove' doesn't use the container system, but does it the old DM way - with items in the wall.
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

RemyR wrote:I'm leaning towards "No" on this one. Because the next step would be a way to change the charges of the included torch, or use custom torch holders, or custom torches.
True. It's probably better to leave it alone. :)
RemyR wrote:The editor adds the "release=true" exvar for sconces through the Archtype Library, so that parts done.
Only for "sconce_full", right?
RemyR wrote:But I did wonder why it was that the normal 'alcove' doesn't use the container system, but does it the old DM way - with items in the wall.
Basically, because of click zones.

The way the DSB engine is designed right now, it would be sort of a mess for an instance to create more than one click zone for itself, and it would be a bigger mess to go sorting through instances that are contained inside of a given instance to try to create click zones for them.

The easy way out is to simply have the items lying in the square, each with their own click zones, and have the alcove with a large click zone behind them. It looks and acts like DM this way, and saves me some headaches.

The double alcoves have only one click zone-- you can click nowhere near something lying in the alcove, and you'll still pick it up. They're not as tall, so it's not as noticable, and the weakness is vastly overridden by the coolness of two alcoves on one wall, but that's why a single alcove does it that way.
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

I keep meaning to reply to this, but I don't have any new questions at the moment.
True. It's probably better to leave it alone.
I welcome your ideas, and I certainly appreciate your help with the Lua portions, so keep them coming.
Only for "sconce_full", right?
Yep. Rather silly to let empty sconces release torches they don't have, innit?

Oh, thought of something -- there is absolutely no way to put things in LIMBO in the editor. Is that bad?

Oh, and I'm terrible with names, so someone, please, suggest something to call this thing besides "the editor", which it technically isn't.
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

RemyR wrote:there is absolutely no way to put things in LIMBO in the editor. Is that bad?
Not that I can think of. Anything there is probably only there temporarily, and is probably being interacted upon by code.
RemyR wrote:someone, please, suggest something to call this thing besides "the editor", which it technically isn't.
The titlebar in your screenshot said "DSB Dungeon Maker," so that's what I thought it was called. Of course, if it's the only editor, why can't it be "the editor"?
Recursive acronyms are always fun! LITE = "LITE is the editor" :P

I will also say that if you want a more amusing name, might I suggest something that makes as little sense as possible. Bonus points if it ends in the phrase "Strikes Back" ;)
User avatar
Joramun
Mon Master
Posts: 927
Joined: Thu May 25, 2006 7:05 pm
Location: The Universe

Post by Joramun »

As for sconces and torches, you may notice that the function "dungeon_translate" can clean up ugly stuff like torches found on the same tile as sconce_full/empty, door+doorbutton without target exvar etc.

Title :
Labyrinth Script Designer ?
MAZE Ain't a Zucchini Editor ?
What Is Your Quest ?
User avatar
Parallax
DMwiki contributor
Posts: 424
Joined: Mon Aug 28, 2006 7:56 pm
Location: Back in New Jersey

Post by Parallax »

What about DSB Standard Builder? Or is that too confusing? :P

And just out of curiosity, how close are you to a release date?
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

And just out of curiosity, how close are you to a release date?
I started out with a simple answer, but then went on rambling, so feel free to ignore most of this. I'm pretty much just talking to myself...
I've been wondering when someone was going to ask. :)
My honest answer is "I don't know". Everytime I enumerate what's left in my head, I get to the list of UI glitches (for example - deleting a dungeon level from the middle of a dungeon doesn't always reset the dropdown box that lets you quickly navigate to different levels. The result is that the dropdown list may read "|Level: 0 | Level: 1 | Level: 3 | Level: 4|" if you've just deleted Level 2. It only happens sometimes, and I have no idea why. Another is in the exvars listing. If you double click the 'cell' - think of that list as a two-column spreadsheet - it's supposed to launch a helper dialog based on what's in the cell before it; so if you're editting a 'target' exvar, it launches the Target Finder dialog. That part works fine - the glitch is when it comes back. If, when you double-clicked, you entered the 'text-edit mode' of the cell - that is, the little blinking caret has appeared and is waiting for you to type - the results of the dialog don't show up; they're "hidden" underneath the space provided for to type. It's there, and it'll appear as soon as you click anywhere else, but it's kind of dumbfounding the first time it happens and you don't realize all that work you potentially put into the dialog isn't gone. I've tried all sorts of ways to fix it, and ultimately it comes down to a problem with .NET itself - which, for some reason, completely refuses to acknowledge that a text caret exists).
There's also the list of things that I need to figure out how to inform the editor about - this is all direct result of it not being able to understand DSB/Lua (another example: for making champions, you need to select a portrait. How should this be done? If I force designers to type them out, I'm looking at a good source for hiccups in the generated code - bad spelling. I'm currently using a dropdown list, but how does it generate that list? Yet-another-config file? The same thing for level-wide wallsets and classes in the 'opby_class' helper (which currently doesn't exist - no helpers exist for 'opby's yet, which is probably a bit more than a minor UI glitch).
The only thing I consider major left to do is custom wallsets - those that are placed in the dungeon on a tile-by-tile basis, not level wide. That really should be done now, because to add it later is going to mean changing the data structure of the dungeon, and that's probably going to mean that old saved dungeons won't work with any updates that include it. I guess the Opby helper is somewhat major, too, but it's not a change to the dungeon data itself, just in the way designers interact with it.
Now, you may be wondering why I'm so fixated on these dumb little exvar helper dialogs (and I'll admit it, I am) - it's because there's really nothing else for a new dungeon designer to learn from. If you wanted to learn how to make a dungeon in CSBuild, the most common piece of advice given is "look at how the DM dungeon is built" - that's how you did it. The first time I used CSBuild, it took me a long while to figure out how to make a sconce with a torch in it. The only reason I ever learned was because I had the DM dungeon to learn from. But this editor has no pre-made dungeons to learn from - and because it doesn't understand Lua, it can't use, say, the ones Joramund has made to help designers along. So, the choices for a new designer are to learn all about how DSB/Lua builds dungeons before ever touching the editor, or giving them lots of help along the way.
The trick is to do it in such a way that people who've already passed the learning curve aren't slowed down by all the dialogs and helpers and such. For example, when you use RTC's editor to make a dungeon, to put an object inside the dungeon you have to pass through a series of dialog screens. The pop-up menu can activate the tile editor, from there you can pop open another dialog for objects, and from there, more dialogs for more options. That's fine, there's nothing fundamentally wrong with how it works. The only problem is you have to do it everytime you want to add something. There's a strict order-of-implementation that must be followed. It certainly makes RTC's editor easy to use (it's impossible to mess up adding an apple to a dungeon), and it doesn't take away from any of it's flexiblity, but it implies that flexibility even if you don't want it. You can't just say "Hey, put some cheese in the corner, there" - you have to say "Okay, I'd like to edit this tile; I'd like to put an item on it; I think it should be cheese; Yes, just cheese". Now, because you have all those steps, it's quite possible to make "super-cheese" - by editting the number of charges or whatever when that particular dialog appears (and it does, everytime, because it didn't, you'd have to go back into the dialog cascade and find it, which would be tedious). But usually, you probably just wanted cheese.
Now, the editor only implements the flexibility of DSB on one level - exvars - but I still wanted it to be as unobrusive as possible. This is the reason for the current "flat" design (its also why the UI was changed - 'flattening' the interface ended up taking up alot of screen space - hence the ability to hide the side-panels as tabs along the sides, and have multiple dungeon level maps open at the same time). Almost everything you need to make a dungeon is present and visible from the moment you go to the File menu and select "New Dungeon...". You can add levels, draw your floor plan, drop in instances, edit their exvars, make containers, whatever, without ever looking at another screen or openning another window (there's two exceptions to that - creating champions requires openning up the roster, and making containers inside containers - like a skeleton carrying a chest with a flask inside - means openning up the Container dialog). I wouldn't recommend it, because common exvars like 'target' can get tedious to type out again and again, you have to remember to give instances unique Id's and blah-blah-blah -but it's certainly possible. There's also not a single case of one dialog creating another one. Because it's all flat, each one is seperate, so you don't have to follow through cascades you might not know how to navigate ("Say, where is that screen where I edit charges, anyway?") to perform tasks.
Alot of this is, of course, a result of Sophia's work with and the general "flatness" of DSB/Lua itself. Exvars give you lots of options, without really ever crowding each other (certain sets, such as 'opby', 'target', and 'msg' are used together and a pretty worthless alone, but that's really on a case-by-case basis), and without requiring lots of things to be setup before hand. Pretty much, the only thing you need to setup an exvar is an instance to set it up on - the editor tries to reflect that simplicity as much as possible.

Anyway, I've veered way off the question, and you're probably all bored to tears, so to answer you: Maybe a week.

*[I'm going to note that I'm implying nothing bad about RTC or CSBuild or any other editor or clone or programmer out there. They've all put in a huge amount of effort. If I make minor complaints, I make them with massive amounts of salt, and completely aware that if they hadn't clocked in those hours beforehand, I wouldn't be here to complain.]
User avatar
Joramun
Mon Master
Posts: 927
Joined: Thu May 25, 2006 7:05 pm
Location: The Universe

Post by Joramun »

Good read !

A week is plain good, but I'm not sure I'll be able to fetch you a custom wallset so fast... I'll try, though !

But anyway, I know it's ugly, but I don't think it's mandatory to have the wallset feature in the very first version :
- Each bitmap must be individually tweaked (offset, size, transparent mask color)
- Each wallset comprise ~20 bitmaps
What Is Your Quest ?
User avatar
Parallax
DMwiki contributor
Posts: 424
Joined: Mon Aug 28, 2006 7:56 pm
Location: Back in New Jersey

Post by Parallax »

Wow, just a week! That's fast. As far as wallsets go, wouldn't WHACK crank out a parfectly usable wallset in like, two seconds? It may need touching up to be pretty, but it should be plenty good enough for testing purposes.
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

The wallsets spit out by WHACK and the wallsets that DSB currently uses are a slightly different format, unfortunately.

It's on my todo list.
Along with a million other things.

If you still don't have a custom wallset for testing I can dig one up, though. :)
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

The custom wallsets not being done isn't because I don't have a wallset to test - it's 'cause I started it, decided I'd have to think about how the designer is going to place them in the dungeon, and never got back to it. See, they're handled like instances as far as the editor is concerned (with some internal differences), but you can only put regular instances in one at a time. I'd prefer to be able to "draw" them, like you can with floors and walls. It's just deciding how exactly to do that.

I'd still like a custom wallset, though, to test it with. I have some questions about how exactly they appear in the dungeon (that is, what they actually look like) 'cause I'd like the mapper to represent it accurately. (For instance, what happens if a wallset is used on a floor? I know how they work on walls - each tile position displays only that wall, and the center displays all four walls. But how does that translate to a floor? Does it, even? Are custom wallsets purely walls?)
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

I sent you one. :)
(to your hotmail address)

As for the wallsets, right now, they're just walls. If it's used on a floor, nothing shows up-- DSB will only use the floor that is part of the main wallset.

At some point I'd like to mask off sections and change the floor too, but that'll be something for down the road. I'd say that to keep from having to change the editor to allow custom wallsets on the floor too. :)
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

Okay, new question...

Is there a maximum dungeon size? (And have I asked this before?)
Both X and Y and depth? I don't specifically have one set, and I don't want to exceed DSB's limits.
User avatar
Joramun
Mon Master
Posts: 927
Joined: Thu May 25, 2006 7:05 pm
Location: The Universe

Post by Joramun »

I could enter a 200x200 text map without problem, and a 512x512 pcx (image) map...

I don't see why anyone would want such a huge map anyway, but it worked.
What Is Your Quest ?
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

Ah, well then, no worries. I decided to cap the limit at 255 x 255, though I really wouldn't recommend pushing it that far unless your computer can handle it graphically (the editor stores shadow bitmaps of the mapper, so that it can refresh quickly - but at those sizes, those bitmaps are massive). Depth is less of a problem. It can generate a 1,000 levels fairly quickly, but I'd put a theoratical limit at 10,000 (100,000 seemed to be where my comp decided it would go no further, but then, that's almost 700 mb of memory it's trying to maintain).

*Edit*

Speaking of limitations, I don't really forsee this as a problem, but I had to bump up the color-depth of the iconset to display custom wallsets in the mapper the way I wanted (to make it customizable, it uses icons, but the icons I made needed to be 32-bit for the alpha channel). So, 8-bit color displays are out, if they ever were going to be in. Like I said, I doubt it's a problem, particularly on top of the .NET requirement, but I thought I'd mention it.
User avatar
Joramun
Mon Master
Posts: 927
Joined: Thu May 25, 2006 7:05 pm
Location: The Universe

Post by Joramun »

RemyR wrote:Ah, well then, no worries. I decided to cap the limit at 255 x 255, though I really wouldn't recommend pushing it that far unless your computer can handle it graphically (the editor stores shadow bitmaps of the mapper, so that it can refresh quickly - but at those sizes, those bitmaps are massive). Depth is less of a problem. It can generate a 1,000 levels fairly quickly, but I'd put a theoratical limit at 10,000 (100,000 seemed to be where my comp decided it would go no further, but then, that's almost 700 mb of memory it's trying to maintain).
Erf, I would have caped it at 256x256 :P
As for the 10,000 level limits... I think it's not only beyond the average lifetime of a dungeon builder, it's also above the lifetime of the hardcore gamer. If you take a level to be 3m high, your dungeon would be 30 km high. So much for the Everest.
I don't know how a player could explore that, unless your dungeon consists of the most awesome pit fall ever seen...
What Is Your Quest ?
Remy
Craftsman
Posts: 111
Joined: Wed Sep 05, 2007 5:24 pm
Contact:

Post by Remy »

Erf, I would have caped it at 256x256
Sorry, should have been more specific - the column and row values range from 0-255, which means 256 rows and columns.
unless your dungeon consists of the most awesome pit fall ever seen...
That was such a good idea, I had to try it. After playing with the falling damage a bit (champions take damage whenever they fall down a pit immediately, it doesn't matter what they land on, so the first test had my player dying after a few levels), I setup a dungeon with a 1000 level-deep pit.
It took a little less than 8 minutes to fall the whole way. After the first 30 seconds or so, it actually got kinda a dull...("Ahhh!" ... "Ahhh!' ..."Ahhh!"...)...
By the way, this does show that DSB can digest a 'dungeon.lua' file a thousand levels deep.
User avatar
Joramun
Mon Master
Posts: 927
Joined: Thu May 25, 2006 7:05 pm
Location: The Universe

Post by Joramun »

And also that fall damage should be cumulated until the player lands on solid ground, otherwise it looks stupid, taking damage from thin air.
What Is Your Quest ?
User avatar
Sophia
Concise and Honest
Posts: 4307
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Post by Sophia »

I am so not going to bother with that. :wink: :roll:
Post Reply