<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Some thoughts on languages and users - was: Macro semi -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Fri, 27 Apr 1998 22:10:01 -0700 -->
<!--X-Message-Id: 199804280508.AAA26403@dfw-ix14.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199804271810.LAA316652#under,engr.sgi.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Some thoughts on languages and users - was: Macro se</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00789.html">Previous</a>
| <a href="msg00791.html">Next</a>
]
Thread:
[ <a href="msg00775.html">Previous</a>
| <a href="msg00250.html">Next</a>
]
Index:
[ <A HREF="author.html#00790">Author</A>
| <A HREF="#00790">Date</A>
| <A HREF="thread.html#00790">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Some thoughts on languages and users - was: Macro semi</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Some thoughts on languages and users - was: Macro semi</LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Tue, 28 Apr 1998 01:12:00 -5</LI>
<LI><em>Delivery-date</em>: Fri Apr 27 22:10:11 1998</LI>
<LI><em>Delivery-date</em>: Fri, 27 Apr 1998 22:10:12 -0700</LI>
<LI><em>Envelope-to</em>: claw#kanga,nu</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent,,,," <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
From: Richard Woolcock <KaVir#dial,pipex.comNOSPAM>
> Newsgroups: rec.games.mud.diku,rec.games.mud.admin,alt.mud.programming
> Subject: [DESIGN] Macro semi-language
> Date: Sat, 25 Apr 1998 04:22:00 -0700
>
> Recently I was asked by a friend and fellow implementor if I could show
> her how to code on the mud. She had used pascal before, but never used
> C, and didn't really seem to have any grasp of the language. In order to
> try and help her, on wednesday I threw together a set of macros to create
> a sort of pseudo-language. I added a few more features on thursday, and
> today got the chance to show her how it worked. Although she is still
> having problems, she is finding this macro-based system far easier to use,
> and I have started wondering if it might help a few other coder wannabe's.
>
I can see why. It's a pretty good approximation of Pascal for C
macros. You might make her even more comfortable by throwing in the
odd semi-colon after the last END. :)
Actually I think it's a great idea. While many of us on this list
are probably fairly proficient C programmers, it is easy to forget
that C is not the simplest nor safest language to use. Perhaps one
might argue that C is simple because there are so few keywords, yet
there are so many subtleties involved with it's syntax that prove
very difficult for a beginner to master.
For example: foo->bar, foo.bar, &foo.bar, y = (int *) **bar, x /=
&foobar(**bar*foo, barfoo(&bar->foo)), z = (x==1?4:*foo).
And I haven't even begun to obfuscate.
> Note that this system is designed for Merc, but could be easily adepted
> to most other hard-coded systems.
>
> The advantages and disadvantages as I see it are as follows:
>
> * ADVANTAGES: More verbose and robust than direct C coding, as well
> as requiring less actual code to be written. Compiles down almost
> as efficiently as pure C, and can be mixed and matched.
If your C compiler does good optimizations, there's no reason to
think it wouldn't be as fast in many cases. I've noticed many of
the available GNU languages compilers like Ada are basically just
smart C pre-compiler compilers. And seem to perform quite well
compared with straight C. In some areas even better than
hand-written C because they call some well-written native libraries.
Full blown compilers to C, bytecode and native code are certainly
good options. (cf. "How to build a compiler." thread).
> * DISADVANTAGES: Excessive macros resulting in poor type checking,
> severe limitations on what you can do, and doesn't really help
> teach the user C. The hope is that as the user requires more and
> more from the code, they will slowly begin to teach themselves,
> rather being dropped in at the deep end and not knowing how to do
> anything.
Yes. Even without macros C has poor type checking. But I think you
hit upon a very important question. How important is it to teach
the user C?
The most definitive answer I can come up with is, It depends on...
A) The server design.
B) The user's role on the server.
C) The user's personal goals (Is the guy/gal studying to be a C
programmer for other reasons?).
Rather than attempting to discuss your server design (since I'd be
quite ignorant), I'll bore you with a few thoughts on my own design
philosophies regarding languages and how they relate to my server
and my users. And needless to say, run right off on a tangent.
First some of my wild-eyed theories:
1) Good builders are creative and imaginative writers.
2) Coders are easier to find than good writers. really(?)
3) It is by sheer accident that you find both in one person.
(Although we do have a few on this list)
4) Players who are immersed/entranced, love to create and love to
destroy. Or as Bubba said to me once, "It was a pleasure to burn,
to see things blackened and changed"
5) Game builders (a different critter than the writer builder) like
to tinker around with machines. Assembling and disassembling
until they get a desired effect.
6) Not all game builders are good coders. Although they may have
tendencies.
Some problems with today's muds:
1) Writing is not enough for the area writer/builder in the mud
medium. The area writer must have tools to produce interactive
fiction. Area writers must program.
2) Playing a game where you have no measurable affect on the
virtual world is not as satisfying as creating, changing or
destroying that world. Players must program to assemble boats,
build castles, create potions, research spells and do complex
maneuvers. In-game building components are just not readily
available in many muds.
3) Knowing how to balance the game rules, design combat systems,
magic systems, design characters, equipment, and run quests is
not enough. Game builders/GMs must program.
What level of language, script or interface is appropriate for these
types of users and their roles?
Well my vision for the C coder (or driver author) is to code the
networking and database interfaces, the language/script
compilers/translators, the user interfaces, the string, memory,
garbage collection, cache management and programming and tools
environment for the rest of the above users. After that he or she
can pack it in, the drivers is done and becomes merely a maintenance
programmer. I don't mean to imply that all drivers should be coded
in C. Feel free to substitute C++, Java, Lisp, Fortran, Ada, or
whatever here. In short there's nothing "game" related here. The
philosophy coincides with MudOS, DGD, MOO, Cold and PennMush.
Next we have an environmental programmer. We have work for our
previously laid C programmers. At this stage environmental code is
built in a mixture of native C and the designed mud programming
language. The designed mud language is not powerful enough to handle
the tasks of creating a skeleton environment, security, etc. or needs
supplemental library functions. The biggest difference here between
MudOS and Cold is that these routines are very loosely coupled, if at
all, to the driver. These component objects are constructed to be
reflective enough to facilitate casual integration into the mud
language and driver (I call them MudX objects or MudBeans <TM>).
Next we have the Game Builder. This person will use the mud
language a truly simple language supplemented by native components.
A language more simple than LPC or MOO, an object-oriented KISS.
All the game rules, character creation, critters, equipment, objects,
poisons and other trappings of the virtual world are created with
this. Dare I say 'business objects'. No I won't. The game builder
can also tweak exposed properties of components or call component
methods.
Then we come to our area writer. A great many of the MudBeans our
C programmer created and Objects our game designer form the
backbone of a visual area creation tool. It comes complete with a
excruciating simple collection of visual language elements that pull
together the beans and objects created into an interactive fiction
generator.
Last but not least we have our player. This is a bit difficult to
explain and was partially germinated in another thread (cf.
"Assemblys" and also "Population Containers") Basically in
addition to all components and mud objects having built-in creation
and destruction methods, they have built in assemble and disassemble
methods. So anything which the virtual world exposes to the player
will be able to be created from something or disassembled into
something. Now I don't start at the atom, I start at resource
objects that make some sense. You could start at any level of detail
and define components up or down the chain of an object. For
example, I create a forest population container which contains a
quantity of trees (only instantiated upon demand!), a tree object's
disassemble method creates component wood objects, while its destroy
method does not. Anyways, the design of the mud language implements
inheritance as "containment & aggregation". Hopefully through these
mechanisms as more malleable world would be built. At least that's
the dream.
In summary: I see more users doing "coding" and be involved in
mud creation and modification. A good many more than those who know
C. Yet be coding in such a high-level and absract way that it's not
programming in the traditional manner, yet it's safe, flexible and
powerful.
--
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc#ix,netcom.com /*\--
--/*\ Mud Server Developer's Page <<A HREF="http://www.netcom.com/~jlsysinc">http://www.netcom.com/~jlsysinc</A>> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00775" HREF="msg00775.html">[MUD-Dev] (fwd) [DESIGN] Macro semi-language</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence <claw#under,engr.sgi.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00789.html">[MUD-Dev] Re: Group mechanics/Leadership [was: Room descriptions]</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00791.html">[MUD-Dev] Re: PK's: A solution?</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00775.html">[MUD-Dev] (fwd) [DESIGN] Macro semi-language</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00250.html">[MUD-Dev] Re: (fwd) [DESIGN] Macro semi-language</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00790"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00790"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Wired, UO, and Internet Gaming (was Re: OT: Birth announcement )</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="00341" HREF="msg00341.html">[MUD-Dev] Wired, UO, and Internet Gaming (was Re: OT: Birth announcement )</A></strong>,
Mike Sellers <a href="mailto:mike#bignetwork,com">mike#bignetwork,com</a>, Sun 03 May 1998, 12:59 GMT
<UL>
<LI><strong><A NAME="00347" HREF="msg00347.html">[MUD-Dev] Re: Wired, UO, and Internet Gaming (was Re: OT:</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Sun 03 May 1998, 20:47 GMT
<UL>
<LI><strong><A NAME="00447" HREF="msg00447.html">[MUD-Dev] Re: Wired, UO, and Internet Gaming (was Re: OT:</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 06 May 1998, 23:12 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</ul>
</LI>
<LI><strong><A NAME="00775" HREF="msg00775.html">[MUD-Dev] (fwd) [DESIGN] Macro semi-language</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Mon 27 Apr 1998, 19:42 GMT
<UL>
<LI><strong><A NAME="00790" HREF="msg00790.html">[MUD-Dev] Some thoughts on languages and users - was: Macro semi</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 28 Apr 1998, 05:10 GMT
</LI>
<LI><strong><A NAME="00250" HREF="msg00250.html">[MUD-Dev] Re: (fwd) [DESIGN] Macro semi-language</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 30 Apr 1998, 00:24 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00776" HREF="msg00776.html">[MUD-Dev] (fwd) Re: POLL: Games ruined by bad players (Player killers, tank rushers etc)</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Mon 27 Apr 1998, 19:31 GMT
<UL>
<LI><strong><A NAME="00787" HREF="msg00787.html">[MUD-Dev] Re: (fwd) Re: POLL: Games ruined by bad players (Playe</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 27 Apr 1998, 23:09 GMT
<UL>
<LI><strong><A NAME="00782" HREF="msg00782.html">[MUD-Dev] Re: (fwd) Re: POLL: Games ruined by bad players (Playe</A></strong>,
Dr. Cat <a href="mailto:cat#bga,com">cat#bga,com</a>, Tue 28 Apr 1998, 02:04 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
