Thread: Re: [DM-dev] okay, just so I'm clear...
Brought to you by:
acdalton,
henningsen
Menu
▾
▴
dungeonmaker-develop
|
From: Henningsen <al...@gl...> - 2001-06-05 21:29:08
|
Stephan Beal wrote:
>In the end, logically, we will have a grid with N objects on it. These
>objects can be doors, walls, open spaces - anything defined in the
>DM::SquareType enum: (DM.h)
> enum SquareType { sq_None = -1, sq_Floor=0, sq_X=1, sq_Wall=sq_X,
>sq_Hash=2, sq_Open=3,
> sq_C=4, sq_Reserved=5, sq_Y=6, sq_Door=7,
> sq_Gen0=10, sq_Gen1=11, sq_Gen2=12, sq_Gen3=13,
>sq_Gen4=14,
> sq_Gen5=15, sq_Gen6=16, sq_Gen7=17, sq_Gen8=18,
>sq_Gen9=19,
> sq_Gen10=20, sq_Gen11=21, sq_Gen12=22, sq_Gen13=23,
>sq_Gen14=24,
> sq_Gen15=25, sq_Gen16=26, sq_Gen17=27, sq_Gen18=28,
>sq_Gen19=29,
Generations should potentially go up to 100, for large dungeons/small
maxAge's - I haven't explored that yet but it should remain possible.
>Each cell is completely independent of any other cell. For ease of writing
>new dungeons, we abstract some of that into higher-level objects like walls
>and rooms (which are only a wrapper around 4 wall objects). These objects are
>not hierarchical in any way, and not related to one-another. For flexibility,
>the high-level objects can be "moved around" in the grid while "in memory",
>and are then rendered to an integer-based grid (the top-level container
>object, the "Dungeon"). This means, for example, that a coder could do this:
>room->move( 5,7 );
>Once it is rendered to the grid:
>dungeon.renderTo( mygrid )
>the data "in the grid" is immutable as an object - each cell must then be
>dealt with independently. The higher-level objects cannot be recreated from
>the grid, is my point. This is the environment the crawlers want, if I
>remember correctly, so we can get a nice separation of the "dungeon basics"
>and the "fleshing out" of the dungeon by the crawlers.
Very good, this is indeed what the Crawlers want, every cell one value
designating its content.
<snip> ...
>This would assume that all walls get a door near the center, or we could use
>a slightly stricter format:
>wall=x,y,w,h // no walls
>dooredwall=x,y,w,h[,doorx=(x+w/2),doory=(y+h/2),doorwidth=1]
I suggest we use a format for the higher level (design-program) objects
where every wall contains data fields for doors, such that doors can be
anywhere in the wall and any size. That for every wall, then they are easier
to parse. You could have a different name for "WallWithNoDoor" which would
be mostly for user convenience, and which would have fewer data fields.
I had a Wall class like that designed earlier, just the .h file, with
WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else...
>Using an altered version of the config file object we can use hopefully use
>that object for the storage of DungeonElement and other dungeon data, like
>the stats data, etc., using ini-style settings for those as we've discussed
>before. Then rooms data can be stored in the same file with the stats, etc.,
>but each type of data is easily user-editable, so they could mix/match if
>they want by using emacs (though editing with vi must be righteously
>unsupported ;).
I guess. If I do the "dungeon evolution" thing, i would also need the
ability to store data in two files, one "rooms"-file, and one
"Evolving"-file. I laid those out in an earlier posting.
>Have I hit everything, or just beat around it all?
Hit things beautifully, i'd say. Isn't it much nicer and easier,
flat-hierarchy style? One thing in case that's not clear: There is no need
for myself to be able to save dungeons in flat style - all saving can be
done as higher level objects (in rooms-file). The Dungeonmaker then reads
those in, generates flat dungeon, and delivers pointer to that dungeon map
to library users. Generally, users will put more data on the map, and save
the map in their own format and style.
Peter Henningsen
http://alifegames.com website re-launched with new content
read "Complicity and the Brain: Dynamics in Attractor Space"
at http://alifegames.com/project/ComplicityBrain.html
|
|
From: Henningsen <al...@gl...> - 2001-06-06 13:48:41
|
>> I had a Wall class like that designed earlier, just the .h file, with >> WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else... > >This is very similar to what I've been thinking, but I didn't know for >sure if you were okay with doors bigger than 1 square. Actually, you should ensure that all doors are larger then minCorrWidth. Currently I have minCorrWidth = 2, and I expect to have agents in those dungeons with radius 1.2 or so, definitely over 1. Imagine the fristration if they could not move through the doors in some dungeons. That's what minCorrWidth is for, insure that all passages are wide enough for the agents, so it must be enforced on doors too. >Easier and harder, actually. The base design is easier, fundamentally, >but harder for my brain because I've got what I like to call "The Peter >Syndrom," named after my friend and computer mentor Pete Angerani, in >Houston. He designs so much flexibility into everything that it never >gets finished. You want a text editor which can do your laundry if you >write extension LISP code? Pete could do it. He used to "program" >pacemakers (it's all done via circuitry, though - no software). He >wanted to make them coin-operated, but his mgt didn't like that. >I have to back away from that far-too-flexible approach sometimes, >because it's not always needed. It's certainly an exercise in >self-restraint ;). I agree completely that it's the best approach for >this app, though, it's just difficult for me to K.I.S.S. sometimes. Yes, KISS!! - we all have to remind ourselves of that from time to time. >Okay, let me finish up and "flatten out" the object moswl and write up >a sample app and then we can begin to mix that in with the existing >system, or start writing towards the new genetic stuff you want. I >suspect that you will want to wait until colder weather hits before >doing that, which (of course) is fine. I can start by porting these >objects into the existing DM 0.9x/1.0 architecture, and making an >intermediary prototype so we can see where we need to go from there. I'm actually considering scrapping the dungeon-evolution stuff, due to some negative feedback I got on the idea: Basically it was that users would always (mis-)use their ability to rate dungeons to try to get the highest score, and rate dungeons higher not on the fun they had while playing them, but on the ease with which they could beat them. If that is done, it will IMO tend to lead towards extreme and possibly degenerate dungeons - either very open or very labyrinthine, whatever is better for the player to win. That's something I don't want. So i consider scrapping the evolution thing. Anyway, I'll do the "random room" thing first, that definitely has higher priority with me ( and with you, right?). I think next cold season I will want to do the rooms-thing, the "focal point - precomputed paths"-thing, and then write a sample game in SDL or Nebula Device. If you come to finish the things you want to do on the DungeonMaker, and have switched it over to work with your objects and files, I would probably do the rooms-thing even over the warm season, just slowly. I can handle writing a bunch of code every week, just not keeping up with your furious pace of change;-) Remember though, it must compile on MinGW:-( or I'll not work on that branch. The Windows market is still quite a bit larger than Linux<sniff>. Peter http://alifegames.com website re-launched with new content read "Complicity and the Brain: Dynamics in Attractor Space" at http://alifegames.com/project/ComplicityBrain.html |
|
From: Stephan B. <ste...@ei...> - 2001-06-06 15:19:17
|
On Wednesday 06 June 2001 15:58, you wrote: > I'm actually considering scrapping the dungeon-evolution stuff, due > to some negative feedback I got on the idea: Basically it was that > users would always (mis-)use their ability to rate dungeons to try to > get the highest score, and rate dungeons higher not on the fun they > had while playing them, but on the ease with which they could beat > them. If that is done, it will IMO tend to lead towards extreme and > possibly degenerate dungeons - either very open or very labyrinthine, > whatever is better for the player to win. That's something I don't =2E.. How about instead of a rating system, you use a numeric system where=20 high and low values don't correlate to "quality" of the data. I can't=20 imagine really clearly how this would work, but you're strong with=20 numbers so maybe you could fill that idea out. Maybe something which=20 uses percentages, like "75% must be taken up by rooms, 12% must be kept=20 empty." That sounds like a nightmare to code, though (enforcing the=20 numbers in the output). There may be something we can do, though. Yes, random generation of dungeons (or "assistedly random," where the=20 user says, "I want N rooms, with cheese, hold the mayo...") would be=20 much more useful for me. The idea of evolving dungeons would certainly=20 be a cool testbed for your AI work, though. Maybe you can train a=20 crawler to spell out "We love you, Pete!" with dungeon walls ;)! > If you come to finish the things you want to do on the DungeonMaker, > and have switched it over to work with your objects and files, I > would probably do the rooms-thing even over the warm season, just > slowly. I can handle writing a bunch of code every week, just not > keeping up with your furious pace of change;-)=20 Yes, I do change things quickly and without notice often (it's a=20 side-effect of having coded alone for so long). As I wrote last week,=20 my software tends to "grow" instead of being a product of a=20 well-thought-out API. I "learn" the API I need as I work with it, and=20 change it accordingly, from a user's perspective. I find that that=20 leads to a pretty usable API in the end, with something for both me=20 (the developer of the library) and me (the user of the library) ;).=20 That's 100% how QUB has evolved as well, with very little forethought=20 other than the vague "vision" or concept of the software.=20 The DungeonElement API is almost done "growing," though. I'm pretty=20 happy with the API in it so far, but want to make some minor tweaks as=20 I remove the extra classes (Door, etc.). Actually probably 1/3rd of=20 libdm/*.cpp will go away tonight as I flatten out the model. > Remember though, it > must compile on MinGW:-( or I'll not work on that branch. The Windows > market is still quite a bit larger than Linux<sniff>. That should be even easier after these changes. Once I'm done I will=20 check out the latest MinGW and try it out under VMWare. I'm only using=20 std c++, so the only problems I anticipate are minor build problems=20 (which I'll work to resolve, of course). I don't _expect_ any problems,=20 but if there are any I anticipate they will be in the shell code I've=20 got embedded in the makefiles. We'll see. You'll see lots of CVS changes tonight. In fact, I may start on the=20 right now. I'm so sick of apache, PHP, Oracle, tomcat, jserv, setting=20 up user accounts and re-orging our server dir structures that I could=20 puke. We got a new woman (sysadmin) in the office yesterday, and she'll=20 take over some of the more mundane stuff soon. I'm looking forward to=20 that. I was online working until 2:30 this morning, and I'm wiped out=20 (in the sense of sick of THIS stuff for a while). I've got 5 days off=20 starting next Thursday, and I plan on doing nothing but Coding. I can't=20 WAIT. Me, the machine, and my bottle of Sprite. And a periodic call to=20 Tony's Pizza, of course (since they bring the Sprite and Spezi)... ----- Stephan Generic Universal Computer Guy st...@ei... - http://www.einsurance.de Office: +49 (89) 552 92 862 Handy: +49 (179) 211 97 67 "...control is a degree of inhibition, and a system which is perfectly inhibited is completely frozen." -- Alan W. Watts |
|
From: Stephan B. <ste...@ei...> - 2001-06-06 10:52:28
|
On Tuesday 05 June 2001 23:38, you wrote: > Generations should potentially go up to 100, for large dungeons/small > maxAge's - I haven't explored that yet but it should remain possible. That's no problem. The enum can be extended. Also, for all functions=20 which use the enum, I've made them take "int" instead of "SquareType"=20 just for this reason: so people can extend the square types and pass=20 them to "core" functions without having to modify the SquareType enum. > > be recreated from the grid, is my point. This is the environment > > the crawlers want, if I remember correctly, so we can get a nice > > separation of the "dungeon basics" and the "fleshing out" of the > > dungeon by the crawlers. > > Very good, this is indeed what the Crawlers want, every cell one > value designating its content. Excellent. This allows us to keep the user-side design completely=20 separate from anything the crawlers need. =2E.. > I had a Wall class like that designed earlier, just the .h file, with > WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else... This is very similar to what I've been thinking, but I didn't know for=20 sure if you were okay with doors bigger than 1 square. > > data is easily user-editable, so they could mix/match if they want > > by using emacs (though editing with vi must be righteously > > unsupported ;). > > I guess. If I do the "dungeon evolution" thing, i would also need the > ability to store data in two files, one "rooms"-file, and one > "Evolving"-file. I laid those out in an earlier posting. Yup, I've been thinking about how to handle that. I'm thinking one=20 central object, which is a proxy for several input/output files. That=20 would allow a user to set DungeonElements and genetic data into one=20 place, and that object could then (if needed) split it into separate=20 files. I don't know if that's terribly useful, though. > Hit things beautifully, i'd say.=20 Oh, good. > Isn't it much nicer and easier, > flat-hierarchy style?=20 Easier and harder, actually. The base design is easier, fundamentally,=20 but harder for my brain because I've got what I like to call "The Peter=20 Syndrom," named after my friend and computer mentor Pete Angerani, in=20 Houston. He designs so much flexibility into everything that it never=20 gets finished. You want a text editor which can do your laundry if you=20 write extension LISP code? Pete could do it. He used to "program"=20 pacemakers (it's all done via circuitry, though - no software). He=20 wanted to make them coin-operated, but his mgt didn't like that.=20 I have to back away from that far-too-flexible approach sometimes,=20 because it's not always needed. It's certainly an exercise in=20 self-restraint ;). I agree completely that it's the best approach for=20 this app, though, it's just difficult for me to K.I.S.S. sometimes. > One thing in case that's not clear: There is no > need for myself to be able to save dungeons in flat style - all > saving can be done as higher level objects (in rooms-file). The I'm trying to take the approach of the higher-level user (i.e., QUB),=20 but you're right in your statement below, I think: > Dungeonmaker then reads those in, generates flat dungeon, and > delivers pointer to that dungeon map to library users. Generally, > users will put more data on the map, and save the map in their own > format and style. That's what I'm thinking, as well. Okay, let me finish up and "flatten out" the object moswl and write up=20 a sample app and then we can begin to mix that in with the existing=20 system, or start writing towards the new genetic stuff you want. I=20 suspect that you will want to wait until colder weather hits before=20 doing that, which (of course) is fine. I can start by porting these=20 objects into the existing DM 0.9x/1.0 architecture, and making an=20 intermediary prototype so we can see where we need to go from there. See ya! ----- Stephan Generic Universal Computer Guy st...@ei... - http://www.einsurance.de Office: +49 (89) 552 92 862 Handy: +49 (179) 211 97 67 "...control is a degree of inhibition, and a system which is perfectly inhibited is completely frozen." -- Alan W. Watts |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X