Any idea you want to code in an LPMud is possible. LPC is a language which is amazingly well suited to this task. All that prevents you from coding your ideas is your knowledge of LPC or an inadequate mudlib or your mudŐs theme or administrative policies. This textbook cannot make the mudlib you are working with any better, and it cannot change the mud theme or the mudŐs administrative policies. Never once think that LPC is incapable of doing what you want to do. If your idea is prevented by administrative policies or themes, then it is simply not an idea for your current mud. If the mudlib is inadequate, talk to the people in charge of your mudlib about what can be done at the mudlib level to facilitate it. You would be surprised by what is actually in the mudlib you did not know about. More important, after reading this textbook, you should be able to read all of the mudlib code in your mudŐs mudlib and understand what is going on at each line in the mudlib code. You may not as yet be able to reproduce that code on your own, but at least you can understand what is going on at the mudlib level.
This textbook starts out with a discussion about what the LPMud driver is doing. One nice thing about this textbook, in general it is completely driver and mudlib independent (excepting for the Dworkin Game Driver). The chapter on the game driver does not get into actual implementation, but instead deals with what all game drivers basically do in order to run the mud.
Next I discuss those magic topics everyone wants to know more about, arrays and mappings. Mappings may be simultaneously the easiest and most difficult data type to understand. Since they are sort of complex arrays in a loose sense, you really need to understand arrays before discussing them. All the same, once you understand them, they are much easier than arrays to use in real situations. At any rate, spend most of your time working with that chapter, because it is probably the most difficult, yet most useful chapter in the book.
After that follows a brief chapter on the LPC pre-compiler, a tool you can use for sorting out how your code will look before it gets sent to the compiler. Despite my horrid intro to it here, this chapter is perhaps the easiest chapter in the textbook. I put it after the mappings and arrays chapter for exactly that reason.
Strings are re-introduced next, going into more detail with how you can do such things as advanced command handling by breaking up strings. Once you understand arrays fairly well, this chapter should be really simple.
The next chapter is the second most important in the book. It may be the most important if you ever intend to go beyond the intermediate stage and dive into mudlib coding. That chapter involves the complex ideas behind LPC inheritance. Since the goal of this textbook is not to teach mudlib programming, the chapter is not a detailed discussion on object oriented programming. Understanding this chapter, however, will give you some good insights into what is involved with object oriented programming, as well as allow you to build more complex objects by overriding functions and defining your own base classes.
Finally, the textbook ends with a simple discussion of code debugging.
This is not an essential chapter, but instead it is meant as more of an
auxiliary supplement to what the knowledge you have accumulated so far.
1.4 Not Appearing in This Textbook
Perhaps what might appear to some as the most glaring omission of this
textbook is largely a political omission, shadows. Never have I ever
encountered an example of where a shadow was either the best or most
effecient manner of doing anything. It does not follow from that, however,
that there are no uses for shadows. My reasoning for omitting shadows
from this textbook is that the learner is best served by learning the concepts
in this textbook first and having spent time with them before dealing with
the subject of shadows. In that way, I feel the person learning LPC will be
better capable of judging the merits of using a shadow down the road. I
will discuss shadows in a future textbook.
If you are someone who uses shadows some or a lot, please do not take the above paragraph as a personal attack. There may be some perfectly valid uses for shadows somewhere which I have yet to encounter. Nevertheless, they are not the ideal way to accomplish any given task, and therefore they are not considered for the purposes of this textbook an intermediate coding tool.
I have also omitted discussions of security and object oriented
programming. Both are quite obviously mudlib issues. Many people,
however, might take exception with my leaving out a discussion of object
oriented programming. I chose to leave that for a later text, since most area
builders code for the creativity, not for the computer science theory. In both
the intermediate and beginner textbooks, I have chosen only to discuss
theory where it is directly applicable to practical LPC programming. For
people who are starting out green in LPC and want to code the next great
mudlib, perhaps theory would be more useful. But for the purposes of this
book, a discussion of object oriented programming is simply a snoozer. I
do plan to get heavy into theory with the next textbook.
1.5 Summary
LPC is not difficult to learn. It is a language which, although pathetic
compared to any other language for performing most computer language
tasks, is incredibly powerful and unequalled for the tasks of building an
area in MUD type games. For the beginner, it allows you to easily jump in
and code useful objects without even knowing what you are doing. For the
intermediate person, it allows you to turn any idea you have into textual
virtual reality. And for the advanced person, itŐs object oriented features
can allow you to build one of the most popular games on the internet. What
you can do is simply limited by how much you know. And learning more
does not require a computer science degree.
Copyright (c) George Reese 1993