in reply to Re: Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure
in thread Modules: Building blocks for the Daft Adventure

If you're worried about sightlines in a 3-D world (which is what it is), then I'd consider visualizing the world as a huge 3-D cube. Each point on the cube has different properties, and would thus be a node in this 3-D grid. One of these properties would be opacity - does light pass through? It then becomes very simple to write a procedure (if it hasn't already been done) to determine the points the sight vector would pass through, and determine where it stops. Weather would also be implemented as a modification of these values. You can get wind (for people flying on griffons), etc.

This also allows for a very easy way to handle underground activities, and how those activities would interact with the rest of the world.

Now, you would have a world grid, then a grid within each of the major locales, like Waterdeep or Undermountain. This would be a sub-grid, sorta. At (40,23,0), there is another grid for that place. You enter the sub-grid at a defined point, depending on where you came from.

Another point that has to be made is that D&D is owned by Wizards of the Coast. I know for a fact that they tend to frown very heavily on people writing stuff for public consumption based on their intellectual property, even if you're distributing it as free-ware. So, if you wanted to do something serious, you would have to make it for private distribution only. Sorry, but you don't want their legal department hitting you with a cease-and-desist. (For examples of this, check out www.mtgnews.com and look in the news archives.)

  • Comment on Re: Re: Re: Re: Re: Re: Re: Modules: Building blocks for the Daft Adventure

Replies are listed 'Best First'.
Re{8}: Modules: Building blocks for the Daft Adventure
by Tiefling (Monk) on Jun 12, 2001 at 19:35 UTC
    Another point that has to be made is that D&D is owned by Wizards of the Coast. I know for a fact that they tend to frown very heavily on people writing stuff for public consumption based on their intellectual property, even if you're distributing it as free-ware. So, if you wanted to do something serious, you would have to make it for private distribution only. Sorry, but you don't want their legal department hitting you with a cease-and-desist.

    Understood. Hence the suggestion that any putative development group would be like a PbeM group. We'd have access to the data, etc, for our own consumption - and it would be a help if the majority of developers ownerd the books the data is drawn from - and we'd not distribute the distinctive D&D features to another living soul. I think that sticks to the ideas of closure and fair use that WotC prefer. And hence also the idea of a low-cal implementation for the general consumption of the monks, based on some simple RPG architecture of our own choosing - perhaps even PerlMonks: the RPG? (Monk: the Coding, for any White Wolf people out there.) I'd enjoy trying to adapt my existing location system, or any other we devised, to a map of London, for example.

    Your description of the grid makes me tremble, I'm afraid. This was the kind of approach I'd been considering for the weather in the last BASIC incarnation, and I'd rejected it as too complex. The present map is an abstract graph, and that's an approach I'd be keen to retain. A grid probably is needed for combat purposes, but I'd prefer (unless it were actually _more_ unworkable) to define each locale as a finite union of cuboids for the purposes of the combat map, and to retain the abstract form of the general map. But then I haven't deciphered (or even played) spork yet. Perhaps that will inspire me further.

    If we do go for an ASCII-graphics combat system, curses is a must.

    Tiefling (getting keen)

    -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--)
!O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y
+?
------END GEEK CODE BLOCK------

    [download]
[reply]
[d/l]
      *laughs* Tiefling, my friend. That is one very good reason why OO is better (at some things) than top-down. Coding something up like this in an OO language would be an extremely simple thing.
      1. Define what each point knows about and knows how to do. Does it know about the wind direction? Does it know about temperature? What about composition (earth, stone, water, air, etc)? I'm sure you can come up with some 30-40 things each grid point knows about.
      2. Create a grid object containing, say, 50x50x10 of these objects. The grid needs to be able to coordinate between the various points, for things like wind changing direction or a warm front moving through. Heck, just for things like daybreak. :-) (There's a number of niftykeen Perl tricks that can be done here to reduce the number of lines and increase the readability.)
      3. Populate said grid.
      Here's the neat part - you have a Map::Grid class and a Map::Point class. The Grid will have, maybe, 500 lines of code and the Point might have 1000 or so. Not all that much, if you think about the fact that that's your entire 3-D world.
[reply]
        All very interesting. But don't forget that I previously had 1800 rooms - the equivalent of your grid points - so it's going to be a little tricky defining them in terms of 1500 lines of data - even allowing for the fact that exit data will be largely redundant. How would you deal with, say, doors? And hang on two ticks: 50x50x10 points is 25 000 areas. How do we go about defining a world with non-generic location descriptions with 25 000 locations in only 1500 lines of code?

        You've seriously got me baffled now.

        Tiefling

        tieflet|at|hotmail|dot|com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--)
!O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y
+?
------END GEEK CODE BLOCK------

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom