dungeonmaker-develop Mailing List for DungeonMaker
Brought to you by:
acdalton,
henningsen
Menu
▾
▴
dungeonmaker-develop — Public list for developers and users of DungeonMaker
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(54) |
May
(22) |
Jun
(16) |
Jul
(4) |
Aug
(25) |
Sep
(3) |
Oct
(3) |
Nov
(2) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(9) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(16) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(11) |
|
From: stephan b. <st...@s1...> - 2005-12-17 14:10:15
|
Hi again! i just got main.cpp building under toc and was poking around the code a bit... The Config type contains a variable (or container) for all of the various genes. As part of a different project i wrote up a class template for modelling genes in a generic manner, plus a container (Genome) to hold series of genes in. Attached are a couple of files which demonstrate how it works. It's based around two types, Gene<ValueType> and Genome<GeneType,KeyType>, and provides a consistent API for writing "breeding functors." These functors are used to breed genes using arbitrary algorithms/heuristics. If the genetic data is moved to such a model, classes like Config don't have to be updated for new gene types. The Genome type acts like a map, so to add new types you simply refer to them in your client code, thereby automatically adding them. The genetic data is also serializable using the s11n framework. A short demo of how to use it: typedef gene::Gene<int> Gene; typedef gene::Genome<Gene> Genome; Genome him; him["geekness"] = 5; him["taste_in_clothes"] = -2; Genome her; her["geekness"] = 0; her["taste_in_clothes"] = 7; Genome them = gene::breed_genomes( him, her, gene::breed_average_f() ); The results in this case would look like: geekness=2 taste_in_closes=2 but arbitrary breeder functors can be used to breed genes in arbitrary ways. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-12-17 13:39:51
|
Yo! i've "tocized" the source tree, so it can alternately build without=20 Autotools. There are some significant TODOs still, but libdungeonmaker=20 builds. i haven't yet looked at building the application code. Peculiarities of this build vs the autotools build: =2D Makefile is still generated by the configure process but is simply a=20 stub which includes Makefile.toc (which is not generated). =2D configure is a stub which runs configure.toc. Autotools will overwrite= =20 this, which is fine (as long as that one's not committed to CVS). =2D The configure tests are incomplete. Since toc targets only GNU=20 platforms, i took some liberties in making many assumptions for values=20 in config.h. (The toc-based template for config.h is config.h.at.) In=20 my experience very little code actually makes use of most of the=20 config.h defines (like HAVE_INTTYPES_H and HAVE_ATEXIT). =2D configure generates dungeonmaker.pc (pkgtool data file) and=20 dungeonmaker-config (a shell script which allows clients to query the=20 cflags/ldflags they need to compile/link against DM). @Aaron/Pete: how do you want to go about examining it and/or getting it=20 into CVS? i can send you tarballs of my tree for examination if you=20 like. =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-12-16 20:39:38
|
Yo again! If you guys can give me CVS access i can upload the changes right into=20 the tree. i won't have to stomp any autotool files to do it, but i=20 would have to check in 'configure' (which is okay because autotools=20 will just overwrite mine if someone builds with those). SourceForge name =3D=3D sgbeal (i used to be on the project but removed myself after a few years of not=20 doing anything.) =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Aaron D. <aa...@da...> - 2005-12-16 17:32:27
|
stephan beal wrote: > Yo! > > i'm putting together a "toc" variant of the build tree, and need only > one small detail: what is the "official" package name. i.e., what > should the distribution tarball be called during 'make dist'. e.g.: > > dungeonmaker-VERSION.tar.gz > dungeonmaker2-VERSION.tar.gz > dm-VERSION.tar.gz > ... > dungeonmaker-VERSION.tar.gz Thanks! -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: stephan b. <st...@s1...> - 2005-12-16 17:29:59
|
Yo! i'm putting together a "toc" variant of the build tree, and need only=20 one small detail: what is the "official" package name. i.e., what=20 should the distribution tarball be called during 'make dist'. e.g.: dungeonmaker-VERSION.tar.gz dungeonmaker2-VERSION.tar.gz dm-VERSION.tar.gz =2E.. ??? =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-12-09 16:37:35
|
On Friday 09 December 2005 00:17, Aaron Dalton wrote: > Yeah, I'm not sure how I'll organize CVS, but we'll work it out =3D)=20 If i may say so, i've got a lot of experience structuring C++ source=20 trees, and a &h!t load of opinions on the topic ;). The current tree is really flat, i'd like to see it separated like so: src/ src/dm =3D core lib code. name needn't be 'dm' src/ui or src/dm/ui =3D UI-centric lib code. src/client =3D client app(s) go here. e.g. src/client/console src/client/sdl src/client/example include/sf.net/dm2 The includes can live under src/dm, but should be copied/symlinked under=20 include/... during the build process. Another alternative is to move=20 the headers under include/... The sources should only reference the=20 headers using <sf.net/dm2/foo.hpp>, rather than "foo.hpp", IMO. This general structure has shown to be very extendable as a project=20 grows. The headers conventions also enforce non-circular dependencies=20 in the various subcomponents. If the copy/symlink approach is used,=20 cyclic deps become impossible because they'll break the first time the=20 tree is built (before all headers are installed under include/...). i've got lots more to say on build trees, but i'll shut up :). =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Aaron D. <aa...@fr...> - 2005-12-08 23:17:48
|
stephan beal wrote: > On Thursday 08 December 2005 07:24, Aaron Dalton wrote: > >>There is no reason we cannot support multiple systems. As the author >>of TOC, if you would be willing to put together a distribution, I >>would be happy to release a separate package. I would also be happy >>to learn how to keep it maintained myself as I upgrade the software >>so you don't have to redo it every release. > > > Excellent. We did that for the pclasses.com source tree. The only tiny > caveat was that in CVS we had the toc 'configure' script and Makefiles > and Autotoolers had to delete those and generate their own. Autotools > and toc have been proven to coexist sanely in the same project tree. > i've got a few days off week after next and i will definitely whip you > up a tree. > > To state the main caveats up front: > > - GNU systems only. Any variant of Linux. Has been known to run on > Solaris and BSD systems, provided they host GNU variants of the most > common Unix tools (sed, find, make, tar, etc). Cygwin might or might > not work. i don't think i ever got linking shared libs working on > Cygwin, and don't have a Windows box anymore to try it on. > > - The variety of built-in configure checks isn't nearly as broad (but > it's easy to extend). That said, since the build tools target only GNU > systems, there aren't nearly as many compatibility checks needed. > > There are numerous advantages, but i'll shut up now. :) > > TTYS, > Yeah, I'm not sure how I'll organize CVS, but we'll work it out =) Thanks! -- Aaron Dalton aa...@Fr... FreeBSD Ports Committer |
|
From: stephan b. <st...@s1...> - 2005-12-08 21:57:19
|
On Thursday 08 December 2005 07:24, Aaron Dalton wrote: > There is no reason we cannot support multiple systems. As the author > of TOC, if you would be willing to put together a distribution, I > would be happy to release a separate package. I would also be happy > to learn how to keep it maintained myself as I upgrade the software > so you don't have to redo it every release. Excellent. We did that for the pclasses.com source tree. The only tiny=20 caveat was that in CVS we had the toc 'configure' script and Makefiles=20 and Autotoolers had to delete those and generate their own. Autotools=20 and toc have been proven to coexist sanely in the same project tree.=20 i've got a few days off week after next and i will definitely whip you=20 up a tree. To state the main caveats up front: =2D GNU systems only. Any variant of Linux. Has been known to run on=20 Solaris and BSD systems, provided they host GNU variants of the most=20 common Unix tools (sed, find, make, tar, etc). Cygwin might or might=20 not work. i don't think i ever got linking shared libs working on=20 Cygwin, and don't have a Windows box anymore to try it on. =2D The variety of built-in configure checks isn't nearly as broad (but=20 it's easy to extend). That said, since the build tools target only GNU=20 systems, there aren't nearly as many compatibility checks needed. There are numerous advantages, but i'll shut up now. :) TTYS, =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Aaron D. <aa...@fr...> - 2005-12-08 06:22:59
|
stephan beal wrote: > Hi, Aaron! > > i'm personally a huge hater of Autotools, but i also firmly believe that > whoever is actually maintaining the tree should be the one to decide > what tools to use. i personally use "toc" (the other configure): > http://toc.sourceforge.net > There is no reason we cannot support multiple systems. As the author of TOC, if you would be willing to put together a distribution, I would be happy to release a separate package. I would also be happy to learn how to keep it maintained myself as I upgrade the software so you don't have to redo it every release. Cheers! -- Aaron Dalton aa...@Fr... FreeBSD Ports Committer |
|
From: stephan b. <st...@s1...> - 2005-12-07 19:14:16
|
On Wednesday 07 December 2005 06:39, Aaron Dalton wrote: > $ ./configure > $ make > # make install > > This is personally my first time using autoconf, automake, and > libtool. Any suggestions or input others with more experience might > have would be warmly received. Hi, Aaron! i'm personally a huge hater of Autotools, but i also firmly believe that=20 whoever is actually maintaining the tree should be the one to decide=20 what tools to use. i personally use "toc" (the other configure):=20 http://toc.sourceforge.net (Disclaimer: i wrote it! ;) In short, toc is "a GNU build system targeting only GNU platforms." It's=20 intended to be a replacement for projects which only target (at least=20 at the *build* level) GNU systems. It's MUCH easier to maintain and has=20 many maintenance benefits (IMO) over autotools. However, it won't build=20 anything on, e.g., a 1990's SCO box. It needs GNU versions of the=20 common Unix tools. :) =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Aaron D. <aa...@da...> - 2005-12-07 05:39:01
|
Version 2.04 has been released. This release contains no functional changes but now uses the GNU build system. This release can now be built as a shared library using the standard ./configure system. To install now: $ ./configure $ make # make install This is personally my first time using autoconf, automake, and libtool. Any suggestions or input others with more experience might have would be warmly received. -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: Aaron D. <aa...@da...> - 2005-11-23 05:29:22
|
This is the initial release of the Perl front-end. It interfaces with v2.03 of the DungeonMaker library and is also available via CPAN. It is not yet the most full-featured interface (having some problems with Swig) but you can generate dungeons, plonk down stuff, and access the SquareData. Future developments are certain. The Swig interface file used to generate this module is contained in the distribution itself. Feedback (and patches) warmly received. -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: Aaron D. <aa...@da...> - 2005-11-21 16:51:14
|
After many years, DungeonMaker has just released version 2.03. My name is Aaron Dalton and I am a new admin on this project. (Peter is still alive and well.) These changes have not altered this library's fundamental functionality but have cleaned up the interface and is preparing the way for scripting front-ends. A Perl interface is forthcoming with others close behind (we hope). A dungeon experimentation homepage is also on its way. Feedback and patches are warmly welcomed. -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: Aaron D. <aa...@da...> - 2005-11-16 03:20:00
|
If somehow the developers do indeed receive this email and are still interested in possible patches to accomodate front-ends, please let me know. I have no desire to "muddy the waters," so to speak and would gladly abandon the fork if this project is still active and open to further development. -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: Aaron D. <aa...@fi...> - 2005-11-16 00:07:11
|
As the developers appear to be unreachable (all emails to them have returned undeliverable) I have forked the v2.02 codebase to a new Sourceforge project called DungeonMakerLib. I did this as I wanted to develop a Perl front-end and the C++ code needed some tweaking. A slightly modified version of this code has now been released and a Perl front-end is forthcoming. You can visit us at http://sourceforge.net/projects/dungeonmakerlib |
|
From: Aaron D. <aa...@da...> - 2005-11-15 23:56:19
|
As the developers appear to be unreachable (all emails to them have returned undeliverable) I have forked the v2.02 codebase to a new Sourceforge project called DungeonMakerLib. I did this as I wanted to develop a Perl front-end and the C++ code needed some tweaking. A slightly modified version of this code has now been released and a Perl front-end is forthcoming. You can visit us at http://sourceforge.net/projects/dungeonmakerlib -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: Ian B. <ian...@ya...> - 2004-02-17 09:52:11
|
At 17:50 16/02/2004 -0500, George Huber wrote: >Ian, > >The link that I provided points to the dissertation titled, > "Automatic Generation of Dungeons for Computer Games" and >this dissertation specifically mentions you. Yes it would. I'm not sure I follow you anymore, but I think we have two web-sites mixed up. The two site are completely unrelated -- except that they both involve me -- - Living@Home - contains no automatic dungeon create content (and very little content of any sort -- yet). - University of Sheffield - contains content of all sorts. Including some documents on my old dungeon-design projects. The first was never part of my message to you. It was only there because it was in my sig line. The second is what I was trying to tell you, but the U of S only have that stuff there for historical reasons, so don't expect it to be organized in any way. Probably what you really need is to see the original project proposals, which I think are long gone. I'll look for them at home.... Ian B Living@Home - Open Source Evolving Organisms - http://livingathome.sourceforge.net/ |
|
From: George H. <kh...@op...> - 2004-02-16 22:54:21
|
Ian, The link that I provided points to the dissertation titled, "Automatic Generation of Dungeons for Computer Games" and this dissertation specifically mentions you. George ----- Original Message ----- From: "Ian Badcoe" <ian...@ya...> To: "George Huber" <kh...@op...> Sent: Thursday, February 12, 2004 10:36 AM Subject: Re: [DM-dev] Re: Suggestions for work on DungeonMaker (Peters reply) > At 00:27 11/02/2004 -0500, you wrote: > >Peter, > > > > > > > >>Couldn't find anything at your website, Ian. Sounds very interesting, > > > >>though. > > > > > > > >Did you mean it was missing or just not much on it? It is a bit sparse. > > > > > > all I found was "under construction"-pages... > > > >While Ian site did not have much content on it, I was able to track down > >the dissertation that was based on this idea. The URL is: > > ((Adding some actual content to the L@H site is high on my todo list....) > > Err, actually the web-site is unrelated to dungeon design issues, it's GP > for evolving creatures with distributed napster-like "grid" computing. > > That line was only on my mail because it's one of my sigs. > > >http://www.dcs.shef.ac.uk/teaching/eproj/ug2002/abs/u9da.htm > > > >There are a few other dissertations that look interesting here, have not > >had a chance to read them. > > We did a whole load of projects about the Games<->academic boundary. The > dept site doesn't particularly regard itself as an archive, however, so > what's left and how easy it is to find is a bit variable. > > Ian Badcoe > > > Free transport into the future, while you wait. > |
|
From: Henningsen <sh...@gl...> - 2004-02-11 13:28:09
|
At 12:33 AM 2/11/04 -0500, George wrote: > >> Oh, I fully concur with this. I always envision the "DungeonHack" program >as >> having as many 3d and 2d windows open as the user wishes, and the >2d-windows >> (for now, anyway) would display the mapview as is is already (somewhat >> primitively) implemented in the current DungeonMaker (just add circles for >> MOBs and avatars). >> >Maybe I misunderstand this. This sounds like you are proposing letting the >player >see the entire level prior to his actually exploring it? > >I would think that this would be bad. One of the driving forces, for me at >least, in >playing first-person (or third-person) is the sense of exploration, of >seeing what is >behind the next door or around the next corner. If I had a map that >detailed the >current level (even the current output of DungeonMaker), much of the fun, >for me >at least, would be gone. The sense of wonder and discovery would be missing >and >the game in my opinion would be nothing more a Quake-like capture the flag >game. IMO, the player should have the choice of playing with a revealed map or of revealing the map through exploration. In single player games, the exploration would probably be what most people do. However, the whole project is intended to eventually lead to multiplayer games, and I have a fully developed scheme to weed out cheaters in these games and keep them essentially honest. Unfortunately, this scheme has no way of detecting a player who would hack the code on his machine to play with a revealed map (even with all the MOBs and avatars revealed), so I expect the normal way of multiplayer gaming in DungeonHack will be "all revealed" except possibly among friends who already trust each other. My vision of the eventual game is that you have a 3D view open where you play most of the time (doing all your fighting, anyway), and a 2D map view open where you observe the movements of MOBs, checking whether you are about to be surrounded and cut off from retreat, and doing strategic planning. The whole project is really intended for MOBs which are not stationary, and the dungeons will have MOB populations which, if they all come together and attack the players together will surely overwhelm them. So players will just be able to raid a dungeon for a limited time. In this environment I think it will be actually more fun to have the "all-revealed"-map, so that while you're fighting a band of MOBs somewhere you also keep one eye on the 2D-map to see whether another band of MOBs is about to attack you from behind and box you in. Then at the last moment you skip into a side tunnel and make your escape, shake off the pursuit, and start another fight somewhere else or move into the next dungeon... This is a whole new approach to MOB-AI and RPG-fighting, and we'll have to see how it actually plays and tune the design during the development process. Peter |
|
From: Henningsen <sh...@gl...> - 2004-02-11 13:28:07
|
At 12:12 AM 2/11/04 -0500, George wrote: >All, > >Looking at the output (at least from the design file on the web site) from >the current >version of dungeon maker, while they are quite good, they can be a little >`stale' after >awhile. By this I mean that all of the corridors, regardless of size, all >run east-west >or north-south. The same can be said of the rooms - they are all regular >quadrilaterals with their axis' running east-west and north-south. > >So, to spice things up I was wondering how hard it would be to implement >several new features: > >1. corridors that are directed at various angles relative to the positive >x-axis.? > >2. Rooms that are rotated with respect to the x-axis? > >3. Rooms that are various shapes other then quadrilaterals - for example >circular, > triangular, and other polygons> > >Of course, these features would need to be limited in their occurrence in >any >dungeon or they loose their uniqueness. > >George The DungeonMaker creates maps as they are currently used in isometric games, where the map is made up of identical-sized squares which are either closed or open. This makes pathfinding very simple, and thus allows MOBs to behave in ways that look much more intelligent than is possible on arbitrary maps, where pathfinding is massively more expensive. If pathfinding sucks and MOBs get stuck or wander senselessly, then all illusion of having actual "creatures" there breaks down immediately. This I don't want to happen, and therefore I will stick with a basic map consisting of open or closed squares, even in a 3D-world. (BTW, this makes DM and Cube such a good fit, because the Cube-world consists just of Cubes. Makes the code simple and easy to work with too...) To rotate a room at 45 degrees on a map like this, you'd get a jagged edge, which I don't think would look good. Other angles would look even worse. It also would make obvious to the player the existence of the underlying map, which is something we don't neccessarily want. So, to answer your question, in order to properly do the things you suggest, the DungeonMaker would have to abandon its basic underlying map concept, which would make it neccessary to do a re-write from scratch. But if you would want to do that, it would work fine: The Tunnelers could easily work in any direction, and also btw work in 3D themselves, tunneling in 3 dimensions instead of in 2. Personally I think that computers are not fast enough yet to handle hundreds of independently moving smart MOBs on such maps, but in about 10 years time, this will be the way to go. Or maybe open landscapes will be more interesting then... Peter |
|
From: George H. <kh...@op...> - 2004-02-11 05:33:31
|
> Oh, I fully concur with this. I always envision the "DungeonHack" program as > having as many 3d and 2d windows open as the user wishes, and the 2d-windows > (for now, anyway) would display the mapview as is is already (somewhat > primitively) implemented in the current DungeonMaker (just add circles for > MOBs and avatars). > Maybe I misunderstand this. This sounds like you are proposing letting the player see the entire level prior to his actually exploring it? I would think that this would be bad. One of the driving forces, for me at least, in playing first-person (or third-person) is the sense of exploration, of seeing what is behind the next door or around the next corner. If I had a map that detailed the current level (even the current output of DungeonMaker), much of the fun, for me at least, would be gone. The sense of wonder and discovery would be missing and the game in my opinion would be nothing more a Quake-like capture the flag game. Then again, maybe I am missing something here. George |
|
From: George H. <kh...@op...> - 2004-02-11 05:28:01
|
Peter, > >>Couldn't find anything at your website, Ian. Sounds very interesting, > >>though. > > > >Did you mean it was missing or just not much on it? It is a bit sparse. > > all I found was "under construction"-pages... While Ian site did not have much content on it, I was able to track down the dissertation that was based on this idea. The URL is: http://www.dcs.shef.ac.uk/teaching/eproj/ug2002/abs/u9da.htm There are a few other dissertations that look interesting here, have not had a chance to read them. I am going to Florida for a few days - should have time to read these papers on the airplane. George |
|
From: George H. <kh...@op...> - 2004-02-11 05:13:02
|
All,
Looking at the output (at least from the design file on the web site) from
the current
version of dungeon maker, while they are quite good, they can be a little
`stale' after
awhile. By this I mean that all of the corridors, regardless of size, all
run east-west
or north-south. The same can be said of the rooms - they are all regular
quadrilaterals with their axis' running east-west and north-south.
So, to spice things up I was wondering how hard it would be to implement
several new features:
1. corridors that are directed at various angles relative to the positive
x-axis.?
2. Rooms that are rotated with respect to the x-axis?
3. Rooms that are various shapes other then quadrilaterals - for example
circular,
triangular, and other polygons>
Of course, these features would need to be limited in their occurrence in
any
dungeon or they loose their uniqueness.
George
|
|
From: Henningsen <sh...@gl...> - 2004-02-11 01:16:26
|
At 04:25 PM 2/9/04 +0000, Ian B wrote:
>...
>I assumed the idea was:
>
>1) do a whole load of work in 2D, learning many useful lessons along the way.
>2) completely scrap that and start again, applying what was learnt in 2D to
>the new, shiny 3D system.
I don't think there's a need to completely scrap, the current DungeonMaker
lays out the general map (topology and corridor-sizes) quite nicely, though
I will modify that part to accomodate very wide "corridors" (possibly up to
hundreds of squares, have to see first how the squares will be mapped onto
the cubes of Cube). The DM code has already been re-written from scratch
after version one and starting into two. I think it's pretty useful as it is.
>...
>Right, again I was assuming more than I said. In the approaches we used,
>creation was always a two-stage process:
>
>1) layout the topological plan of the dungeon
>2) "implement" the topology as a 3D model
1 needs some fiddling with, but 2 is the main task at hand.
>The nice thing about this is, if the output of stage 1 is "rich" enough
>(e.g. if two nodes can be topologically connected by such relationships as
>"PlayerCanCrossForwards", "PlayerCanSeeAcross", "CloseTo",
>"MonsterCannotCross"), then stage 1 works well for 2D or 3D output. There
>are some augmentations you might want to make. E.g. for 2D you can phrase
>the "grammar rules" never to cross two corridors through one-another but in
>3D you don't need to. You can also add stylistic things in 3D which would
>not apply in 2D ("CanLookDownInto", although this is just a special case of
>CanSeeAccoss + CanNotCross).
This grammar stuff is quite interesting, but I don't use that at all. My
dungeons are completely emergent from the interactions of hundreds of
Crawlers and Tunnelers. The wall-building Crawlers are implemented such that
the labyrinths they make stay always well connected, the Tunnelers must be
supervised, because it is possible that they can build dungeons that consist
of several disjunct parts.
>Stage 2 we usually assumed would also be in several stages:
>
>1) layout rooms + corridors
>2) set styles on regions
>3) add fixed furniture (like doors) matching to style where appropriate
>4) add objects (matching to style)
>5) paint/texture/light (matching style)
This is quite interesting, breaking down the tasks like this, but once
again, my alife approach will be quite different. I've thought about it some
more, and will have the following new actors:
1. Evaluators, one of which is started at every dungeon entrance, and who
roam through the dungeon, analyzing the lay of the land (topologically) and
creating new Evaluators (at tunnel branchings) and Modifiers (see below) as
needed. Evaluators will also determine two new variables, floorHeight(fH)
and ceilingHeight(cH) for every tunnel. For instance, a wide hall-like
tunnel could have fH = 0; cH = 255, whereas a small side tunnel could have
fH = 80; cH = 95. Then it will be neccessary to later modify the tunnel
junction so that floor-walking entities can surmount the 80 cubes high step
at the small-tunnel entrance by e.g. making a staircase. That is one of the
jobs for Modifiers.
2. Modifiers are entities that modify the 3D layout that is left behind by
the Dungeonmaker and the Evaluators. So far, I think they will come in at
least 2 flavors:
a) Predefined algorithms for removing/adding cubes (the Cube world can be
conceptualized as consisting of nothing but stacked cubes), which can in
particular handle all possible tunnel junctions with aestetic, useable
solutions like staircases. These will also add geometrically predefined
lavapools, etc.
b) More true to the spirit of alife, but less useable with large cubes, the
second type of Modifiers will add/remove very few cubes and spawn more
Modifiers of its own kind. This process can create irregular organic shapes.
c) Then I'll also have to place objects, of course...
>Right, I thought "cube" was just the name of some inner-part of
>dungeonmaker, not an engine in its own right. My doom comment (let's see
>if any virus scanners object to that :) ) is irrelevant then.
Cube is a playable game and a game engine you can check out at
http://cubeengine.com/
Just look at the gorgeous pictures:-)
>>Couldn't find anything at your website, Ian. Sounds very interesting,
>>though.
>
>Did you mean it was missing or just not much on it? It is a bit sparse.
all I found was "under construction"-pages...
|
|
From: Henningsen <sh...@gl...> - 2004-02-10 20:46:58
|
At 02:02 PM 2/9/04 -0500, George wrote: >Having made the suggestion of a 2D version, it seems that my exact intent was a little unclear. > >I see a 2D version as being useful for testing the various AI algorithms and AI engin that we intend to use without the burden developing in 3D. For example consider the following sections of a dungeon: >>(snip) >My though is that with a 2D, down-looking view we can observe the actions of the MOB's and see if they are behaving as we expect them to. For example, if the patrolling MOB in the above example detected the noise, and changed state from patrolling to investigation, but reversed direction and moved away from the disturbance, we could conclude that there is a problem in our algorithm. Note, that this behaviour might not be readily apparent in a 3D version since the only the MOB's in the field of view would be observable. > >Hope this gives a few more details on what I was hoping to accomplish in a 2D version. Oh, I fully concur with this. I always envision the "DungeonHack" program as having as many 3d and 2d windows open as the user wishes, and the 2d-windows (for now, anyway) would display the mapview as is is already (somewhat primitively) implemented in the current DungeonMaker (just add circles for MOBs and avatars). Peter |
