Nekromanti Use cases i rollspelsdesign

[Krille]

På vägen till jobbet så funderade jag i vanlig ordning på Västmarks trolldomssystem, och kom fram till att vad jag egentligen vill ha är ett antal situationer och ett system som stödjer dessa. Så jag började fundera i banorna use cases, användningsfall, något som är tokvanligt i mjukvarudesign. I princip så utgår man från att någon vill ha något gjort, och skriver ner ett exempel på någon som vill ha detta något gjort. Utifrån det modellerar man och designar mjukvaran.

Det här är en jefligt vettig filosofi, och den har säkert använts undermedvetet i rollspelsdesign också. Oftast är det dock i form av "jag vill ha en regel för kavallerichock", eller "jag vill ha en regel för blödning", och det är mer på kravspeclistan än ett use case. Ett av de bättre use case-liknande fallen jag har sett är Marcos gamla Noir-tråd, Det kom bloood ur Mordekai, som nästan låter som ett use case om man sammanfattar det:

"Mordekai är en stenhård och rätt otrevlig typ som har blivit skjuten. Mordekai har tidigare erfarit system där blödning är ett sätt att bestraffa spelaren. Han vill ha ett system där han kan blöda på ett coolt och genreriktigt sätt."

Det viktiga när man börjar formulera ett use case är att behandla själva systemet eller regeln som en svart låda, och sätter upp ett scenario runt omkring som beskriver vem som vill använda det, i vilken situation han vill använda det, och vad han förväntar sig för resultat, detta med ett språk som är så fritt från teknisk jargong (inklusive regelhänvisningar) som möjligt. Detta leder till vad som kallas för en brief eller casual business use case. Det kan expanderas om man vill, men jag är inte säker på att det är nödvändigt.

Fördelen med ett use case är att man, utan att skriva själva regeln, kan se om den passar in i spelet som man håller på att skriva. Beslutar man sig för att skriva regeln så har man dessutom fått en specifikation på hur regeln förväntas uppföra sig i spel. Man behöver så att säga bara fylla i den svarta lådan, och man kan enkelt testa den svarta lådan så att den faktiskt ger det förväntade resultatet. Det gör också att det blir lättare att undvika att "slentrianskriva" regler som "alltid har funnits med".

 

[Gardener]

Roleplaying Design Patterns och nu use cases... Det här börjar ju kännas som jobb. Det rinner use cases ur öronen på mig just nu sen jag definierat upp ett komplett system precis. Rollspel ska ju vara för att få bort tankarna från jobb! =]

Men det är helt klart en vettig tanke, och likt systemutveckling så blir det nog en klar förbättring om än lite segare utvecklingstakt om man orkar utföra det.

Ska det skapas systemsekvensdiagram för initiav också?

 

[Krille]

Jag kan nog tänka mig att use cases kan snabba upp designprocessen, i och med att man tar reda på vad man vill ha och sedan gör det, snarare än att göra något och sen se om man vill ha det genom speltest. Jag vet inte hur många gånger jag har skrotat rollspel och system som jag har skrivit på efter att i efterhand upptäckt att de inte ger mig vad jag vill ha. Jag har helt enkelt inte plockat fram vettiga use cases tidigare, utan slentrianskrivit och hoppats att de passar.

 

[Gardener]

Det räknade jag in som att slutprodukten blir bättre, inte att utvecklandet tar kortare tid.

Ska man jämföra med en utvecklingsmetod som vattenfallsmodellen, så att man inte upptäcker felen förrän i slutet så tar det ju definitivt mycket längre utan use cases.

Men jämför man det med en agil iterativ process, där man förhoppnings skulle upptäckt problemet långt tidigare så blir det skillnad. Då ser jag use cases mer som en förbättring av kvaliteten än som en uppsnabbning av arbetet (eftersom den uppsnabbningen redan är gjord, så att säga).

 

[Björn Wärmedal]

Kan det bli problem med use cases också? Om man har krav på vad man vill ha, och utvecklar en regel för en situation, kan det då hända att det blir en alldeles för specifik och begränsad regel? Så att man till slut hamnar med en regel för varje use case, dvs en helt unik regel för varje situation?

 

[Brynolf]

Det låter rimligt, men då får man väl skapa ett övergripande use case som säger att systemet ska vara strömlinjeformat på ett snyggt sätt.

Mycket prat om svarta lådor och casar... =)

 

[Krille]

Det problemet tror jag mest uppstår om man inte utvärderar sina use cases ordentligt innan man skriver reglerna. Slänger man sig på ett use case direkt efter att det är skrivet, då tror jag att man bäddar för problem. Samlar man use cases på hög, utvärderar dem i lugn och ro och grupperar ihop dem, så tror jag inte att problemet uppstår.

 

[Gardener]

Det är en bra sak att tänka på. Use Cases ska inte ha en till en-relation med regler. Det är snarare situationer, som kan ge upphov till flera lösningar eller helt enkelt utnyttja/utöka befintliga.

Man bör också rita upp diagram över hur alla use cases hänger ihop, vilka innebördes relationer dom har. Då blir det lättare att följa vilka use cases som kan utnyttja samma regler och vilka som borde ge upphov till nya delar.

Sen när man bygger den underliggande strukturen (dvs reglerna), så utgår man från use cases och bygger upp en struktur över vilka regler som behövs för att implementera alla use cases. När man sen vet vilka regler som behövs så är det bara att fylla i själva mekaniken.

Man får också automatiskt en fin lista över vilka regelexempel man kan skriva (och de är i stort sett redan färdiga, bara att fylla ut med regeldata, mer eller mindre). Och hur olika delar i systemet ska testas.

Tycker det verkar vara en lysande idé för att bygga spelsystem. Nästan så jag blir lite intresserad av att skriva något nytt bara för att testa det.

 

[Gurgeh]

Jag har ofta haft det här tänket i bakhuvudet, men inte använt det på ett organiserat sätt. Framför allt är det två scener som jag har velat att mina regler ska kunna återskapa:

1) Scenen från Books of Magic #2 där John Constantine håller ett helt rum med onda magiker i schack bara genom att stå och se nonchalant ut.

2) Scenen från Ivanhoe där Brian de Bois-Guilbert kidnappar Rebecca och den skadade Ivanhoe inte kan göra mycket åt saken annat än att ligga och tycka synd om sig själv.

Däremot kan jag väl inte påstå att jag lyckats, men att ha ambitionen att kunna återskapa de nämnda scenerna får väl räknas som en halv seger.

/tobias

 

[Krille]

Man får också automatiskt en fin lista över vilka regelexempel man kan skriva (och de är i stort sett redan färdiga, bara att fylla ut med regeldata, mer eller mindre). Och hur olika delar i systemet ska testas.

Mycket bra poäng. Den tankelinjen hade jag snuddat vid men inte fullföljt, utan bara sprungit förbi. Tack för att du formulerade den åt mig.

 

[Krille]

Use cases i praktiken

• Vart och en av casen verkar vara rätt kompetenta rollpersoner.
• Vi har några områden som rollpersonerna vill vara kompetenta inom, som kan skickas vidare till färdighetsdesignen.
• Det bör finnas subsystem för handel, strid, sjöresor, landresor, trolldom och heliga förmågor. Sjö- och landresor kan betraktas som ett specialfall av resor, och trolldom och heliga förmågor skulle kunna slås ihop till ett system för övernaturligheter.
• Sociala motsättningar (kvinnor kontra vissa yrkesverksamheter, gamla traditioner mot den nya tron, frestelser och otillåtna handlingar) bör finnas med.

 

[Man Mountainman]

Re: Use cases i praktiken

Så din idé går ut på att man ska fråga en massa andra miffon vad dom vill göra i ens spel?

Vad är det för sätt att angripa speldesign? Publikfireri! Populism! Sell-out!

 

[Krille]

Re: Use cases i praktiken

De andra miffona kan vara som Mållgan om du vill - namngivna aspekter av ens eget högst vimsiga sinne. De kan också vara folk som vill spela ditt spel, eller som du lurar att speltesta - eller för den delen du själv. Namnen finns mest där som etikett så att man vet vad man talar om.

Edit: Det heter ju trots allt "use case", användningsfall; inte "user case", användarfall. Vem användaren egentligen är spelar föga roll - det viktiga är användningen.

 

[Ram]

Fällorna med Use case metodik samt beröm

Strålande tråd! Mycket intressant designgrepp.

Det finns ett antal designfällor som man ofta kommer till när man utvecklar programvara med hjälp av Use cases. Jag vet inte om de är applicerbara här egentligen, men jag berör dem lite ändå bara för att.

Ett Use case används programmatiskt idealt till att lösa ett enkelt problem och en enkel hantering. De klassiska exemplet brukar oftast vara en läskautomat. Problem uppstår när man får prestandaproblem eller resurskonkurensproblem. Use case-design utan ett robust underliggande system leder ofta till problem sent i utvecklingen då fall som verkar orelaterade plötsligt relateras via resurskonflikter. Därtill är det också ett problem att man i Use case design fokuserar så hårt på att lösa sina Use cases att man inte tar hänsyn till den ökade komplexitet som det fallet tillför.

Så, det om det.

I övrigt tycker jag att det är en briljant verifikationsmetod om inte annat. Men hur säkrar man "resten" om man använder det som desigmetod? Eller är tanken att de fall som inte täcks in av Use cases skall vara oviktiga? Det kommer att ställa rejäla krav på use cases. Det bästa är nog att använda det som en del-designmetod.

 

[Gardener]

Re: Fällorna med Use case metodik samt beröm

Håller med om att man bör hålla koll på att man inte bygger in för stor komplexitet bara för att tvinga ett till use case. Då bör man kanske snarare tänka igenom om det use caset behövs, eller om det kan skrivas om.


Man utgår från use cases för att hitta hur den underliggande strukturen ska vara. Man kodar ju inte en funktion per use case så att säga.

För att applicera det på rollspelsutveckling så betyder det att när man har alla use cases så måste man ju gruppera dem och se vilka designlösningar som bäst löser alla fallen. Här kan man till exempel ta hjälp av Roleplaying Design Patterns för att hitta vilka olika system som bäst passar in på det man vill åstadkomma. Fall som verkar lika kan använda samma regler, dvs man har generiska regler som funkar för flera fall. Jag tror till och med att när det gäller rollspelsregler så bör man tänka efter väldigt noga om en regel bara används i ett enda use case. Är det något som verkligen behövs då?

För att hitta vilka regler som behövs för ett use case så skriver man ett komplett use case. Där går man igenom hela flödet och beskriver vad som utförs av systemet och vad som utförs av aktören. Detta görs fortfarande utan tekniska termer eller referenser till specifika lösningar. Detta behövs inte göras för alla use cases, men det bör finnas minst ett för varje skiljd del av systemet. Genom att gå igenom use cases mer detaljerat så kan man se exakt vilka regler som behövs för att utföra allting i use caset. Sen när man har gått igenom alla use cases så har man en samling regler som behövs. Därefter kan man gå igenom dessa och avgöra hur de ska delas upp, vilka som är samma eller i stort sett samm osc.

Det går även att referera till andra use cases, för att visa att det ska utföras som en del av ett annat. Ett typiskt sådant skulle kunna vara konfliktresolution, som man kanske vill ska vara lika genom hela systemet.

 

[Krille]

Mer praktik

• Skulle någons själ tas så vill Svava kunna stärka personens livskraft så att kroppen fortfarande lever när själen återvänder.
• Svava vill kunna föra den sjuke in på andeplanet för att finna sin själ, och sedan leda denne tillbaka när själen är funnen.
• Svava vill själv kunna vandra in på andeplanet och hjälpa sina kamrater därifrån, och det utan att det bryter spelmötet för ett "separat cyberspejsspelpass".