Nekromanti Programmera en fisktanksgenerator

[krank]

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

<div>
</div> <div>Jag funderade på det där tidigare idag, och jag känner mig lite korkad. För inte kan det väl vara riktigt såhär lätt? </div> <div>
</div> <div>
</div> <div>Alltså, vi har en tabell KATEGORIER, en RELATIONER, en KAT_KOPPLINGAR, en SAKER och en SAK_KATEGORI. </div> <div>
</div> <div>SAKER har SakID och SakNamn. T.ex "1"; "Bonde" </div> <div>
</div> <div>KATEGORIER har KatID och KatNamn. T.ex. "34"; "person" eller "12";"föremål" </div> <div>
</div> <div>RELATIONER har RelID och RelNamn. T.ex. "56"; "älskar". </div> <div>
</div> <div>KAT_KOPPLINGAR har KopplID, FromID, RelID och ToID. FromID och ToID är id's från KATEGORIER. RelID är id's från RELATIONER. </div> <div>
</div> <div>KAT_KOPPINGAR beskriver alltså t.ex att "personer" kan ha relationen "älskar" med "personer" och med "saker", men att "saker" inte kan ha "älskar" med "personer". </div> <div>
</div> <div>(Alltså t.ex 1; 34; 56; 34 betyder att personer kan älska personer. 2; 34; 56; 12 betyder att personer kan älska saker. Däremot finns ingen 3; 12; 56; 34 eftersom föremål inte kan älska personer. och första siffran i dessa tre är bara ett löpnummer, bry er inte om det) </div> <div>
</div> <div>SAK_KATEGORI har SakKatID, KatID och SakID. Den beskriver att bonden (1) bland annat tillhör kategorin "personer". </div> <div>
</div> <div>
</div> <div>Med detta har vi ett ganska flexibelt ramverk, där man kan lägga till nya kategorier eller ändra på vilka kategorier som kan ha vilka sorters relationer med vilka. </div> <div>
</div> <div>Som sagt, jag känner att jag måste ha missat något. </div>

 

[solvebring]

Coolt. Får du ihop sådana där saker med bara en hjärna eller har du lånat några externa?

Nya kod-Sokrates? =)

Därav hoppas jag att ingen dyker in och påpekar vad du missat, för för närvarande är ditt tillsynes inlägg smart och jävligt förvirrande - i positiv bemärkelse.

... skriver solvebring som tänkte: "He say whoot?! Låter apsmart iaf!"
... Btw, de gamla grekerna skulle haft datorer.

 

[krank]

Coolt. Får du ihop sådana där saker med bara en hjärna eller har du lånat några externa?

<div>
</div> <div>Det, öh, är resultatet av att ha haft en (1) databaskurs på gymnasienivå, inför vilken jag fick se till att lära mig lite databasgrejs lite kvickt. Jag hyser inga tvivel öht om att jag missat eller förbisett något viktigt. </div> <div>
</div> <div>Den svaghet jag ser är att systemet teoretiskt sett tillåter något att vara av två ickekompatibla kategorier (t.ex något kan vara en person och ett föremål; och just nu skulle "får ha relation X" alltid anses viktigare än "får inte ha relation X", dvs om något är en person och ett föremål så får det tillgång till båda kategoriernas tänkbara relationer. Men det kanske är OK, nu när jag tänker efter. Om vi t.ex har ett magiskt svärd som har en personlighet, så kan det ju helt klart både "vara stulet av" någon och "älska" någon annan. Så att säga. </div>

 

[krank]

Jag skulle för övrigt lösa det programmeringsmässiga ungefär såhär: <div>
</div> <div>1. Låt användaren välja eller slumpa hur många av vilka kategorier man ska börja med. </div> <div>2. Se vilket element som har minst antal potentiella kopplingar. Skapa tre kopplingar (valbar siffra) till andra saker. Går det inte att skapa tre kopplingar, ta bort elementet och ersätt det med nåt från en annan kategori. </div> <div>3. Gå igenom elementen från ovanstående till det med flest möjliga kopplingar, tills alla har det inställda antalet kopplingar. Kan tänka mig att användaren kan få välja hur många kopplingarna ska vara (även "mellan 1 och 7" etc). </div> <div>
</div> <div>Hur man kollar hur många möjliga kopplingar det finns: </div> <div>1. Kolla elementets kategori-id. (SAK_KATEGORI) </div> <div>2. Kolla till vilka andra kategorier detta kategori-id får ha relationer (KAT_KOPPLINGAR) - t.ex vi får veta att människor kan "älska" eller "hata" både föremål och saker, men kan bara "vara avundsjuk på" personer, inte saker. </div> <div>3. Kolla hur många andra element det finns, som inte fått det inställda antalet kopplingar ännu, som är av de kategorityper elementet får ha relationer till (dvs vi får ha relationer till personer; men finns det personer? Hur många?) </div> <div>
</div> <div>Sedan ska koden såklart minimera antalet relationer mellan två identiska saker. (om två personer t.ex älskar, hatar och är avundsjuka på varandra och vi bara ska ha tre relationer, så blir de u inte kopplade till resten av nätet. Även om man absolut an både älska, hata och vara avundsjuk på nån). Lite spridning vill vi nog ha. Fördelningen av relationer bör också regleras, så att inte alla äälskar varandra om nu inte älskar är det enda vi har i databasen... </div>

 

[ripperdoc]

• Fördela relationer någorlunda jämt mellan noder (men inte helt jämt, jag tror fisktanken blir bättre om det finns ett antal spindlar i nätet, snarare än helt generiskt)
• Klassificera vilka noder som får ha relation med varandra, regeln kan vara annorlunda för inkommande relationer gentemot utgående
• Hitta en balans mellan negativa och positiva relationer
• Specifikt konstruera relationsserier. Ex. A hatar B, B älskar C som är närmaste allierad med A. Överkurs är att identifiera relationsserier som skapar
• Gruppera noder och få detta att påverka relationer. Eg. om ett antal noder är i samma grupp (samma allians, samma familj, samma stad) så kan det påverka vilka relationer som oftare genereras. Detta lär dock bara behövas i större fisktankar.
• Coolaste funktionen någonsin: att generera fisktanksdiagrammet över tid. Koppla "handlingar" till relationerna. E.g. "älskar" kan ge upphov till handlingarna "söker giftermål med", "talar ut sin kärlek", "blir deprimerad av obesvarad kärlek". Handlingarna definieras sedan ha en viss effekt på diagrammet, e.g. lägga till eller ta bort en relation. Sedan kan man över tid slumpa fram dessa handlingar och se hur diagrammet förändras. Vips så behöver spelledaren inte göra något

 

[Ram]

Det är ungefär så som jag skulle lösa det hela också. Databasen skulle innehålla egenskaper och de tillåts växa i princip obegränsat (även om det blir enklare desto tightare det är). Databasen har dock ingen kunskap om beroenden, åtminstone inte huvuddatabasen, det sköts endera via vetoklasser (en vas kan inte älska en odöd lich, men en odöd lich kan älska en vas) eller via en beroendestyrande databas.

Som sagt, 70-80% av jobbet är att systematisera databasen/databaserna. Gör man det bra innan man börjar koda resten.

 

[Ram]

Hitta en balans mellan negativa och positiva relationer

Specifikt konstruera relationsserier. Ex. A hatar B, B älskar C som är närmaste allierad med A. Överkurs är att identifiera relationsserier som skapar dilemman och skapa dem extra ofta eller för de viktiga noderna (rollpersonerna). Annat exempel: "A fruktar B, A vill ha C, B innehar C, B behöver hjälp från A".

Gruppera noder och få detta att påverka relationer. Eg. om ett antal noder är i samma grupp (samma allians, samma familj, samma stad) så kan det påverka vilka relationer som oftare genereras. Detta lär dock bara behövas i större fisktankar.

Oj, dessa var lite svårare än jag tänkt mig...

Relationsberoenden i flera led, det tror jag blir ganska meckigt... Det går säkert att lösa, men det ställer högre krav på databasen.

Vad gäller den första, vill man verkligen ha balans mellan positiva och negativa kopplingar? Därtill så tycker jag nästan att det förtar charmen i det hela. Jag vill nog nästan ha lite halvknas kopplingar i autogenererade fisktankar tror jag.

 

[ripperdoc]

Relationsberoenden i flera led, det tror jag blir ganska meckigt... Det går säkert att lösa, men det ställer högre krav på databasen.

Vad gäller den första, vill man verkligen ha balans mellan positiva och negativa kopplingar?

Det behöver inte bli meckigt i databasen, det är snarare en algoritm i kod som tar någon enkel parameter relationerna har. Om en relation kan mätas i positivt eller negativt värde så är det ju alltid intressant om dessa går i konflikt (A älskar++ B, B är vän med+ C, C hatar-- A. Det betyder att den totala relationen mellan A och C är ex. + mot --, om vi antar att det minsta värdet på vägen mellan A och B gäller). Det blir helt enkelt en typ av vandringsalgoritm i grafen. Det svåra är förstås om man vill på något sätt maximera eller minimera denna effekt.

Och balans mellan positivt och negativt - kanske inte, men man behöver kontroll över balansen. Fisktanken riskerar bli obalanserad om 90% av noderna hatar och 10% älskar. Dessutom, att balansera på nod-nivå är bra, det betyder att alla en balanserad mängd vänner och fiender. Ännu bättre om man som ovan kan ta hänsyn till relationer i flera led.

Lycka till!

 

[solvebring]

Ja, jag skojade mest.
Det var bara det att då rabblade så i ditt inlägg att det lät dundersmart, så jag var bara tvungen att ge dig cred för att låta just så smart. =)

... Mjo, stundtals lider jag av riktigt taskig humor, jag vet. =S

 

[Rickard]

Vad gäller den första, vill man verkligen ha balans mellan positiva och negativa kopplingar?

Nej.

/Han tycker det inte behövs och som kan säga att två fraktioner kan ha flera relationer

 

[Rickard]

* Fördela relationer någorlunda jämt mellan noder (men inte helt jämt, jag tror fisktanken blir bättre om det finns ett antal spindlar i nätet, snarare än helt generiskt)

Starka och svaga fraktioner i en fisktank beror på antalet relationer de har. En svag fraktion har kanske 1-2 saker medan en stark relation har fler än 3-4 stycken. Se tonårsflicka #1 i relationskartan som jag exemplifierar med i trådstarten. Hon har 10 relationer till sig.

För att skapa "spindlar" är det bara att skapa en fraktion som ska ha minst 3 andra relationer. Varje relation som skapas följer denna lista:
+ Slumpar om relationen hänvisar till en ny eller redan existerande fraktion.
+++ Om den inte finns någon existerande fraktion skapas en ny.
+++ Om maxantalet för fraktioner har uppnåtts kommer inga nya fraktioner att bli skapade utan istället hänvisa till redan existerande.
++ Varje ny fraktion får sedan 1-3 nya relationer som följer mallen ovan.

Beroende lite på hur man väljer variablerna kommer den första skapade fraktionen att ha en större sannolikhet att få fler relationer till sig.

Det skulle kunna vara möjligt att användaren vill skriva in en eller flera viktiga fraktioner i scenariot och få ut en relationskarta där de har fler relationer tilldelade sig än övriga fraktioner. Detta skulle man kunna göra genom att vikta chansen för att en relation väljer den fraktionen istället för andra.

/Han som kan säga att det sista borde vara en tillägg i kommande versioner

 

[krank]

Jag vill förresten inte att nån ska tro att jag har tid eller energi att faktiskt bygga en sådan här databas. Det var en trevlig utmaning för en kväll att designa skiten, men det betyder inte att jag har energin eller tiden att omsätta i praktiken. Dessutom gör Hans inställning till mig (var väl max en månad sedan han senast skrev "det här var den sista gången jag läser nåt du skriver) att jag inte känner mig så sugen på att hjälpa till...

 

[Ram]

Det absolut ballaste vore att göra databasen som en wiki så vem som helst kan fylla på den och modifiera för rimlighet.

 

[Snow]

Jag kan tänka mig ett samarbetsprojekt om någon annan är sugen? Till att börja med så enkelt som möjligt:

* Fasta (eller väldigt begränsade) indata - senare flexibelt.
* Hårdkodad databas - senare riktig sql/document-databas, editerbar av communityn.
* Generering av diagram med (tex) Graphviz. Senare kanske svg-grafik.
* Ingen interaktivitet, man får ett diagram. Senare kanske man kan byta ut bara vissa noder etc.

Jag kodar i java eller möjligtvis möjligtvis php. Html, js o css o sånt är inga problem.