Nekromanti Programmera en fisktanksgenerator

[Rickard]

Jag lägger det här i makarforumet då det handlar om att skriva ett scenario.

Något jag har funderat på länge, men inte har haft kunskapen att göra, är att skapa en fisktanksgenerator.

Förfrågan
Det jag söker efter är någon programmerare som har kunskapen att göra detta. Det jag tänker mig är någonting som fungerar likt Sagas bygenerator och visar relationskartor likt det här:


Funktion
Generatorn ska slumpa ut fraktioner: händelser, föremål och personer/grupperingar
Generatorn ska binda samman dessa med streck (eller pilar), där varje pil ska bli förklarad hur ena fraktionen hänger samman med den andra. Detta är en relation.
Generatorn ska ge upphov till inspiration till scenarion. Användaren själv ska få fylla i luckor genom att förklara hur vissa av relationerna artar sig.

Kravlista
Onlinegenerator
Kunna visa fraktioner och dess relationer.
Relationskartan som genereras ska vara övergriplig, alltså inga fraktioner ligger för nära varandra och inga relationer ska (helst) överlappa andra relationer eller fraktioner.

Funktioner
Lista med händelser.
Lista med föremål.
Lista med personer/grupperingar.
Lista med relationer för händelser?
Lista med relationer för föremål.
Lista med relationer för personer/grupperingar.
Visa dessa i en relationskarta på ett sätt som är överskådligt.

Tillägg
Kunna utöka generatorn genom att föreslå fraktioner/relationer. Möjligtvis via en wiki.
Lista med övernaturliga saker.
Lista med rollspelsspecifika saker.
Val att kunna inkludera dessa två punkter ovan.
Val hur många händelser det ska förekomma.
Val hur många fraktioner det ska förekomma, dock minst 3.
Val hur stor procents chans det är att en fraktion är ett föremål.
Ha en enkel och avancerad version. Den enkla ser ut som Sagageneratorn medan den avancerade har massor av specialval som redan listats här ovan.
Generatorn skapar en wikisida som visar en relationskarta, där folk får gå in och skriva mer om relationskartan.
Möjlighet att välja den färg och form som relationer och fraktioner får på relationskartan.
Personer som får attribut, alltså några ord som beskriver personen.
Möjlighet för användaren att skriva in viktiga fraktioner som då kommer få fler relationer tilldelade sig och därmed blir viktigare i scenariot.

Det är inte meningen att tilläggen måste vara med men det någonting man kan hålla i huvudet för framtida versioner.

/Han som tycker det här vore en awesome generator och kan tänka sig att betala med ett Matiné-exemplar till de inblandade

[EDIT] Versionsändringar:
Lade till attribut sist till listan.
Delade upp relationer i flera delar.
Lade till i Tillägg Möjlighet för användaren att skriva in viktiga fraktioner.
Lade till i Funktion att användaren ska fylla i med förklaringar i fisktanken.
Tog bort tillägget att man ska välja hur många relationer någonting minst/max får ha.
Lade till i första Tillägget att en wiki kan användas för att föreslå fraktioner och relationer.

 

[mcwolfe]

Har funderat på något liknande själv. Överlag är programmeringen inte så svårt för de olika delarna, med ett undantag. Utplaceringen av noderna och relationerna är riktigt svår att lösa matematiskt/automatiskt (åtminstone det lilla jag sysslat med det). Det går, men är inte helt lätt, särskilt inte med större lösningar (fast det är klart.. med någon pinning-funktion kanske det skulle kunna fungera.. att användaren får placera ut ett par noder, spika fast dem och sen klicka på "layout" eller så)

Ska klura lite på det

/McWolfe

 

[solvebring]

Förutom interfacet och det grafiska är det där inte så värst krångligt. Det som behövs är en slumpgenerator, mer eller mindre. Och en sådan kan t.o.m. jag fixa i Python om jag bara borstar av rosten och läser på lite igen. Jag sätt en del med generatorer för ett tag sedan och fick hjälp av krank att påbörja en rollpersons-gen. Det falnade dock pga. tidsbrist och ork. Med andra ord är generatorer pretty basic, om till och med jag fixar det. Hur som haver, det där är nog inte så speciellt krångligt att ordna. Därav hoppas jag att någon programmerare här ställer upp, för en sådan generator vore ju fetnajs.

Med andra ord kommer jag inte försöka även om jag skulle vilja försöka. Att jag försöker är nog mest slöseri med tid, eftersom jag egentligen inte vet vad ja gör. =) Och det finns ju trots allt en del folk här som vet vad de gör. En sådan generator vore hur som helst najs och det ska bli kul att se om det blir någon.

Hur som haver, jag tror att det verkliga problemet ligger i allt jobb att komma på nog med fraktioner att slumpa fram. Det behövs ju trots allt en hel del för att inte generatorn ska börja upprepa sig efter en tid. Om den sedan ska vara inställningsbar för olika settings blir det än mer jobb att ta hänsyn till det och försöka tillmötesgå dem alla.

 

[Unfair]

• Bagaren i staden (person)
• Smeden från granbyn (person)
• Kungen över landet (person)
• En adelsman från ett främmande land (person)
• En halt bonde (person)
• En tiggare (person)
• Hammare (föremål)
• Svärd (föremål)
• Skördefest (händelse)
• Midsommar (händelse)
• Bråk i hamnen (händelse)

 

[Snow]

Släng ett öga på detta:
http://www.graphviz.org/Gallery.php

Om någon känner sig manad kan man väldigt enkelt kunna generera koden, mata in den i graphviz och ploppa ut ett diagram.

Graphviz hjälper alltså till med den kluriga biten. Placering av noder och sånt. Vi kör den på jobbet för att generar tillståndsdiagram och det ser nästan exakt ut som din graf.

 

[Snow]

Förtydligande: Graphviz tar en textfil in som beskriver diagrammet. Ut kommer en bild.

Texten in kan se ut såhär:

<div class="ubbcode-block"><div class="ubbcode-header">Code:</div><div class="ubbcode-body ubbcode-pre" ><pre>
digraph finite_state_machine {
rankdir=LR;
size="8,5"
node [shape = doublecircle]; LR_0 LR_3 LR_4 LR_8;
node [shape = circle];
LR_0 -> LR_2 [ label = "SS(B)" ];
LR_0 -> LR_1 [ label = "SS(S)" ];
LR_1 -> LR_3 [ label = "S($end)" ];
LR_2 -> LR_6 [ label = "SS(b)" ];
LR_2 -> LR_5 [ label = "SS(a)" ];
LR_2 -> LR_4 [ label = "S(A)" ];
LR_5 -> LR_7 [ label = "S(b)" ];
LR_5 -> LR_5 [ label = "S(a)" ];
LR_6 -> LR_6 [ label = "S(b)" ];
LR_6 -> LR_5 [ label = "S(a)" ];
LR_7 -> LR_8 [ label = "S(b)" ];
LR_7 -> LR_5 [ label = "S(a)" ];
LR_8 -> LR_6 [ label = "S(b)" ];
LR_8 -> LR_5 [ label = "S(a)" ];
</pre></div></div>

Och ut kommer detta:
http://www.graphviz.org/content/fsm

 

[Rickard]

Graphviz hjälper alltså till med den kluriga biten. Placering av noder och sånt. Vi kör den på jobbet för att generar tillståndsdiagram och det ser nästan exakt ut som din graf.

Ja, för det är ju det som är det svåra. Det är just den grafiska presentationen som ligger över min programmeringsförmåga. Fast menar du att sno koden därifrån eller vad? För jag såg inte att det var en onlinegenerator.

/Han som såg att ER-diagram fanns på den sidan, vilket han rippade rakt av när han formade sin fisktankspresentation

 

[Snow]

Jag tänkte mig att man laddar hem programmet och sen bara anropar det från sitt eget program. Så man får själv lägga det online.

 

[Tony.Meijer]

Det här är inte menat som ett nego-inlägg, men du är medveten om att det här inte är ett trivialt problem? Som i att det här är ett jättesvårt problem att lösa programatiskt.

Problemet är att varje nod i ditt träd kommer att ha underliggande states, vilket kommer att göra det svårt att skapa relationer mellan dem (individer som är döda som är ihop med folk exempelvis).

Jag gissar på att för att skapa ett bra fungerande system så behövs åtminstone ett par tre månader heltid i utvecklingstid av en medelkompetent kodare.

 

[Ram]

Tror du...?

Asså, den största utmaningen är att skapa den databas som bör utgöra underlag till det hela. Den behöver lämpliga fält för att kontrollera begränsningar för beroenden (så att Stulen spira inte kan få relationen Kärlek till En stor vit katt). Jag tror man kan klara sig rätt bra med... säg tio begränsande fält? Något miljöfält, en handfull typfält och lika många vetofält? Eller kanske bara sätta upp lite fler databaser från början...?

Det grafiska borde vara hyfsat hanterbart. Det finns mängder med state machine-visualiseringsverktyg därute och flera är open source. Ett sådant har redan länkats till i den här tråden.

Med dem på plats så borde inte generatormjukvaran vara jättekomplex. Ett par tre styrklasser, någon för att hantera beroenden, lite slump och något som genererar output till visualiseringen.

Systematiserar man bara databasen/baserna bra så är 70% av jobbet gjort. Den kommer inte att kunna generera så komplexa och tillrättalagda beroenden som i Hans exempel, det kräver nog betydligt mer (såsom i mer jobb än det är värt), men de borde kunna generera rätt balla fisktankar rakt upp och ned tror jag. Om inte annat så är väl eventuella sneda beroenden endera charmiga eller en anledning att generera om...

Eller?

 

[solvebring]

Jag kom just att undra över en sak. Det här med spelledande och scenarion och dylika. Gillar vi inte just den kreativa delen, att få skapa? Det gillar jag i alla fall, och du själv Han verkar minst sagt vara en kreativ person med flera järn i elden. ... Så, jag antar att du inte egentligen tänkt att använda generatorn så mycket för egen del? Att generera småsaker som byar, utrustning och det är en sak, fast vill man inte egentligen pilla med scenarion för egen maskin?

... Jag menar, vad är egentligen problemet med att t.ex. göra på det viset som du gör nu?

... undrar solvebring som mest är glatt nyfiken.

 

[Tony.Meijer]

Tror du...?

Asså, den största utmaningen är att skapa den databas som bör utgöra underlag till det hela. Den behöver lämpliga fält för att kontrollera begränsningar för beroenden (så att Stulen spira inte kan få relationen Kärlek till En stor vit katt). Jag tror man kan klara sig rätt bra med... säg tio begränsande fält? Något miljöfält, en handfull typfält och lika många vetofält? Eller kanske bara sätta upp lite fler databaser från början...?

Det grafiska borde vara hyfsat hanterbart. Det finns mängder med state machine-visualiseringsverktyg därute och flera är open source. Ett sådant har redan länkats till i den här tråden.

Med dem på plats så borde inte generatormjukvaran vara jättekomplex. Ett par tre styrklasser, någon för att hantera beroenden, lite slump och något som genererar output till visualiseringen.

Systematiserar man bara databasen/baserna bra så är 70% av jobbet gjort. Den kommer inte att kunna generera så komplexa och tillrättalagda beroenden som i Hans exempel, det kräver nog betydligt mer (såsom i mer jobb än det är värt), men de borde kunna generera rätt balla fisktankar rakt upp och ned tror jag. Om inte annat så är väl eventuella sneda beroenden endera charmiga eller en anledning att generera om...

Eller?

Säg att du vill ändra något i det här, säg lägga in en ny grupp av objekt och beroenden till ett par tre andra grupper av objekt, hur gör du då? Jo, du måste lägga in det här i modellen vilket kommer att kräva att du gör om styrklassen. Nå, när du har tio grupper av objekt så måste du nu alltså lägga in tjugp olika beroenden (tio för den nya gruppen och tio för de gamla, de flesta kommer visserligen att vara går inte men ändå).

Du kan ju göra det via databasen, men då får du en helt annan uppsättning problem i hur du bygger upp dina databastabeller och när dessa tar slut (som i att din gissning inte räckte utan du är tvungen att lägga till ett nytt fält) är du rökt för när du börjar fippla med det så ber du om problem.

Den enda rimliga lösningen som jag ser är att varje objekttyp håller de relationer den kan kopplas till internt och att när du genererar ditt träd utgår du ifrån en eller ett par centrala spelare och slumpar ut vilka noder som kan vara kopplade till den och sedermera vilka noder som kan vara kopplade till de noderna. Men det betyder, förutsatt att du vill ha en skallbar och rimlig lösning där folk kan lägga till material själv, att du måste göra en egen motor för det här med en grupp klasser, dvs gissningsvis två till tre månader heltid för att få allt att fungera.

Visst, du kanske, och det är ett stort kanske, kan göra en oflexibel och stel variant snabbare, men den kommer inte att skala och så fort någon inser att det här funkar inte, vi vill ha det så här istället, då är det bara att kasta ut din lösning och börja om. Detta gäller SPECIELT om du använder något så stelt som en databas när du designar ditt system.

För att avsluta ur ett positivt perspektiv, så vet jag att det kan göras, men det kräver en hel del jobb

 

[Rickard]

Så, jag antar att du inte egentligen tänkt att använda generatorn så mycket för egen del? Att generera småsaker som byar, utrustning och det är en sak, fast vill man inte egentligen pilla med scenarion för egen maskin?

... Jag menar, vad är egentligen problemet med att t.ex. göra på det viset som du gör nu?

Av följande anledning:

"Ville bara säga att den här tråden/artikeln var så inspirerande att jag satte mig ned och testade. Det funkade fint, även om MITT problem är att jag nog inte riktigt får till lika bra grundstoff som du eller Rising. Jag tenderar att fastna i klichéer."
-- Basenanji, från följande inlägg

/Han som alltid tycker det är bra att få äventyrsfrön som får en att tänka i nya banor, exempelvis hur man kan förklara att en Stulen spira har relationen Kärlek till En stor vit katt

 

[solvebring]

Fair enough, eller ja, väldigt enough. Låter som en helt klart vettig anledning, och förövrigt har nog Basenanji en mycket bra poäng. Det blir nog väldigt ofta så att man skapar klichéer och i princip aldrig stiger ur lådan. Det sker av sig själv på något vis. Frågan är huruvida det är medvetet eller undermedvetet. Möjligen är det nog kanske för att en kliché känns trygg på något sätt - eller för att klichén är bekant och det undermedvetna tar den stig som det vandrat förut.
... Fast nu är jag inne på något helt annat. Tack för svaret i alla fall. Det stillade min nyfikenhet. Jag trodde nästan att du faktiskt mest ville få detta programmerat bara för att det går. =)

 

[Snow]

Lösningen är antagligen inte att försöka programmera "Det kompletta systemet" från början. Snarare gör man något så enkelt som möjligt, som, utifrån en textfil med fraktioner och en med relationer mellan fraktioner, genererar en enkel graf. Kanske fungerar det alldeles utmärkt för ändamålet. De gånger man får upp saker som "Muterad hob älskar magisk ring" så väljer man om man vill trycka "Generera en annan fisktank" eller använda sin fantasi för hur det kan vara möjligt.

Om det inte fungerar så bra, men det kommer förslag på vad man ska förbättra, så har man både motivation och mål att arbeta mot.

 

[Ram]

Säg att du vill ändra något i det här, säg lägga in en ny grupp av objekt och beroenden till ett par tre andra grupper av objekt, hur gör du då? Jo, du måste lägga in det här i modellen vilket kommer att kräva att du gör om styrklassen. Nå, när du har tio grupper av objekt så måste du nu alltså lägga in tjugp olika beroenden (tio för den nya gruppen och tio för de gamla, de flesta kommer visserligen att vara går inte men ändå).

Det är därför man använder vetoklasser. Det är de som sätter begränsningarna mellan typer och fält och de är betydligt mer flexibla än att hårdkoda dem i huvudklassen eller i databasen. De kommer mao att verifiera om det framgenererade beroendet håller. Vetoklasserna kommer att operera i första hand på typerna.

Sedan så tror jag att man har en gigantisk vinst i att verkligen arbeta igenom databasen innan man får för sig att börja koda. Den kommer att utgöra basen för alla möjligheter och problem som vi har. Jag håller med dig helt om att vi får ett saftigt merjobb om vi måste designa om den i någon högre utsträckning.

Sedan som sagt, då får man en "good enough"-emulator.

 

[Tony.Meijer]

Du är välkommen att försöka och blir du klar snabbare så är jag den första att gratulera

 

[Snow]

Första vettiga outputten från mitt program. Programmeringstid hittils: 1.5h.

Jag har som synes ingen indelning mellan saker, platser, personer och händelser och vilka relationer som kan existera mellan dem. Allt kommer i en enda stor lista. Givetvis väldigt långt från vad du frågade efter Han.

Om någon undrar, anledningen att jag inte använder svenska tecken var att sajten jag använde för att göra diagrammet inte tålde det. Tror jag. Eller så var det minustecken. Jag orkade inte kolla så noga.

 

[Snow]

Eller den här:

 

[Ram]

Mmm. Det är en intressant utmaning helt klart. Vilka databaser vill man ha och vilka fält?