This documentation was produced in good faith for use by people who like to program muds for their own pleasure. That means that we won't charge for using or distributing it provided that this is the purpose it's being used for.
Specifically, we want to make sure that someone who runs commercial muds don't provide this manual as an aid to further their monetary aims. If they want it they can either pay us a lot of money for it or produce one of their own.
Please read the copyright statement in the printed section of this manual to get the full text. The gist of it, however, is exactly what was related here.
The background behind this rather gargantuan project naturally is that neither Thorsten nor I (Ronny) can leave well enough alone. It's a well-known phenomenon that as soon as things are starting to settle down one tend to edge expectations and goals another notch upwards and start over. This project is very much intended to be a development in mud strategy of the same order as when we moved from version 2 to 3 in the Genesis mud.
For this reason it's impossible to start using an old mudlib and just update that, keeping old code in the game. One has to start fresh from the bottom, rewriting every scrap of code there is, revising both the thinking behind the setup as well as the actual code itself.
It is our hope that other mud administrators will find this work worthwhile and switch to using it, but we're really only doing this for our own personal pleasure and satisfaction.
This documentation contains information both for players, coders and people who wish to use the code for their own projects.
A lot of people have been active in helping out with suggestions and ideas for the mudlib and the game. Their individual efforts aren't in any way documented in the actual code, we like to see this as a common effort where who actually wrote which line of code doesn't matter much. However, we certainly would like to make known who they are and in a general sense what their main contributions are, just so you'll know whom to grovel for and why :) The names within brackets are their best known mud identities.
LPC is the interpreted mud language created by Lars Pensjoe for his invention LPMUD, an interactive multiuser environment suited for many purposes, games not the least among them. Since the first appearance in 1988 the language has changed dramatically.
Ronny Wikh started out as arch-wizard of Genesis at the time Lars Pensjoe still was active. Since then he's been in and out of the administration in that game a lot of times, when he's in he's mostly been `Keeper', manager of the game.
Thorsten Lockert became involved at a later date, but soon also became involved in administrating the game as arch-wizard and general busy-body. Both of them now reserve their strength to working at this project at the exclusion of all others.
Felix A Croes was one of the early participants of the first LPmud, making himself very useful as a hyper-active trouble-finder in the game. It wasn't long until he became possessed with ideas about how to do things that differed with Lars' approach and started the development of his own Game-driver. In the game he was known as Dworkin, so the name of the game-driver became Dworkin's game-driver, DGD for short.
This game-driver differs from Lars' in the fundamental thinking that it is very minimalistic functionality-wise. In this concept that means that if you can create a function in LPC through the use of other game-driver functions, that function has no place in the game-driver. It's also written by one single person - Felix - which means it's a lot easier to read and written in just one style, not several over the years by different people.
As we add our efforts we will make certain exceptions to Felix' ideas and introduce concepts he didn't intend to be there from the start. To a certain extent we are, by doing that, corrupting the game-driver. However, as will become clear in this documentation, all of the things we add are closely related to the basic principle of the game we want to build.
The distinction between game-driver and mudlib might seem hard to define at times, but it's really very simple. The game-driver is the program that runs on the host computer. It is basically an interpreter in conjunction with an object management kernel, almost a small operating system in its own right. It defines and understands the LPC language, interprets it and executes the instructions given to it through the LPC objects in the game.
The mudlib is the collection of LPC objects that make up the basic game environment. While the game-driver knows nothing about what it is actually doing, the mudlib does. (The mudlib can conversely be said to have no idea about how it does what it does, while the game-driver does). It contains the basic set of LPC objects that are used in the game, the players, the monsters, the rooms etc. Individual efforts (game code) is stored and handled separately and uses both the services of the game-driver and the mudlib.
As stated, we are using the game-driver produced by Felix A Croes, the DGD, of the latest version available. Since Felix keep hacking away on it, we'll keep updating ours as well as time goes on. We also keep adding on our own bits and pieces to the game-driver to make it work as we figure it should. These additions are for most part available as add-on `packages' distributed along with the DGD by Felix himself. For some reason most of what we've done so far seems to have pleased Felix and found its way into the main distribution. We count that as a nice compliment on our part :)
The mudlib is an entirely new creation, written exclusively by us for the benefit of SO2403. However, we do code it to be fairly flexible and general anyway since that's usually the most convenient way of writing things. It's distributed as free-ware under the same conditions as this manual.
The game code that makes up so2403 as such, i.e. the rooms, the NPCs, the gadgets and all of that for most part is the property of the individual coders of the game. It is not distributed in any way, in fact it is covered by a copyright of it's own.
The world of SO2403 is centered around a common theme. No deviations from this theme is allowed. The idea behind this (as compared with most other muds) restricted environment is to provide a much better define setting for role-play for the players. SO2403 is short for 'Space Opera AD 2403', and anyone familiar with Space Opera knows that it's full of opportunities both for adventure and role-play.
Now... before you go on reading any more you should determine your position in the game. Are you a player or a coder? Players should read the player section following immediately on this text, but nothing more. There's nothing stopping you from going on and reading the rest, but it's my belief that it will take away quite a lot of your enjoyment in exploring and finding out about things for yourself in the game. I really recommend you to restrain your immediate curiosity and instead find things out the exciting way - by playing.
Coders on the other hand are required to read each and every word in the entire documentation, or they'll stand no chance of producing a worthwhile contribution to the game.
The player section contains information of how to become a coder, in case you're just starting out right now but thinking of another career later. Remember that no one starts out as coder without having been a player first, so there's no need to rush ahead.
NOTE! The game is NOT set up for playing yet. It's impossible to enter, and impossible to even register with. All the instructions below are preliminary.
Obviously the purpose of this game is to play it! However, you'll need a bit of an introduction before you can start. You can either read this manual that'll provide you with all the information you'll need to know about the basics, or you can stumble headlong into the game and try to collect the same information by asking people and discovering for yourself what's going on. Your choice. :)
Anyway, for the people with a desire to know what they are getting themselves into before the fact, here's a bit of stuff for you to read:
Do you have to be a role-player to join SO24303? No, you don't. However, it's a lot more enjoyable if you do put in an effort to actually live a character. SO2403 really tries to live up to the Space Opera feeling, and role-playing is the glue that makes everything stick together here.
For those unfortunates that never has played a role-playing game of any kind before, let me explain that role-playing simply is the act of as much as you're able living and being the character you portray. For that reason we have created a rather extensive background in which you live along with descriptions and commands that will enhance your role-playing capabilities as much as we can make it possible within the interface to the world.
To be able to role-play you need to read all the information about the world you will be part of, and you will also have to come up with part of a background yourself. In SO2403 there are several races available, not just earth humans but aliens of various kinds as well. Playing aliens is tricky, a lot trickier than being a human, so I really advice you to start out as an 'ordinary' earthling. Later you can simply swap to another race just as you like.
Now... what is role-playing as such? Well... read this just for starters:
Your character in the game is not just a set of numbers on a server, but a role that you play, quite different from your own personality. The way you act is influenced by his or her race, alignment, chosen profession and so on... To avoid becoming a stereotype, you can also add your own personal touches to the preconception of how you want others to think of your character. One easy way of doing this is to pick an adjective to begin with, and stick to it for a while:
"I am an honourable adventurer" or "I am a sleazy adventurer".
The personality of your character is the most important part of role-playing. Useful tools of the trade to spice things up are manners of speech, use of emotes, and so on...
Imagine the following situation: A human player is faced by a another player (a Heth-type alien), standing over the corpse of one of his comrades.
Standard course of events:
The human player says: You killed one of my pals, now I can attack you and get your stuff!
The other player: Yeah, well like you could even scratch me you puny fuck, I've got four topped stats, a medibot and a laser gun!
(PLAYER FIGHT)
Role-playing course of events:
The human player says: You creep! You killed my buddy in cold blood! I'm going to stomp you flat for this, you roach!
The other player says: Matsho! You will soon djjoin the thcum human thlime rotting on the filthy ground! Much honour to m'Heth for me.
(PLAYER FIGHT)
In the first example, the human and the Heth player acted out of character, and it was a conflict between the two players. Even if the two characters in the second example acted a bit stereotypically, it was clearly a role-playing situation. So what is the difference, really?
Well, in the first example, the human is angry because of the fact that the Heth killed a friend in the game, but as he is not a role-player, he views the Heth simply as a "mobile" which happens to be a status symbol because it is the source of potential loot. He is also outraged by the fact that this ass-hole actually killed on of his chosen type of characters... This is not role-playing, merely a rivalry between two power-players.
In the second example, the human is horrified by the death of a fellow adventurer, a faithful companion in countless adventures. The Heth is an evil monster, driven by unfathomable motives and a savagery that is just barely contained by his servitude to m'Heth - the deity of all their ilk. He is invigorated by the victory, and thirsts for more carnage... In the second example, the players are clearly separated from their alter egos in SO2403. In fact, if they are real role-players there could be a player fight and a death, and the players could talk about it and laugh later when they are not in character. The manner of speech also adds a bit of spice to the course of events (no pun intended).
The world of SO2403 is a very dynamic place. Great events have taken place in the history of Earth that forever will change the way people act and look upon the universe. You will play a character who's caught up in the maelstrom of development, intent on making the most of it for your own personal satisfaction.
The year is AD 2403, even though few people still refer to it as being 'anno domino' - in the year of the Lord. The old entity-based religions of Earth is dying away, loosing ground for the old Indian and middle-east religions based on the perpetual soul rather than a supernatural being. New alien religions are also gaining followers among the people of Earth, hungry for something new that will change their lives. None of them has anything more substantial than faith to offer though, so it's much the same story as ever but perhaps on a higher level of education, generally speaking.
Population on Earth has stabilised around an even figure of 8 billion, this after enforcement of strenuous laws regarding birth control and food production. Anyone who feels these laws are unjust are free to emigrate to an off-world colony somewhere, even though the choice of destination might be very limited unless you have special education or abilities. Still, the option is there and lots of people take it. Life on Earth is safe, but dull and as the players of the game supposedly make up the elite of the more adventurous-minded, they will have little enough to do with the people there. Read the excellent descriptions of an Earth of this kind in Ann McCaffrey's `Decision at Doona', Niven & Pournelle's `Legacy of Heorot' and naturally Isaac Asimov's pre-foundation series `The caves of steel' and related novels.
The events that led to this situation begins in AD 2105 with the accidental discovery of the TE (trans-Einstein) drive. The 100-km highly radioactive craters that you find where Cern and Boston used to be marks the spots where the TE effect were first explored. A certain sense of caution instilled itself on the scientists after that so the following experiments were not as costly. However, it was another fifty years before the first TE-drive was tested in orbit.
The use of independent computer-controlled vessels proved to be a total flop however. They were sent away, but none returned. At the time the exact effect of the TE-drive was not known, but the scientists had (correctly) guessed that a TE-jump of less than one light year was not possible and that the direction of the jump (wrong) was determined merely by the speed and direction in E-space at the time of entering TE-space.
After ten years of costly and remarkably unsuccessful experimenting a fleet of a hundred well-armed, well-armoured spaceships suddenly appeared in orbit around Jupiter. Suddenly man realized he wasn't alone in space any more. The commandant of the alien vessels promptly headed for Earth and began a series of tactical maneuvers that left the Earth defenceless and quite at the mercy of his whims. However, people being what they are didn't quite accept this until all of Chicago, Baghdad, Tel Aviv, Berlin, St Petersburg and Beijing was smoldering holes in the ground. After that negotiations went rather smoothly.
It turned out that the visitor wasn't a conquerer after all, he was simply the local (20 ly globe) chief of the cybernetic police. After having been straightened out on what was really going on he was honestly apologetic. So begun Earth's membership in the loosely tied confederation of intelligent species that to this date consists of ten major species and another 20 or so who's still struggling to lift themselves from the stone-age level.
(Confederation of the Sapient Species of the Galaxy)
As far as anyone can say the history of the confederation begins about a million years ago, approximately at the dawn of man in fact, with two races inhabiting two different (but close) systems in the region of alpha Ursa Major. Certainly there is proof if intelligent races elsewhere both earlier and at the same time of these events, but as we will see they haven't left quite the impression on the galaxy as these two did.
Their development was quite parallel even though they developed from different backgrounds and social circumstances. Both turned war-like and aggressive and due to the (relative) proximity of their systems they early on became aware of each other. None were particularly interested in friendly cooperation but the (then) unconquerable gulf of space that separated them kept them at arms length for a long period of time. Then one of the races discovered the TE drive and immediately set up to build a fleet of warships to conquer the other race. The other race however, got hold of the news some time before the actual attack and frantically prepared for a final battle.
Instead of a quick bomb-and-grab campaign, the war turned into a generation long struggle. The end came some three hundred years after the first attack when weapons development had taken one of the races deep into computer research, resulting in methods where computers could be, first surgically then genetically, implanted in living tissue, thus enabling a super-race. Unfortunately the result was not quite what the researchers originally had desired. The new race proved to harbour an unforgiving megalomaniac and xenophobic mind, incapable of thinking the word 'peace'.
Other, more peaceful races around the galaxy had cautiously begun taking contact with each other. A loose network of interstellar treaties formed as one race after another discovered the TE effect and made themselves known. The culmination came some 300.000 years ago when the now victorious race of cybernetic beings managed to puzzle together the remains of the TE drives that had fallen into their hands during the final battle. They immediately set out on a war of annihilation and before anyone could react they had managed to utterly destroy thirteen systems.
The survivors frantically tried to find a way of ending the threat, but little save brute force seemed to work. The ensuing fight ended only 2000 years previously with no real winners. Another six systems had met their doom, two was reduced to the animal state and the remaining five had suffered losses so big it would take them a millennia to recover. Of the cybernetic race they fought, only ancient bases and a few scattered ships remained.
As the five surviving races struggled back to their previous level of development they resolved themselves never to let this happen again. A confederation was formed and while the charter is long and complicated it boils down to a resolution that no race, nowhere, will be allowed to use computerised equipment other than as a non-intelligent piece of machinery. In other words; no cybernetically linked machines, no computers capable of independent thinking and reasoning.
As time went by they encountered both new races who were invited into the confederation and remains of the cybernetic race that promptly was destroyed. When the scientists of Earth started experimenting with TE- ships 'manned' only by computers, the confederation immediately sent out a force to stomp out the plague before it could spread to unmanageable size. As they realized their mistake Earth was invited to join the confederation and a whopping big sum of money in the form of technical aid and other trade was paid as damages, soothing the ruffled governments who hastily had brought the entire Earth on war footing.
Approximately three hundred years has now passed and while Earth still is the most junior member of the confederation, it has rooted itself well among the others and things are looking good.
Crossing over to TE space isn't particularly difficult. It requires the use of a fairly big computer to determine the space-time relative to the rest of the universe at the particular spot where the mass to transfer resides. The effect is stable only in an environment of about 10 angstrom from that point, requiring a rather lot of simultaneous computations if one wishes to transfer larger masses. Failure to do this results in complete mass-energy conversion for the offending masses. A psychological factor is also involved in the actual transition, requiring a trained pilot to guide the drive in and out of TE space at a favourable moment. This explains why purely mechanical ships never end up where they had intended and why pilot training both is expensive and in high demand.
The TE effect as such is instantaneous. The pilot relies on the computer to keep the electro-magnetical fields around the ship in a state where transition is possible and then simply wills it over at the 'right' time, as he sees it. Physical limitations dictate that this can only happen near a large mass, but not too close, say 10-30 radius distance from an earth-sized object. Without a mass-reaction point nearby nothing will happen, so if a pilot accidentally drops his ship in empty space he will have slow journey back on reaction drive alone. The transition requires an almost indecent amount of energy, however this is no problem since the required power easily can be generated by allowing the computer to transition small amounts of matter in the centre of a specially designed reactor. The result of deliberate miscalculations will then generate any desired amounts of energy through total mass-energy conversion.
Power-up and field stabilisation sets the jump-preparation time to anything from one to ten minutes, thereby also defining the minimum and maximum time for a TE jump. A jump can not be shorter than one light year and may not end up closer to a planetary mass than the distance required to jump from it.
Current technology level sets the minimum size of a TE ship to be approximately the size of 20 greyhound buses, stacked in a 4x5 heap. This leaves living room for the pilot, the computer engineer, the drive engineer and nothing else. Theoretically the only the pilot could transition simply by limiting the field on himself, but he would then have to rely on someone to pick him up on the other end before he dies in the cold space - a rather bleak prospect. The TE effect dictates that no matter what the pilot wishes to bring with him HE must go in any case. He can't send away stuff and remain at the same time.
While only matter can be sent by use of the TE effect there is a method by which very simple information can be transmitted. This method is used by derelict ships to signal for help. If one allows the TE-field to collapse uncontrollably, the result will be of a momentary disruption of the TE-space in that region, the effect of which can be detected everywhere. Private rescue/salvage companies routinely scan for such disruptions. These companies has invested tremendous amounts of money to find and capture a micro black hole. They simply build their ship around the black hole and bring it along with them as they jump. Unfortunately, in doing so they need to consume about as much energy as a medium-sized star outputs in a week, and there's no shielding available that will protect the crew entirely from such the leakage that unavoidably occurs in such a blast. For the cost of building and maintaining this contraption and the inherent risks of using it they charge a very stiff premium from anyone using their services. There's another drawback as well; The result of the TE-field disruption is to completely scramble any matter within the area of effect. This means that the crew of a spaceship who wishes to send out a distress call must jettison the TE-drive, or they will be scrambled along with it. The cost of such a call together with the premium for rescue usually makes people very careful about getting the jump go right the first time.
For reasons of security and keeping an orderly setup on the game, we have chosen a rather different approach to how players (and coders for that matter) join SO2403. What follows might sound harsh, but unfortunately there's ample precedents on other muds to warrant this procedure.
Instead of just logging on and creating your character, you are required to set up a user account. You set up your interface options as well as play your characters from there. You are allowed to have more than one character in the game, in fact up to ten individual characters, but only one logged on at a time. Breaking the rules of SO2403 might end up with having your account terminated with no chance of ever getting it back, effectively preventing you from playing the game for good, so please behave yourself.
In order to set up an account, you need an ordinary account on a computer with an email address. This account must be yours and not shared with anyone else. We're sorry, but we can not accept applications from people who do not have an email account. Just telnet to so2403.cd.chalmers.se 2403 and follow the instructions there. You will be asked to state your real name, country and city you're living in as well as your email address. This information is treated as confidential and not shared with anyone. Only the administration of SO2403 have access to it (it's encrypted on file) and they will not reveal it to anyone, even in the event of having to dismiss you from the game entirely. Failing to provide this information or giving false information will result in your banishment from the game forever.
The reason we require this information naturally is to keep the cheaters and game-wreckers at bay. You, the serious and honest kind of player, will only be protected by this system. There exists no hidden obligations or drawbacks.
Upon completion of this information you will have to wait a while during which the game automatically checks your application against a list of previously evicted offenders. Provided nothing untoward is detected you will be mailed a temporary user password. You can then log on to your account and start exploring the game. If for some reason your request can't be admitted, an explanatory letter will be sent to you. If you don't receive a reply within 24 hours of applying (usually it's just a matter of minutes) you should contact the mud administration to find out what has gone wrong with the application process.
Here's just a bit of information about how your character works in the game. It's a bit different from most other games, so pay close attention:
First of all, you can't move your character out of the game while you're logged out. Once your character enters the game he won't leave it until he dies. This means that if you just log out or become link-dead your character will switch to a somnambulate dazed state. In this state he's able to move around and defend himself a bit, but he's really no match to a determined aggressor. On the whole it's best if you find a safe place for him to hole up while you're not in command. On the other hand he won't ever lose what he's holding, unless you explicitly drop it.
When your character grows in experience, he'll become stronger, more intelligent and robust. However, it's not like with other games where a newbie player wilts if you look at him and an experienced adventurer topples buildings by breathing hard on them. No, you'll evolve physically a bit, but not a great bit. The emphasis here lies on equipment and education. The older and more experienced you get, the better equipment and skills you can acquire.
When your character dies in the game he's dead. However, there's great medical faculties available in SO2403, you don't necessarily have to stay dead. Not if you remembered to pay your health insurance policy anyway. Keep in mind though that a body can only be abused so much. Dying ages the body... which leads us to the next surprise:
Your character has a limited lifespan. Adventuring is hard on the body, and you can't really expect to live forever, now can you? Oh you expect it, well, that's just too bad. In any case, your character will eventually start to deteriorate due to old age and ultimately die. Death through old age is not reversible, it's final. The total life span of a character corresponds to about 40 days of logged playing though, so he really is rather long-lived. The risk of dying through other misfortunes is a lot greater.
All this death sounds real serious and... well... boring. How much fun is it to play a character who'll be gone eventually anyway? Well, dying is part of life, people do it sooner or later no matter how much they try to avoid it and we prefer not to cheat here and pretend otherwise. However, all need not be lost. Your name can live on if you want it to: When you create a character you are asked for a family name, this name is linked to your user account and only you may use it. When your character starts to deteriorate you may play him until he finally dies from old age, or retire him early. Then you can start a new character with the same family name, this new character may even inherit the old and thus get a head start. So, while the individual may die, the family line will live. Old family lines naturally are well known and hold great power in strength of their continuity. For obvious reasons, family lines are race-bound. You can't expect a human to become another race and retain the same family name, fortune and reputation.
In the game, you won't know everyone by name just by looking at them. People are fairly anonymous being and you need a proper introduction to know them on first name basis. So don't be too surprised if you at first get the impression there's no one in the game, it's just that you don't know anyone yet.
The rules are all rather simple, they can be summarised into the simple sentence Do not impede on your fellow player's right to enjoy the game. However, there's details that needs elaborating so the list below will indeed be a bit longer. Remember though, that the administration won't feel bound by the exact wording of the rules, it's the intent that counts. Don't worry too much though. Just be honest and all will be well.
Coding in the game is not a natural continuation of the playing process. it's a vocation in its own right and you really must be serious about it in order both to be accepted, or later to succeed.
While you won't be banned from playing entirely, it must be understood that by becoming a coder you do agree to put a major part of your effort into creating, not using. Playing the game will in fact be required of you in order to keep in touch with what's going on, but it's coding that you should concentrate on. If you do discover that playing is more enjoyable than coding, you really should retire (temporarily or for good) to pure player status rather than be humiliatingly dismissed for inactivity later. There's no shame in discovering ones preferences after all, and certainly no honour in sticking to something one really doesn't enjoy either.
In order to code in the game you must have a reasonably good understanding of how it works. For certain, good coders are usually not the same thing as good players; Those who like to create often enough doesn't much like to participate in the game as such. However, a certain period spent in getting in touch with the game and what it entails is necessary.
Hence the requirements to become a coder is as follows:
To apply for coder privileges simply use the special 'apply' command (use help within the game for the exact syntax). Your application will be processed and replied to as soon as possible.
We need a unified setting in the mud so that people later only add stuff that fits in. So many muds are lacking in a central theme to hang on to, Genesis none the least, which makes the game hard to understand and prone to imbalancing factors from stray themes that collide with others in various aspects.
In order to remedy this we will be opposed to allowing people to paste in themes or major scenes that they have seen or read before either from movies or from books. In other words clipping in the starship Enterprise complete with captain Cork and Mr pointy-ears is a no-no. However, stealing details like the transporter or phaser, that's OK since it doesn't add a foreign theme to the mud and can be considered as a detail and not a central part of the story. However... should someone start waving a shiny humming rod around we'll probably have some objections since that is so closely linked to the entire `force' philosophy, something that we wish to avoid as well.
Naturally the border between what's OK and what isn't is a bit fuzzy and in the end it simply has to be up to us to decide what is acceptable and not.
In order for code to be produced in an orderly fashion, some kind of hierarchy has to be imposed. It's impossible to expect a non-organized mob of coders to produce something worthwhile.
The goals with the hierarchy are a bit hard to pin-point, but loosly they can be itemised as follows:
To achieve these ends, we have come up with the following hierarchy with names borrowed from an ancient civilisation:
Most of these positions are mutually exclusive, however, some are not. Any Patriciae or higher can also be a Questor in one or more capacities. Any Senator can also be a Tribunus. An Emissarius may be given Patricius privileges and hence also Questor status if desirable.
Work within the domain is divided into departments, as could be seen from the previous hierarchical list. A deparment corresponds to the Genesis domain concept, but the name has been changed to further reduce the visualisation of a geographically boundered area. Most commonly it does have geographical boundaries of some kind, but also might contain a lot more or something non-physical entirely.
The department is usually easily dividable into smaller projects. As the department grows, more and more projects are added to it. A project can be a smaller area, a guild or just some kind of common feature used throughout the department. The Tribunus appoints a project leader, Praefectus, to head the project. He in turn recruites other coders to work within that project. A coder can be active in several projects spread out over several domains, though it's preferrable if a certain modicum of concentration of efforts is maintained. Spreading out too thin seldom works well in the long run.
New departments are usually not founded from scratch, they are made by fission of already existing departments.
The work of a Praefectus within a department is semi-independant of the other projects. The Tribunus makes sure progress in coordinated within the master plan for the department, but the Praefectus is only responsible for his project.
The code is produced, without exceoptions, in a special development directories. On completion it is quality checked by the Tribunus before being opened for use by players. If the Tribunus has participated in the coding of the project, the DepS must be contacted to provide an independant QC handler for the project; the Tribunus may not QC his own code.
Once code is opened for the use of players, only changes that does not affect balance may be done on it, such as minor additions of locations, changes in descriptions and suchlike. If balance-affecting factors are to be changed, the code must be copied to a development directory, worked upon and then re-QC'd before it can be allowed to replace the original code.
Departments which become very big and hence hard to manage are encouraged to split into two or more parts so that congestion in the development process is avoided.
It's important that the technology level isn't too far advanced; if it gets too far the game will suffer and become boring. If you extrapolate the industrial development of the past hundred years five hundred years in the future, you'll end up in a society where physical interaction is a mere unpleasant part of your ancestry. However... that's rather boring from a a game point of view. It's also very hard to envision a future that's too far removed, both socially and technologically.
In fact, what we need is a setting that a lot resembles the one in Frank Herbert's Dune-series. An advanced technology that is hampered by religious beliefs or laws that restrict it. Computers are not allowed to be anything more than simple tools; they may never 'think' for themselves or be allowed to make other machinery work independently of a human operator.
This means that any `virtual reality' shit is totally out of the question and players are forced to play the game for themselves without having machines doing the job for them.
We need an environment that is rather more Space Opera than any other variety of SF so that people can have fun. For those who don't know what Space Opera is, I recommend Edgar Rice Burroughs' `John Carter of Mars' series and (amazingly) Ron Hubbard's `Battlefield Earth'. Sure, you can stick in the Star Wars series as well if you wish, but they have a streak of commercialisation (written by different authors for the same reason [money]) in them with makes them less palatable.
Further on we do need a setting where the human race is spreading across the galaxy so that we have space travel. We need alien races, benign and malign so that the coders won't have too hard a job of inventing nice stories. These races can't be too alien either since it's humans who's supposed to characterise them for the most part ;)
This project will in all likelihood run over a long time. For obvious reasons, or at least reasons that's obvious to anyone who's ever been part of developing a mud, we need to document and discuss every part of the mud before we actually commit it to code.
For that reason this chapter will contain anything that's under discussion but currently not decided on, the mudlib and DGD chapter will contain what's been decided and implemented.
Now... what is it that will make this mudlib different from every other mud around here? Simply the idea of continuity. Almost without exceptions all games today don't care much about their resources, if an object is needed it is created and put in the game regardless of the amount already out there. When a new monster is coded it is equipped and put out there with little regard to the amount of weaponry, armour and money that's already floating around.
This kind of thinking has two consequences over time: Due to the constant high entropy in the game, the purely physical resources such as primary memory soon are all wasted - the game has to be stopped and restarted from scratch again (most games does this several times a day). Secondly the constant influx of new objects with no control of what's already in there leads to a slow but inexorable inflation - things start to cost more as there's more and more money floating around, monsters get harder and harder to beat since the weaponry that's put in slowly is made better and better. Battling this inflation is about as rewarding as trying to keep the tide back - it just gets higher and higher no matter what you do.
Obviously the remedy to this problem is to keep track of anything that can be termed a resource and only allow a controlled amount to be in circulation at any given time. Also, the game-driver needs to be able to save the current state so that it can restart from that state later in case the need for a reboot of the game occurs. Theoretically speaking the game-driver never should have to reboot, but these things happen. This kind of game will be a continuous mud, or resource conservative mud. The DGD happens to meet the demands necessary for running a mud of this kind - it's tight with memory (no leakage) and it can save and restore states.
A truly continuous mud has all objects in memory all the time. A new object is created and merged to the list of loaded (if not instantiated) objects at need and is never truly removed until such time that it is permanently discarded.
There's several problems associated with this kind of strategy however. The ordinary sloppy way of handling things, restarting the game often, neatly takes care of inconsistencies by simply forgetting everything and starting over. In a continuous mud these problems remain until they are removed manually, so the underlying system really has to be proof of most common problems. The cause of many of these problems is that you have both a written source code and a compiled object in the game. In an ordinary mud it's perfectly possible to have several versions of the same object loaded with no relation to the actual source code that has been changed over time.
So... How to solve it then? Well, the solution just like the problem must be split into different parts. Let's start with the problem of having the source code synchronised with the objects.
The solution really is very simple. On the disk new code is stored
with the suffix .new. When an object is updated the file
is renamed, removing the suffix, and the permissions is changed so
that it's impossible to edit it from within the game. Thus you can
always rely on the object on disk actually being the one in use,
without wasting a lot of disk-space.
The only flaw here is .h-files, or any file that's being included
in fact. However, solving this is very very tricky. A system of
dependencies which keeps track of which files includes which would have
to be set up somehow. This is fairly easy to solve, but it takes a lot
of time when you actually want to run a check on it. No, in this case
we'll have to depend on the wizards to update their objects when
necessary.
The problem here is how to update all instances of a particular object at the same time, and how to know when to update a child object when one of its ancestors are updated.
This, unfortunately isn't possible with any kind of demands on
performance of the game. The DGD contains a special
upgrade_object() kfun which makes it possible to upgrade the code
segment of an object within a certain amount of limitations, without
disturbing the object pointer. This function thus makes it possible to
invisibly upgrade any object in the game, as long as the changes hasn't
been too profound.
This all sounds very good, except that upgrade_object() is
very costly. It's not something you can run any time you wish
since the game might halt for an hour or longer if the upgrade is done
on a widely used object. Obviously, this is something that has to be
reserved for special maintenance.
An alternate solution would be to forego direct inheritance and instead use the MOO solution with indirect references, i.e. cloned 'parent' objects which you access through external calls. However, this solution is both slow (you add an extra level of indirection both for variables and functions) as well as that it robs us of several of the great features in LPC, namely inherited prototypes and type-checking.
On the whole, that solution isn't very attractive. Instead, we're going to use this model:
Code is written using direct inheritance, just as usual. A coder can submit objects he wishes to have upgraded to a central service. When regular maintenance is done (once every other day or so) his object will be processed along with any other upgrades that need to be done. Most of the time, however, he will make out perfectly well with the ordinary kind of updates.
We do wish, however, to make sure that there aren't several versions of the same object in the game. So, the resource manager (described later) will be taken into use here. When an object is updated, the coder can require all clones either to be replaced, or simply destroyed. There's no alternatives really. A problem is objects that inherit an object that has been changed. It's fairly simple to build lists of which object inherits which through the special driver object, however, these lists will rather long. We'll have to think about whether it really is worth to have them. If we do decide to do it that way, updates would either replace or destroy the children of updated objects as well.
It will be the responsibility of the coder to make sure that any object lists in his code that might contain objects that are replaced are updated properly. Possibly as special call to the environment and any objects held in the inventory can be introduced to facilitate this.
A list of resources must be set up. Anything that reasonably can be measured must be put on that list.
A central service will take care of the accounting for resources. Through the auto object it will be called automatically when an kfuns are used that affect measurable resources. Special mudlib code will interact with it in order to keep tabs on other kinds of resources.
Resource control and the concept of game balance are as closely linked as almost being synonyms. The resource control of SO2403 is intended to be dynamic and self-adjusting so that it more or less manages itself with as little external manipulation as possible.
First lets define what a resource is. We distinguish between two basic types of resources: immediate and temporalized. The immediate type of resource can be recycled and put back in the system the very second it's been used up. The temporalized resource on the other hand must be metered out at a fixed rate.
In order to handle balance in the game, the amount of resources for most part must depend on the amount of active players. For this reason the resource handler must have access to information on the current load on the system. The resource handler should do updates every hour and then us a time-integrated value to determine how much of a particular resource should be in the game at the time. This goes for both immediate and temporalized resources. Hence it's natural for the temporalized resources to be replenished hourly as well.
If the resource manager decides that an immediate resource should be decreased but the actual number of already allocated resources of that type exceeds the maximum, the handler should only make note of the new maximum and leave it at that. When the resource later is used in the game and returned to the system, it simply won't be returned to the domain resource pool.
To make this kind of balance mechanism work, objects which currently aren't in use in the game must be discounted from the allocation scheme. With this we mean the objects that are held by players who are logged out at the moment. When they log in, their objects are re-evaluated and their resource requirements subtracted from the domain pool. In this particular case both types of resources may end up in the red. When they log out, the resources are returned to the pool.
Supportive code must exist in the standard objects for easy determination of resource requirements. It must be easy to define an object and simply ask how much it consumes in the way of resources. The result can then easily be used to determine if it's possible to create it, or a bundle of different objects by just summing up their individual needs.
Methods must exist that return allocated temporalized resources which aren't used up the intended way, for example if an object which is worth money is destroyed instead of sold.
Obviously there's room for resource seepage here, in the form of objects which allocates resources and the bugs out before they can return them etc. At the regular maintenance time it's hence necessary to perform a resource synchronisation that goes through all objects in the domains and re-evaluates their resource consumption. Thus the figures for resource usage might not be exactly correct all the time, but correct enough to work.
These resources must be handled a bit differently from the immediate. They should be allocated when first requested, but not eligible for replenishment until actually consumed and thus released. For example if a bottle of medicine is sold the amount of healing it contains is allocated with the server. However, it's not until the medicine actually is consumed and the healing applied that the domain may have the resource replenished.
All standard objects should be of the type virtual classes, i.e. they should have to be inherited in order to be instanced, not simply cloned as they are.
Base class objects should be split into as unique objects as possible so that you can inherit the ones you need without having to include the entire bunch all the time.
These classes are intended to be very general. Any kind of object that has need for the kind of functionality they implement should inherit them. There might even be tests in them so that it's required that they are used and not inventions of the coders themselves. This both to discourage useless duplication of code, and to ensure a homogeneous functionality throughout the game code.
The DGD has absolutely no idea about commands so we'll have to solve all of that ourselves. Any object that wishes either to use, or to define commands should inherit this module.
Objects should be able to define three kinds of commands:
When an object containing this module is moved to a new environment, this module will broadcast its set of commands. The same happens if something is introduced to its inventory. When it moves, it will remove all commands belonging to objects in the environment, when an object is moved from its inventory, it removes all commands from that object.
This modules should be used for any object that can protect against damage and any object that can be damaged in any way.
This module would describe the object inheriting it. Four kinds of descriptions for normal use would be needed:
Apart from these, a description based on dimensions will be generated automatically for dark conditions.
This module will also handle the following properties:
Another very important concept is that of conjunctivity. Objects must be able to exist in conjunction to each other, without necessarily being in each other's inventories. A typical example is that of the bottle and the cork. Neither is in the environment of the other, yet they are handled as one and any description of them would be given as one, not two separate. This module also must handle this with particular attention to rooms, rooms can be conjugated and hence form room complexes with several possible positions, still handled visibly as one.
This module handles dimensions of objects. This should be done a bit more extensively than usually so that good dimensional control could be possible.
The module also should be able to determine if one objects fits inside another or not through internal methods.
Functions that one wants a coder to override or modify the functionality of must be fitted with hooks. This module provides the basic functionality which is needed for implementing such hooks. It handles multiple object overloading and resolution of execution results.
This module handles global identity, making it possible for other objects to identify it uniquely.
Obviously this module also has to interact somehow with the description module above. Perhaps they even should be integrated to one, making identity and description inseparable.
The following parameters should be handled:
Any object that could be used as a weapon should inherit this module.
The module should define the following properties:
This module defines movement routines for objects. Any object that wishes to have any kind of positional relation to another object in the game must inherit this module.
The game defines a three-dimensional grid where all objects have a position. This module takes care of distance computations and translations in the grid.
All objects have properties they want publicly available for all other objects. These properties controls the functionality of the object and the way other objects interact with it in various ways. This module handles such properties and also provides functionality for type-checking on the property contents.
No game system yet to be devised has escaped magic of some kind. Psi points as they are called here could just as well have been called `mana' or something like that.
This module handles Psi interaction of any kind, as implemented by the coders of the world. It basically contains methods for comparing Psi values and compute results.
This basically is the interface to the resource manager. It will help the coder of the object to specify resource requirements and determine if the necessary resources are available.
This module handles time management in the game. It provides a universal clock and translation tables for special time within an area. It also allows the handling of schedules for campaigns of various kinds.
Any object with a defined mercantile value will have to inherit this module. This includes actual money as well. The module will contain method for value translations and exchange.
This module defines container object classes, used with containers of any kind, rooms, backpacks etc.
This module will enable objects to define ways of entering and leaving other objects. It will compute and handle costs for moving as well as provide hooks for transition control.
This module defines an inventory in an object and provides routines for determining order and access control.
This module defines living object properties, used with any type of living object in the game, mobile as well as static.
Inherits the communication and position module.
Any living object capable of independent action must inherit this module. It will provide an easy programmable interface for inherent command execution where conditional events can be detected and acted on, such as combat, speech, reception of items etc.
Any object who wants to be able to to receive and transmit messages should inherit this module. It will be the interface for all kinds of communication channels in the game.
Inherits the defence and offence modules.
This module will be used by any living object to define how it is put together.
This module will implement skill handling of all kinds. Not only which skills the object is capable of, but also task determination and difficulty assessment.
The following skills are defined, skills marked with (*) will need special mudlib support and will be part of the general mudlib.
General skills:
Psi skills:
Combat skills:
Secret agent skills:
Spaceship handling skills:
Inherits the morphology module.
This module defines all vital statistics for living objects.
The statistics that are managed are the following:
The module also handles combat since this is so closely linked to the vital statistics. It's impossible to do one without the other.
These modules are used to build the following standard base objects, basically only for the coder's convenience, they can put together the same kind of objects themselves if they want from the base components:
Standard armour base.
Standard door base.
Standard room base.
Standard money base.
Standard NPC base.
Standard object base.
Standard player base.
Standard transport base.
Standard weapon base.
This chapter is empty right now, but will later contain the documentation for the implemented game-driver. The non-implemented information resides in the development chapter.
This chapter is empty right now, but will later contain the documentation for the implemented mudlib. The non-implemented information resides in the development chapter.