Ah, there's the joy of it: 1500 lines of code defines "a grid point", and then when you create your map, you instantiate however many gridpoints with the properties you want. If I understand what dragonchild means, a gridpoint is probably smaller than a room, having properties such as opacity, density, and the like (that is, you can or cannot see or move through it in certain directions).
While I am not (by any means) experienced in D&D
matters, I would love to join up to try to make that kind of a 3D world system workable.
If God had meant us to fly, he would *never* have give us the railroads.
--Michael Flanders
| [reply] |
As you may have deduced from my handle (or not), I'm a fan of the old Planescape setting. I would _like_ to have a map that wasn't so tied to geometry as this would be. Being able to map the hideous contours of the Abyss would be, while inessential, distinctly nice. This comment, of course, also goes for any Cthulhu implementation, wherein the Dreamlands and other curious locales might exist.Consequently:
Desirable properties of a 'room':
- Type - dungeon passage, dungeon chamber, tavern, etc. Possibly to be used as the superclass of the room, so that properties can be generalised.
- Description - optional, but desirable. If the description is undefined, it gets inherited from the type. Description should decompose into Visual, Auditory, Olfactory, Tactile and several Ranged components, not all of which are needed. The Ranged components are my preferred answer to the sightlines query, consisting of a distance (for comparison with fog and darkness) and a nice description of the object visible at that distance.
- Lighting effects present
- Susceptibility to weather
- Latitude and longitude, for determining weather. Possibly also a 'planitude' to determine whether the rain is likely to be water, frogs or blood.
- Exits. Abstract links to other rooms, identified by direction, and possibly also by location in the room (see below) and/or some kind of subsidiary descriptor. Whilst it might not be fair, I'd like to use this section to describe any locations accessible with fly, passwall, etc, here, rather than risk the players breaking the system by indiscriminate use of travel spells.
- Liquid nature and depth, if any.
- Contents. Well, duh. :-)
I hope that lot helps to clarify how I've been thinking thus far.
Tiefling
-----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------
| [reply]
[d/l] |
This implementation goes back to the old Diku-style MUDs. I coded on a Diku-variant some years back and it was built in an OO perspective, even if it was in C. (OO isn't a language thing ... languages may support OO, but that doesn't mean that you can't write OO Cobol or Fortran ... it's just a little trickier.)
There are basically two options. The first is that you have a class for every single room/gridpoint. That's a real bear, especially as 99% of all rooms/gridpoints will be nearly identical, save for some textual differences. (Name, description, etc).
The better option would be to have a start-up file for each grid (or zone or area or whatever). This would be a text-file that could either just be text or be a file that you would do and then assign the resultant values to the right places. That way, you can have your standard room/gridpoint which has a field for Name, Description, Exits (with a gridpoint/roomname), etc. Plus, there could be a field for either a room-specific function or a substitute Room object. That's the power of inheritance - so long as there is a RPG::Room::* (or RPG::Point::*) object there, no-one cares what's going on. The object knows what it's about, which is all that matters. You don't care, because the object will take care of everything it needs to take care of.
One of the biggest stumbling blocks a top-down programmer has when switching to an OO mode is the question of "How is it going to work?!?" Well, the answer is "You don't care." It's going to frustrate you to no end, and it still frustrates me to this day, well over 2 years after I started coding OO. But, it's the real answer. You simply do not care how stuff happens. All you want to know is that it does happen.
I guess the best analogy is that you're the manager for a group of engineers/programmers. You are responsible for making sure that Project X gets out the door by the deadline. Are you going to go to each of your programmers and demand hourly status reports? Are you going to go to them and tell them how to do their jobs? Of course not! That's micro-managing and none of us would like that done to us. That's the difference between top-down and OO. Top-down is micro-managing. OO is trusting your subordinates to "do their thing" and it's only if they fail that you go in and fix stuff (i.e., debug the module).
| [reply] |