[MUD-Dev] Re: World Creation Notes, version 061098

[Mike L Kesl]

> [Chris Gray:]
> Understood, mostly. Do you plan to display other characters and NPC's on
> the world map? If so, to what scale - the same visual size as the player?
> The problem I've had with stuff sort-of like this is in deciding how
> much the map and the player actions interact. To clarify, one thing I've
> played with is a tiled top-down view of a big castle. Small corridors
> in the castle are one tile wide. The character's icon is also about the
> same width. If two characters meet in the corridor, what should I do
> about it? Can one block the other? Do they have to cooperate in getting
> past each other? Do I need to represent that with a little animation
> of the icons flattening out and going past each other? What if there is
> a whole line of people - how do I figure out where anyone can move to,
> in response to player input?

I am not sure if I am going to display other PC's on the map, but I am
sure that the NPC's will not be shown, at least not in either of the text
clients (telnet with/without ansi are the two test interfaces for the
game), that would be too much, although showing other pc's is an idea.
In the actual graphic/tile-based client I will show all that stuff and
this ties in with the post on output classification.

Something that crossed my mind in brainstormign was to have each room
divided into positions. I do not think they would be objects themselves,
but instead maybe they would just make up that object we call the room
(i.e. making the room a container of these positions) With this plan I
think you could do a lot of stuff, specifically with combat I am thinking,
but also with movement (which would be a part of the combat), this would
be good for rranged fighting as well as limiting the number of attackers
in a melee fight to the 6? attackers around a certain "heroic" defender in
the middle, if you were in fact using a 6 sided positioning scheme in the
room. Another option would be to simply give rooms a size. For example,
maybe a wagon could not go down this alley because it's size was too
small, better yet give the room height and width dimensions. Going this
way leads me to think that perhaps a system based on such a large minimum
unit size (a room) is not ideal. I mean, you could go around making the
smallest unit size one meter or something, then you could get real
complicated, as well as end up serving quake :p

> General question to you, relevant to my comment about space to your
> previous post. Why does your ATOM program have to run at all? Can you
> not just have the bitmap maps stored in the system, and then produce the
> other needed stuff (e.g. textual descriptions) at run-time, working
> just from the bitmap? That'll save a lot of space. Only if you need to
> do something special in a given room or area do you actually have to
> instantiate it. Somewhat more work in the server, but it might be
> possible to off-load some of it to the client if they have the
> bitmaps (which you might want, if you give players some magical or
> technological way of seeing an area from on high).

My current thoughts are that the image will be stored in a directory as a
gif. When the game boots, or when commanded, the gif will be parsed into
the world. I do not plan on giving every zone in the world a unique
description. There will be a pool, like the flyweight pattern, of room
descriptions for the zones (wilderness/countryside in a planet setting)
and each zone will simply refer to one instance of the description pool
for it's description. Actually there will be a pool of pools, a pool of
zone descriptions pools for each terrain type. With java, even if I tried
to waste space by assigning each room it's very own, but non unique room
description, I would not succeed because java's default way to handle
assignment is by adding another reference to an equal object already
existence, creating a new one if needed. This is to say that Java does
Shared String Memory management automatically, something I had to
implement in my C mud with some code from Oliver Jowlette I think it was.

I plan on having overhead views for all players. This view will be
enhanced and the like by various effects, and a spell giving a larger
overhead view is conceivable. Also, it might be worth nothing that the
overhead view is not exactly guaranteed, I mean, if you are at the south
base of some mountains, for example, the overhead will not show the
rooms/zones to the north (into the mountain) of where you stand. I am
guessing I will have some sort of visibility level in the rooms/zones,
which in turn might be affected by a passing storm, or fog, or simply the
lack of sunlight after it has set. Stuff like that I think...


Mike Kesl,
aka Kroudar