dungeonmaker-develop

Re: [DM-dev] Dungeon Rendering :)

[Henningsen <al...@gl...>]

>Pretty simple, I think. Now once I can load my serialized data, we can store 
>and user-created load dungeons.
>
>It wouldn't be hard to implement a small scripting language, like:
>room( x, y, w, h )
>wall( x, y, orientation, length )
>
>Should probably just use that for the config files, I guess. It's just that 
>parsing that stuff is such a pain in the butt in C. I can be done, however, 
>and I wouldn't mind doing it, if it makes sense to use a "script" instead of 
>a "config file". The objects would simply save themselves in "source code" 
>format:
>room( 12, 47, 7, 7 )

I would just design a file format that is easy to parse, (can be edited by
humans ???), and still can hold all the data we need. But I get the feeling
you are a perfectionist;-) Still, with the classloading stuff, I think you
don't have to go that far. Just assume all the subclasses that people are
going to use are all compiled into the program. I mean, if someone writes a
new subclass, they are probably smart enough to be able to recompile the
program including their class? And anyway, we can include a nice set of
precompiled classes.

If you want to write the perfect app, OK, but otherwise let's just write an
app that is good enough to make the perfect dungeons;-) People here in Nova
Scotia are usually trying to do things "good enough", and that is very wise
i think. Saves a lot of trouble, anyway.

Remember to give doors the number 7;-) like in floor=0, wall=1, high
wall=2,... door=7!

C'ya,
Peter

???: If we have an interactive design program, the file does not even have
to be editable by humans as far as I'm concerned. And if it's not edited by
humans, you can let the file reading function fail for any missing space or
added comma or whatever (like I do anyway). Then things shouldn't be so hard.

Re: [DM-dev] Dungeon Rendering :)

[Henningsen <al...@gl...>]

>> Remember to give doors the number 7;-) like in floor=0, wall=1, high
>> wall=2,... door=7!
>
>Ah, yes, I forgot about that. I'll fix that tonight.

That's just for the internal parameters - when the map is printed, it can of
course be anything... "D" would probably be best i think. When you talk
about "rendering", I presume you mean rendering to the "Map" object inside
the DungeonMaker? You're not putting some kind of "rendering-to-screen"
function in the program, right? That should all be left to the users IMO.

Peter

Re: [DM-dev] Dungeon Rendering :)

[Stephan B. <st...@wa...>]

On Tuesday 01 May 2001 00:45, you wrote:
> >> Remember to give doors the number 7;-) like in floor=0, wall=1, high
> >> wall=2,... door=7!
> >
> >Ah, yes, I forgot about that. I'll fix that tonight.
>
> That's just for the internal parameters - when the map is printed, it can
> of course be anything... "D" would probably be best i think. When you talk
> about "rendering", I presume you mean rendering to the "Map" object inside
> the DungeonMaker? You're not putting some kind of "rendering-to-screen"
> function in the program, right? That should all be left to the users IMO.

Nonono... I mean "rendering to some object using X/Y coordinates and int 
values, using the DMGrid interface."

:)

-- 
----- Stephan Beal - st...@wa...
http://qub.sourceforge.net  -  http://stephan.rootonfire.org
http://dungeonmaker.sourceforge.net
"Now I'm not normally the kind of person who likes to trespass, but
sometimes you just find yourself over the line." -- Bob Dylan

Re: [DM-dev] Dungeon Rendering :)

[Stephan B. <ste...@ei...>]

On Tuesday 01 May 2001 00:45, Henningsen wrote:
> >> Remember to give doors the number 7;-) like in floor=3D0, wall=3D1,
> >> high wall=3D2,... door=3D7!
> >
> >Ah, yes, I forgot about that. I'll fix that tonight.
>
> That's just for the internal parameters - when the map is printed, it
> can of course be anything... "D" would probably be best i think. When
> you talk about "rendering", I presume you mean rendering to the "Map"
> object inside the DungeonMaker? You're not putting some kind of
> "rendering-to-screen" function in the program, right? That should all
> be left to the users IMO.

Okay, here's the current state:

I've got the Door class basically done, but I've got a bug or two I=20
need to work out. The problem is, it works okay as long as you don't=20
change the orientation of your wall after the Door is placed. Let's say=20
you have a wall which looks like:

xxxDxxx (D =3D=3D Door)
If you call setOrientation( Vertical ), the wall will look like:

x
x
x
x
x
x
x

But the Door will be here:
x[--D----]
x
x
x
x
x
x

and won't be rendered (or rendered incorrectly). I want to fix this=20
before I commit the Door stuff. I know it's not an important fix, but I=20
think it will be handy later for other types of objects, and allows=20
programmers to change their walls after building them without having to=20
move the doors manually. The problem is that I know if I don't fix this=20
now, I'll be scratching my head in 2 months saying, "why does it do=20
that?" because I will have forgotten what the problem was (aus dem=20
Augen, aus den Sinn).

The current implementation of setting a wall's orientation is kind of=20
lame, but it works for our simple case: it simply resizes the wall.=20
Each wall has a Length field. If orientation =3D=3D Horiz, then it's=20
resized to length,1. If it's vertical, then it's resized to 1,length.=20
The 1 is currently hardcoded, but can be gotten around by calling=20
resize() or setGeometry() on the wall after setOrientation() is called.=20
I will work around this inconsistency one of these days, and get away=20
from the hard-coded width/height of 1.

I spent much of yesterday working on adding convenience functions to=20
the DungeonElement API and getting the Doors done. I've added the=20
following to the DE API:


get/setSquareSubType(): by default this returns -1. Subclasses may use=20
this to set a "sub type" for their square. A Wall square could specify,=20
for example, if it's a corner wall, a "high wall", etc. A door could be=20
open, closed, gold-inlaid, etc. This function is used by Door to hold=20
it's type. The subtype can be collected for the object as a whole (the=20
case with most objects, plus the default implementation) or objects may=20
supply a subtype for a square at at a given x/y coordinate. Currently=20
only Door uses these at all, but it's there for future use if we want=20
it. I think client apps will get the most out of it, as it lets them do=20
things with their rooms which DungeonMaker can't do (doesn't specify=20
corner wall joins, for example).

I've also added several other convenience functions, like:

- removeAllOfType( DungeonElement *de )
removes all child objects which are of the same class as the given=20
DungeonElement *.

A Room can use this, for example, to remove all walls while keeping=20
other data (like the chest of gold in the middle):=20
  Wall *w =3D new Wall();
  removeAllOfType( w );
  delete( wall );

Actually, that function is completely untested, but "should work" ;).

Load/save is still on the back burner. I spent about 4 hours yesterday=20
completely rewiring the class hierarchy and moving functions around=20
into a hierarchy which made more sense to my brain. We should now have=20
forward-compatible save support so we can drop in binary, XML,=20
GridSlammer, etc. save support with very little pain later on (the pain=20
is only in the parser). We'll simply have to implement new Serializer=20
objects for the new file types. I've still got plenty of work to do on=20
the text-saving version, I think a few more days.

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Go away or I shall replace you with a very small shell script."

Re: [DM-dev] Dungeon Rendering :)

[Henningsen <al...@gl...>]

>xxxDxxx (D == Door)

You should also make a check that the door opening is at least minCorrWidth.
Right now, with a minCorrWidth of 2, if an entity had a radius of 1.5, it
could not pass through this door. Major annoyance!

>If you call setOrientation( Vertical ), the wall will look like:
...
>and won't be rendered (or rendered incorrectly). I want to fix this 
>before I commit the Door stuff.

Yeah. Squash bugs as soon as you notice them, or the code will go all to
hell over time. Whenever I notice a bug, I make it my number 1 priority to
fix it. I mean, there's no one coming after us who *will* fix it if we
don't... and when you fix it soon, you still remember what you were thinking
when you wrote that code. (I hope you put lotsa comments in your code too;-)

>The current implementation of setting a wall's orientation is kind of 
>lame, but it works for our simple case: it simply resizes the wall. 
>Each wall has a Length field. If orientation == Horiz, then it's 
>resized to length,1. If it's vertical, then it's resized to 1,length. 

I don't get that. You mean when the wall was length 5, when you flip it from
vertical to horizontal, it gets length 1 in the process? Or do you mean all
walls currently have width one?

>get/setSquareSubType(): by default this returns -1. Subclasses may use 
>this to set a "sub type" for their square. A Wall square could specify, 
>for example, if it's a corner wall, a "high wall", etc. A door could be 
>open, closed, gold-inlaid, etc. This function is used by Door to hold 
>it's type. The subtype can be collected for the object as a whole (the 
>case with most objects, plus the default implementation) or objects may 
>supply a subtype for a square at at a given x/y coordinate. Currently 
>only Door uses these at all, but it's there for future use if we want 
>it.

We will definitely want lots of wall types in the dungeon, but whether they
will be set here or later (by a program that uses our library) i don't know.
We definitely want to preserve the generation information of walls, to be
able to render different graphics for different wall generations.

>Actually, that function is completely untested, but "should work" ;).

Uh-oh. You're not committing without testing your code first, I hope.

>Load/save is still on the back burner. I spent about 4 hours yesterday 
>completely rewiring the class hierarchy and moving functions around 
>into a hierarchy which made more sense to my brain. We should now have 
>forward-compatible save support so we can drop in binary, XML, 
>GridSlammer, etc. save support with very little pain later on (the pain 
>is only in the parser). We'll simply have to implement new Serializer 
>objects for the new file types. I've still got plenty of work to do on 
>the text-saving version, I think a few more days.

Ahh... I hope you're still having fun;-) 

Peter

Re: [DM-dev] Dungeon Rendering :)

[Stephan B. <ste...@ei...>]

On Wednesday 02 May 2001 14:32, Henningsen wrote:
> Yeah. Squash bugs as soon as you notice them, or the code will go all
> to hell over time. Whenever I notice a bug, I make it my number 1
> priority to fix it. I mean, there's no one coming after us who *will*
> fix it if we don't... and when you fix it soon, you still remember

That my major flaw in coding:
I set out to do one task, come across a bug, chase the bug, and always=20
end up 4 features away from what I set out to do. I end up with 3 times=20
as many features, but not because I set out to do it ;).

> what you were thinking when you wrote that code. (I hope you put
> lotsa comments in your code too;-)

You'll see some comments like, "too innebriated to deal with this. Fix=20
it later." ;)  I comment to myself only because I have, so many times,=20
gone back even just a week later and said, "what the FU<< was I=20
DOING?!?!"

> I don't get that. You mean when the wall was length 5, when you flip
> it from vertical to horizontal, it gets length 1 in the process? Or
> do you mean all walls currently have width one?

Basically. It's length stays at 5, but it's "relative" length is set to=20
1, and it's height it then set to 5. It's visually the same as rotating=20
it, without actually rotating it. This only works on simple objects,=20
though (the same square type throughout the whole object). Objects=20
which have children can't do this - they would need to actually rotate=20
to make the visuals show up correctly.

> We will definitely want lots of wall types in the dungeon, but
> whether they will be set here or later (by a program that uses our
> library) i don't know. We definitely want to preserve the generation
> information of walls, to be able to render different graphics for
> different wall generations.

As it stands, we can hold more data than the original objects, but are=20
still 100% backwards compatible with those as well, at least from the=20
point of view of functionality (as opposed to programmatic usage).

> >Actually, that function is completely untested, but "should work"
> > ;).
>
> Uh-oh. You're not committing without testing your code first, I hope.

That part, yes, because I have no code which can test it yet. Once I=20
get the hierarchy building all tested then it's a simple matter to call=20
room->removeAllWalls() and watch what happens. The code looks like=20
it'll work, though. It uses the typeid() functions to compare data=20
types, which I used a lot in earlier versions of QUB.

> >Load/save is still on the back burner. I spent about 4 hours
> > yesterday completely rewiring the class hierarchy and moving
> > functions around into a hierarchy which made more sense to my
> > brain. We should now have forward-compatible save support so we can
=2E..
> > I've still got plenty of work to do on the text-saving version, I
> > think a few more days.
>
> Ahh... I hope you're still having fun;-)

Still enjoying it! It's a nice challenge, certainly.

Have a great day!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...and 'do as you will' shall be the whole of the law." -- ??

Re: [DM-dev] Dungeon Rendering :)

[Henningsen <al...@gl...>]

>That my major flaw in coding:
>I set out to do one task, come across a bug, chase the bug, and always 
>end up 4 features away from what I set out to do. I end up with 3 times 
>as many features, but not because I set out to do it ;).

Ahh - feature-creep - where will it get us?

And me, with my philosophy of the sparse interface... 

I should let you know that my monitor is acting up, and I suspect it will go
"kaputt" some time soon, and then I'll be offline for a while. Might be a
long while, since the outdoors is very enticing, and not having a monitor is
a very reliable way to keep me off the computer;-) In emergencies, my phone
is 902-528-2467.

Peter

Re: [DM-dev] Dungeon Rendering :)

[Stephan B. <ste...@ei...>]

On Thursday 03 May 2001 16:01, you wrote:
> >That my major flaw in coding:
> >I set out to do one task, come across a bug, chase the bug, and
> > always end up 4 features away from what I set out to do. I end up
> > with 3 times as many features, but not because I set out to do it
> > ;).
>
> Ahh - feature-creep - where will it get us?

If I was any good an planning past the next 4 hours I'd tell you ;)

> And me, with my philosophy of the sparse interface...

Mine is more a philosophy of simple-to-use interface. I build a very=20
high-level interface, and then build the low-level API which can=20
provide that functionality using more lines, in the case that the user=20
really wants to screw around with it.

> I should let you know that my monitor is acting up, and I suspect it
> will go "kaputt" some time soon, and then I'll be offline for a
> while. Might be a long while, since the outdoors is very enticing,
> and not having a monitor is a very reliable way to keep me off the
> computer;-) In emergencies, my phone is 902-528-2467.

Good to know. I may just call to speak to the man who started it all. I=20
haven't been on the PC so much at home because my arms are acting up=20
(I've had RSI for about 8 years now, because I just can't break myself=20
away from computers). My willpower is about 4cm long, though, so I=20
never stay off for too long ;).

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...and 'do as you will' shall be the whole of the law." -- ??

Re: [DM-dev] Dungeon Rendering :)

[Stephan B. <ste...@ei...>]

On Monday 30 April 2001 00:33, you wrote:
> I would just design a file format that is easy to parse, (can be
> edited by humans ???), and still can hold all the data we need. But I
> get the feeling you are a perfectionist;-)=20

Only when I know others may see my code ;)

> Still, with the
> classloading stuff, I think you don't have to go that far.=20

Me, too.

> Just
> assume all the subclasses that people are going to use are all
> compiled into the program. I mean, if someone writes a new subclass,
> they are probably smart enough to be able to recompile the program
> including their class? And anyway, we can include a nice set of
> precompiled classes.

That's also the conclusion I came to.

> Remember to give doors the number 7;-) like in floor=3D0, wall=3D1, hig=
h
> wall=3D2,... door=3D7!

Ah, yes, I forgot about that. I'll fix that tonight.

> ???: If we have an interactive design program, the file does not even
> have to be editable by humans as far as I'm concerned. And if it's
> not edited by humans, you can let the file reading function fail for
> any missing space or added comma or whatever (like I do anyway). Then
> things shouldn't be so hard.

I would, but it frustrates me to a) have a data file which I can't=20
hand-edit if I need to and b) one which may not work with the next=20
software version (and I can't hand-edit it to bring it up to spec). I'm=20
still deciding on the data format, but that part can wait a little=20
while while I clean up the rendering and such. I can currently save the=20
data, but the format isn't really one I can use to read back easily.=20
I've got to to simplify significantly before I can read it back.




----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet