LPC (programming language)
LPC is an object oriented programming language similar in syntax as C or C , for network text adventure games ( multi-user dungeon, MUD short ).
LPC is a mixture of the interpreter language and compiler. LPC MUDs usually allow, at runtime add programs to start and also subsequently change without starting the whole game. The LPC code is first converted by a compiler into a bytecode and then executed by an interpreter.
History
The term LPC derived from the inventor of the language, Lars Pensjö, from. Pensjö LPC has developed in the early 1990s and after an assessment of the C programming language. Apart from the similar syntax but there are a few similarities between the two languages.
In the original implementations of the language LPC were compiler and bytecode interpreter components of a single program, the basic, put necessary functionality for the operation of a Multi -User Dungeons, the so-called Game Driver or Driver shortly. Also the MUD Amylaar contributed substantial part to the driver. This primarily involves the operation as a server to a Telnet or a special MUD client a connection can be made . This software is distributed under the name LPMud; a modern development based on the original source code LPMud listens to the name LDMud ( also after the initials of the maintainer ). Another implementation of the same concept, including the language LPC is MudOS.
From the LPC independent script language Pike emerged. This has so far not reached a high penetration levels.
Features
LPC supports the following programming techniques:
- Procedural programming
- Modular programming
- Structured Programming
- Object-oriented programming ( with multiple inheritance )
- Programming with user-defined data types ( abstract data types )
- Weakly typed variable
Differences to other C-like languages
The basic syntax of LPC corresponds to the C language, including the characters used for the identification of blocks, functions, arguments, and argument lists and the use of the semicolon as a statement terminator.
In contrast to C LPC has no strongly typed variables. Although a variable can be created with a predetermined type, but then still add a value of another type. In addition, the mixed type exists for untyped variable.
This also has an impact on return values and parameters of functions: in the normal case, neither the arguments nor return value must be provided with types in the function signature. However, you can force a check for valid arguments for the translation time by specifying preprocessor directives:
- # pragma strong_types - types for arguments and return value must be specified
- # pragma strict_types - will cast the return value of the called methods in foreign objects must
The class library of MUDs
The language LPC knows only a small number of standard functions ( efuns ). These are in the executing program (game driver), so for example LPMud or LDMud implemented. In addition, each MUD, which is operated with such a software, a separate class library ( MUDlib ). The MUDlib contains interfaces that allow the driver can game some of the responsibility back on them. This includes the generation of a player object to a player is logging or error handling. There is here no standard MUDlib that would be used by all MUDs. However, some MUDlibs be in operation in the are open source or otherwise free to use. Relying on a few MUDlibs freely available more widespread MUDlib branches have emerged that are used in many MUDs. In German-speaking countries, for example, the descendants of the MUDlibs MUDs dawn on the one hand and on the other hand UNItopia are common.
Differences with respect to the runtime environment
Apart from the linguistic side, LPC differs in several points with respect to the definition of the runtime environment of other programming languages. With the original objective as a language of an online role-playing game, in which multiple developers can bring their own code with different rights, the runtime includes, for example, so-called privileged functions that can be called only after prior review by a master object of MUDs from a normal object.
Current LPC runtime environments does not support threads. In a single thread sequentially all tasks to be done. This necessarily results in a limitation of the duration that is set for the treatment of a coherent event. In LDMuds this limitation can be dynamically revoked or for single function calls.
Another special feature is the almost complete equivalence of built-in functions ( efuns ) with the class library of MUDs ( MUDlib ) given simul_efuns. In this way it is possible to override standard functions or prohibit access to it.
Differences in object orientation
In contrast to many LPC known object-oriented programming languages , no distinction between classes and objects. Normally, a single object is generated from a source code file. However, all objects in memory can be duplicated ( cloned / cloned ). The process of Clonens is similar to the instantiation in other programming languages ; However, the clone ( clone ) and the original ( blueprint ) are equal and both can theoretically be used in the same way.
Special constructs
LPC has no concept of shadowing. It is a possibility, a function of an object to intercept all accesses from the outside, for example, to filter it or to stop completely, similar to the Decorator Pattern. The principle is applied by an object with the efun shadow ( ) is registered as a "shadow" of any other object. When a call to a function of the target object, which does not happen directly within the target object, then the same function in the shadow object is called if this object contains such a function. Exists in the shadow object not a function of the same name, the call like a normal function call is treated in an object without shadow. The shadow object also has the ability to function in the target object that " overshadowed " it to call.
Special data types
Functions are in LPC no first -class objects ( first-order functions). Nevertheless, the language has function references. Borrowed from the world of functional programming is the name of closure for this data type, based on the concept of closure. The referenced function can be dynamically created using the function lambda ( ) at runtime. It creates a new function is created from an array of closures and symbols at runtime, which can then, like any other closure, passed by value or called as a function. The variant used in the LPMud LDMud LPC development also contains the ability to create on informally specified inline functions at compile Closures. For this purpose, the so-called Smiley notation is used in the normal LPC code within (: and :) is converted by the compiler into a normal function of the object and the expression will be replaced at the site of its occurrence by referring to this function closure.
Arrays exist in LPC and may in the code with the individual elements are separated by commas and enclosed by ({ and}) are generated. Access to individual elements is done using the index operator [ ] comparable to C. In addition, there are standard functions for handling arrays. Arrays, as well as other variable also untyped. This means that the elements of an array may be of different types. Other arrays are also allowed as elements of an array. This makes it possible to LPC to build complex structures as arrays. A variable that can hold an array is, by the element type hintan asked Asterisk (*) is indicated. However, no type checking is performed. Variable of type mixed may also contain an array.
LPC also knows also called associative arrays similar to the dictionaries of the Python language. In LPC, the term mapping is used for this. These mappings are implemented as a hash table. In an associative array, a key element of a value can be assigned. A special feature of associative arrays in LPC is the per mapping variable number of values per key. Thus, a mapping example for each key contained an arbitrary but within the same mappings number of values. To address these values , nor a numeric index, in addition to key at a level indexing operation can be specified.
Hello world program in LPC
The following object is when it first loads the text " Hello, World! ", since the create ( ) method is usually called automatically when loading / cloning of objects.
Void create () { write (" Hello, World! "); } Complex example object
LPC is mainly used for the description of objects in role-playing games. Such objects are, in many cases, objects, people, or spaces of a virtual world. The class library ( MUDlib ) therefore typically contains objects that in general an object - or a particular class of objects - represented. The same is true for rooms, monsters, and all other objects that need to be frequently produced in different variations.
The following example refers to the application of LPC with an existing class library that is not supplied by LPMud. It implements an apple and inherits from a standard object that implements edible food from the player. This includes the need to implement the dining operation in the game logic. In the inheriting object must then only the values of properties are set, the specific effects of eating within the possibilities of the base class. Which in this example is referenced MUDlib this the SetProp () function available. The names of the properties are preprocessor macros. It is, depending on the MUD, also common to access properties of individual accessor functions.
Inherit " / std / food";
# include
Links to MUDlibs
- Tubmud access
- The English MUDlibs Heaven7 and D20
Newsgroups
- De.alt.mud ( in Google Groups)
- Scripting language
- Object-oriented programming language
- Computer game development