Följande text är ett planer på ett projekt som aldrig lyfte. Det utvecklades ur diskussioner om hur man skulle utveckla Adventure eller StarTrek. Vi ville inte skapa ett fler- användarspel av type alla-mot-alla: hack-and-slash spel finns det nog och övernog av. Den bästa vägen att gå, tyckte många, var att behålla de stressade situationer, man kan finna i StarTrek, men satsa på en uppdelning av sysslorna. På det viset skulle användarna inte sitta stumma framför sina terminler, vilt hamrande på sina tangentbord; utan en mer kommunikativ spelmiljö skulle växa fram, där kommunikationen INTE skedde via datorn utan genom vilda rop och uppmaningar till grannen! Tänk er hela-havet-stormar i ett terminalrum!! Detta är alltså en av de jäsningar som föregått ASGÅRD. vad mån den skisserade interaktionen kommer att finnas med i ASGÅRD är svårt att säga. Säkert är dock att iden är värd att räddas: inom Lysator ha inte mycket hänt på CREW- fronten, men det kanske kan hända... eller iden kanske adopteras av någon annan datorförening, utvecklas och jäser vidare ... Innehållet är en MM-konversation mellan flera medlemmar inom Lysator: därav diskontinuiteten i artikel!/Ed Thulin CREW Sören Tirfing: Denna fil innehåller planer och ideer till ett nytt rymd- krigsspel i StarTrek, PSI eller MUSW-stil men med en extra toppnivå utöver vad såna här system normalt har, för att tillåta att flera spelare spelar ihop på ett skepp och hanterar detta gemensamt genom att åta sig specialiserade arbetsuppgifter som eldledare, styrman/kapten, radarofficer, datorofficer, sambandsofficer etc. och bilda en CREW. - Systemet skall klara av att det sitter olika antal mänskliga spelare på varje skepp. Obs att om har en crew på 1 person, sköter denna allting på ett LITET skepp, som har mindre energi, mindre vapen men är kvickare i vändningarna. Om man har 3 mans crew, får man ett större skepp, och om man har 9 mans (pust) crew får man en battlestar. (Skeppen bar ha parametrar som tröghet vid sublightaccelertion etc.) - Varje deltagare kan med 1-bokstavskommandon titta på antingen radar, telekomm, översikt, maskinstatus, navigation/hopp etc. Ensamma spelare måste hoppa mellan olika moder och har därför större problem. Crews delar upp muntligt vem som gör vad och har därför fördel av detta. Man måste vara connectad till navigation för att kunna styra. Man måste vara connectad till eldledning för att kunna skjuta... Detta medför att totala antalet kommandon FÖR VARJE MOD blir mycket mindre. Därför räcker det med enbokstavskommandon i varje mod. Alla som koppla sig till eldledingen får skjuta samtidigt, men de får tillsammans bara en total eldkraft som motsvarar vad en ensam eldledare skulle ha haft. All skärmmoder begriper cursorförflyttningar med pilar och/eller EMACS-kommandon. Dessutom finns "select closest ship"-tangent (home) och tangenter far att byta till de andra displaymoderna i alla moder. Dessutom tillkommer olik skillnader i vare mod, som tex vad SELECT skall inneb6ra, och speciella kommandotangenter. Alla oidentifierade skepp ser ut p samma Satt (lat oss säga "o"). Dessa kan inte beskjutas anat an med relativa koordinatangivelser. Radarofficeren kan sätta spårnings- labels p skepp (dessa tappar spåret om fi gör ett hopp) mha SELECT (varvid närmaste skepp laser vid cursorn) falt av en label-bokstav A-Z. Därefter kan eldledare beskjuta dessa med samma labelangivelse. Datorprogram till skeppsdatorn (nedan kallad HAL) kan iordningsst51las i man av fritid som kan utf6ra sekvenser av kommandon (i klartext eller något språk) som (kanske, kanske inte) kan utf6ra saker i alla moder (Alternativet r att dataofficeren kan exportera program till all andra moder, men att dessa inte kan samverka ned varandra. Detta skulle haja mänskliga interaktioner lite.) F6rutom skepp, styrda av crews finns det skepp som datorn hanterar och f8r dessa skepp simuleras en hel crew av datorn. Dessa skepp implementeras Sa att det finns ett directory (definieras med logiskt namn) som innehaller filer av typ bigklingon.ship, smallsmuggler.ship, richplayboy.ship etc. Dessa innehåller data med viss struktur, och utg6r ett kokboksrecept eller program, om man Sa säger, p hu detta skepp uppfar sig vid kontakt med ett av de skepp som de mänskliga spelarna använder. Datorn slumpar ut vilken fil som skall k6ras och later spelarna konfronteras med denna. Spelarnas uppgift blir att gemensamt: 1. identifiera skeppet. Det finns ett "ask for identification"-kommando. Resultatet av detta kan vara sant eller falskt eller utebli. Anas kan man frs6ka f kontakt med det med radion. Samma sak dr, "fiende" kan ljuga, skriva " $$% $ $(%" (främmande obegripligt språk), utmana en på strid i det Kzitianska imperiets namn eller iaktta total radiotystnad. Dessutom kan man begära att HAL farsker identifiera fiende åt en. 2. Kontakta skeppet och ta reda p vad de har för ärende etc. Om de har skummiteter far sig (tex smuggling) skall man beslagta, arrestera, bogsera mfl relevanta åtgärder (eller i alla fall försaka). 3. Om det andra skeppet (skeppen), i fortsättningen kallad FI farsaker fly, angriper eller utmanar, skall man farfala, öppna eld etc. 4. Efter en sådan skärmytsling vidtar rutinarbete igen, som tex reparationer, rapport till hq, loggboksföring och mera patrullerande. Meningen r nu att man skall jobba fram ett bra samarbete mellan de olika crewmedlemmarna. De utför alla olika uppgifter och har olika saker på sin displayer. Olika roller och deras skarminnehall vid normalläge: * Sambandsofficer - Radiotrafik med andra skepp. * Radarofficer - Log range sensor scan * Kapten - Diverse sammanfattande info. Short range sensor scan + översikt. * Computer officer - Datorinteraktion, inklusive definition av namngivna macron far stridssituatuioner. Dessa kan INTE sparas p fil! * Eldledningsofficer - short range sensor scan. f Maskinofficer - Far träffmeddelanden och skaderapporter. Beordrar reparationer och måste optimera med hänsyn till begränsade resurser. Kan också utläsa om man har energi kvar att hoppa, åka eller skuta med. - Filerna som beskriver fi kan innehålla saker som * Olika responser p vissa standardmeddelanden. ibland flera alternativ av vilka ett väljes slumpvis. * Uppförande (attack omedelbart, flykt, do-nothing, etc) * Info på skeppstyp, vad HAL tror att det r för typ, vikt, energi, energif6rdelnig datorn slumpar ut hur mycket energi som finns kvar f6r vare skepp man m6ter), skadef6rdelning (samma dir), namn (e hel lista som man slumpar ett ur) etc. - Fi skapas med slumpmässiga intervall. (Ibland kan det finns flera fi samtidigt i rymden, ibland kan man skriva loggbok i lugn och ro i 10 minuter och inget händer) Bernt Nilsson: Några ideer om implementationen =============================== Detta r ett medelstort eller stort projekt, alltså inget enpersonprojekt, det krävs några stycken. Inte f6r många kanske... det kräver oxå ganska ordentlig spec, annars blir det blaha ! det enda vettiga är att g6ra det Sa flexibelt att det relativt snabbt går att implementera en miniversion som undan f6r undan kan utökas utan att det f6r den skull blir risigt. Detta far att det inte ska bli tråkigt innan vi blir färdiga, och att det är n6dvndigt att kunna provköra delar f6r att undersöka om just de (spelsituationerna ?) ar bra. Detta ger, att vi borde f6rska speca en någorlunda generell grund som man lätt kan bygga såna ha "spelsituationer" på. Tex nån gemensam data bs hantering / kommunikation mellan olika personer, mm. ett sätt r att ha det stora jätteprogrammet "Alan" som alla små skärmprogrammen pratar med, dvs. GamesMaster- modellen. Ett annat r att göra något som liknar det ag går nu med PSI och MUSW, en gemensam databas och flera program som updaterar den. Bad sätten har fördelar och nackdelar. Alan måste startas n6 någon(gra) vill köra (kan ske automagiskt), men r klart mycket enklare att skriva. Med flera "aktiva" program Sa ökar komplexiteten kanske, men de olika typerna spelare kan vara lättare att implementera, andra sidan s kommer d som alltid frågan vem som ska k8ra alla "yttre" händelser (som inte r människostyrda). - vilka andra r intresserad av att vara med, d v s ska projektet vara "officiellt" (inom lysator) ?? u fler kockar... Sören Tirfing: Det universum vi konstruerade hade m81ighet att bli mycket stort (2**35 * 2**35!). Dessutom sa vi att universum skulle vara tomt ända tills någon besöker en viss sektor. först då sätts stjärnor etc. upp far just den platsen. Efter ett tag har då skapat en stor mängd objekt, stjärnor, planeter och annat. Troligen vill man ha möjlighet att rensa upp detta. Förslag: Man använder flera universa. Spelarna ska inte ges möjlighet att styra vilket universum de lever i. När man går in med ett nytt skepp i spelet hamnar man i det nyaste universat (man håller man sig regelmässigt med tre st: ett ungt, ett medelålders, och ett d6ende). Vid hyper-hopp finns det en viss chans att man kommer ut i ett helt annat universum n det där man startade (utan att spelet säger något om saken givetvis!!) Ju äldre ett uiversa bli (matt i antal objekt i det tex) desto större ar chansen att man lämnar det. På detta sätt kommer man att fä en migration mot nyare universa på ett naturligt Satt. s a ren Tirfing: Nr man startar programmet (lat oss kalla det CREW) blir man tillfrågad vilket skepp man vill köra. Man kan då svara med ett existerande skepp eller ett nytt. Om skeppet inte existerar: Man far svara på lite frågor om vilken sorts skepp man vill ha skapat. Dessutom far man ge det password som gäller far skeppet i fortsättningen. Om skeppet existerar: man uppmanas ge passwordet för skeppet, om det stämmer, och det finns plats på skeppet, det bara att köra. Annars blir man utslängd med en lämplig förolämpning. Kari Dubbelman: Alla parametrar står inte under spelarens kontroll. an kan alltid ange hur många spelare som skall kunna köra skeppet och alltså ungefär hur stort det skall vara. Däremot r det inte säkert att man skall kunna ange om man vill ha ett piratskepp, handelsskepp, patrullskepp, lustjakt eller Battlestar. Det kan f vara en av de saker som slumpas ut av systemet. P detta sitt får man lite variation i de roller och aktioner man tvingas delta i. Det kan vara intressant att ibland ligg p fel sida i Antipati-matrisen också. Skeppets parametrar (som hastighet, acceleration, massa etc beror u p storleken. Lämpligt ar att om man vill ha ett 4-mannaskepp, Sa slumpar systemet ut en skeppstyp blad all definierade 4-mannaskepp, och parametriserar detta enligt beskrivningsfilen. Kari Dubbelman: Här kommer ett f6rslag p innehallet i en Ship s description file: - En SDF (Ship Description File) innehåller allt som systemet behöver far att kunna skata alla utåt synliga funktioner v ett rymdskepp. Först lite terminologi: SDF - Ship Description file. CUAN - Computerized Universe ANager, "DEC-20" NPS - Non-Playing Ship = En etitet som styrs av CUAN PS - Playing Ship = Entitet som styrs av deltagande spelare (Human) HAL - Dtorn i en PS (Prototypnamn. Den heter olika pa olika skepp) PSF - Prametriserad slumpfunktion. Se nedan. Hopp - Hyperrymdshopp. Skeppet farsvier och dyker upp nnanstas. Bas - Rymdsttion man kan docka med. Kan ven vara pa en planet. Aktiva objekt r skepp, baser och planeter. Strnor r passiva obekt. - Samma sorts fil anv6nds far både PS och NPS. Får ett PS bestäms uppfarandet av besättningen. Far ett NPS skater CUAN om allting. Därför krävs att en SDF innehaller tillräckligt med info far att det skall vara SVÅRT att skilja pen PS från ett NPS! - E Parametriserad Slumpfunktion r e randomfuktio med vissa parametrar. TilI en barjan gr vi bara en enkel funktion (rektangelfardelning) med inparametrarna vinte- vrdevrde och spridning, Sa att resultatet blir VV +- spridning, tex ett skepps vikt r 200Tg + - iOO Tg. En annan trevlig slumpfunktion ar Max - trollg farbukig. Anvinds fr tex energireserven i ett skepp nr man stter p det. Ett fiendeskepp kan normalt taka iOO TeV men ha anvnt hdgst 80% drav s nr man skall slss med det har det kvar (1-0.8*Rnd) *iOO TeV br6nsle bla till att skjuta med). Alla skepp skall ha vissa standardparametrar. Dessa definierar skeppstypen. Sedan r varje skepp e istans av denna typ dir PSF:erna har evaluerats vid skapande- tillfllet, och ndrar sig (eventuellt) inte Sa mycket under drift. Ett PS kan givetvis uppgraderas i en BAS genom att man tex kaper ny mjukvara till sina datorer f dyra pengar. Radiotrafiken behaver en del "burkade" svar pJ stadardfragona. E stor del av beskrivigsfilen i drf6 text. Vi beh6ver en funktion som givet en typ av fraga returnerar en textstrng som plookas slumpmssigt u- en lista av troliga svar. Uppfafandet hos ett NPS-skepp beror pa f a 1 ande faktorer: - Aggressivitetsvariabelns nuvarande vrde. Denna slumpas vid initieringen av en PSF och pavefkas av nistan allting. - Nrhet till det adra skeppet - Koefficient i Antipatiarrayen (som berittar om olika typer trivs ihop) - Kvarvarande brinsle - Vilka fragor man stller pa radion (diplomati etc) - Hur starkt det andra skeppet verkar vara relativt sett - Hur lang tid som gr - Aggressivitet hos det andra skeppet - Om det andra skeppet appnar eld eller anvnder annat vald (Traktorstralar) - Hur stora skador man har ftt (vardet av skadevariabeln) Ett skepps inre status sammanfattas i ett fatal variabler som slumpas vid uppstart och farndras gradvis vid interaktion med andra. PSf far dessa variabler skall finnas i SDF. En del vaiabler blir vardelasa far PS. Skeppstypen (VarJe fil gller alltsa far en skeppstyp) bestmmer vilka PSF som skall anvndas f6r alla parametrar. - Massa. Paverkr acceleration och man8verbarhet. - Motorstyrka. Paverkar acceleration och man6verbarhet. Hoppmotortyp. Pvekar hoppma6verbarheten. ELdstyrk. Anger hur mycket kraft man kan lgg i sina skott. Datorkpcitet. En integer som sammanfattar hrd och mukvara. Pverkar precisionen hos hoppen och precisionen hos skotten. Besittningstyp. Anvinds f6r uppslaging i Antipatiarryen. Konservatism. En sammanfattande term f6r hur ltt man kan paverka en NPS att skaffa sig andra ml in de ursprungliga. Constitution. Anger hur mycket defensiv bevpning mn har (tex skaldar). Moral - Om man har varit ute lnge eller slagits mycket ir stimningen, sammanhllninge och stridslusten p ett skepp dalig. De ger littare upp. Skadegrad. Berittar hur mycket stryk man ftt. Ages 0-99. Om man fr O r man en hag skrot som driver omkring. Under 50% kan man inte man8vrera. Unde 20% kan man inte reprer sig silv utan beh6ver assistans utifrn. Under 10 ir man d8d. (Detta kan vrier. Det skall implementeras tabelldrivet) Aggressivitet. En sammanfattande variabel som bero pa en massa annt. Det ir i huvudsak denna som bestimmer om en fiende angriper eller inte. Charisma. Ytterligre e antipativariabel. Pverkar HAL. Destination. NPS firds mot sitt mal med lmplig strategi utan att krocka med stirnor, baser elle planeter. Detta berknas vid skapandetillfllet och beh6ver direfter vildigt lite cpu-tid f att underhalls. Nir ett NPS nar sin destination finns tva alternativ - antingen f6strs det da det antogs att det var ett skepp p en one-shot tripp och det har landat p obestimd tid. Eller ocksa gar skeppet p en fast rutt och vnder efter en viss delay och b8rar ka tillbaka. Vanligt far handelsskepp. - En del varibler gar inte som uttrycka som enkla integers: Utseende p hgupplasande radar. Ka vara diffus om man lgger ut radrst8rningar. Burkade svar pa radiomeddelnade. Dessa haf sidoeffekter pa ndra vriabler, som tex aggressivitetsnivn. Namn p instnser v skeppet. 1 SDF finns uppgift om hur mnga skepp av denna typ som existefar i universum totlt och vd de heter (Samtliga!). Vid instansieringen (skapandet av ett skepp) tar man ett namn som inte anvndes fr tillfllet. Om alla nmn r upptagna fr man bra om. Radiotrfiken hanteras med ngot som ser ut som en COND-klausul i Lisp Syntaxen ser ut som Trigger1 (messagel)(message2)(message3) Trigger2 Triggef3 (message4)messageS) dr triggern r antingen ett nyckelord (i radiotrafik) ur mingden dentify! - Ber om identifikationssignal fdr skeppet (namn och typ) Who are you? - Ber besttningen beritta vilka de r Your Mission? - Vad har i faf rende? Surrender! - 6e upp striden! Abandon Ship! - Ga i livbatara Vi skall spfga skeppet! Dock! - Docka med oss (Ffivilligt ellef ofrivilligt) eller en konditio, tex (Aggressivity > 50) Take this, You bastards! aaggressivity = 75;aattack; (Kommandon i text (far sidoeffekter) faregas av 2') Haningen av aggressivity till 75 garantera att ma slass en gd stund Observera den averliggande strukturen pa allting Ett ftal variabler (enkla integers) bestammer skeppets uppfarande Dessa kan ndras dynamiskt av andra variabler och yttre paverkan Algoritmerna far att fatta besluten blir rttframma och lttberknade De variabler som inte r integers inehaller "noise" - info som ite avdes annat n nr ett NPS mater ett PS Denna info behver u inte kopieras till vare instas utan tages diekt ffn beskivningsfilen nar den behavs Christe Bickstam - Enligt tidigare diskussioner har vi funnit att antalet sysslo- ombord p ett rymdskepp ar ganska stot De befattningar som nmnts ir tex Beflhavare, Eldledre, Navigatar, Radaropeata, Radiooperata, Maskinist och Datooperat6r ("hacker"). P got sitt mste vi alltsa se till tt mn kn skdt ett rymdskepp med en liten crew (extrem- fall, en man). Variante att varje cew membe fa- flera sysslor r kappast lyckad i nagon starre utstrckning eftersom varje syssla mste vara tillrckligt krvande far en man p "heltid". De f6rslag jg har, r att en liten crew far: i. Om den inte har goda finanser: Ett litet skepp som inte r Sa avancerat. Det kan tex. sakna avancerad radar, radio och navigationsutrusting, varfar dessa sysslor med f6rdel kan sk8tas av en man. Naturligtvis vore det ocksa mycket osut att under dfift programmer om den lilla opalitliga HAL som finns i ett dylikt skepp. 2. Om den har hyfsade (ls goda) finanser: Ett skepp med de flesta sysslor automatiseade. Navigatio och radar- tracking r givetvis helautomatisk och kan sk6tas av tex. beflhavaren. Maskinerna har givetvis ocksa helautomatisk 6vervakning. Hir f61jer nagra vaga farslag om vad olika crew membes pJ ett stort skepp. Beflhavare: Styr skeppet och bar kanske ocksJ vara BEFLHAVARE i dess egentliga mening. Navigat6r: Lgger upp kurser och beriknr koordinater at Befilhavaren. Det r r navigatarens sak att se till att vi inte hamnar i en stjrna. Radaroperat: Sk6ter radrn dvs skter om radartraoking pa UFO:n och fars8ker avgara vad dessa ir far ngot. Radiooperat6r: Anropar baser f6re ankomst, rapporterar till sitt Space Control Center, ta emot nadrop mm. R har ocksa till uppgift att via radio f6rska identifiera UFO:n. Eldledare: Leker pang-pang! Maskinist: Ansvrar fr skeppets maskiner. Han ska ha mlighet att averbelasta reaktorn (med uppebaa risker) vid stora energibehov (tex. Skald och eldstrid samtidigt). Han skater ooks kraftskald och traktorstrale, d dessa enormt energikrvande. M b8r ocksa f6rbereda energiresurser fare hyperymdsprng. Utaver detta det ocksa maskinisten som fJr alla meddelanden om skador och som ansvarar far reparation. Datoroperatar: Skater HAL samt skriver program och macros pa avriga crew members' begran. En medelstor crew bar nog klara alla dessa sysslor genom dubbelarbete.