August 20, 2015 at 16:28Chapter 1. "What are Virtual Worlds and how they arose." Translation of Richard Bartle's book Designing Virtual Worlds
I invite everyone to join the translation of the book. Thank you Lilia Kutueva for translating the first chapter.
Start here .
Despite the fact that there may be (and there are) more fundamental definitions of this concept, nevertheless, Virtual Worlds (VMs) always adhere to certain conditions that distinguish them from other related virtual spaces. The most basic will be the following:
Game chat is not a VM, because it does not have the specified physical parameters. Wargame strategy does not project a player onto the character he is playing. Email play does not occur in real time. A single player game is not multiplayer. The world of first-person shooter is unstable.
In some examples, the arguments are not so straightforward. For example, are desktop RI virtual worlds? No, because they are not automated, but not far from that. Can an educational MPM of two players be called virtual? Maybe. Will there be such a world of a game for 500 players, a world so large that some players may never meet each other? Yes, but this is a moot point.
In fact, to determine whether the world is virtual or not is quite easy - just check its origin. If its device is largely decommissioned from the device of the existing VM, it is almost certainly a VM; if not, then it is almost certainly not him.
Virtual worlds are often called MPMs (MUDs), because the first VM that was successful was called MPMs. Although earlier worlds were textual and could be defined as VMs, nonetheless, their seeds fell on barren soil. MPMs, in contrast, evolved to spawn their seed.
The first MPM was developed in the MACRO-10 assembler program on a DecSystem-10 computer in the fall of 1978 at the University of Essex, England. Roy Trabshaw, a talented graduate of the Faculty of Computational Sciences, became its author. The first version was just a test program designed to find out the basic principles on which a multi-user world can be built. When she earned, Roy immediately took up version II, which became a text VM. And to this day, this program remains a model of VM. The second version was also created in the MACRO-10 assembler, but such a solution led to the fact that as new characteristics arose, the program became more cumbersome. Therefore, in the fall of 1979, Roy decided to start work on the third version of the game, which this time he divided into two parts. The game engine was written in BCPL (the predecessor of the C language). And the game world itself was written in the language of his own invention - MUDDL (language of definitions of a multi-player strategy). The idea was that multi-user worlds could be created in the MUDDL language, but they would work on one constant engine (which was actually an interpreter program).
By April 1980, Roy already had a basic work program, but that was only a small part of what he intended to do. That year was graduation, and he realized that he did not have enough time to complete the project. Someone else was needed.
From the very beginning, Roy has always been open to the suggestions of his friends on how to expand and improve the MMP. Many of these ideas came from fellow students Richard Bartle (that is, me) and Nigel Roberts. Unlike Nigel, I was younger than Roy and I didn’t have to graduate next year (in fact, I had to stay there until 1989, first as a graduate student, and then as a lecturer). Fortunately, among other things, I was also a first-class programmer and had serious experience in game modeling. So Roy shifted the creation of the MPM (MUD) to my shoulders, and I subsequently wrote the rest of the engine and almost the whole world, so that in the end what turned out to be the paradigm of the whole genre. To this, to your relief, dear readers, I stop bragging and continue.
Roy had two reasons to come up with MUD. First of all, he really liked single-player story games, such as ADVENT Crowther and Woods, ZORK Anderson, Blanck, Daniels and Lebling, HAUNT Laird, and he decided to create a multiplayer game of their type. Secondly, he was seriously engaged in writing programs - parsers and interpreters. And he combined these two programs into one when he discovered a way to share recording areas of the DEC-10 memory and thought about the possibilities of their application.
In the abbreviation MUD, “D” means “Dungeon” (English - “tower, dungeon, dungeon”). Contrary to popular belief, this term has nothing to do with the role-playing game D&D, and does not mean that the game world must have a DnD setting2. On the contrary, the word “Dungeon” appeared in the abbreviation due to the fact that the version of ZORK played by Roy was programmed in Fortran and was called DUNGEN3. Roy wanted to create something similar to the multiplayer DUNGE (o) N, and it immediately occurred to him to name the game MUD (MPM).
2 But this does not mean that it may not be.
3 The DEC-10 used six-digit file names in capital letters. Therefore, old admins like me call Dungeon - DUNGEN, and Adventure - ADVENT.
Essex University is just a 45-minute walk along a country road from the British Telecom main research center (there used to be a post office) in Martelsham Heaf, near Ipswich. This circumstance led to the fact that the university was elected to test a new, experimental electronic packet data switching system, for short - EPSS (electronic packet-switching service). Among other things, using EPSS, it was possible to exchange data with the ARPA (Advanced Research Project Agency) network located in the United States. Thus, Roy managed to talk about MUD to his American colleagues and some of them even came to England to try out4 this program. As for the ARPA network, over time it has become what we call the Internet today.
4 This fact put an end to more than one fictitious patent application.
However, during its formative years, MUD (MPM) continued to be a phenomenon mainly of the University of Essex, existing mainly due to the generosity of the Computer Services team and their manager, Charles Bowman. Between complaints of wasted money spent on them, members of the University Computer Society were allowed to spend their free time from scientific research doing whatever they wanted. Many chose to play in the MMM (MUD).
However, some were inspired by the idea to write their games in the MUDDL language using the MUD engine, and quite a few of them appeared. The most prominent games were ROCK (based on the Freggle Rock puppet television show), MIST (original and masterful); BLUD (original and bloody); and UNI (Faculty of Computer Science in the Virtual World of Might and Magic).
In addition to EPSS connections, the University of Essex also had several dial-up modems. The MUD news reached the ears of a small community of BBS (bulletin board system - electronic bulletin board) users from the United Kingdom, and they got permission to play MUD through a direct connection. At times, they flirted to such an extent that any normal person at that time would already have seen the tenth dream. And the demand for the game was so great that those who wished to play had to unite and buy money to the university to buy more modems for the university to cope with such a load!
The network coverage was increasing and gradually all the universities in the United Kingdom united into a system called JANet (Joint Academic Network). EPSS from an experimental connection became publicly available PSS (packet switch service - a packet-switched data transfer system), enabling people who had access to PSS accounts either at work or simply had sufficient money to connect to the university’s computer systems in increasing numbers . In 1984-85 articles about MUD appeared in almost all specialized magazines about computer games throughout the UK. The process has begun.
Unfortunately, the MUD engine also had its limitations. He could support no more than 36 players at a time5. With a large number of players, one more game should be chosen, which would replace the first. In addition, the engine could only work on the DEC-10 processor. And although copies of the program were sent to other educational institutions in the United Kingdom, Sweden, and Norway, however, only two of them could provide external access - the technical college in Dundee and the University of Oslo.
5 DEC-10 supported 36-bit encryption of the game world. Roy prescribed 1 bit per player for internal linking.
At the same time, as Roy was developing the second version of MUD, another student at the University of Essex, Stephen Murrell, wrote his own VM from scratch, using a different way of communication between the players - using designated devices. His game, PIGG, was also written on MACRO-10 and over time faced the same operational issues as MUD. Nevertheless, a precedent arose and many external MUD users who were disappointed in it, or, conversely, inspired by it, got the idea to write their own games.
And the first such VMs were the Shades of Neil Newell, Gods Ben Laurie, and AMP6. Behind them appeared the active Mirror World of Pip Cordry and Co. And since all these games came from the MMM (MUD), they began to call them that. True, sometimes they were also called MUG (MPI - multiplayer game).
Now the original MUD has been dubbed MUD1 (although at that time it already existed in the third version) to distinguish it from the rest of the class of MPMs. This was the beginning of the Second Age of VM.
6 Unfortunately, I only once encountered a couple who were behind the creation of AMP, and I can no longer remember their names. I do not think that I was also interested in them, which means a reduction in AMP.
The ability to make money on such games grew, so MUD1 began to function both on CompuServe, the main Internet service of the United States of that time, and on a similar service in the United Kingdom, CompuNet. One of CompuNet's programmers, Alan Lenton, even moved to write his own VM, Federation II, whose difference was that he was the first MPM with a sci-fi setting.
MUD1, Federation II, Shades (in the Prestel Micronet teletext system) and Gods (in German translation) continued to gain commercial success. Other MPMs written by Big Four players have been successful in the United Kingdom. That was a time of great research, both in the field of creating game worlds, and in the field of engine development. Moreover, the main work in this direction was carried out by Mirror World Group on the IOWA system7 (Input / Output World of Adventure - an adventure world as a data exchange system).
7 This research period can be compared with the early stage of creating computer games, although they happened at different times.
Around the same time, the decision came to rewrite MUD1 as MUD2 (in fact, it was already version 4). By that time, the original architecture and the DEC-10 MUD1 platform had proved their limitations, and the MUDDL language (which borrowed a lot from the database definition scheme used by the ADVENT game) was not powerful enough to work with innovative ideas. Therefore, especially for writing MMM, a new language was developed from the very foundations - MUDDLE (Multi-User Dungeon Definition LanguagE - definition language for a multi-user strategy). It turned out to be expressive enough to stand the test of time, and thus the MUD was then completely rewritten for the last time.
In fact, almost all the basic issues of creating virtual worlds were resolved in the first and second eras. For example, by 1987, all protocols and in-game tools for resolving players' problems had already been and were relatively systematized. All this was made possible thanks to the efforts of pioneers such as Mark Longley (MUD1), Michael Laurie (MIST), and Pip Cordy (Mirror World). Unfortunately, this language has not reached us in its original form.
Developers of later games, as a rule, knew what should be, but they did not always have an idea why it should be so and not otherwise. As a result, after several generations, a number of fundamental principles were lost.
Therefore, developers of games that were launched 10 years later had to rediscover everything from their own experience.
Most MMRs written in the Second Age were designed by individual enthusiasts at home8. At the same time (albeit not for long), multi-user text adventure games became a very important part of the computer games market, so there were enough people who understood the basic principles of game design. But since few scientific institutions in the United Kingdom were as liberal with their computer capabilities as the University of Essex, the MPM, written there by loners, managed to achieve only limited recognition.
8 A complete and comprehensive study on this subject can be found here: www.mud.co.uk/richard/imucg.htm
An exception to this rule was AberMUD, so named because it was written at the University of Wales (Aberystwyth). The developer of this game, Alan Cox, wrote it in 1987 in the language “B” (another predecessor of “C”) for the Honeywell L66 computer, under the GCOS3 operating system with TSS multitasking support. A year later, AberMPM was translated into the “C” language, which was a turning point in the history of the VM. Although the game was not particularly advanced technologically or in terms of content (it was focused mainly on battles), it was a great pleasure. Moreover, being rewritten in the “C” language, the game was a huge step forward: now AberMPM worked in the Unix program.
AberMUD has spread to computer science departments like a virus. Its copies appeared on thousands of computers running on Unix. Four versions of AberMUD followed one after another, simultaneously spawning several copycats. The most significant were three: TinyMUD, LPMUD, and DikuMUD.
The game TinyMUD, authored by Jim Asines of Carnegie Mellon University, was released in 1989. Its main predecessors were AberMUD and “Monster” (for VAX series computers with VMS support), released a year earlier. “Monster” (created by Rich Skrent of Northwestern University) is unusual in that this game was written independently of the basic standard MUD1. Her main innovation was the ability to create elements of the virtual world from within himself. However, during the transition from the second version to the third, this ability was removed from MUD1.
Initially, TinyMUD was a stripped down version of “Monster”. It was a virtual world, but essentially non-gaming. Players could create new locations and objects (with limited functionality) almost unhindered. And while MUD1 and AberMUD could only boast of 400-500 autonomous locations, the popular 1990 TinyMUD copy called “Islandia” contained more than 14,000 locations over the course of several months of its existence.
The lack of game action in TinyMUD meant that the players were mainly engaged in creating different objects and talking about what was created. And although it was not the best predominantly “social” VM (Clive Lindus’s more fascinating world of “Void” 9 went around it for several months), TinyMUD became the VM from which, in fact, all subsequent similar worlds originated. TinyMUD was designed to get away from the hack-and-slash style prevailing in AberMud. In addition, it was believed that the letter “D” in the name means, rather, “dimension” (English “dimension”) or “Domain” (English “domain”), rather than “Dungeon” (English “dungeon, tower” ), which became the main reason for the future difference between MUD and MU * a few years later.
9 Over the years, its name was “Void”, “The Void”, “Vortex”, but the essence remained the same. “Void” by nature is more intended for an adult audience, and the prototype for it was the first such VM - The Zone.
LPMUD was named after its author, Lars Pensjo of the University of Gothenburg, Sweden. Having played both in AberMUD and TinyMUD, he decided to create his own game, which would contain elements of the adventures of the first world and at the same time enhanced user capabilities of the second. While most developers were arrogantly confident that players were unable to create the worlds that they created, Lars was convinced of the opposite - that players could construct virtual worlds better than himself. To this end, he developed an in-game programming language - LPC (Linear Predictive Coding - linear prediction coding), which allowed players with the necessary experience to add not only individual objects, but also powerful functionality of the game itself.
This was an important achievement that introduced many people to the world of programming, in contrast to traditional academic courses that simply blew up the brain. The LPC language has been designed so carefully that it is still used today.
DikuMUD was designed at the Department of Computer Science, University of Copenhagen, Denmark, and was released in 1990. A group of friends became its authors: Katya Nieboe, Tom Madsen, Hans Henrik Sterfeldt, Michael Seifert and Sebastian Hammer. This VM was only conceived as an improved version of AberMUD, and it had nothing to do with either TinyMud or LPMUD. And while the last two games in their development came to the possibility of allowing operational changes to be made in VMs, the DikuMUD developers went the exact opposite way and hard-coded everything that was possible.
Nevertheless, they turned out to be very good programmers: DikuMUD was already launched “prepared” and was well organized inside. An experienced C programmer could easily rewrite the original DikuMud code and create his own new world, or replace the existing databases and create as if a different world. Many did so.
As a result, several core codebases (excluding the MUD software package) were created based on the original DikuMUD sample. Among them, the first MPMs were Circle, Silly and Merc. Merc, among other things, spawned ROM (Rivers of MUD) and Envy, which, in turn, had their own offspring. All of these have arisen - and continue to arise - a dizzying number of subversions.
LPMUD, unlike them, did not contribute to the emergence of so many descendants, because the LPC language was universal enough to allow people to write their own games, without forcing them to rewrite the game engine. And although many LPMUDs are oriented to combat, strictly speaking, they are not required to be such (unlike DikuMUDs) 10.
10 To understand the difference between LPMUDs and DikuMUDs, search the Internet for a book by Ron Shaw and James Romin, “Playing MUDs,” N.J., Wiley, 1995.
The TinyMUD family tree is perhaps one of the most interesting of the three main branches of AberMUD. TinyMUD itself was nothing more than a prototype. Copies of this game used to appear on some forgotten Unix-based computers, enjoy a short but brilliant life for a few short months, and then disappear, leaving behind a feeling of annoyance, indifference and packages clogged with disks to the top.
The same players who have not yet developed a persistent aversion to virtual worlds, switched11 to the next offspring of TinyMUD and the cycle was repeated, in the style of slash-and-burn agriculture.
11 That is, those who had access to the Internet could do so. At that time, he was far from everywhere, and not every player could find a new refuge when the local TinyMUD collapsed.
The problem was that the players could not do anything in TinyMUDs except to invite each other to admire their latest masterpiece, which could not be called anything other than “wallpaper”. In 1990, one of the players, Stephen White, decided to expand the functionality of TinyMUD and created the world of TinyMUCK (“muck” as a kind of “mud”) (perhaps a play on words: mud - “mud”, muck - “dung”). Using it as a template, he developed MOO (Object Oriented MMM (MUD)). MOO used a fully functional scripting language (as such in-game programming languages are called12 programming languages). Thus, the capabilities of the LPC language were introduced into socially oriented VMs. MOO became the basis for two important offspring: LambdaMOO Pavel Curtis (loved by journalists, researchers and losers), and, after CoolMUD,
12 As will be seen later, some other programming languages are also called.
MOO heirs have found a niche in the field of education, due to ease of use; in addition, object-oriented MPMs (like LPMUDs) have the opportunity to demonstrate programming principles to beginners without scaring them to death. However, MOOMUD was not the only family of codebases that came out of TinyMUCK.
Later, in the same 1990, Larry Ford released TinyMUSH. The word MUSH at first did not mean anything, but later the abbreviation was adjusted to the definition of Multi-User Shared Hallucination (massive multi-user hallucination). The TinyMUSH code base introduced a number of enhancements, such as a plot engine and software robots (known as "mobs") - all of which together contributed to role-playing action. Accordingly, many descendants of TinyMUSH (known as MUSHs) are essentially role-playing games: what you do determines who you are, and not vice versa.
From an unhistorical point of view, the hallmark of MOO, MUSH and other TinyMUCK offspring (the so-called MUCKs) is the absence of program-controlled monsters in them, which players must track down and, according to the laws of these virtual worlds, kill. Those who play VMs of this class are likely to use the term MU *, leaving the abbreviation MUD to refer to those games where there are computer-controlled monsters that players must seek out and kill13.
13 In this regard, MUDs are often dismissed as lower game forms. MUD players, in turn, pay reciprocity, calling the MU * players a “karebir” team (carebear is a player who tries to avoid conflicts at all costs, a pacifist).
Thus, the third era of the virtual worlds has become a period of powerful development. More people than ever tried to create their VMs. Indeed, studies of NSFnet network traffic in 1993 showed that over 10% of the bits belonged to MUDs; in other words, even before the advent of the World Wide Web (WWW), MUDs occupied about 10% of Internet traffic!
However, there were less pleasant consequences. If before, someone who wanted to start his VM had to write it from scratch, now the sudden influx of ready-made code bases meant that this was no longer a problem. Want to start your VM - just download one of the existing ones, and voila! - the new VM is ready! And, although theoretically, developers could change any properties in a bootable VM (especially LPMUD and TinyMUD), in fact, many simply added additional characteristics to what was already there. And this means that two worlds using the same code base will have similar geography and physics, but with many variations. And let some “old men” complain that this leads to monotony and, thus, stifles creativity - this is not the main problem. Perhaps the difficulty is that if the designer does not understand, why does the passage with which he works does what he does (and does not do what he does not), how can he be sure that the changes he makes will only be for the better? And for that matter, how can he be sure that the sample with which he started does not contain flaws?
Even considering only graduate students and amateur enthusiasts, we can say that the third era still has a strong influence on us. There are several thousand LPMUDs, DikuMUDs, MOO, MUSHs, and MUCKs, and the number of people playing some of them is simply impressive. However, the torch of innovation was soon picked up by another carrier - business.
Start here .
Despite the fact that there may be (and there are) more fundamental definitions of this concept, nevertheless, Virtual Worlds (VMs) always adhere to certain conditions that distinguish them from other related virtual spaces. The most basic will be the following:- VMs are based on basic automated rules that encourage players to make changes in it (however, they cannot change the rules themselves that give them such an opportunity). These are the physical foundations of VM.
- Players play their characters "inside" the world. They may have partial or full influence on an army, team or group of people, but in this world there is only one game entity with which they are represented and with which they are firmly connected - this is their character. Therefore, all interactions with the world and other players are mediated by this character.
- Interaction with the world is carried out in real time. Accordingly, when you do something in it, you can expect an immediate response.
- This world is multi-user.
- This world is stable (at least to some extent).
Game chat is not a VM, because it does not have the specified physical parameters. Wargame strategy does not project a player onto the character he is playing. Email play does not occur in real time. A single player game is not multiplayer. The world of first-person shooter is unstable.
In some examples, the arguments are not so straightforward. For example, are desktop RI virtual worlds? No, because they are not automated, but not far from that. Can an educational MPM of two players be called virtual? Maybe. Will there be such a world of a game for 500 players, a world so large that some players may never meet each other? Yes, but this is a moot point.
In fact, to determine whether the world is virtual or not is quite easy - just check its origin. If its device is largely decommissioned from the device of the existing VM, it is almost certainly a VM; if not, then it is almost certainly not him.
The first era - 1978-1985
Virtual worlds are often called MPMs (MUDs), because the first VM that was successful was called MPMs. Although earlier worlds were textual and could be defined as VMs, nonetheless, their seeds fell on barren soil. MPMs, in contrast, evolved to spawn their seed.
The first MPM was developed in the MACRO-10 assembler program on a DecSystem-10 computer in the fall of 1978 at the University of Essex, England. Roy Trabshaw, a talented graduate of the Faculty of Computational Sciences, became its author. The first version was just a test program designed to find out the basic principles on which a multi-user world can be built. When she earned, Roy immediately took up version II, which became a text VM. And to this day, this program remains a model of VM. The second version was also created in the MACRO-10 assembler, but such a solution led to the fact that as new characteristics arose, the program became more cumbersome. Therefore, in the fall of 1979, Roy decided to start work on the third version of the game, which this time he divided into two parts. The game engine was written in BCPL (the predecessor of the C language). And the game world itself was written in the language of his own invention - MUDDL (language of definitions of a multi-player strategy). The idea was that multi-user worlds could be created in the MUDDL language, but they would work on one constant engine (which was actually an interpreter program).
By April 1980, Roy already had a basic work program, but that was only a small part of what he intended to do. That year was graduation, and he realized that he did not have enough time to complete the project. Someone else was needed.
From the very beginning, Roy has always been open to the suggestions of his friends on how to expand and improve the MMP. Many of these ideas came from fellow students Richard Bartle (that is, me) and Nigel Roberts. Unlike Nigel, I was younger than Roy and I didn’t have to graduate next year (in fact, I had to stay there until 1989, first as a graduate student, and then as a lecturer). Fortunately, among other things, I was also a first-class programmer and had serious experience in game modeling. So Roy shifted the creation of the MPM (MUD) to my shoulders, and I subsequently wrote the rest of the engine and almost the whole world, so that in the end what turned out to be the paradigm of the whole genre. To this, to your relief, dear readers, I stop bragging and continue.
Roy had two reasons to come up with MUD. First of all, he really liked single-player story games, such as ADVENT Crowther and Woods, ZORK Anderson, Blanck, Daniels and Lebling, HAUNT Laird, and he decided to create a multiplayer game of their type. Secondly, he was seriously engaged in writing programs - parsers and interpreters. And he combined these two programs into one when he discovered a way to share recording areas of the DEC-10 memory and thought about the possibilities of their application.
In the abbreviation MUD, “D” means “Dungeon” (English - “tower, dungeon, dungeon”). Contrary to popular belief, this term has nothing to do with the role-playing game D&D, and does not mean that the game world must have a DnD setting2. On the contrary, the word “Dungeon” appeared in the abbreviation due to the fact that the version of ZORK played by Roy was programmed in Fortran and was called DUNGEN3. Roy wanted to create something similar to the multiplayer DUNGE (o) N, and it immediately occurred to him to name the game MUD (MPM).
2 But this does not mean that it may not be.
3 The DEC-10 used six-digit file names in capital letters. Therefore, old admins like me call Dungeon - DUNGEN, and Adventure - ADVENT.
Essex University is just a 45-minute walk along a country road from the British Telecom main research center (there used to be a post office) in Martelsham Heaf, near Ipswich. This circumstance led to the fact that the university was elected to test a new, experimental electronic packet data switching system, for short - EPSS (electronic packet-switching service). Among other things, using EPSS, it was possible to exchange data with the ARPA (Advanced Research Project Agency) network located in the United States. Thus, Roy managed to talk about MUD to his American colleagues and some of them even came to England to try out4 this program. As for the ARPA network, over time it has become what we call the Internet today.
4 This fact put an end to more than one fictitious patent application.
However, during its formative years, MUD (MPM) continued to be a phenomenon mainly of the University of Essex, existing mainly due to the generosity of the Computer Services team and their manager, Charles Bowman. Between complaints of wasted money spent on them, members of the University Computer Society were allowed to spend their free time from scientific research doing whatever they wanted. Many chose to play in the MMM (MUD).
However, some were inspired by the idea to write their games in the MUDDL language using the MUD engine, and quite a few of them appeared. The most prominent games were ROCK (based on the Freggle Rock puppet television show), MIST (original and masterful); BLUD (original and bloody); and UNI (Faculty of Computer Science in the Virtual World of Might and Magic).
In addition to EPSS connections, the University of Essex also had several dial-up modems. The MUD news reached the ears of a small community of BBS (bulletin board system - electronic bulletin board) users from the United Kingdom, and they got permission to play MUD through a direct connection. At times, they flirted to such an extent that any normal person at that time would already have seen the tenth dream. And the demand for the game was so great that those who wished to play had to unite and buy money to the university to buy more modems for the university to cope with such a load!
The network coverage was increasing and gradually all the universities in the United Kingdom united into a system called JANet (Joint Academic Network). EPSS from an experimental connection became publicly available PSS (packet switch service - a packet-switched data transfer system), enabling people who had access to PSS accounts either at work or simply had sufficient money to connect to the university’s computer systems in increasing numbers . In 1984-85 articles about MUD appeared in almost all specialized magazines about computer games throughout the UK. The process has begun.
Unfortunately, the MUD engine also had its limitations. He could support no more than 36 players at a time5. With a large number of players, one more game should be chosen, which would replace the first. In addition, the engine could only work on the DEC-10 processor. And although copies of the program were sent to other educational institutions in the United Kingdom, Sweden, and Norway, however, only two of them could provide external access - the technical college in Dundee and the University of Oslo.
5 DEC-10 supported 36-bit encryption of the game world. Roy prescribed 1 bit per player for internal linking.
At the same time, as Roy was developing the second version of MUD, another student at the University of Essex, Stephen Murrell, wrote his own VM from scratch, using a different way of communication between the players - using designated devices. His game, PIGG, was also written on MACRO-10 and over time faced the same operational issues as MUD. Nevertheless, a precedent arose and many external MUD users who were disappointed in it, or, conversely, inspired by it, got the idea to write their own games.
II Second Age (1985-1989)
And the first such VMs were the Shades of Neil Newell, Gods Ben Laurie, and AMP6. Behind them appeared the active Mirror World of Pip Cordry and Co. And since all these games came from the MMM (MUD), they began to call them that. True, sometimes they were also called MUG (MPI - multiplayer game).
Now the original MUD has been dubbed MUD1 (although at that time it already existed in the third version) to distinguish it from the rest of the class of MPMs. This was the beginning of the Second Age of VM.
6 Unfortunately, I only once encountered a couple who were behind the creation of AMP, and I can no longer remember their names. I do not think that I was also interested in them, which means a reduction in AMP.
The ability to make money on such games grew, so MUD1 began to function both on CompuServe, the main Internet service of the United States of that time, and on a similar service in the United Kingdom, CompuNet. One of CompuNet's programmers, Alan Lenton, even moved to write his own VM, Federation II, whose difference was that he was the first MPM with a sci-fi setting.
MUD1, Federation II, Shades (in the Prestel Micronet teletext system) and Gods (in German translation) continued to gain commercial success. Other MPMs written by Big Four players have been successful in the United Kingdom. That was a time of great research, both in the field of creating game worlds, and in the field of engine development. Moreover, the main work in this direction was carried out by Mirror World Group on the IOWA system7 (Input / Output World of Adventure - an adventure world as a data exchange system).
7 This research period can be compared with the early stage of creating computer games, although they happened at different times.
Around the same time, the decision came to rewrite MUD1 as MUD2 (in fact, it was already version 4). By that time, the original architecture and the DEC-10 MUD1 platform had proved their limitations, and the MUDDL language (which borrowed a lot from the database definition scheme used by the ADVENT game) was not powerful enough to work with innovative ideas. Therefore, especially for writing MMM, a new language was developed from the very foundations - MUDDLE (Multi-User Dungeon Definition LanguagE - definition language for a multi-user strategy). It turned out to be expressive enough to stand the test of time, and thus the MUD was then completely rewritten for the last time.
In fact, almost all the basic issues of creating virtual worlds were resolved in the first and second eras. For example, by 1987, all protocols and in-game tools for resolving players' problems had already been and were relatively systematized. All this was made possible thanks to the efforts of pioneers such as Mark Longley (MUD1), Michael Laurie (MIST), and Pip Cordy (Mirror World). Unfortunately, this language has not reached us in its original form.
Developers of later games, as a rule, knew what should be, but they did not always have an idea why it should be so and not otherwise. As a result, after several generations, a number of fundamental principles were lost.
Therefore, developers of games that were launched 10 years later had to rediscover everything from their own experience.
Most MMRs written in the Second Age were designed by individual enthusiasts at home8. At the same time (albeit not for long), multi-user text adventure games became a very important part of the computer games market, so there were enough people who understood the basic principles of game design. But since few scientific institutions in the United Kingdom were as liberal with their computer capabilities as the University of Essex, the MPM, written there by loners, managed to achieve only limited recognition.
8 A complete and comprehensive study on this subject can be found here: www.mud.co.uk/richard/imucg.htm
An exception to this rule was AberMUD, so named because it was written at the University of Wales (Aberystwyth). The developer of this game, Alan Cox, wrote it in 1987 in the language “B” (another predecessor of “C”) for the Honeywell L66 computer, under the GCOS3 operating system with TSS multitasking support. A year later, AberMPM was translated into the “C” language, which was a turning point in the history of the VM. Although the game was not particularly advanced technologically or in terms of content (it was focused mainly on battles), it was a great pleasure. Moreover, being rewritten in the “C” language, the game was a huge step forward: now AberMPM worked in the Unix program.
Third Age: 1989-1995
AberMUD has spread to computer science departments like a virus. Its copies appeared on thousands of computers running on Unix. Four versions of AberMUD followed one after another, simultaneously spawning several copycats. The most significant were three: TinyMUD, LPMUD, and DikuMUD.
The game TinyMUD, authored by Jim Asines of Carnegie Mellon University, was released in 1989. Its main predecessors were AberMUD and “Monster” (for VAX series computers with VMS support), released a year earlier. “Monster” (created by Rich Skrent of Northwestern University) is unusual in that this game was written independently of the basic standard MUD1. Her main innovation was the ability to create elements of the virtual world from within himself. However, during the transition from the second version to the third, this ability was removed from MUD1.
Initially, TinyMUD was a stripped down version of “Monster”. It was a virtual world, but essentially non-gaming. Players could create new locations and objects (with limited functionality) almost unhindered. And while MUD1 and AberMUD could only boast of 400-500 autonomous locations, the popular 1990 TinyMUD copy called “Islandia” contained more than 14,000 locations over the course of several months of its existence.
The lack of game action in TinyMUD meant that the players were mainly engaged in creating different objects and talking about what was created. And although it was not the best predominantly “social” VM (Clive Lindus’s more fascinating world of “Void” 9 went around it for several months), TinyMUD became the VM from which, in fact, all subsequent similar worlds originated. TinyMUD was designed to get away from the hack-and-slash style prevailing in AberMud. In addition, it was believed that the letter “D” in the name means, rather, “dimension” (English “dimension”) or “Domain” (English “domain”), rather than “Dungeon” (English “dungeon, tower” ), which became the main reason for the future difference between MUD and MU * a few years later.
9 Over the years, its name was “Void”, “The Void”, “Vortex”, but the essence remained the same. “Void” by nature is more intended for an adult audience, and the prototype for it was the first such VM - The Zone.
LPMUD was named after its author, Lars Pensjo of the University of Gothenburg, Sweden. Having played both in AberMUD and TinyMUD, he decided to create his own game, which would contain elements of the adventures of the first world and at the same time enhanced user capabilities of the second. While most developers were arrogantly confident that players were unable to create the worlds that they created, Lars was convinced of the opposite - that players could construct virtual worlds better than himself. To this end, he developed an in-game programming language - LPC (Linear Predictive Coding - linear prediction coding), which allowed players with the necessary experience to add not only individual objects, but also powerful functionality of the game itself.
This was an important achievement that introduced many people to the world of programming, in contrast to traditional academic courses that simply blew up the brain. The LPC language has been designed so carefully that it is still used today.
DikuMUD was designed at the Department of Computer Science, University of Copenhagen, Denmark, and was released in 1990. A group of friends became its authors: Katya Nieboe, Tom Madsen, Hans Henrik Sterfeldt, Michael Seifert and Sebastian Hammer. This VM was only conceived as an improved version of AberMUD, and it had nothing to do with either TinyMud or LPMUD. And while the last two games in their development came to the possibility of allowing operational changes to be made in VMs, the DikuMUD developers went the exact opposite way and hard-coded everything that was possible.
Nevertheless, they turned out to be very good programmers: DikuMUD was already launched “prepared” and was well organized inside. An experienced C programmer could easily rewrite the original DikuMud code and create his own new world, or replace the existing databases and create as if a different world. Many did so.
As a result, several core codebases (excluding the MUD software package) were created based on the original DikuMUD sample. Among them, the first MPMs were Circle, Silly and Merc. Merc, among other things, spawned ROM (Rivers of MUD) and Envy, which, in turn, had their own offspring. All of these have arisen - and continue to arise - a dizzying number of subversions.
LPMUD, unlike them, did not contribute to the emergence of so many descendants, because the LPC language was universal enough to allow people to write their own games, without forcing them to rewrite the game engine. And although many LPMUDs are oriented to combat, strictly speaking, they are not required to be such (unlike DikuMUDs) 10.
10 To understand the difference between LPMUDs and DikuMUDs, search the Internet for a book by Ron Shaw and James Romin, “Playing MUDs,” N.J., Wiley, 1995.
The TinyMUD family tree is perhaps one of the most interesting of the three main branches of AberMUD. TinyMUD itself was nothing more than a prototype. Copies of this game used to appear on some forgotten Unix-based computers, enjoy a short but brilliant life for a few short months, and then disappear, leaving behind a feeling of annoyance, indifference and packages clogged with disks to the top.
The same players who have not yet developed a persistent aversion to virtual worlds, switched11 to the next offspring of TinyMUD and the cycle was repeated, in the style of slash-and-burn agriculture.
11 That is, those who had access to the Internet could do so. At that time, he was far from everywhere, and not every player could find a new refuge when the local TinyMUD collapsed.
The problem was that the players could not do anything in TinyMUDs except to invite each other to admire their latest masterpiece, which could not be called anything other than “wallpaper”. In 1990, one of the players, Stephen White, decided to expand the functionality of TinyMUD and created the world of TinyMUCK (“muck” as a kind of “mud”) (perhaps a play on words: mud - “mud”, muck - “dung”). Using it as a template, he developed MOO (Object Oriented MMM (MUD)). MOO used a fully functional scripting language (as such in-game programming languages are called12 programming languages). Thus, the capabilities of the LPC language were introduced into socially oriented VMs. MOO became the basis for two important offspring: LambdaMOO Pavel Curtis (loved by journalists, researchers and losers), and, after CoolMUD,
12 As will be seen later, some other programming languages are also called.
MOO heirs have found a niche in the field of education, due to ease of use; in addition, object-oriented MPMs (like LPMUDs) have the opportunity to demonstrate programming principles to beginners without scaring them to death. However, MOOMUD was not the only family of codebases that came out of TinyMUCK.
Later, in the same 1990, Larry Ford released TinyMUSH. The word MUSH at first did not mean anything, but later the abbreviation was adjusted to the definition of Multi-User Shared Hallucination (massive multi-user hallucination). The TinyMUSH code base introduced a number of enhancements, such as a plot engine and software robots (known as "mobs") - all of which together contributed to role-playing action. Accordingly, many descendants of TinyMUSH (known as MUSHs) are essentially role-playing games: what you do determines who you are, and not vice versa.
From an unhistorical point of view, the hallmark of MOO, MUSH and other TinyMUCK offspring (the so-called MUCKs) is the absence of program-controlled monsters in them, which players must track down and, according to the laws of these virtual worlds, kill. Those who play VMs of this class are likely to use the term MU *, leaving the abbreviation MUD to refer to those games where there are computer-controlled monsters that players must seek out and kill13.
13 In this regard, MUDs are often dismissed as lower game forms. MUD players, in turn, pay reciprocity, calling the MU * players a “karebir” team (carebear is a player who tries to avoid conflicts at all costs, a pacifist).
Thus, the third era of the virtual worlds has become a period of powerful development. More people than ever tried to create their VMs. Indeed, studies of NSFnet network traffic in 1993 showed that over 10% of the bits belonged to MUDs; in other words, even before the advent of the World Wide Web (WWW), MUDs occupied about 10% of Internet traffic!
However, there were less pleasant consequences. If before, someone who wanted to start his VM had to write it from scratch, now the sudden influx of ready-made code bases meant that this was no longer a problem. Want to start your VM - just download one of the existing ones, and voila! - the new VM is ready! And, although theoretically, developers could change any properties in a bootable VM (especially LPMUD and TinyMUD), in fact, many simply added additional characteristics to what was already there. And this means that two worlds using the same code base will have similar geography and physics, but with many variations. And let some “old men” complain that this leads to monotony and, thus, stifles creativity - this is not the main problem. Perhaps the difficulty is that if the designer does not understand, why does the passage with which he works does what he does (and does not do what he does not), how can he be sure that the changes he makes will only be for the better? And for that matter, how can he be sure that the sample with which he started does not contain flaws?
Even considering only graduate students and amateur enthusiasts, we can say that the third era still has a strong influence on us. There are several thousand LPMUDs, DikuMUDs, MOO, MUSHs, and MUCKs, and the number of people playing some of them is simply impressive. However, the torch of innovation was soon picked up by another carrier - business.
