[MUD-Dev] Re: openmud: open issues

Vadim Tkachenko vt at freehold.crocodile.org
Thu Oct 29 22:06:42 New Zealand Daylight Time 1998

James Wilson wrote:
> I'd like to set down the design issues that have come up, in short pithy blurbs.
> Please add to this list:
> 1. implementation language: C/C++/others?

Any, provided they all modularized and support the common communication

> 2. target architectures: posix/Win32/others?

Does it matter?

> 3. threads: emulated in-core? using native threads? no threads at all?

"TheThread" abstraction. If it doesn't exist for a selected combination
of language/platform, too bad - probably you made a wrong selection.

> 5. module system: what goes in the core, and what comprises a module?
> how do modules interact?

see (1)

> 6. distribution: should an explicit design goal be to support a distributed
> mud?


> what are the requirements?

See (1)

> 7. database: disk-based DB? distributed DB?

"Storage system" abstraction.

> is this invisible to the programmer?


> what is the DB model (object vs relational vs ...)?

Doesn't matter

> could there be multiple DB's?

Why not?

> 8. memory management: garbage collection? explicit allocation/deallocation?

At least some kind of smart pointer with a mark-n-sweep or reference
counter, the latter is better in the languages like C++ where it's
possible to have static/automatic objects behave as their dynamic
counterparts (explanation will follow if there's enough demand; I had a
very stable implementation working exactly the same for MS-DOS, Windows
and OS/2, only Java prevented it from existing in UNIX incarnation)

> 9. overall goals. 'a really fast mud'? 'a really scalable mud'? 'a really
> usable mud'? 'a really advanced mud'?

A really extensible MUD

> James

Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
UNIX _is_ user friendly, he's just very picky about who his friends are

More information about the MUD-Dev mailing list