Was bei größerem Projekt beachten? (Am Beispiel des Spiels "Risiko")

Ich möchte das Spiel Risiko implementieren. Mir ist durchaus bewusst, dass sich damit kein Geld verdienen lässt und auch schon viele Implementierungen in unterschiedlichsten Sprachen existieren.

Mein Ziel ist einfach, durch ein etwas größeres Projekt mehr Erfahrung im Bereich .NET / C# zu sammeln und mein Wissen auszubauen.
Auch denke ich, dass mein Projekt sehr gut erweiterbar ist, da man nach einer einfachen Einspieler Test Version, sich optional mit so Themen wie Netzwerk, KI oder verbesserter Grafik beschäftigen könnte.

Worum es mir bei meinem Beitrag geht, sind ein paar grobe Fragen damit ich nicht direkt in Sackgassen laufe.

Ich möchte die Grafik (WPF) so sauber wie möglich von dem Logikbereich trennen. Erreiche ich das durch ein sauberes Klassen Design oder wie muss ich mir das vorstellen?

An dem Thema Threads komme ich logischerweise nicht vorbei. Kann man sagen ob einer der vielen Wege (BackgroundWorker, Dispatcher, ..) für meine Applikation besonders von Vorteil ist oder ist das eher eine Frage der persönlichen Vorlieben?

Falls euch noch der eine oder andere Tipp einfällt, was ich gerade in der Anfangs (Planungs- /Überlegungsphase) beachten sollte, würde ich mich sehr freuen.

Erstmal vorneweg: Threads halte ich für nicht so wichtig.

Die Logik vom GUI abzutrennen ist nicht besonders schwer. Am einfachsten wäre, "abstrakte" Logikklassen zu erstellen (Spiel, Spielfeld, Spieler, Einheit etc.) und dann GUI-Komponenten zu erstellen welche die jeweilige Logik-Klasse kapseln. Es sollte auch ein EventSystem geben, das es den einzelnen Bausteinen ermöglicht miteinander zu kommunizieren.

Dann brauchst du natürlich ein Grundgerüst, welches das "abstrakte" Spiel ablaufen lässt, also die Moves ausführt und zeichnet, weswegen du hier noch eine Schnittstelle einführen solltest, welche den Renderer repräsentiert.

Der Renderer nimmt dann deine Spielklasse, kapselt in seinem Subsystem die entsprechenden GUI-Klassen und stellt alles wie gewünscht dar. Für das RendererSubsystem und die Instanziierung der einzelnen GUI-Komponenten würde sich das Abstract Factory pattern anbieten.

... da man nach einer einfachen Einspieler Test Version, sich optional mit so Themen wie Netzwerk ...

Ich kann dir hierzu nur den guten Tipp geben, daß es im nachhinein schwieriger ist, ein Spiel netzwerkfähig, d.h. Multi-User fähig zu machen, wenn es vorher nur als Solospiel implementiert wurde.
Ich spreche da aus Erfahrung, da ich selber mehrer Jahre in der Spielebranche tätig war...

Wie GMLOD schon geschrieben hat, ist auf jeden Fall die strikte Trennung der Logik von der GUI sehr wichtig. Dies heißt zwar erst einmal einen höheren Aufwand (Erstellen von Schnittstellen, viele Klassen und Dateien, Programmierung der Datenübergabe etc.), jedoch brauchst du für ein längerfristiges Projekt immer eine gute Struktur.

Am besten, du erstellst dir als erstes einmal eine Grobstruktur deines Programms (d.h. die benötigten Klassen) und erstellst daraus dann eine hierarchische Struktur.

Am einfachsten wäre, "abstrakte" Logikklassen zu erstellen (Spiel, Spielfeld, Spieler, Einheit etc.) und dann GUI-Komponenten zu erstellen welche die jeweilige Logik-Klasse kapseln.

Ob das wirklich die beste / einfachste Möglichkeit ist, ist IMHO sehr fraglich.

Gerade im Zusammenhang mit der WPF gibt es eigentlich nur ein Pattern: MVVM.

Wobei eigentlich schon ein Model, das INotifyPropertyChanged implementiert, reichen würde und das per _DataTemplate_s und DataBinding an die Benutzeroberfläche gebunden ist.

Gut, ich kenne MVVM nicht, und er will mit WPF ran.

Ich habe mir darüber noch keine detaillierten Gedanken gemacht, finde aber, dass man prinzipiell nicht auf WPF angewiesen sein sollte, sondern auch einfach zwischen graphischen Frontends switchen können sollte, deswegen wäre ich gedanklich erstmal so naiv an die Sache rangegangen, das würde auch prinzipiell funktionieren.

Huui, so viele Antworten ..

Thema Grafik:
Also wenn ich mit den 6 Sätzen die ich bin in 4 Minuten zum Thema MVVM Pattern gelesen habe, das Ganze richtig verstandne habe.
Dann bau ich zwischen die Daten und die Darstellung eine weitere Schicht, die Kenntnis von den Daten und der Art der Darstellung hat und so steuernd beim weitergeben der Daten eingreifen kann.
Wie auch immer, ich denke das ich mit dem Thema DataBinding und der Schnittstelle INotifyPropertyChange genug beschäftigt bin und auf diese weitere Ebene verzichten werde, die vielleicht gerade bei extrem paralleler Entwicklung interessant ist, aber ich bin ja alleine.

Thema Netzwerk:
Da ich eher vorhabe das Spiel netzwerkfähig zu gestallten, als eine KI zu implementieren .. werde ich wohl nach Th69s Aussage, das Thema gleich von Anfang an in meine Planung mit aufnehmen.

Da ich weder vorhabe es zu verkaufen oder im größeren Stiel zum download anzubieten, denke ich das ich keine Post von Hasbro bekommen werde.

Im Buch Steve McConnell, Code Complete wird das Thema Projektplanung ausführlich ung gut verständlich erklärt.