Handbok för SvenskMUDmagiker
Handbok för SvenskMUDmagiker
Under 1980-talet utvecklades ett internationellt nätverk av datorer i högskolor och universitet och även vissa företag. Det består av snabba unixdatorer och en fundamental byggsten är snabb och direkt överföring av information mellan nästan godtyckligt valda datorer i nätverket.
Ett sådant här nätverk är en perfekt förutsättning för göra datorspel med en fleranvändardimension. I den ursprungliga nätverket är kapaciteten ganska liten så de första spel som uppenbarar sig är textbaserade (1). De ser mycket ut som de adventurespel som förekom under 1970-talet och alla kommandon och beskrivningar ges med enkel text.
Den här typen av spel kallas mud.
Man kan hävda att mud bara är spel men man kan också hävda att de är en ny sorts litteratur där läsarens (eller spelarens) och andra läsares val i varje läge påverkar hur historien kommer att fortsätta.
Det finns likheter med traditionell litteratur vad det gäller den skönhet och det intellektuella utbyte som man kan få ur spelen och också i hur muddet speglar författarens upplevelser om samtiden.
Till skillnaderna hör det sätt på vilket intrigen byggs upp. I traditionell litteratur är läsaren (deltagaren) utlämnad helt åt författarens val och författaren har full kontroll över hur handlingen byggs upp och förs framåt. I ett mud är det läsaren (deltagaren) och hans eller hennes med-läsare (andra spelare) som driver fram handlingen och bestämmer hur de olika intrigerna vävs samman och påverkar varandra.
Att vara författare till en sådan här flervalshistoria är mycket svårare än att författa en vanlig bok, dvs om den skall uppnå samma kvalitet. Till dags dato har inget spel ens lyckats närma sig "kvaliteten" som finns i den enklaste kiosklitteratur. Mest för att det är svårt att åstadkomma en intressant intrig.
Å andra sidan är det många saker som finns i mud som aldrig kan realiseras i en vanlig bok. Bl.a. kan författaren själv finna nöje i att "läsa spelet" eftersom intrigen kan förändras av andra "läsare".
SvenskMUD hör till en typ av spel som kallas LPmud. Det är en typ som utvecklats av datorintresserade och en av grundideerna är att det skall vara lätt att skapa mer saker i spelet (skriva mer i boken). Detta gör att spelet förändras från dag till dag. Det tillkommer saker och saker ändras.
Många mud fungerar så att det finns möjlighet för läsarna (spelarna) att efter "slutläst" mud, oftast en viss mängd avklarade uppdrag i spelet, få möjlighet att själva ta del i skapandet. Detta skänker ytterligare en intressant dimension av gemensamt författarskap (2) som är väldigt sällsynt i den traditionella litteraturen.
Egentligen är skillnaden mellan att vara "läsare" och "författare" lite diffus eftersom "läsaren" också påverkar historien. I SvenskMUD skiljer man på dödliga och magiker. Magiker har rätt att skapa helt nya saker medan de dödliga är utlämnade åt de möjligheter som magikerna skapar åt dem.
Ibland kallas världen som finns i spelet för en virtuell värld och de olika magikerna ansvarar kanske för var sitt geografiskt område i den virtuella världen.
Det ursprungliga målet med SvenskMUD är att erbjuda ett alternativ till den engelskspråkiga amerikainfluerade kulturen som finns i den svenska hackervärlden och speciellt bland utbudet av muddar. SvenskMUD var faktiskt först i världen med att erbjuda ett mud på Internet där själva kommunikationsspråket var något annat än engelska. Sedan dess har det dykt upp mud på tyska också.
Världen är tänkt att återspegla den nordiska mytologin och den svenska litteraturen och utspela sig någongång på 1800-talet.
Dessutom har en del magiker svårt att skaka av sig oket från den amerkanska kulturen och det finns inslag som inte riktigt lever upp till kraven/målen.
Man måste vara medveten om vad det är för personer som är spelare och blir magiker. Eftersom spelet bara är tillgängligt för personer som finns på Internet så är det nästan uteslutande datorintresserade högskolestuderande som spelar. Det innebär att mycket av det skapande som görs inte handlar om att få en bättre värld utan istället är inriktat på att hitta programmeringtekniskt utmanande problem och lösningar.
Sådana åtgärder orsakar genast motsättningar i författargruppen och resulterar otvivelaktigt i att det fungerande resultatet blir mycket mindre. Mindre diversitet och mindre möjligheter. Dessutom finns det ingen som har tid att ställa upp med den tid som behövs för det trista arbetet att godkänna och rensa ut prylar.
I SvenskMUD är målet att skapa en kreativ och hjälpsam anda bland magikerna. I viss mån har stilmålet och kvalitén fått kompromissas för att alla skall känna att de är välkomna att deltaga i skapandeprocessen.
Geografiska inkonsistenser i den virtuella världen löses genom att övertala magikern att flytta sitt område istället för att flytta det utan förvarning. Inkonsistenser i tidsepoken löses genom att man skapar en tidsmaskin eller genom att man låter spelaren börja drömma och i drömmen vara i en annan värld eller liknande.
Allt för att så många som möjligt skall få utlopp för sin kreativitet och känna på denna alldeles speciella typ av författarskap.
Ett angränsande problem är att författarna är spridda över hela Sverige (egentligen hela världen) och i stor utsträckning inte känner varandra. Att kommunikationen dem emellan är begränsad till att prata med varandra i spelet i den mån de råkar vara inne i spelet samtidigt och skicka brev till varandra gör det ibland kan vara svårt att förstå varandra. Det blir lätt missförstånd.
Pga ovanstående kommunikationsproblem kan det inte skapas en fungerande demokrati i spelet utan jag har utnyttjat min position som gud och implementerat mina ideer. På senare tid har jag mest utnyttjat min diktatorställning till att utse Ärkemagiker som jag tror kan behålla den kreativa miljön och arbeta för konsistens i spelet. I detta val har jag också försökt verka för att SvenskMUDs underhållningsvärde skall öka och skapandet skall koncentreras på en fin värld.
De ideer som jag implementerade ursprungligen är: @nobreak
Den första LPmudden kom i april 1989 och det var Genesis som kördes på milou vid CD. Det var skrivet i LPC och spelets språk var engelska. I maj 1989 så hade även föreningen Lysator ett mud, då körandes på brutalix. Det är detta mud som sedermera blev det legendariska nannyMUD, som är det för närvarande äldsta muddet som bygger på det ursprungliga mudlibbet och har magiker kvar från allra första början.
Det som gjordes var en direkt översättning vad gäller viktiga rum och funktioner, kyrkan, puben, spelarobjektet mm, men jag passade på att bygga om byn så att den fick en lite annorlunda utformning, dvs rummen sitter ihop på ett lite annorlunda sätt. Exempel på detta är att man går ur kyrkan västerut, man kommer till Leo från äventyrarnas klubb istället för från kyrkan.
När vi väl hade gjort det mesta av arbetet med översättningen så var vi
tvungna att lägga till en del saker i mudlibbet för att det skulle passa
bättre med det svenska språket. Bl.a. så har set_gender fler alternativ.
Ett annat exempel är hantering av namn i bestämd form. query_namnet och
att funktionen set_name tar två argument eller en array.
I januari 1992 så gjordes ett byte från COMPAT (4) till NATIVE (5). Det innebar att en hel del objekt måste skrivas om och det är bl.a. nu som master-objektet kommer till användning. (I kompatibilitetsmod finns inget masterobjekt.)
Under sommaren 1992 så lades det in stöd för iso-8859-1 tecken i drivern. Det innebar att de som har ett kommunikationsprogram som klarar iso-8859-1 tecken samt ett terminalprogram som klarar det kan få tecknen åäöÅÄÖ. För de som kör med äldre utrustning konverteras all utmatning till }{|][\ eller iso-646.
Fram till och med sommaren 1992 hade SvenskMUD levt en ganska undanskymd tillvaro och Harry var under stora tider helt ensam inne i spelet. Under hösten 1992 kom det en stor anstormning spelare från Halmstad, Umeå med flera ställen och de blev också snabbt magiker.
Våren 1993 såg en ny anstormning, nu med folk från Stockholms universitet och de drog även med flera av nästa årskurs som fyllt spelet under hösten. Dessutom tillkom det en hel del spelare från Luleå under hösten.
Bodil är en Sun 4/280 med 32MB ram och SunOS 5.3 som är donerad av Sun.
Lysator är en medlemsorganisation i Förbundet unga forskare.
Lysator har till uppgift att bibringa sina medlemmar mål och möjlighet att fördjupa sig i datorteknik och datorvetenskap och att sprida kunskap om modern datorteknik.
Resten av denna handbok är tänkt att försöka ge tips till nya och gamla magiker vad det gäller hur man skapar saker i spelet. Tipsen gäller både tekniska frågor och stilfrågor.
Det står dig nästan helt fritt att välja vilka metoder du vill
använda för att editera filer om de bara på något sätt kan
samarbeta med de grundläggande metoderna för att få in
filer i spelet (ed och ftp).
Emacs med ange-ftp fungerar bra om bara någon lägger in programmet
ls hos dig i ditt `bin'-bibliotek. Det finns alltså ingen som
helst anledning att tillbe avgudar som ed, vi och
framemaker.
Glöm inte att fylla alla dina rum med bilder, statyer och reliefer av Gud.
Dessutom kan du fylla dem med människor, djur och saker. Det ger atmosfär och gör det möjligt för nybörjare att samla ihop lite saker och om du gör monstren pratsamma så kan de ge tips till nybörjaren som stannar och lyssnar.
Inte heller vad det gäller namn skall du hysa några som helst betänkligheter. Se bara till att svartlista de namn du använder och inte använda redan svartlistade namn eller spelares namn.
Söndagar brukar det inte vara så mycket folk inne i spelet så det är en synnerligen lämplig dag att leta buggar på.
Din fader och moder vet inte hur många timmar du sitter och kodar ett visst rum eller område. Behöver de veta?
Prova att slå ihjäl alla dina monster som du skapar och verifiera att
de kan dö, att de kommer tillbaka vid nästa reset genom att
anropa reset i rummet och kolla så att vikten på liket är rimlig.
Det finns faktiskt ingen som har kodat en möjlighet att gifta sig än i SvenskMUD trots prat om sådant. Tills dess kan du ju försöka lyda detta bud. Att vara otrogen mot sin trolovade räknas inte som äktenskapsbrott i detta fall.
Om du inte vet hur du skall göra vissa saker så fundera ut var du sett något liknande och titta hur det är gjort där. Det bästa sättet att lära sig är att kolla hur andra gör saker.
Om du lånar till alla dina saker så glöm för den skull inte att lära dig under tiden.
Hela världen är ju egentligen en schimär. Se till att hålla skenet uppe för spelarna så länge så möjligt. Undvik att skicka ut text av teknisk karaktär till spelarna. Gör fullständiga meningar som betyder något, tillräckligt fullständiga för att spelarna ska förstå vad det handlar om.
Var speciellt försiktig om du håller på att eka eller ropa saker. Tänk på att spelarna lever i en annan värld och anpassa dina meddelanden till det. Ropa t.ex. "Nu skall jag ge mig iväg på en lång upptäcksresa i öst och nord." istället för "Nu går jag hem och lägger mig.".
Spring omkring i de andras områden, kolla vad de bygger, skicka en massa buggrapporter och gör sedan bättre själv.
Även när det gäller de andra magikernas prylar skall du se till att använda dem. Om du vill ha ett likadant monster som en annan magiker gjort är det bara att klona ett sådant och stoppa in det i ditt rum. Förbehållet givetvis att det kan vara bra om den andre magikern känner till det så att han inte, dig ovetande, ändrar filnamn eller andra egenskaper hos det monstret.
Livet som magiker skiljer sig i väldigt stor grad från livet som spelare. Som spelare kan man inte se de tekniska svårigheter och möjligheter som magikerna har. Att göra bra och genomtänkta saker är svårt och kräver mycket tålamod och tid.
Det händer att nyblivna magiker har väldigt stora planer och färdigritade kartor med hundratals rum som de vill göra, men så finner de att de egentligen inte har tid att göra det och lägger ner projektet. Man kanske skall passa på att påpeka att fler rum oftast inte är bättre. Det går att göra mycket på bara ett fåtal rum och det är betydligt bättre att göra ett bra rum där det kan hända saker än 100 tomma rum.
Ur spelets och spelarnas synvinkel spelar det kanske inte så stor roll om dina högtflygande planer inte blir implementerade för att det visade sig att du inte har tid och det är heller ingen som tar illa upp om du ångrar dig och gör något annat istället. För din egen skull kanske det är bäst att ta ett steg i taget och börjar med att göra roliga småsaker medan du lär dig det man behöver kunna för att kunna göra bra saker. Först när du kännt på vad som är möjligt och hur lång tid saker tar är det dags att börja planera större projekt.
Som skapare har man ett ansvar för att se till att världen blir så bra som möjligt. Det är någonting man slipper som spelare. Det kan vara ganska svårt för vissa begrepp blir helt ställda på huvudet.
Från att pengar på banken har betytt trygghet så är nu problemet hur mycket man skall ta betalt för olika tjänster som man implementerar.
Andra saker att tänka på är att när man som spelare springer omkring så är man inne i historien och då gäller det att få så bra prylar som möjligt. Det är lätt att tänka att när jag blir magiker skall jag minsann göra bättre än det här. Bättre i bemärkelsen kraftigare. Det är ännu lättare att faktiskt implementera en sådan pryl men det riskerar att sabotera balansen i spelet. Se section Inflation i spelet.
cd, ls,
mkdir, rmdir finns till exempel.
Filträdet är direkt uppbyggt på UNIXens filträd. Drivern
gör inte chroot(2) men skrivning och läsning av filer
som inte ligger under detta träd är trots det helt omöjlig
inifrån drivern eftersom alla filnamn kontrolleras.
Detta gör att man kan ha symboliska länkar som pekar ut ur detta filträd.
ls /. Vissa av dessa filer är
kataloger och vissa är filer. Om man gör ls -F / istället kommer
katalogerna att listas med ett / efteråt.
Iden med att placera varje kommandon i en fil kommer ursprungligen från TMI (6) där den är helt genomförd.
Vinsterna med denna uppdelning av kommandon är:
PATH.
head *.c ^ grep filen ^ more
Problemet med det hela är att det inte är riktigt genomfört. Det finns bara ett begränsat antal kommandon som man kan kombinera på detta sätt.
Ett annat problem är att det är ganska svårt att skriva nya kommandon. En utmaning kanske? Läs filerna `/bin/IDE' och `/bin/S]FUNKARDET' för att se hur det är tänkt att det ska fungera.
I flera av underkatalogerna finns det en katalog som heter `obsolet'. Där har jag flyttat ner de filer som ersatts av nyare, i samband med översättning eller omskrivning.
Denna fil skall läsas av alla magiker!
Andra bra filer som du ska titta på är `vapen.lista', `monster.lista', `skydd.lista' och `drycker.lista'. De innehåller information om de olika objekten och riktlinjer för hur objekten ska se ut.
De flesta efunar finns beskrivna i denna katalog. Har du magikerboken
kan du komma åt dem t.ex beskrivningen av find_player med
`man find_player'. Jag har nyligen stoppat in en kopia Profezzorns
`lpc_for_morons' här. Detta för att den är bättre.
De gamla filerna kan du hitta i `/efun.old'.
De funktioner som beskrivs är främst de som finns i monster och prylar, men även en del viktiga funktioner som anropas från drivern:
@nobreak
catch_tell anropas i objekt som gjort enable_commands om
någon pratar till objektet, dvs objektet finns i ett rum där någon gör
say, som någon gör tell_room till eller liknande.
init anropas när ett objekt flyttas in i ett annat objekt. Dels
anropas init i objektet som vi flyttar in i och dels anropas
init i alla andra objekt som redan fanns i det objektet vi
flyttas in i.
exit ska du helst inte använda. (7)
id anropas när man gör present. Den ska returnera sant eller falskt
beroende på om objektet känns vid en visst namn.
Detta dir ska vara lässkyddat för alla andra än SvenskMUDs magiker.
#include <filnamn>Detta dir är först i denna default-path. Saker som ligger här är bl.a `gender.h' som används för att hantera könen och `tune.h' som reglerar hur spelet är justerat, dvs hur mycket ett erfarenhetspoäng kostar i ören.
log_file. Vilket objekt som helst får skriva med den men då
hamnar det alltid i detta dir. Här finns det också vissa filer som
skrivs hit av spelet.
Se till att rensa dina filer här regelbundet.
De magikerspecifika filerna för magikern `linus' är:
present i spelaren hittar svärdet och du har gjort svärdet så hamnar
det hos dig. Om spelaren menar ett annat svärd än det present hittar så
hamnar det nog fel.)
Av någon outgrundlig anledning (tradition heter det nog) ligger även filen `init_file' i detta dir. Det är den filen som läses när man ska avgöra vilka slott som ska läsas in när spelet startas om.
Det viktigaste är masterobjektet. Masterobjektet har dels hand om säkerheten och dels reglerar det vad som händer när spelet bootar om.
Se section Masterobjektet.
save_object på spelarobjektet när man gör spara, råkar ut för
`Jag sparar dig automatiskt.' och när man gör sluta.
Dessutom är det här som magikerna får sin filkatalog som de själv bestämmer över. Denna skapas när man släpper sitt slott och då skrivs också slottet dit.
En speciell fil är `castle.c'. Denna laddas vid uppstart och är din enda möjlighet att länka in ditt område. Denna autoladdningsmöjlighet regleras i filen `/rum/init_file' och kopplas på när du släpper ditt slott. Den kan givetvis också plockas bort om du inte sköter ditt område eller inte vill ha det med i spelet längre.
`/std/namn.c' är en sak jag gjorde när jag flyttade alla funktioner som hade med namn att göra från `/obj/treasure', `/obj/weapon' mfl. hit.
I underkatalogen `magiker' finns magikerverktyg dvs. objekt som magiker kan använda som verktyg för sitt konstruerande.
Det kan kanske vara intressant för magikerna att veta att alla gamla nummer av `{@sl SvenskMUDs Dagblad'} och `Svenska Mudbladet' finns sparade här.
dumpallobj i muddet. Det kan
ibland vara användbart för att få reda på om saker finns, vilka saker
som finns och var saker finns.
write utan att
this_player är satt till någonting så skrivs det ut på
stdout (med ett ] före).
Objektet med namnet `/obj/hej' kallas hädanefter för förlagan och objekten med namnen `/obj/hej#123' kallas för kloner eller klonade objekt.
För varje typ av objekt kan det antingen bara finnas kloner eller också bara förlagan inne i spelet. Om man försöker klona ett objekt där redan förlagan finns i spelet så får man `Cloning a bad object'. Om man försöker använda (ändra variabler i) förlagan för ett objekt som är klonat så får man `Using a cloned object'.
För rum finns normalt bara en förlaga. För att göra om rum så gör man `uppdatera {@it filnamn'} och sedan går man in i dem igen eller laddar in dem med `ladda {@it filnamn'} .
Ditt slott (`castle.c') är också bara en förlaga. Det innebär att du inte ska klona det utan det ska laddas.
create anropas i förlagan när den laddas.
clone_object och man anger då som argument namnet på förlagan. Det man
får tillbaka är en nyskapad klon.
object hej;
hej = clone_object("/obj/hej");
Om förlagan inte är laddad så laddas den först och create anropas i den,
därefter klonas ett objekt och create anropas i klonen.
Dessutom finns det möjlighet att avgöra om ett objekt är "living"
eller inte. Att det är "living" innebär att det har ett namn så att
man kan hitta det med find_living, som gör det snabbt att hitta monster
och spelare.
Objekt kan också ha en s.k. "heart_beat". Det innebär att funktionen
heart_beat anropas regelbundet i objektet. Alla monster använder sig av
detta för att slåss och räkna upp sin egen ålder. Spelare använder den
dessutom för att hela.
Om man kan så skall man försöka undvika att använda sig av
heart_beat eftersom det anropas så ofta. I de allra flesta fall
kan man klara sig lika bra med en call_out som har betydligt
längre tidsintervall.
Alla standardprylar som man ärver ifrån, `/rum/rum', `/obj/weapon', `/obj/treasure' mfl gör redan detta så om man använder någon av dem är det inga problem.
I `/std/object' finns det inte så mycket och egentligen borde det finnas ännu mindre där.
Det som finns är bl.a. en move_object som gör att man kan flytta vilket
objekt som helst. Normalt, i NATIVE, är att varje objekt bara kan flytta sig
själv med move_object.
Jag har slängt in genushanteringen här. Det innebär att alla objekt i
spelet har funktionerna set_maskulinum, set_femininum, set_utrum,
set_neutrum, query_gender, query_pronoun mfl och dessutom en variabel
som håller reda på detta.
Om du inte ärver `/std/object' i något led så går det inte att flytta in objektet i spelet. Det existerar men finns utanför. Detta kan vara förvillande om man inte känner till det.
create anropas i masterobjektet.
flag anropa en gång för varje argument till flaggan -f som
drivern startas med.
epilog anropas.
Det är i denna funktion som filen `/rum/init_file' läses och förladdar det som ska förladdas.
valid_{@it whatever}-funktioner
som anropas
när man gör olika "farligare" saker. När man ska skriva på
en fil så anropas valid_write för att kolla att du får lov att
skriva på den filen. Den anropas med filnamn, vilket sätt man
håller på att skriva filen med och vem som gör det. Sedan
avgör funktionen om det är tillåtet eller inte.
Om du läser masterobjektets fil ser du att valid_read alltid
returnerar sant. Det är ett medvetet val. Alla ska ha möjlighet att
läsa överallt!
Enda svårigheten är att veta vilka värden olika saker ska ha. Det är också en avvägningsfråga när man ska avgöra hur mycket man ska dela ut.
Saker som bara ligger och skräpar ska vara billiga, typiskt under 20 öre. De är inte onödiga bara för att de är så billiga utan de är till för att även nybörjare ska ha något att plocka upp och springa och sälja. Om det ligger en liten liten bärnsten vid stranden eller en vacker blomma på ängen som man kan sälja i affären så kommer det också att bidraga till stämningen.
Saker som stora monster bär på och som är extra belöning för att man har lyckats slå ihjäl det kan ju vara lite värdefullare. Likaså saker som ligger i svåråtkomliga rum.
Att pengarna alltid visas som daler och ören är tillagt efteråt. Det
finns en färdig funktion för konverteringen. I filen `/obj/libfun'
finns funktionen print_money som tar ett belopp i ören som
argument och returnerar en sträng.
Andra saker att tänka på är att skyltar, tidningar mm ska man kunna
läsa, likväl som man kan titta på dem. Dessa båda sätt att undersöka dem
på behöver inte resultera i samma text men båda möjligheterna ska finnas.
Speciella saker att tänka på är att vapen med högre nivå än 17 plockas bort ur affären om någon skulle sälja dem och att vapen med en högre nivå än 20 ska ha allvarliga nackdelar. Hur allvarliga de behöver vara bedöms av den ärkemagiker som godkänner det.
Dels finns det i `/doc/build/skydd.lista' en lista över vilka nivåer som är tillåtna för olika rustningstyper och vilka kostnader de får ha. Dessutom ska man se till att hålla sig till de typer som finns, bokstavsgrannt, så att man inte kan ta på sig för mycket skydd.
Enklaste sättet är att klona `/obj/armour' och sätta namn, typ och klass.
create i `/obj/monster' (eller på något annat sätt gör
set_living_name och enable_commands.
Även när det gäller monster är det viktigt att man använder sin kreativitet för att de ska bli trevliga. Monstren är inte automatiskt bättre för att de är starkare och man behöver inte börja med jättemonstret Allan. Även små monster är befogade för att ge atmosfär och ge tips för nybörjarna.
När ett monster dör skapas ett lik. Man kan i monstret sätta ett värde på hur mycket liket skall väga. Gör man inte det så väger liket 5, som ungefär motsvarar en människa. Mitt förslag är att sätta mindre (1-2) på katter och hundar och mer (8-15) på kor, hästar och björnar.
heart_beat i monsterheart_beat utan istället i funktionen
heal_slowly. Detta beror på att när du lämnar ett monster så stängs
heart_beat av för att slås på igen när någon kommer. heal_slowly
anropas via call_out varannan minut ända till monstret är helt
läkt. Då slutar den för att startas igen nästa gång någon börjar slå på
monstret. Detta sparar kraft för drivern i och med att monstrets
heart_beat stängs av.
Om du gör ett monster så se till att försöka använda denna eller
liknande mekanism för att slå av heart_beat då monstret står
ensamt i ett rum.
En annan sak som bör observeras är att monster inte har någon magisk styrka. Hur många besvärjelser de kastar beror helt och hållet på vilka slumpfaktorer du har satt.
Egentligen borde det finnas färdiga monster att klona fram och bara sätta nivån hos. Det borde i så fall ligga i `/stdobj/monster'. Då borde det finnas en fil/objekttyp för varje ras.
Exempel på vad man skulle kunna göra är:
I det vanliga `/rum/rum' så kan man enkelt klara detta med items.
Andra saker att tänka på är att göra vettiga beskrivningar och att inte överlasta rummen med prylar.
Om man använder sig av ordinarie rummen så kommer de att rensas bort vid
clean_up om de är tomma. Dvs efter ca 2 timmar om ingen har varit
i dem. Vill man behålla dem, för att man lagrar variabler eller annat
där, så får man definiera om clean_up.
Nackdelarna är att nybörjare får det svårare (dvs även de enklaste monster är för svåra) och att man måste göra om kraven hela tiden, kanske ändra till nivå 30 för att bli magiker med 100 miljoner erfarenhetspoäng.
De mekanismer som finns för att motverka detta finns där för att motverka detta och inte för att kringås!
Se till att inte göra saker som är dyrare än tio daler, det retar bara upp spelarna.
Uppdragen har tre syften:
Det första du ska tänka ut när du börjar planera ett uppdrag är vad ditt syfte är med uppdraget.
Om ditt syfte är att spelaren ska utforska hela din del av världen så är det första du ska göra att se till att din del av världen går att gå i och "tål" att utforska. Dvs det finns något kul (8) i varje rum, något monster, någon pryl, något ihåligt träd, ...
Eftersom uppdraget ska lösas flera gånger, en gång för varje magikeraspirant, så är det bra om du kan få ihop historien så att det på något sätt är förklarligt att det kan lösas flera gånger. Kanske ett litet skådespel en stund efter (medan spelaren står och begrundar belöningen) som på något sätt återställer saker så att det kan lösas på nytt.
Man kan betrakta magikerskapet som målet med spelet och det är det enda mål som finns i ett LPmud, förutom att ha roligt.
I vissa delar av den här boken har jag kallat magikerna för författare eller skapare. Det är de som skapar spelet och utan dem vore spelet dött.
Det kan bara finnas en gud.
Dessa är skrivna i LPC och exekveras därför mindre effektivt än efunarna.
Dessa är också skrivna i LPC.
I LPC finns ingen egentlig kontroll att man i en variabel av en viss typ verkligen har ett värde av den typen. Man kan däremot deklarera funktioner så att de tar vissa typer som argument och vid kompileringstillfället kolla att alla anrop är korrekta.
unsigned, float, double, long, char, void * mfl.
Vissa av dessa ersätts helt eller delvis av andra typer.
struct, union, enum, typedef.
Över huvud taget existerar inte alls mycket konstruktioner som ska beräknas vid kompileringstillfället.
struct och union kan man implementera med mappings eller arrayer
men hela hanteringen måste ske vid exekveringstillfället. enum och
typedef tvingas man emulera med #define.
Det går inte att komma åt C's biblioteksfunktioner från de olika objekten. Vad man kan göra och inte kan göra är begränsat av vilka efunar som finns. Man tvingas lägga till nya efunar om man vill utöka detta, det innebär en omkompilering av drivern.
Man tvingas göra en objekt-global variabel.
Man tvingas göra ett speciellt objekt hos vilket man registrerar variabelvärden. Personligen tycker jag detta är en snygg lösning.
call_other. Den tar som argument ett objekt eller möjligtvis
filnamn, ett funktionsnamn och eventuella argument. Argumenten kan vara
av godtycklig typ och det finns inget som helst sätt att vid
kompileringen av objekt, kolla om man har rätt typer.
Vidare returnerar call_other någonting som har datatypen mixed så ska
man använda det vidare måste man tala om vad det är för typ, med ett
c-liknande cast.
call_other(objekt, funktionsnamn, argument)
(9).
Det är inga som helst konstigheter med att ärva flera olika filer. Man kan också själv välja från vilket ärvt objekt som en funktion ska anropas. Ex från facklan: @nobreak
inherit "/std/object";
inherit "/std/namn";
short()
{
if (is_lit)
return namn::short() + " (tänd)";
else
return namn::short();
}
Det innebär att short i `namn' anropas även om det skulle
finnas en short i `/std/object.c'.
Om man vill att de ärvda objekten inte ska kunna modifiera en
variabel mer än genom vissa funktioner kan man göra variabeln privat
(private). På samma sätt kan man begränsa funktioners räckvidd.
En funktion kan deklareras så att inget objekt tillåts definiera om
funktionen efter att ha ärvt det objektet. Det gör man med uttrycket
nomask.
sscanf.
@footnote {Ej att förväxla med C-bibliotekens sscanf, den som finns här är
mycket enklare och är en del i språket. Man ska exempelvis inte skicka
med pekare till tal och strängar utan variablerna direkt.}
Arrayer kan man också addera och då får man en ny array som är sammanslagningen av de två. Man kan också subtrahera arrayer från varandra, det innebär att man får en ny array som innehåller alla element i den första arrayen utom de som finns i båda.
På både strängar och arrayer kan man ta ut delar av dem med hjälp av intervall-operationer. Ex. `"hej"[1..2]' blir `"ej"'.
Mappings är en helt ny typ. Man kan kalla det en slags array där indexen kan vara vad som helst. Dessutom finns det funktioner för att ta fram alla index eller alla värden.
init() (för att lägga till dina saker). För att
dest_dir-riktningarna ska fungerar måste du anropa rum::init() i
init() så att det görs add_action() på dest_dir-riktningarna.
heart_beat() slutar monstret att slå.::heart_beart() från heart_beat().
Den sköter stridsmekanismen samt ser till att slå av heart_beat när
ingen spelare finns i närheten (sparar mycket exekveringstid för drivern).
init() för monstret? Om du glömt att
anropa ::init() så kommer nämligen inte heart_beat att sättas
igång automatiskt när någon kommer in.
heart_beat() på mitt monster så stängs heart_beat av hela tiden.reset() från create()?
Funkar det att klona dem vid sidan om?
Är de synliga? Om du sätter en pryls namn mm i reset() istället
för i create() så blir de osynliga fram till första reset.
create(). create() anropas först i
förlagan och sedan i klonen. Kanske det ena paret är pare till förlagan.
Det finns magiker som blir besatta av magikerverktyg och som koncentrerar hela sin verksamhet på att göra bättre och bättre verktyg hela tiden. Låt inte det smitta av sig, du behöver inte också göra ett magikerverktyg! Utnyttja de som redan finns!
man som slår upp hjälptexter. Den söker igenom vissa kataloger
efter filer som matchar ett visst namn när man anger det.
Du får magikerboken automatiskt när du blir nivå 20. Annars finns den i `/obj/magikerbok'.
Magikerboken definierar följande kommandon:
man {@it funktion}}
MANPATH}
MANPATH+={@it bibliotek}}
man-kommandot.
MANPATH-={@it bibliotek}}
man-kommandot.
MANPATH=default}
När man skall ange objekt till staven kan man antingen ange filnamn (för
kloner följt av
#{@it nummer}),
en spelares namn eller ett objekt
som finns i närheten.
Dessutom kan man ange {@it objekt},{@it n} vilket betyder det
{@it n}:te objektet i {@it objekt} eller också {@it objekt},{@it namn}.
Då söker den igenom {@it objekt} efter det objekt som bekänner sig vid
namnet {@it namn}.
Några av ekstavens kommandon är:
Hjälp}
Ä}
Kolla {@it objekt}}
Titta}
Beskriv}
testa {@it objekt}}
anropa {@it objekt} {@it funktionsnamn} {@it argument}}
Exempelvis:
> Ä Objekt i OBJ(obj/player#2741) <-> Linus skaparen (gud) 0: OBJ(stdobj/magiker/brain#2747) <-> linus' shell 1: OBJ(obj/magobj#2750) <-> Osynligt objekt. 2: OBJ(obj/magikerbok#2749) <-> en magikerbok 3: OBJ(stdobj/magiker/fizbans_stav#2748) <-> En gammal ekstav 4: OBJ(obj/soul#2742) <-> Osynligt objekt. Det var allt. > anropa mej,staven long Du inser att staven har en magisk kraft. Returvärde : 0 > anropa mej,2 short Returvärde : en magikerbok >
Staven hittar du i `/stdobj/magiker/fizbans_stav'.
Mha den kan man göra en del saker direkt som man annars skulle behövt ett speciellt objekt för.
Objekt kan anges på samma sätt som med ekstaven.
De mest användbara av shellens kommandon är:
shellhelp wizard}
shellhelp {@it rubrik}
.
id}
gauge {@it kommando}}
eval {@it uttryck}}
Du kan klona shellen ur `/stdobj/magiker/brain'.
valid_{@it whatever}
add_action
Beskriv
call_other
call_out
catch_tell
chroot(2)
clean_up
clone_object
create
create i masterobjektet
dest_dir
dumpallobj
ed
emacs
enable_commands
epilog i masterobjektet
eval
exit
find_living
flag i masterobjektet
ftp
gauge
heal_slowly
heart_beat
heart_beat i monster
heart_beat()
Hjälp
id
init
init()
items
Kolla
ladda
log_file
ls
man
MANPATH
move_object
nomask
present
print_money
private
query_gender
query_namnet
query_pronoun
reset
reset()
rum::init()
say
set_femininum
set_gender
set_living_name
set_maskulinum
set_name
set_neutrum
set_race
set_utrum
sscanf
tell_room
testa
Titta
valid_read
valid_write
Ä