[MUD-Dev] Re: PDMud thread summary
shades at mythicgames.com
Sat Oct 24 00:40:21 New Zealand Daylight Time 1998
At 12:47 PM 10/23/98 -0700, Jon Leonard wrote:
>On Fri, Oct 23, 1998 at 01:46:44PM -0400, Adam J. Thornton wrote:
>> I second this. If it's Posixy, porting it will be much simpler.
I agree as well. POSIX with a mind towards safe programming practices
(liberal use of sizeof() for example.)
>There really aren't that many OS features that a MUD needs to use, and with
>a modular design, these can often be isolated.
>I think the only things that all modules would have to be aware of are
>dynamic linking and threads. There should be compile time options to
>turn those off, too. (My old computer supports neither, for example.)
We may have to consider some internal threading for mud processing rather
than use OS-based threads in order to be more compatible across platforms.
>Filesystem access and player communications should probably be isolated to
>singles modules, so the effort of porting them to exotic systems should
>be fairly low.
I agree there too. I would like to see us support multiple communication
protocols in the base distribution. Filesystem could be a plugin too, but
I don't see that being as necessary... especially if we roll our own db.
>In short, I think portability is important, and with only a little extra
>effort we can make stuff portable even beyond the range of posix systems.
>Things we'll have to be careful about for portability:
>Endianness (sending data between systems might get mangled)
>64-bit cleanliness (sizeof(int) isn't necessarily sizeof(pointer))
>Sockets and other non-blocking IO
>Other things I haven't thought about
>Systems that I want to be portable to:
>Linux/Intel (my laptop)
>SunOS/Sparc (my old computer)
>There'll probably be someone interested in porting to Microsoft platforms,
>an probably also to AmigaDos. Others?
I'd like to see it run on:
HPUX 10+/HP-PA (my development workstation)
Win32/Intel (my other development machine [besides my linux box])
>Still, I think the better approach is to start designing the system to
>be functional, and then profile it to see what needs to be made faster.
>Premature optimization is a big waste of time.
I agree. We want to be careful not to design ourselves into a circle.
Lets concentrate on basic features, make sure they work together (with an
eye towards optimization later) and begin laying the groundwork.
More information about the MUD-Dev