| rauschma hat Folgendes geschrieben: |
| Eine flexible Codebasis hilft mir aber auch beim getrennten Programmieren (also wenn ich noch nicht einen Alleskönner-Server machen will), denn dann kann man beide Server aus sehr viel ähnlichen Bausteinen zusammenstecken. Und wenn man seine Codebasis in Ordnung hat, dann schockiert einen relativ wenig, wenn der Kunde heute hü (getrennte Server) und morgen hott (ein Alleskönner) sagt. |
Die Entscheidung für alleskönner ist bei uns ganz am Anfang gefallenm als sich die Regel reversi abgezeichnet hat. Es gibt auch einen GameMaster+SpielModell der das Spiel führt und grundsätzlichmal n-Spielerspiele mit m-Beobachtern spielen kann, was im Zusammenhang mit dem lange diskutierten trackAndComputeMove zu Problemen geführt hat. Wir wollten eben __ein__ modulares System in das auch die Administration gepasst hat. Leider sind die Lobby/Turnier Modi momentan noch festverdrahtet (ein Map<String, Queue> für den kontinuierlichen Spielmodus (vor Lobbyphase) und ein Map<String, Tournament> für die Turniere, jeweils nach Regeln geordnet). also Vielleicht bekommen die noch ein Interface enqueue(ExtendedPlayer) extrahiert, sodass unsere Serverkern beliebig viele Spielmodi (Lobby/Turnier/fifo/roundrobin/...) modular unterstützt. Was dann auch Kompartibilität zu den (pre-lobby) KI-Test-freundlichen kontinuierlichen fifo Spielmodus schaffen würde.
|
