Amiga Special: Spiele Hits/Hits-CD.iso/aminet/spiele/ammud1_1.lha/AmigaMUD/Doc/Decisions.txt

Text File | 1997-06-28 | 22KB | 386 lines

Some Rambling Thoughts on Various Things


Could have a size on objects. Then, a container would have a maximum size
that it could handle, and its size would be its base size plus the size of
everything in it. => Don't bother. It might add a bit of realism, but likely
doesn't do much for gameplay.

Could put a digital clock in the title bar of the MUD program. => Don't bother.
It doesn't add much and is kinda tacky.

Might be nice in the proving grounds to have:
    place to buy speed/strength/hits  (suggest prices each of 50000/50000/1000)
    very occasionally find gems lying around
    need place to sell them

If a picture is loaded that has no palette, it would often be useful to
    reset to the default palette at that time. Then again, if a scenario
    is consistently using a different palette, you wouldn't want to.
    So, let's not. The scenario can force a palette if needed.

Might want to add an 'ActionToString' builtin, to return a string containing
the text of a routine. The resulting string would be a pain to process,
however (essentially have to write part of a proc parser in MUD code), so
I don't think it would really be useful.   *** DONE ***

Could conceivably add a 'resynch' packet to the serial protocol. This could
be used to re-establish a connection that MUDAgent thinks is still there,
but that went away on the client end. This would only work on a direct line,
however, since MUDAgent normally pays attention to CD. It could also be a
big security hole - there is no way to check that the person reattaching
is the same one that detached.

In the build stuff, could have button-driven entries for destroy object,
move symbol, rename symbol and delete symbol. Decided not to - they are
less likely to be needed and can be potentially dangerous.

Some "spam" preventing stuff can be done. Set up a clock tick to go off
every second. When it does, check the number of inputs that
have come from a client in that second (keep a count, and reset on the
ticks). If it is over a threshold that is settable by a builtin call, then
mark that client as spamming. In that mode, send failing replies to any
request that needs a reply. For requests that don't (most), just chuck
them. Hmm. Perhaps just handle the ones that need replies - they are
wizard mode stuff mostly. Have another builtin-settable parameter which is
how long they stay in "spamming" mode. Need to set the first to a very high
value for the initial sourcing of the scenario (or anything similar).

Might also want to put limits on the number of rooms or objects that can
be created by a character using the build stuff. Give some kind of message
like "apply to SysAdmin for more". SysAdmin can just clear their counters.

Thought of having a 'FlashButton' graphics effect, so that when the user
uses a function key for moving, I could "flash" the on-screen image of
the corresponding button. I decided against this, since with a slow
connection or a slow server, the flashing would be too long after the
keypress to have the right feedback effect.

Had a note suggesting adding an AreaEnterCheck/AreaLeaveCheck action list.
I believe this was to be used when teleporing in/out of an area, to do
whatever cleanup was necessary. E.g. if a wizard teleports out of Questor's
office, no-one else can go in. Decided not to do this for now - the wizard's
will have to be careful.

Could add a flag to MUD and MUDAgent for "-reliable", which would indicate
that the serial connection is fully reliable. Then, don't need to use CRC,
ACK/NAK or sequence numbers. Decided not to do this. The gain would likely
not be that much, either in CPU usage or amount of data transmitted. Also,
any error or glitch encountered would hang the connection permanently.

Parser Extensions:
    Would like to be able to properly parse things like:

    take a picture of the book
    sit down on the bench        [currently kludged]

    This could be done either by allowing a multi-word separator
    ("a,picture;of") or by allowing multi-word verbs ("take,a,picture,of").
    Either requires some changes to the data structures used in-memory and
    in-database for grammars and verbs.

    Put off until later, if ever. (How important is it?)

Out on the nets is the concept of "Tiny-Mail", where a player can mail
commands to a MUD and get the results back. Could do this for AmigaMUD.
Is there any point? (It would be VERY slow to play!)

Want some kind of more intelligent/realistic NPC. This could be a lot
of work. Have to think about it. Not for this release.

It might be possible to do some kind of mazewars type game with AmigaMUD.
Experiments show that this would not be feasible at 2400 baud, even with
effects routines. To do this, might want to increase the resolution of
'After' to 1/100 second instead of 1 second. Maybe later.  *** The
parameter to 'After' is now a fixed-point value, allowing subsecond
timing. ***

Could add a 'CreateThingWithSpace(thing parent; int propCount)', which
would create a thing in the database with space pre-allocated for 'propCount'
properties. Might reduce fragmentation. Probably not worth it.

The MUD client can end up temporarily suspended after typing a RETURN, so
that further typing works, but hitting RETURN again doesn't work. This is
carefully done in the text I/O code, but I don't quite remember the reason
for it. An extra level of recursion would happen if it were allowed, and
too many of these could cause problems. The situation is that the client
is busy doing something (like editing, or processing effects stuff), not
that the client is waiting for the server (input lines are not acknowledged).
*** The simple case of the client being busy handling stuff from the server,
while waiting inside the recursion-locked code has been mostly fixed. You
will still lock if you are parsing code from the edit buffer in wizard
mode and you try to enter a direct wizard-mode command at the same time -
that would take two simultaneous parses to handle! ***

Could have ANSI terminal output stuff. Then, players without the remote
client could get a bit more than just straight text. Would need routines
like ANSIOn, ANSIMove, ANSIClearLine, etc. One problem is the nature of
MUDs in general - output can come at any time. A possible approach to
handling this is to require that the ANSI emulator support a scrolling
region, which would be used for all output not specifically directed to
other parts of the screen. The scenario would have to make sure that any
non-scrolling output sequences leave the cursor at the bottom left of the
scrolling region. Descision: no ANSI support - we are trying to move to
graphics support - ANSI support doesn't help that goal and might even
hinder it.

Some MUDs have a "snoop" facility, which can let wizards or sysadmins
directly watch what players are doing. This includes displaying all of
their input and output. I could add such a facility to the AmigaMUD server
without too much trouble, but have decided not to. The only legitimate
uses of snoop that I can think of are a sysadmin watching for abusers;
and for wizards to watch people playing their creations, looking for
problems with them. Both of these can be handled by proper reporting.
The possible abuses of a snoop facility are many.

Under V1.3 it is possible to select multiple menu items at once, by holding
down the shift key. In doing so, it is possible to select any number of
the items in a set which are supposed to be mutually exclusive. Because
of the way Intuition reports these events, some will be missed if a given
item is selected more than once. If a program just follows the codes in
the menu events given to it, it can then be out of step with the checkmarks
in a set of items. This can be fixed by checking the state of the checkmark
flag bit before doing anything. I started to do this, but it was adding
too much code to handle a rare and not fatal case. Also, later versions
of the system handle this better. So, I do not handle this situation, and
do not plan to do so.

Fighting in the dark is currently not allowed. Changing this, and keeping
darkness consistent (i.e. you can't see where you are or who/what is there
with you) would