nakedmudv3.3/
nakedmudv3.3/lib/
nakedmudv3.3/lib/logs/
nakedmudv3.3/lib/misc/
nakedmudv3.3/lib/players/
nakedmudv3.3/lib/txt/
nakedmudv3.3/lib/world/
nakedmudv3.3/lib/world/examples/
nakedmudv3.3/lib/world/examples/mproto/
nakedmudv3.3/lib/world/examples/oproto/
nakedmudv3.3/lib/world/examples/reset/
nakedmudv3.3/lib/world/examples/rproto/
nakedmudv3.3/lib/world/examples/trigger/
nakedmudv3.3/lib/world/limbo/
nakedmudv3.3/lib/world/limbo/room/
nakedmudv3.3/lib/world/limbo/rproto/
nakedmudv3.3/src/alias/
nakedmudv3.3/src/char_vars/
nakedmudv3.3/src/editor/
nakedmudv3.3/src/example_module/
nakedmudv3.3/src/help/
nakedmudv3.3/src/set_val/
nakedmudv3.3/src/socials/
nakedmudv3.3/src/time/
My style of function naming may seem a little bit odd (and, I would agree) but
there is a method to the madness that I will try and explain here for you all:

I'm making an attempt to modularize as many datastructures as I can, making it
so people can only interact with them through the header files; I'm guessing it
will cut down on bugs by forcing people to reuse already existing functions
instead of writing their own, which are known to (hopefully) work correctly. 
I've tried to distinguish between functions designed to interact directly with 
datastructures (e.g. get and set methods) and those that actually have some 
functionality to them (e.g. sending messages to sockets, combat routines, etc) 
by using different casing. Functions that are deisgned to interact directly 
with a datastructure are in CamelCase and everything else is in snakey_case.

For functions in CamelCase, functions should take a naming syntax like:
[datatype][routine][target] (e.g. roomGetName, roomRead). The exception is
for creating and deleting datastructures. For doing these things, it is always
[new | delete][datatye] (e.g. newList, deleteChar).

Hopefully this will explain the seemingly odd programming style you see in my
code. Undoubtedly, this is a very bad convention to use (I would be better off
using one type of casing or the other) but that's life, I guess. Perhaps in a
later version, I will go through and redo the function naming conventions.

Geoff Hollis
hollisgf@email.uc.edu
http://www.uc.edu/~hollisgf/