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

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':

I hope that lot helps to clarify how I've been thinking thus far.


-----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------

Replies are listed 'Best First'.
Re{14}: Modules: Building blocks for the Daft Adventure
by dragonchild (Archbishop) on Jun 12, 2001 at 21:35 UTC
    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).