Architektur einer Lebenssimulation

Moin,

ich entwerfe gerade eine Lebenssimulation als mobile App/Spiel (ja, davon gibts schon ohne Ende, aber darum geht es nicht).
Als Datenspeicher werd ich eine ganz einfache SQL Datenbank nutzen um die verschiedensten Dinge abspeichern zu können.

Ab und an sollen Zufallsereignisse ausgelöst werden. Diese können mal nur eine Antwort-Option enthalten, oder mal (maximal) drei. Soweit kein Problem. Nur stocke ich beim folgenden Gedankengang und weiß nicht recht wie ich das am geschicktesten umsetze:
Die Antwortoptionen können verschiedene "Situationen" auslösen. Also beispielsweise die Veränderung der Beziehung zu einer Person, eine Gehaltserhöhung, das geliebte Haustier muss eingeschläfert werden, oder es passiert einfach nichts.
Beispiel: Du gehst mit Deinem geliebten Haustier "Waldi" spazieren, durch einen dummen Zufall wird Waldi von einem SUV angefahren. Der Fahrer steigt aus seinem Auto und siehe da, es ist Dein Chef.
Reaktionen:
Eskalieren - Das Verhältnis zu Deinem Chef verschlechtert sich um x%, Waldi überlebt mit einer Schramme
Ruhig bleiben - Du bekommst eine Gehaltserhöhung weil Dein Chef ein schlechtes Gewissen hat, Waldi stirbt aber
Ja blödes Beispiel, aber es zweigt was ich meine.

Wie kann ich das am besten in der Datenbank umsetzen?

Danke schonmal!

Hallo Kriz,

vllt. ist eine "einfache SQL Datenbank", also eine relationale Datenbank, hier nicht die beste Wahl. Mach dich mit dem Konzept von Graph-Datenbanken vertraut. Mit denen können solche Beziehungen besser abgebildet werden.

mfG Gü

Hi,

mein Ansatz wäre, dass für ein Objekt (Person, Tier, Auto) an einem Ort (Zimmer, Straße, Kneipe) mit einer gewissen Wahrscheinlichkeit ein Ereignis eintreten kann. Das kann ein Ereignis sein, auf das man keinen Einfluss hat oder eine Reaktion zulässt. Also eine Handlung zulässt. Verhältnisse zwischen Objekten würde ich über Beziehungen abbilden, die definieren wie der aktuelle Stand der Beziehung (z.B. Angestelltenverhältnis) ist.

Ich würde es für den Anfang auch sehr einfach halten. Kümmere Dich erst einmal darum, wie Deine Ereignisse ausgelöst werden und welche Komplexitäten Du hier benötigst. Tritt Dein Ereignis immer nur an einem Ort auf? Kann es auch an mehrere Orten auftreten? Lege ich im Zweifel neue Ereignis-Duplikate an oder versuche ich diese für andere Orte wieder zu verwenden? Die Frage ist in diese Fall, lässt Du Redundanz zu oder reduzierst Du diese durch komplexere Objektstrukturen.

Wichtig ist auch, was siehst Du am Anfang als gegeben an. Hat Dein Charakter immer einen Job? Wenn nein, dann kann er seinem Chef nicht begegnen. Hat Dein Charakter immer ein Haustier? Das kann Auswirkung darüber haben, welche Ereignisse zulässig sind. Heißt Du brauchst ggf. Eigenschaften am Ereignis, dass ein Chef benötigt wird. Kann heißen, dass das Ereignis gar nicht ausgewählt werden darf oder eben nichts passiert, wenn das Ereignis aufgrund der Bedingungen für das Eintreten nicht eintreten kann.

Ich hoffe, ich habe es einigermaßen verständlich geschrieben. Auf die Datenhaltung bin ich nicht eingegangen, da die sich in der Regel aus den gewählten Strukturen von ganz allein ergeben. Es sei nur angemerkt, dass das Pflegen der Daten sehr schnell und einfach gehen sollte und die Daten sich ggf. unabhängig von der eigentlichen Programminstallation aktualisieren lassen sollten.

Ach ja, ich fänd es witzig, wenn man "ruhig bleiben" auswählt, aber der Charakter sich mit einer gewissen Wahrscheinlichkeit trotzdem für "eskalieren" entscheidet, weil zu einem bestimmten Prozentsatz immer "eskalieren" ausgewählt wurde.

Ich sehe das wie gfoidl, das sowas eher mit Graphen umsetzbar ist.
Bei einer relationalen Datenbank wirst Du mit Workarounds arbeiten müssen, zB dass gewisse Beziehungen durch Applikationslogik, nicht die Datenbankrelationen zu lösen sind.