Ich weiß, dass es dumm klingt. Ich selbst bin mit mir sehr unzufrieden und möchte das alles nachholen, um nie wieder solche dämlichen Fragen zu stellen
Nein, das ist am Anfang durchaus normal. Und im Unterricht wird - nach meiner Erfahrung - in erster Linie die Sprache selbst beigebracht, aber eben keine wirkliche Vorgehensweise, wie man sowas angeht. (Und wenn owas Stoff ist, dann wird man mit UML und Co erschlagen und hat dann Formalismen aber keine saubere Herangehensweise!)
Eine Möglichkeit ist (ich stelle jetzt einen agilen Ansatz vor - es gibt aber diverse andere Möglichkeiten):
a) erst einmal identifizieren, was für Features es gibt. Features können hier z.B. User Stories sein. Du beschreibst einzelne Schritte, die in der Software möglich sind.
"Als <Spieler> möchte ich <Points Fragen richtig beantworten können> damit <ich meine Indizien verbessen kann>."
Das ist ein typischer Aufbau für eine User Story: "Als ... möchte ich ... damit ..."
b) Wenn man das hat, dann sortiert man das. Da sind dann Abhängigkeiten wichtig. So ist die User Storie vom Spieler, der Fragen beantwortet klar nach einer Story "Als Admin möchte ich Fragen erfassen, damit Spieler diese später beantworten können."
Wenn Du dann sowas hast, dann gehst Du das im Detail durch. Du nimmst, da Du alleine bist, nur die oberste Story. Und dann musst Du überlegen:
c) Abnahmekriterien: Was muss gelten, damit die Story als abgenommen gilt. Beispiel:
"Als Admin möchte ich Fragen erfassen, damit Spieler diese später beantworten können."
-> Es gibt zwei Arten von Fragen (s.o.)
-> Jede Frage besteht aus einem Text und der Antwort (Ja / Nein)
-> Fragen werden gespeichert in einer Datei.
-> Fragen können aus der Datei geladen und angezeigt werden
d) Dann setzt Du das um.
-> Du schreibst eine Klasse Question mit den notwendigen Feldern.
-> Du schreibst eine Klasse, die die Fragen verwaltet, es gibt Methoden zum hinzufügen, speichern und laden. (Da nicht spezifiziert wurde, wie gespeichert wird, kannst Du da was nutzen, das Du willst. Binary Serialisierung? JSON? XML? Ganz Dir überlassen!)
Und so gehst Du die User Stories durch. Nach jeder abgeschlossenen User Story kannst Du überlegen: Gibt es änderungen? Evtl. wird eine User Story nicht mehr gebraucht? Oder es wird eine verändert? Oder es gibt neue? Die Reihenfolge ist evtl. anders?
Wenn man diesen agilen Ansatz so nicht durchexerzieren möchte, dann kann man auch einfach Datenbasiert heran gehen:
-> Was für Daten brauchst Du so? Dann hast Du die Fragen und die Verwaltung der Fragen. Du hast Indizien mit irgendwelchen Werten. Du hast ein Spiel und in dem sind die Liste der unbeantworteten Fragen, eine gewisse Anzahl Spieler, Jeder Spieler hat Indizien, ....
-> Dann implementierst Du die Daten selbst. Das sind dann erst einmal reine Entity Klassen die noch kein Verhalten groß haben.
-> Und dann fügst Du nach und nach Verhalten hinzu: Fragen speichern / laden z.B. Dann dass ein Spiel erzeugt wird. Dass Spieler irgendwas machen können ...
Am Ende, wenn das Spiel so funktionieren würde (Das sollte immer per Unit Tests sicher gestellt sein!), dann baust Du die Oberfläche. Die Daten, die Das Spiel so hat, werden da dann angezeigt und User Events werden dann umgewandelt in entsprechende Aktionen auf deinem Model (So nennt man das, was wir vorher aufgebaut haben).
Das ist so ein einfaches Vorgehen. Das ist auch etwas, das ich in dem
JAdventure versucht habe etwas aufzuzeigen. Evtl. schaust Du Dir das auch einmal an. Es ist bei weitem nicht fertig und ich habe auch keine Ahnung, ob es gut ist. Aber Du kannst es Dir anschauen (und mir dann auch gerne Deine Meinung sagen. Ich brauche keinen Honig um mein Maul geschmiert - sachliche Kritik ist mir lieber: Das ist für dich absolut unbrauchbar, weil ......)
