Bryter ut detta från .
Kommer prata om saker som har pratats om i [url=https://www.rollspel.nu/threads/68665 Interaction & Purpose[/url]–tråden men jag tyckte den tråden urartade rätt snabbt med sammanblandning av Fate Points och XP osv. Jag väljer att dra igång en ny kula för detta!
OK, som vanligt nu Rickard är jag lite rädd för att argumentera mot dig. Tycker du är en fantastisk pedagog som brinner för samma aspekt av rollspelande som jag: att förstå & lära ut hur dom egentligen funkar. Och du gör ett otroligt jobb på det här och på andra forum.
Det sagt så har jag något att säga om detta ämne. Det kommer bli långt så på med säkerhetsbältena folks!
Ska ge lite exempel:
När man skapar eller finslipar en speldesign är det alltid viktigt att tänka “kan jag göra den här funktionen mer direkt istället för att använda en sidovaluta eller en sidoresurs?” Ibland blir spelet mer elegent och direkt och snyggare och bättre genom att göra det mer direkt. Hex hade inte varit i närheten av att vara lika elegant om det hade använt “blockpoäng”.
Men Go använder sina poäng för att göra själva spelandet mer elegant och smidigt. Det är först i slutet som man verkligen behöver räkna ut poängen (det är bra strategi att ha koll på poängen medan man spelar, men rent praktiskt/regelmässigt hänger spelandet inte på det).
Ska dra en liknelse från programmeringens värld.
Inline method vs Extract method.
Inline method är detta. Man gör om:
till
Medan Extract method är det direkt motsatta, ex gör man om:
till:
Det är lätt att se en av dessa två och tänka “wow, det är ju ursnyggt, ursmart, urelegant, den ska jag alltid använda” osv osv. Men skenet bedrar. Dom har fördelar och nackdelar.
(Ordlista: Semanticitet: “att saker bär mycket mening”, roten “sem” handlar ofta om “mening”, “betydelse”, “innebörd” i ord som polysem, semantik, semiotik osv)
Extract Method skapar semanticitet i koden som, om semanticiteten var oklar, gör den lättare att förstå för människor. Det är också ibland rent praktiskt elegantare för om den extraherade metoden ska användas på flera ställen kan den nu göra det på ett konkret sätt.
Ska ge ett exempel på Extract Method i rollspelsdesign.
Säg att det finns lite olika sätt att levla upp sin rollperson. Du kan skriva ett brev. Eller du kan baka två kakor (i spelvärlden med hjälp av din cakebaker-skill). Eller du kan döda tolv monster. Eller du kan hitta en skatt på minst 1800 kr.
Det finns då, ibland, ett syfte att lägga in en indirekt/abstrakt resurs såsom erfarenhetspoäng för att hantera det. Att skriva ett brev ger dig 1800 xp, att baka en kaka ger dig 900 xp, att döda ett monster ger dig 150 xp, att hitta en kr ger dig 1 xp. Ibland löser detta tänkande designproblem och ibland skapar det bara mer problem. Man får använda det med eftertanke och avsikt och ABT (always be testing) alternativet.
Du extraherar “levla om du har si”-funktionen till en grej: Levla genom att betala xp.
Inline Method är också jättebra. När designern gör om “Skriv brev för att få xp” + “Betala xp för att få level” till “Skriv brev för att få level” är det ett bruk av Inline Method.
Ett annat mer skolexempel är spelfas-systemet i D&D.
I B/X:
“En spelfas är tio minuter” + “Att göra [si och så mycket saker] tar en spelfas” + “Var [antal] spelfas händer [olika saker]”
I femman:
“Att göra [si och så mycket saker] tar tio minuter” + “Var [antal × 10] minut händer [olika saker]”
(Ordlista: Adjudicera: göra en regelbedömning efter eget huvud men med hjälp av spelets verktyg)
Fördelar:
Nackdelar
Konkreta semantiska enheter är något vår hjärna [URL="https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf"]använder hela tiden. Det gör det så sjukt mkt enklare att tänka utzoomat och korskoppla ihop begrepp på nya och oväntade sätt. Om jag vet att en viss prepteknik kallas “fisktank” och har namnet “fisktank” så blir det så mkt smidigare än om jag ska behöva återuppfinna “SLP:er med agendor, hemligheter, laddade relationer” varje gång. Redan den beskrivningen använder en massa konkreta semantiska enheter.
SLP:
jag har en begrepp om vad en spelledarperson är, hur dom kan skapas, användas och gestaltas.
Agenda:
jag vet att SLP:n vill något, att dom har ett mål och det kan hjälpa mig gestalta dom och det gör dom mer intressanta att interagera med
Hemlighet:
Stöder upptäckarmomentet i rollspelsupplevelsen
Relation:
Inte bara A älskar B utan även kanske B hatar C, C vill hämnas på A osv.
Inline Method och Extract Method (finns även Inline Temp och Extract Variable som är exakt samma sak fast för data istället för kod) är verktyg som hjälper oss designers att tänka.
(Ordlista: implicit = något som inte sägs rent ut utan bara finns mellan raderna, explicit = något som är uttryckt direkt och konkret)
Ja, visst är det snyggt med koncisa, konkreta och direkta spel, såsom Magician. Men ibland kan att “dra ut” implicita begrepp till nya ord vara värt det. Nackdelen är att du får något abstrakt och konstigt (vad är en “slott”, en “xp”, en “hp” egentligen? det är flogiston och orgoner for all I care) men fördelen är att du får något hanterbart och explicit.
Du sätter ett “handtag” på begreppet.
Och ibland går är det en mycket smidigare designlösning. Patchwork utan knapparna… tja… kanske det… allt kostade bara timglas…? Det skulle bli ett mycket grundare och ointressantare spel!
Dags för lite Norman, Rams och Maro design basics:
Donald Normans bok The Design of Everyday Things har ett mischmasch av poänger men egentligen framförallt ett centralt budskap. Varje funktion på föremålet du designar ska ha en knapp. Att försöka göra att det ser enklare ut genom att ta bort knappar (“tryck tre gånger på pausknappen för att hoppa till nästa låt”) är dålig design.
Sidospår om hans bok
Att då extrahera en “metod” så här, det är att identifiera en vanlig funktion i spelet, och skapa en knapp åt den.
Och att inline:a en metod är då att identifiera att hoppsan, den här grejen görs bara vid ett enda tillfälle och då baka in den funktionen i en annan knapp. Såsom “hoppsan, besvärjelsestyrka är redan indirekt kopplat till hur avancerad koreanska som används, vi kan då lägga in dom i samma.” Bara för att vara tydlig: The Magician är bra design och ibland är inline method rätt.
Dieter Rams säger att bra design är så lite design som möjligt. Enkelhet och direkthet.
Men jag säger att verktyget ska matcha problemdomänen som verktyget ska användas på. Och komplicerade domäner behöver ibland lite mer semantiska enheter (lite mer “knappar” och “handtag”) för att bli lättbegripliga.
Och som alltid har vi Maro. “En produktdesigner gör en lampa som är lätt att tända och släcka. En speldesigner gör en lampa som är en utmaning att tända och släcka.” Knapp-ekonomin i Patchwork är den del av utmaningen i Patchwork.
Till alla dom som läste allt detta med öppet sinne: ???? fyra hjärtan får ni!!! äh jag slänger in två till: ??
Kommer prata om saker som har pratats om i [url=https://www.rollspel.nu/threads/68665 Interaction & Purpose[/url]–tråden men jag tyckte den tråden urartade rätt snabbt med sammanblandning av Fate Points och XP osv. Jag väljer att dra igång en ny kula för detta!
Helt rätt!!! Falle power in the CC hour!!Rickard;n245992 said:
OK, som vanligt nu Rickard är jag lite rädd för att argumentera mot dig. Tycker du är en fantastisk pedagog som brinner för samma aspekt av rollspelande som jag: att förstå & lära ut hur dom egentligen funkar. Och du gör ett otroligt jobb på det här och på andra forum.
Det sagt så har jag något att säga om detta ämne. Det kommer bli långt så på med säkerhetsbältena folks!
Har hittat äldre och äldre och äldre trådar på både WRNU och WRDÅ om detta från ffa dig Rickard men det jag alltid snubblar på är… det verkar finnas ett avskrivande av indirekthet i detta.Rickard;n245992 said:
Ska ge lite exempel:
- “skriva ett brev för att levla upp” vs “skriva ett brev för att få xp” + “använda xp för att få levla upp”.
- “säga besvärjelsen på mer avancerad koreanska för att få lägga mer avancerad besvärjelse” vs “säga besvärjelser på mer avancerad koreanska för att få xp” + “använda xp för att få lägga mer mer avancerad besvärjelse”
- “ta lappar för att få mer lappar” vs “ta lappar för att få knappar” + “använda knappar för att få mer lappar” [brädspelet Patchwork, använder det senare]
- “knyta för att blocka” vs “knyta för att få blockpoäng” + “använda blockpoängen för att få mer blockkraft” [brädspelet Hex, använder det första, det finns ingen “blockpoäng” i spelet]
- “lägga kort för att få lägga mer kort” vs “lägga landkort för att få mana” + “använda mana för att lägga besvärjelsekort” [kortspelet Magic, använder det senare]
- “lägga stenar på ett sätt som claimar mycket yta för att vinna” vs “lägga stenar på ett sätt som claimar mycket yta för få poäng” + “få mycket poäng för att vinna” [brädspelet Go, använder det senare]
När man skapar eller finslipar en speldesign är det alltid viktigt att tänka “kan jag göra den här funktionen mer direkt istället för att använda en sidovaluta eller en sidoresurs?” Ibland blir spelet mer elegent och direkt och snyggare och bättre genom att göra det mer direkt. Hex hade inte varit i närheten av att vara lika elegant om det hade använt “blockpoäng”.
Men Go använder sina poäng för att göra själva spelandet mer elegant och smidigt. Det är först i slutet som man verkligen behöver räkna ut poängen (det är bra strategi att ha koll på poängen medan man spelar, men rent praktiskt/regelmässigt hänger spelandet inte på det).
Ska dra en liknelse från programmeringens värld.
Inline method vs Extract method.
Inline method är detta. Man gör om:
Code:
int getRating() {
return (moreThanFiveLateDeliveries()) ? 2 : 1;
}
boolean moreThanFiveLateDeliveries() {
return _numberOfLateDeliveries > 5;
}
Code:
int getRating() {
return (_numberOfLateDeliveries > 5) ? 2 : 1;
}
Code:
void printOwing() {
printBanner();
//print details
System.out.println ("name: " + _name);
System.out.println ("amount " + getOutstanding());
}
Code:
void printOwing() {
printBanner();
printDetails(getOutstanding());
}
void printDetails (double outstanding) {
System.out.println ("name: " + _name);
System.out.println ("amount " + outstanding);
}(Ordlista: Semanticitet: “att saker bär mycket mening”, roten “sem” handlar ofta om “mening”, “betydelse”, “innebörd” i ord som polysem, semantik, semiotik osv)
Extract Method skapar semanticitet i koden som, om semanticiteten var oklar, gör den lättare att förstå för människor. Det är också ibland rent praktiskt elegantare för om den extraherade metoden ska användas på flera ställen kan den nu göra det på ett konkret sätt.
Ska ge ett exempel på Extract Method i rollspelsdesign.
Säg att det finns lite olika sätt att levla upp sin rollperson. Du kan skriva ett brev. Eller du kan baka två kakor (i spelvärlden med hjälp av din cakebaker-skill). Eller du kan döda tolv monster. Eller du kan hitta en skatt på minst 1800 kr.
Det finns då, ibland, ett syfte att lägga in en indirekt/abstrakt resurs såsom erfarenhetspoäng för att hantera det. Att skriva ett brev ger dig 1800 xp, att baka en kaka ger dig 900 xp, att döda ett monster ger dig 150 xp, att hitta en kr ger dig 1 xp. Ibland löser detta tänkande designproblem och ibland skapar det bara mer problem. Man får använda det med eftertanke och avsikt och ABT (always be testing) alternativet.
Du extraherar “levla om du har si”-funktionen till en grej: Levla genom att betala xp.
Inline Method är också jättebra. När designern gör om “Skriv brev för att få xp” + “Betala xp för att få level” till “Skriv brev för att få level” är det ett bruk av Inline Method.
Ett annat mer skolexempel är spelfas-systemet i D&D.
I B/X:
“En spelfas är tio minuter” + “Att göra [si och så mycket saker] tar en spelfas” + “Var [antal] spelfas händer [olika saker]”
I femman:
“Att göra [si och så mycket saker] tar tio minuter” + “Var [antal × 10] minut händer [olika saker]”
(Ordlista: Adjudicera: göra en regelbedömning efter eget huvud men med hjälp av spelets verktyg)
Fördelar:
- Du har en regelterm mindre att lära ut och att komma ihåg
- Spelet är mer direkt
- Reglerna kan skrivas kortare
- Reglerna kan vara mer flexibla, du kan göra saker efter 2 minuter också inte bara jämna intervall av 10
- Reglerna liknar naturligt språk mer och kan därför användas för att adjudicera mer oväntade situationer
Nackdelar
- Du har blivit av med en konkret semantisk enhet
Konkreta semantiska enheter är något vår hjärna [URL="https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf"]använder hela tiden. Det gör det så sjukt mkt enklare att tänka utzoomat och korskoppla ihop begrepp på nya och oväntade sätt. Om jag vet att en viss prepteknik kallas “fisktank” och har namnet “fisktank” så blir det så mkt smidigare än om jag ska behöva återuppfinna “SLP:er med agendor, hemligheter, laddade relationer” varje gång. Redan den beskrivningen använder en massa konkreta semantiska enheter.
SLP:
jag har en begrepp om vad en spelledarperson är, hur dom kan skapas, användas och gestaltas.
Agenda:
jag vet att SLP:n vill något, att dom har ett mål och det kan hjälpa mig gestalta dom och det gör dom mer intressanta att interagera med
Hemlighet:
Stöder upptäckarmomentet i rollspelsupplevelsen
Relation:
Inte bara A älskar B utan även kanske B hatar C, C vill hämnas på A osv.
Inline Method och Extract Method (finns även Inline Temp och Extract Variable som är exakt samma sak fast för data istället för kod) är verktyg som hjälper oss designers att tänka.
(Ordlista: implicit = något som inte sägs rent ut utan bara finns mellan raderna, explicit = något som är uttryckt direkt och konkret)
Ja, visst är det snyggt med koncisa, konkreta och direkta spel, såsom Magician. Men ibland kan att “dra ut” implicita begrepp till nya ord vara värt det. Nackdelen är att du får något abstrakt och konstigt (vad är en “slott”, en “xp”, en “hp” egentligen? det är flogiston och orgoner for all I care) men fördelen är att du får något hanterbart och explicit.
Du sätter ett “handtag” på begreppet.
Och ibland går är det en mycket smidigare designlösning. Patchwork utan knapparna… tja… kanske det… allt kostade bara timglas…? Det skulle bli ett mycket grundare och ointressantare spel!
Dags för lite Norman, Rams och Maro design basics:
Donald Normans bok The Design of Everyday Things har ett mischmasch av poänger men egentligen framförallt ett centralt budskap. Varje funktion på föremålet du designar ska ha en knapp. Att försöka göra att det ser enklare ut genom att ta bort knappar (“tryck tre gånger på pausknappen för att hoppa till nästa låt”) är dålig design.
Sidospår om hans bok
Ett av hans största cases har han helt fel kring. Vattenkranar. Han tycker det ska vara: en kran för kallt, en för varmt, så kan man blanda själv. Jag är uppvuxen med engreppsblandare, vilket Norman haaatar. Där är det en axel för hur mycket, en för temperatur. Det är alltså två funktioner, två “knappar”, dvs bra design. “Temperatur” är flum för det är en mekanism som styr den ist för att jag blandar själv, men, den abstraktionen behöver inte användaren veta. Dessutom är det ofräsch att hålla på och vrida på hårda kranar som folk har vridit på innan dom tvättade händerna.
Synd att en i stort otroligt bra bok ska förmörkas av han har fel i ett av sina huvudexempel
Synd att en i stort otroligt bra bok ska förmörkas av han har fel i ett av sina huvudexempel
Att då extrahera en “metod” så här, det är att identifiera en vanlig funktion i spelet, och skapa en knapp åt den.
Och att inline:a en metod är då att identifiera att hoppsan, den här grejen görs bara vid ett enda tillfälle och då baka in den funktionen i en annan knapp. Såsom “hoppsan, besvärjelsestyrka är redan indirekt kopplat till hur avancerad koreanska som används, vi kan då lägga in dom i samma.” Bara för att vara tydlig: The Magician är bra design och ibland är inline method rätt.
Dieter Rams säger att bra design är så lite design som möjligt. Enkelhet och direkthet.
Men jag säger att verktyget ska matcha problemdomänen som verktyget ska användas på. Och komplicerade domäner behöver ibland lite mer semantiska enheter (lite mer “knappar” och “handtag”) för att bli lättbegripliga.
Och som alltid har vi Maro. “En produktdesigner gör en lampa som är lätt att tända och släcka. En speldesigner gör en lampa som är en utmaning att tända och släcka.” Knapp-ekonomin i Patchwork är den del av utmaningen i Patchwork.
Till alla dom som läste allt detta med öppet sinne: ???? fyra hjärtan får ni!!! äh jag slänger in två till: ??
