blob: 2e3c7ff754e359beda84286b9eaf1138f6497e03 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001 LPC Basics
2 Written by Descartes of Borg
3 23 april 1993
4
5
6 INTRODUCTION
7 This manual, how to use it, and its terms
8
9I have seen a lot of requests lately on USENET for LPC manuals. In addition,
10the immortals on my mud have been telling how good the building documentation
11of Nightmare is, but that there was just no adequate explanation of the
12LPC programming language. So I decided to try my hand at writing a manual.
13Some things you should keep in mind.
14LPC is a very easy programming language to learn, and it has real
15value in that place most of us know as the real world. I began playing
16muds in 1991, and in the space of a month created an unimpressive area
17and musician's guild on the original Bates College MUD called Orlith.
18After that, I moved to Los Angeles for a year and had no contact with
19mudding or computers. In June of 1992, I was back on the internet and
20a wizard of Igor. In September of 1992 I began coding the Nightmare
21mudlib for our use, and then later decided to distribute it due to there
22not being any mudlibs for MudOS at the time that a person could just throw
23up a running mud with (now, that of course is not the case :)).
24So, I have been doing serious coding for less than a year. As a
25Philosophy major in a world of Computer Science majors, I just want to
26make clear that it is not at all required that you have ever done anything
27with your computer than log into a mud in order for you to really come
28to understand LPC coding. This manual makes the following assumptions:
29Someone has taught you basic UNIX commands like ls, cd, mkdir, mv, rm, etc.
30You know how to enter your mud's editor and write a file. No other
31assumptions are made. If you know C, you are handicapped in that LPC
32looks a lot like C, but it is not C. Your preconceptions about
33modular programming development will be a hinderence you will have to
34overcome. If you have never heard of the C programming language (like
35me in May of 1991), then you are only missing an understanding of the
36simple constructs of C like the flow of program execution and logical
37operators and such. So a C guru has no real advantage over you, since
38what they know from C which is applicable to LPC is easy to pick up.
39The stuff they know about C which makes them a guru is irrelevant to
40LPC.
41
42The chapters of this manual are meant to be read in order. Starting with
43the introduction, going sequentially through the chapter numbers as
44ordered in the contents file. Each chapter begins with a paragraph or
45two explaining what you should have come to understand by that point
46in your studies. After those introductory paragraphs, the chapter then
47begins to discuss its subject matter in nauseating detail. At the end
48of the chapter is a briefly worded summary of what you should understand
49from that chapter if I have been successful. Following that may or may
50not be some sidenotes relevant to the subject at hand, but not necessary
51to its understanding.
52
53If at any time you get to a chapter intro, and you have read the preceeding
54chapters thoroughly and you do not understand what it says you should
55understand by that point, please mail me! Clearly, I have failed at that
56point and I need to know where it is I have gone wrong so I can revise
57it properly. Similarly, if you do not understand what the chapter summary
58says you should, please mail me. If your mumud is on the MudOS intermud
59system, mail descartes@nightmare. Otherwise mail borg@hebron.connected.com.
60
61Some basic terms this manual uses:
62driver-
63This is the C program which is the game. It accepts incoming sockets
64(links to other computers), interprets LPC code defined by the mudlib,
65keeps mud objects in memory, makes periodic attempts to clean unused
66mud objects from memory, makes periodic calls to objects, and so on.
67
68mudlib-
69LPC code which defines the world in which you are in. The driver of itself
70is not a game. It is just a program which allows the creation of a
71multi-user environment. In some sense, the driver is like an LPC
72compiler, and the mudlib is like a compiler's library (a very loose
73analogy). The mudlib defines basic objects which will likely be used
74over and over again by people creating in the mud world. Examples of
75such objects are /std/room (or /room/room), /std/user.c (or /obj/player.c),
76and so on.
77
78area or castle:
79Specific creator coded objects which often use a feature of LPC called
80inheritance to make use of the properties of basic mudlib objects and
81turn them into specific objects to be used by players in the game
82
83object:
84a room, a weapon, a monster, a player, a bag, etc. More importantly,
85every individual file with a .c extension is an object. Objects are
86used in different ways. Objects like /std/living.c are inherited by
87objects like monster.c and user.c. Others are cloned, which means a
88duplicate of that code is loaded into memory. And still others are
89simply loaded into memory to be referenced by other objects.
90
91native and compat:
92these two terms refer to two popular flavours of drivers. Native mode
93mudlibs make use of on the design of LPMud driver 3.0 and later. You may
94have a 3.0 driver however, but have a 2.4.5 style mudlib. This is what
95is meant by compat mode. Mudlibs which are native mode are any for
96MudOS, CD, and LPMud mudlibs that
97are listed as native. Compat mudlibs are any LPMud mudlib before 3.0 and
98those which are 3.* compat mudlibs. I believe Amylaar's is compat.
99[ Not true, Amylaar supports native and compat mudlibs, MorgenGrauen
100 is native - Boing ]
101
102Good Luck!
103George Reese
104(Descartes of Borg)
10512 july 1993
106borg@hebron.connected.com