So, die Admins haben gesprochen und bis auf weiteres wird alles hier besprochen. Bei großen Unterthemen sollte man vielleicht einen seperaten Thread anbrechen, aber das sehen wir dann ja.

Zuerst eine Frage an Kreks, weil ich dazu noch nichts gelesen habe. Wann bist du mit installieren, eingewöhnen, etc. fertig - sprich, wann kannst du loslegen?
Soll kein Zeitdruck sein, ich fange schonmal an zu planen/spinnen ^^ Würde nur gerne wissen, wann es Sinn macht, sich um so Dinge wie Schreibzugriff zum Quellcode zu kümmern.

Also, erster Punkt der Tagesordnung: Roadmap.

Ich bin kein Projektmanager. Aber ganz ohne Organisation und Planung geht's nicht, und da wir wohl kaum einen Dritten finden, der sich darauf konzentriert... Brainstorming ist angesagt. Ich hoffe mal, dass ich zu dieser späten Stunde keinen groben Unfug schreibe.

X-Force (oder allgemeiner X-COM-artige Spiele) ist ein großes Spiel. Mal ganz langfristig gedacht, sehe ich folgende Bereiche:

Wir sollten uns bald entscheiden, ob wir für die Simulation der Spielwelt fixe Zeitschritte wollen oder ob variable Zeitschritte OK sind. Siehe z.B. gafferongames.

Spieldaten müssen irgendwie organisiert werden. Eine gegebene Datenstruktur in ne Datei schreiben und wieder auslesen ist schon drin. Aber das muss auch vernünftig angewendet werden. Eventuell muss man hier experimentieren.

Wo wir dabei sind, Assets (Grafiken, Skripte, etc.) müssen sowohl für's Hauptspiel als auch für Spielsätze geregelt werden. Mein Wunschsystem wäre, dass man ein paar Pfade in eine Datei schreibt und die Daten von dort lädt oder für die Distribution packt.

Apropros, irgendwo müssen die Grafiken lagern, aber kein (freies - Perforce kann das angeblich ganz gut) VCS ist dafür gedacht oder geeignet. @DirkF, Natter, JohnS, fox oder wer auch immer bescheid weiß: Wo speichert ihr die XF-Grafiken?

Skripte müssen geladen werden, aufgerufen werden, Zugriff auf Objekte und Events kriegen, etc. Das ist relativ einfach in Python, aber dennoch nicht trivial. Es gibt ein paar Möglichkeiten, dass zu strukturieren. Die einfachste, aber "gefährlichste" ist, einfach alles anzubieten - aber dann gehen bei jedem Update 30% der Skripte kaputt. Alternativ könnte man explizit ein interface definieren und alles, was davon abweicht, als Fehler (oder wenigstens Warnung) behandeln. Dann ist noch zu überlegen, ob man sowas direkt an den Objekten macht oder Wrapper erstellt. So oder so wird Metaprogramming sehr nützlich sein, um den Aufwand gering zu halten.

Geopolitik, Arbeitsmarkt und Handel scheinen alles recht kleine Themen zu sein.

Forschung ist, wie die Erfahrung gezeigt hat, wohl ein recht kompliziertes Thema. Bevor wir daran auch nur denken, sollten wir gucken, was für Fehler die aktuelle Implementierung in XF hat und wie die bei der aktuellen Neuplanung umgangen werden.

Der Bodeneinsatz ist ebenfalls ein riesiges Thema. Der verdient seinen eigenen Thread. Auf jeden Fall würde ich hier (noch mehr als bei anderen Komponenten) darauf achten, dass man den auch seperat und automatisch laufen lassen kann. KI ist wichtig, und wenn man sie schon hat, kann sie sich gefälligst auch selbst testen. Generell sollten wir uns hier nicht zu sehr an XF orientieren und von vornerein gut planen. Zum Beispiel wurden Einheiten, die sich über mehrere Felder erstrecken, öfters gewünscht (Beispiele: Panzer, richtig große Aliens, liegende Infanteristen, und andere Objekte könnte man so auch einfacher simulieren). Sagte ich schon, dass hier gut geplant werden muss?

Der Geoscape ist momentan flach und pixel-basiert. Das es flach dargestellt wird, ist erstmal OK (ehrlich gesagt finde ich es auch als Spieler übersichtlicher, da man die gesamte Welt sofort im Blick hat). Aber Längen- und Breitengrade wären schon wichtig. Jemand mit mehr Ahnung von Topologie sieht da vielleicht noch mehr Realismus-Probleme.

Luftkampf sollte ebenfalls relativ einfach werden, wenn wir bei der textbasierten Simulation bleiben. Manuelles Arcade-Gameplay macht IMHO wenig Sinn, wie auch schon bei XF beschlossen wurde.

Es werden sich sicher einige Dinge finden, die man als generischen Supportcode umsetzen und an mehreren Stellen verwenden kann. Das speichern und laden von Daten ist ein Beispiel, dass schon angebrochen ist. Für Events bietet pyglet zwar was, aber damit bin ich nicht so ganz glücklich (sehr dynamisch, man muss überall über strings gehen) und was hausgemachtes kann man wahrscheinlich leichter mit Skripten zusammenbringen. Mal schauen, was sich ergibt. Sowas kann man schlecht im vorraus planen.

Zahllose Arten von Items müssen definiert, gelagert, in Umlauf gebracht, und benutzt werden. Das ist der einfache part, und der verteilt sich auch auf viele der oben genannten Bereiche. Und dann gibt's Upgrades, Ausgabgsmaterialien, Werkstätten, etc.

Basen müssen gebaut werden. Wenn wir Alphatron oder ein Equivalent wollen, muss man daran kommen können. Basen brauchen ein internes Layout, diverse Gebäudetypen, Intergration in den Geoscape, und haben natürlich auch mit Items, Luftfahrzeugen und Personal zu tun.

Dann wäre da noch die UFOPädie. Die könnte einige... "interessante" Auswirkungen darauf haben, wie viele anderen Daten organisiert werden (wie kommt der UFOPädie-Code an die ganzen Objekte und ihre Daten?). Also sollten wir das im Hinterkopf behalten.


... mir gehen die Ideen aus. Was gibt's noch? Anmerkungen zum bereits gesagten? Oder will selbst was in den Raum werfen? Hat jemand schon konkrete Vorschläge/Ideen?

Der Hauptfehler von Jim bestand (meiner Meinung nach) darin, dass er verschiedene Arrays/Listen erzeugt und Objekte dazwischen verschoben hat.
Die neue Planung sieht deshalb nur einen Projektarray mit allen Daten vor, der über Flags zur Statuskennzeichnung und Steuerung verfügen wird.

Genau das war ein Teil des Problems mit der Forschungsliste.
Allerdings ist das nicht so kritisch, da man sowieso immer nur ein Objekt anzeigt und solche Daten einfach per Methode abfragen kann.

Bin grad dabei mich mit dem Sourcecode von dir vertraut zu machen. Mal sonebenbei: Ist es die generelle Python-Praxis mehrere Klassen in eine Datei zu schreiben? Bei Dingen wie der model.py sehe ich ja, dass man das ungern auf 30 Files verteilt.

Was noch fehlt ist die Sprachunterstütztung, wobei die in meinen Augen keine hohe Priorität hat, aber man sollte andenken wie sie eingebaut wird.

Der Geoscape als flaches Rechteck bietet mehr Vorteile als Nachteile. Man kann zb ein Bild des gleichen Ausmaßes darüber bzw daraunter legen und so die Welt farblich kodieren und hat so eine (individuell anpassbare) politische Karte. Längen und Breitengrade mögen zwar schön sein, aber machen in dem Fall keinen Sinn. Auch wenn die oberste Linie nur ein Punkt ist, kann sie in diesem Fall behandelt werden als sei sie eine Linie.

Die Spieldaten würde ich trotzallem in XML verfassen. Es produziert zwar overhead ist aber von Mensch und Maschine relativ einfach zu lesen und würde die Manipulation der Spieldaten unabhängig vom (nicht vorhanden) Editorumfang entkoppeln. Es würde auch schneller zu ersten herzeigbaren Resultaten führen, da nicht vorher ein Editor geschieben werden muss.

PS: Danke Dirk!

Sag Bescheid, wenn du anfängt selber was zu produzieren und commiten willst. Bräuchte nur deinen Bitbucket-Benutzernamen, dann gebe ich dir Schreibzugriff.


Die generelle Python-Praxis ist, Dateien mit Modulen, nicht mit Klassen zu verbinden. Ein Modul kann sich um eine einzelne Klasse drehen. Aber wenn ein Modul sinnvollerweise mehrere Klassen beinhalten kann und das nicht zu voll wird, können auch mehrere Klassen zu einem Modul gehören. Nebenbei sind auch "freie" Funktionen, also Funktionen ohne Klassen, völlig in Ordnung und willkommen.

Sprachunterstützung: Definitiv, und sollte auch von anfang an getan werden. Letztlich wird das aber v.A. eine Disziplinfrage, mehr nicht.

Geoscape: Ich bin auch recht angetan von 2D. Aber auf jeden Fall sollte Spielsätzen erlaubt sein, mit Längen- und Breitengraden zu arbeiten, damit Positionen leichter angegeben werden können und vor allem, damit die Positionen nicht an die Bildschirmgröße gebunden sind.

Spieldaten: Ich werde nen Teufel tun und alles mögliche von Hand parsen und ausschreiben. Ich bin überzeugt, dass man das erstellen von Lade-/Schreibe-Routinen komplett automatisieren sollte. Das alles von Hand zu schreiben, ist Zeitverschwendung, langweilig, fehleranfällig, und schwer zu erweitern (ich erwähnte doch schon das migrieren von Daten von einer Version zur anderen?).

Welches Dateiformat der generierten Code dann liest und schreibt, ist wieder eine andere Sache. Da lasse ich mit mir reden, und ehrlich gesagt bin ich auch nicht glüchlich mit dem aktuellen Format. Ich habe vorhin etwas rumgesponnen und bin auf so ein Format gekommen (exemplatisch XML, ginge aber in JSON und YAML genauso gut):

<!-- soldiers.xml -->
<soldiers>
  <soldier id="john-rambo">
    <firstname>John</firstname>
    <lastname>Rambo</lastname>
    <kills>999</kills>
    <based_in>base1</based_in>
  </soldier>
  <soldier id="the-duke">
    <firstname>The</firstname>
    <lastname>Duke</lastname>
    <kills>1337</kills>
    <based_in>base1</based_in>
  </soldier>
</soldiers>
<!-- bases.xml -->
<bases>
  <base id="base1">
    <long>120.45</long>
    <lat>61.93</lat>
    <soldiers>
      <soldier>john-rambo</soldier>
      <soldier>the-duke</soldier>
    </soldiers>
  </base>
</bases>

Man würde also quasi alle Referenzen auf andere Objekte über Benutzer-erstellte "IDs" oder "Schlüssel" regeln, statt wild zu verschachteln und sich aus dem nichts numerische IDs auszudenken. Ich wäre zu XML bereit, zugunsten externer Tools. Aber ich denke, selbst für die wäre es sinnvoller, die Metadaten die in den Python-Klassen abgebildet werden, zu verwenden. Naja egal, wird sich zeigen.

Aber um meine Frage an die Admins, Programmierer und Grafiker nochmal zu stellen (hoffentlich gibt's endlich eine Antwort): Wo lagert X-Force die Grafiken? Im SVN offenbar nicht (oder ich find's nicht). Gibt's da einen Passwort-geschützten Ordner auf dem Server oder sowas? Oder sind die garnicht zentral gesammelt und jeder muss gucken dass er die zusammenkriegt? Wenn Natter ein Release kompiliert, wo kommen die Grafiken her, die in die .pak gehen?

Ich habe momentan keine lauffähige Programmierumgebung zum nachgucken und Natter ist anscheinend in Urlaub oder aus sonstigen Gründen abwesend, sonst hätte es wohl schon eine Antwort gegeben. Müsst Ihr Euch noch einige Zeit gedulden, falls die pak-Dateien nicht im SVN liegen...

Blöd für mich, aber da könnt ihr ja nichts für. Danke für die Info.

Für mich wäre der erste Punkt, erstmal zu klären, in wie weit es wirklich ein Rewrite werden soll, man sich also am jetzigen X-Force orientiert, oder ob man relativ frei den Neuanfang starten will. Bei ersterem sollte man sich zeitig überlegen, an welchen Stellen man vielleicht anders vorgehen will (der Globus wurde ja schon angesprochen; auch die geplanten Umstellungen auf Klassifizierungen sollten dann imho mit aufgenommen werden). Ansonsten (wenn man keinen direkten Rewrite versucht) müsste man sich noch viel mehr Konzeptionell Gedanken zu Spielmechanik und Co machen.

Einen wichtigen Punkt für die Roadmap hätte ich noch. Ihr solltet von Anfang an überlegen, wie er Sinnvolle Fehlermeldungen von Spielern bekommen könnt.


edit
Ich hätte erstmal den Link lesen sollen ^^. Ich hatte an was ganz anderes gedacht, also einfach ignorieren.
/edit
Ich würde fixe Zeitschritte empfehlen. X-Force hatte früher Variable Zeitschritte. Das hat aber diverse Nachteile. Zum einen wird der Code schwerer zu lesen, weil viele Formeln die Variablen Zeitschritte berücksichtigen müssen. Außerdem wirken sich verschiedene Zeitschritte (je nach Umsetzung) aufs Ballancing aus.


Wir hatten in der Vergangenheit verschiedene Ansätze, und sehr lange Diskussionen. Für einen Reibungslosen Ablauf und vernünftige Fehlersuche ist es imho mit Abstand am besten, Spielsatzspeziefische Daten im Gameset selbst zu speichern. Will man trotzdem einen einfachen externen Zugriff ermöglichen, könnte man die Spielsätze ja als ZIP-Archiv oder ähnliches organisieren. Bei allgemeinen Daten ist das weniger kritisch. Aber auch dort solltet ihr zumindest eine Art Versionsprüfung einbauen - damit ihr bei Fehlermeldungen wisst, ob an den Dateien herumgespielt wurde. Die Erfahrung zeigt, dass Spieler auf Nachfrage oft der Meinung sind, sie hätten nichts verändert (z.B. am Spielsatz), eine längere Fehlersuche zeigt dann aber das Gegenteil.


Es gibt mehrere *.pak-Dateien mit den Daten und Grafiken. Die default-Skripte befinden sich in der scripts.pak (und auch in einem extra Verzeichnis im SVN). Symbole, Grafiken, Datensätze zu Städten etc. werden in der data.pak und der xforce.pak gespeichert. Für die Model-Daten der Einheiten (Animationen) gibts auch noch die model.pak. Mehr kann ich dazu aus dem Gedächtnis erstmal nicht sagen.

Zum Bodeneinsatz - der behersscht derzeit schon einen Auto-Modus. Man kann also durchaus 2 KI-Skripte gegeneinandewr antreten lassen. Was man bei einem Rewrite gleich beachten sollte - derzeit ist vieles auf 2 Parteien ausgelegt, das sollte bei einem Rewrite von Anfang an anders gehandhabt werden.

Guter Punkt. Für mich war das schon klar (und mein Eindruck war, dass andere das ähnlich sehen). Deshalb hab ich nichtmal dran gedacht, es explizit anzusprechen. Aber stimmt schon... also hier meine Meinung:

Es soll ja definitiv ein Spiel in der Tradition von X-COM werden. Das ist X-Force auch, und hat mMn einiges ziemlich gut gemacht, vieles recht gut, aber auch einiges suboptimal. Folglich bin ich dagegen, alles wieder genauso zu machen. Die generelle Aufteilung des Gameplays macht schon Sinn. Bei jedem dieser Punkte sollte dann frei überlegt werden, was am sinnvollsten ist. Da kann und wird X-Force (inklusive geplanten Änderungen an XF, wie z.B. die Konzepte) aber eine wichtige Inspirationsquelle sein. Das machen wir ja grade.


Oh ja, definitiv.


Beispiele? Klingt eigentlich sehr offensichtlich (was anderes wäre mir nie in den Sinn gekommen), also vielleicht fasse ich "spielsatzspezifische Daten" zu eng.


Ich denke eher daran, das Format für gepackte Spielsätze (und alle anderen gepackten Daten) zu einem Implementierungsdetail zu erklären. Dann können und sollten aber Tools bereitstehen (und bei jeder Installation dabei sein!), die das Dateiformat entpacken wieder verpacken.


Danke für den Hinweis, auf sowas wäre ich nie gekommen ^^
Hier fält mir spontan ein Ansatz ein: URL mit der "offiziellen" Version speichern und vorm losschicken eines Bugreports die Daten vergleichen. Das hängt natürlich von goodwill und Disziplin der Spielsatzersteller ab und fordert evtl. ein paar technische Einschränkungen (z.B. relativ beim Ordner-Layout). Andere ideen?


Danke, aber (sorry wenn ich nerve ^^) mir ging's darum, wo die ungepackten Grafiken und sonstige binäre Dateien (inkl. der meisten .paks, wenn ich mich nicht irre) gespeichert werden. Ich suche nur nach Ideen, wie wir folgendes Problem lösen können: Grafiken (und sonstige Binärdateien, aber bei Grafiken ist es am schlimmsten) schlecht für VCS geeignet sind (riesige Downloads, unnütze diffs). Aber sie sollten irgendwie zentral auffindbar sein, damit nicht jeder potentielle Entwickler (und jeder Entwickler, der sich eine neue Umgebung aufsetzt) sich durch das halbe Internet schlagen muss.

Vergesst sowas, ihr braucht eine Checksummezu jeder Versionsnummer, die vom Spieler unabhängig kleine Änderungen erkennbar macht.
In einem der Fälle hatte der Spieler, der den Bugreport über eine Skriptfehlermeldung eingstellt hatte, auch bei der ersten Nachfrage behauptet er hätte keine Änderungen am Spielsatz vorgenommen. Ich habe dann insgesamt zwei Stunden lang die Usertags kontrolliert ohne das Objekt mit den falschen Datenzu finden - und dann konnte ich in einem anderen Zusammenhang von dem Spieler im Forum lesen, dass er den GalWar vereinfacht hatte, weil ihm das zu schwer war.
Der Fehler lag natürlich in einem verbesserten Objekt, bei dem dann die Daten im Usertag nicht mehr stimmten...

"Goodwill" hilft da nicht, es muss eine echte Meldung auf geänderte Dateien geben (zumindest solange ihr die Editoren auch den Spielern gebt).

Die Geschichte kenne ich, habe ich glaube ich selbst mit erlebt. Ich hatte das auch nicht so gedacht, dass jeder der den Spielsatz anfasst einen gut versteckten Knopf "Ich habe diesen Spielsatz geändert" drücken muss. Ich wollte eine URL eintragen lassen, unter der eine offizielle Version zu finden ist (könnte man sowie gebrauchen, wenn man automatische Updates will). Die könnte dann vom Spieler unabhängig verglichen werden.

Aber der Ansatz mit Prüfsummen ist eigentlich noch besser, da weniger Arbeit für alle Seiten. Daumen hoch!

Hab ich mir schon gedacht - nur den gibt es bei X-Force so nicht. Der einzige zentrale Ort sind die pak-Dateien ^^.
Wir haben einen internen Server, aber auch da sind nicht alle Daten vorhanden. Denkbar wäre auch eine Verwaltung über Mantis.


Nun, es gab ja mehrmals den Wunsch, die Spielsatzdateien in einem Verzeichnis abzulegen (um z.B. an Skripte leicht ranzukommen). Für mich zählen dazu auch Grafiken, Karten, Animationen usw.

Okay, blöd ^^ Aber danke für die Antwort.

Das klingt gut. Warum macht ihr das nicht, so aufwändig das umzustellen?

Aber wo wir dabei sind: Wie du schon angesprochen hast, brauchen wir früher oder später einen Bugtracker. Wäre es möglich, dass wir als Unterprojekt im XF-Mantis einsteigen können? *lieb guck*

Naja, der Nutzen ist eher gering. Es gab bisher sowieso immer nur eine einzige Person, die sich um das Zusammenstellen eines Setups kümmerte. Anfangs war das jim_raynor, danach ich. Und wenn man aus einem anderen Grund an die Dateien will, kann man ja einfach die Archive öffnen. An den Grafiken (Hintergründe, Symbole etc.) wird ja eh selten was geändert. Andere sachen, z.B. die Modelldaten oder default-Skripte finden sich ja im SVN, und werden automatisch per Compilerschalter in den Archiven aktualisiert.

Später durchaus - schließlich haben ja auch verschiedene Spielsätze schon eigene interne Foren etc bekommen, und in den meisten Fällen auch ungefragt.
Aber die dafür geltenden Kriterien gelten auch für sowas wie dieses Rewrite-Projekt: Wir wollen erstmal einige Zeit gucken, ob genug Interesse und Helfer hierfür auftauchen.
Macht so weiter wie bisher, holt eventuell noch ein paar andere Programmierer dazu und irgendwann kriegt Ihr entsprechende Zugriffe.

Übrigens:
Ich habe bei den Konzepten die Grundgedanken hinter der neuen Projektliste beschrieben, damit Ihr diesen Ansatz vergleichen könnte. Wenn Ihr ähnlich vorgeht, dann könnte man irgendwann einmal einen Spielsatz-Import/Export für die beiden Programme schreiben...

Zu den Grafiken, einige habe ich direkt Natter gegeben, andere vorher zusammen in die pak-Datei gegeben und dann an Jim/Natter weiter, bzw intern verlinkt und der Ersteller sich dann das brauchbare zusammengesucht.

Grundsätzlich sollte irgendwo wo eine Grafik hinsoll unbedingt ein Platzhalter wie Fragezeichen, Bild demnächst oder sonstwas plaziert werden, und keinesfalls eine schon vorhandene Spielgrafik als Standard (Waffe, Rüstung) gesetzt werden.
Das erleichtert es den Grafikern sofort zu sehen wo eine Grafik fehlt. Als Grafiker würde ich es begrüßen wenn ich den Grafikpfad in einer XML-Datei eintragen kann, und sofort im Spiel das Ergebnis sehen kann. (vor allem Hintergründe, Ufopädiebilder)

Bei einer XML-Grafikliste oder ähnlich ließe sich evtl ein kleines Tool bereitstellen was sämtliche Grafiken(links) prüft und fehlende Grafiken (also Platzhalter) anzeigt.

Vorzugsweise Bilder-Format in 4:3, 16:10 oder 2:1. Ungünstig ist eine 1:1 Auflösung. Ich hoffe auch das sich pink als Transparenzfarbe ablösen läßt.

Selbstverständlich :)


Danke dafür!


Wenn wir, wie angedacht, teilweise von XF abweichen (also ein echtes Rewrite statt einer Neuimplementierung), sollte das schwerer werden. Aber natürlich ist noch nichts vom Tisch.

@JohnS: Ich denke, pink können und sollten wir loswerden. Für mich klingt PNG gut (verlustfrei, direkter Alpha-Kanal, weit verbreitet, nicht allzu groß), und ist für uns ohne weiteren Aufwand möglich. Das erlaubt auch halbtransparenz, statt fast-aber-nicht-ganz pinken Rändern. Welches Format würdest du empfehlen?


Kann man sicher tun, wenn man das Laden von Bildern einbaut. Klingt sehr vernünftig. Ich erinnere mich an riesigen transparent-gelben Blöcke in Morrowind, wenn ein Mod Mist gebaut hat.

Hier muss man gucken, das hängt von der Organisation der Assets generell ab. Auf jeden Fall sollte es nicht viel komplexer werden als ein Dateipfad. Und ja, den wird man dann überprüfen können.

Meine Gedanken zu den einzelnen Sachen:

Zeitschritte:
Feste Zeitschritte sind einfacher zu programmieren. Außerdem weiß man dann, dass die Simulation auch immer gleich ist (also nicht bei manchen Computern unvorhergesehene Sachen passieren, nur weil die variablen Zeitschritte plötzlich zu Spezialfällen führen). Man könnte sich aber eventuell überlegen, die Grafikanzeige und die Berechnung unabhängig voneinander zu machen (Stichwort parallele Programmierung). Dafür müsste ich aber wissen, ob Python parallele Programmierung unterstützt.

Bodeneinsatz:
Der Bodeneinsatz sollte am Besten wie ein eigenes Programm behandelt werden. Man startet also sozusagen ein Programm im Programm (in einem neuen Frame oder in einem neuen Fenster). Beim Starten des Bodeneinsatzes gibt man ihm alle nötigen Daten (Ufo, Aliens, Transporter, Soldaten, Karte, AI, etc.) und beim Gewinnen oder Verlieren liefert man die Ergebnisse ans Hauptprogramm zurück (übrige Soldaten, übrige Aliens, Missionsergebis (gewonnen, verloren, geflüchtet), evtl. zerstörte Objekte, erledigte Missionsziele). Dadurch kann man theoretisch auch ohne das Spiel den Bodeneinsatz starten, wenn man ihm die nötigen Daten gibt.

Geoscape:
Hauptproblem bei einer flachen Karte (die vermutlich rechteckig ist) ist, dass die Objekte in horizontale Richtung umso schneller fliegen, je weiter sie vom Äquator entfernt sind (da die Längenkreise dort einen kleineren Umfang haben). Ganz oben und unten wäre es dann sogar so extrem, dass die ganze Linie ein Punkt wäre (nämlich Nord- bzw. Südpol).

Luftkampf:
Beim Luftkampf würde ich ebenfalls bei etwas einfachem bleiben. Ist ja bei X-Com ebenfalls so, dass man nicht viele Möglichkeiten hat (glaube aggressiv, vorsichtig und flüchten, oder so ähnlich).

Prüfen von Änderungen an Spielsätzen:
Eventuell sollte man bei der Implementierung von den Spielsätzen gleich an eine Funktion denken, die zwei Spielsätze miteinander vergleicht und Unterschiede in den Daten markiert. Dies hängt natürlich stark davon ab, ob die Spielsätze in einem Format gespeichert sind, das man einfach lesen kann.

Da teile ich deine Einschätzung zu Einfachheit und Zuverlässigkeit. Die Anzeige und die Physik sollten auf jeden Fall unabhängig voneinander sein. Sie komplett parallel zu machen, wäre allerdings unnötig aufwändig. Und letztlich wäre ja doch wieder jede Menge Synchronisation nötig (sprich: Die Simulation müsste fast alles stehen und liegen lassen), wenn man keine Frames haben will, auf denen die halbe Welthalbkugel einen Schrit weiter ist als die andere. Von Concurrency-Bugs wollen wir mal garnicht erst anfangen. Ich denke nicht, dass das allzu sinnvoll (und auch nicht nötig) ist.
Außerdem wäre es zwar möglich, aber mäßig schwer in Python: Threads mit Locks etc. gibt es, benutzen aber zumindest beim offiziellen Interpreter zu jedem Zeitpunkt nur einen Kern zum rechnen. Mehrere Prozesse geht dagegen recht leicht und benutzt mehrere Kerne, aber dann hat man den overhead von interprocess communication. Wenn schon, dann scheint es für die KIs am sinnvollstan. Die könnten sinnvoll arbeiten, während gezeichnet wird: Sie lesen öfters, um zu entscheiden, aber tatsächlich müssen sie nur selten schreiben. Noch dazu müssen die eh asynchron als Eventhandlern geschrieben werden.


Das war meine Sorge beim Realismus des flachen Rechtecks. Aber ich denke Kreks hat recht, das ist erstmal nicht nötig. Unrealistisch wird's ohnehin ^^


Richtiges diffing ist relativ komplex. Ein einfacher Un-/Gleichheitstest ist viel einfacher und für den angesprochenen Zweck ausreichen.