ASGÅRDprojektet

Sammanställt av Paul Svensson
Projekt ASGÅRD är Göran (oden) Karlssons examensarbete. GK var under
sin (långa!) tid tid LiTH verksam i Lysator bl a som sekreterare. Han
gick ut D-linjen i våras, och jobbar nu i Stockholm. Eftersom många
inte känner till projektet, kommer här en liten sammanfattning.
Naturligtvis är den tvåspråkig.

   THE PROJECT

There are different ways of gaining experience on what kind of
programming environment is suitable for programming multiuser
games. Either you write a "tailor made" program, which you then
modify(with some effort), or you write a "supergeneral" system, which
hopefully make changes of the main software, the "kernel",
unneccesary. Both ways have their natural advantages and
disadvantages. A tailor made system runs faster, but is harder to
modify = harder to test different ideas. A general system is easier to
modify, but runs slower. The ideal route seems to be to first build a
general system for experimenting, and then use the experience gained
to write a faster, more specialized system.

   IMPLEMENTATION

As a part of our research on computerized multiuser games, we have
implemented an experimental programming environment. It's based on a
LISP interpreter, extended by a multiuser data base, a very general
parser, a process machinery, a multiple window system and a message
passing system. Most of this Is written in C.

   EXPERIENCES

We may have made a mistake choosing to implement the system on a pdp11
under BSD UNIX 2.9; 2.9 doesn't have any "real" primitives for
sharing a data base between processes. This caused too much time to
be spent on implementing these primitives. The system is rather slow;
we underestimated the importance of fast shared data base
managing. The way we do it, reading and writing symbolic expressions
on files, severely limits system speed. There are two ways of
increasing the speed: Either a common data base, directly accessible
by all programs, with the whole or major part of the data base in core
memory; this takes larger addressing space. Or a copy of the data base
in each program with a mechanism to broadcast updates to all
interested; if a distributed game system is to be implemented, this is
needed anyway.

   FUTURE PROJECTS

As we now have gained some experience on implementing a multiuser game
on *one* machine it's natural to look at how to do it with several
(possibly different) machines, on some kind of network. This should be
possible, as updates are infrequent compared to questions, which makes
possible a distributed data base, with more or less complete copies on
several places in the net. Note that it may not be neccesary to always
keep global consistency in a game world, as long as the world is not
to weird, from the players point of view.



ASGÅRD (också kallat runes) innehåller följande:

   IDENTIFIERING

Det finns ett loginförfarande med password som ser till att obehöriga
ej kan komma åt databasen. För tillfället kan endast betrodda
personer få en användaridentitet i runes, på grund av problem med
setuid och filskydd. Kontakta paul-s@obelix.liu.se om du är
intresserad.

   LISPINTERPRETATOR

Vi har gjort en egen lispdialekt. Denna har byggts ut med bland annat
namn på block (PROG och PROGN) och defaultvärden på parametrar. Vi har
också ansett att GO logiskt sett hör ihop med PROGN och inte med
PROG. Detta gör att man kan göra hopp överallt där det finns en PROGN
eller en implicit PROGN. (PROG är en funktion med implicit PROGN!)

   DATABAS

Databasen är delad i två delar, en för atomer och en för för
lisputtryck. Den sistnämnda har fyra nycklar där varje nyckel 
måste vara antingen en atom eller ett tal. Denna används for att lagra
egenskaper. Den fjärde nyckeln har speciell betydelse.

Vi har implementerat något som vi i brist på bättre namn har kallat
drömmar. Den fjärde nyckeln i databasen är namnet på den dröm som
datat tillhör. Den dröm som heter nil skall inte betraktas som en
dröm utan som verkligheten. När man börjar drömma så läggs så att säga
ett lock på databasen med effekten att man inte längre kan förändra
verkligheten dvs det som fanns innan man började drömma. Om samma data
(m a p nycklar) finns både i drömmen och i verkligheten så läses det
som finns I drömmen annars läses det som finns i verkligheten. Om man
drömmer och skall skriva så skriver man alltid i drömmen och inte i
verkligheten.

Detta innebär att om man använder en dröm, så har man råd att göra
fel, även om någon annan använder de delar man uppdaterar. När man
sedan är klar så kopierar man vid lämpligt tillfälle innehållet i
drömmen till verkligheten.

Det är möjligt att drömma i en dröm, men det är förbjudet att drömma
en dröm som man redan drömmer, dvs drömma i loop.

I databasen finns det ett skyddssystem på varje data som påminner om
de skydd som finns för filer i normala operativsystem.

   PROCESSKÖER

Det finns en enklare form av bakgrundsprocesser som exekverar när
datorn vantar på tangentbordsinmatning eller när man kör funktionen
DlSPATCH. Det finns en global kö och en kö för varje användare.

   PARSER

Denna kan användas till kommandoavkodning och kan klara av samma saker
som en kompilatorkompilator kan.

   NÄTGENOMSÖKARE

Denna söker igenom nätverk och exekverar kod som finns i de objekt som
genomsöks. Ett kommando från äventyraren utförs som en sådan sökning
med utgångspunkt från äventyraren själv. Nätgenomsökaren använder sig
av parsern.

   LÖSS

Som alla stora system har det har en del mer och en del mindre kända
löss. Det största problemet fn är att Göran verkar ha fumlat lite med
filskydden...