z.Bsp sind die Grafiken im BE rechts unten für die Waffen direkt aus der Ufopädie. Wer sich erinnern kann früher waren das die kleinen Icons der Ufopädie. Ein Soldat ist mit Granaten ausgerüstet und wirft die, dafür gibts aktuell nicht immer eine extra-Animation. Grafik zwischen Ausrüstung-Soldat und Grafik im BE stimmt nicht überein, der Geoscape könnte bei der Ausrüstung die Animation des BE anzeigen, tut er aber nicht, aufgrund anderer Auflösung usw.

Aber um es mal ganz grob zu sagen, betrachte ich den Geoscape nur als Frontend der Bodeneinsätze ^^.
Sieht man das andersherum, kann man die BE auch automatisch berechnen lassen und sich auf den Geoscape, Verwaltung, Ufoabschuss konzentrieren. Die Aufteilung würde aus meiner Sicht die Qualität der Einzelteile steigern, bzw zeitlich einfacher abzustimmen sein, da man nicht beides sofort auf einmal machen muss. Daher gilt es abzuwägen ob maximale Freiheit und Konfigurierbarkeit für Spielsatzersteller angestrebt wird, oder die Modifikation nur mit den gegebenen Tools oder nur eingeschränkt stattfinden soll.

Ich will nicht so weit gehen und sagen das ich mir einen eigenen BE-Simulator schreibe, weil ich die Parameter einfach bekomme, oder das ich weil die BE getrennt ist einfach ein Fantasy-Setting mit Barbaren und Trollen mache. Aber die Separation bietet aus meiner Sicht mehr Vor- als Nachteile, auch weil die benötigten Parameter kritischer betrachtet werden müssen, anstatt mal einen quick-hack zu machen und sich über ne Krücke Daten zu besorgen.

Ist eben eine knifflige Sache. Meist ist es so, das Tester oder Programmierer beizeiten ein Ergebniss sehen wollen, oder was zum spielen haben möchten. Je komplexer die Sache ist, desto später stellt sich ein mögliches Erfolgserlebnis ein. Von daher bevorzuge ich ein schnelles Ergebnis, was sich testen und anpassen läßt.

Ich versuche eher Natter und DirkF von den Vorteilen einer Trennung zu überzeugen. Die am ReWrite beteiligten, werden das von allein machen, schon um schnell mal etwas testen zu können. Ob das ne separate *.exe ist oder nur eine Platzhalter-Simulation sei mal dahingestellt. Ist ja auch eine Frage der Austauschbarkeit, wenn jemand Stärken im Proggen der BE hat, warum soll er sich da mit den Interna des Geoscape rumschlagen und umgekehrt. Reicht doch zu sagen hier hab ich die neuste vom Geoscape generierte xml und fütter damit meine BE. Dann kann ich die solange tunen wie ich will (Physik, Grafik, alles mögliche), ohne Gedanken an den Geoscape oder Basis oder Wissenschaftler oder Alphatron zu verschwenden.

Um das aber abzuschließen, ich sehe in einer Trennung eher Vorteile.

Über externe Dateien zu gehen, halte ich für Humbug. Es hilft kein Stück dabei, BE und restliches Spiel besser zu trennen, als eine strikt definierte und eingehaltene interne Schnittstelle (Interface, API, nennt es wie ihr wollt), über die Zugriff auf den gemeinsamen Speicher erlaubt wird. Ob nun die Geoscape-Zeit einfriert und der BE an den Daten rumspielt, die der Geoscape sonst verwendet, oder ob man die ganzen Daten speichert, vom BE laden lässt, im BE ändert, dann wieder speichert und im Geoscape lädt... von der (potenziellen - man kann alles ruinieren) Korrektheit und Modularität nimmt sich das nichts (oder zumindest nicht viel), aber letzteres ist deutlich aufwändiger.
Das gilt übrigens für Rewrite und XF gleichermaßen.

Nur mal eine kleine technische Klarstellung: Für den Computer gibt es erstmal keine echte Parallelität (zumindest solange man nicht einzelne Kerne getrennt verwaltet).
X-Force simuliert Parallelität, indem es einzelne Schritte schnell nacheinander ausführen lässt. Natter könnte dazu mehr Details zusteuern, aber im Grundprinzip sagt die Geschwindigkeitseinstellung im Geoscape nur, wieviele Zeitschritte pro echter Zeiteinheit als Minutenaufruf-Befehl ausgelöst werden sollen.
Sobald ein anderer Bildschirm als der Geoscape aufgerufen wird, werden diese Zeitimpulse nicht mehr ausgeführt und der Geoscape ist gestoppt. Und der Bodeneinsatz ist erstmal nichts als ein anderer Bildschirm, der nur aufwendigere Anzeigen und Buttons hat als z.B. Labor oder Werkstatt.

Ich würde Euch empfehlen, bei dem Rewrite eine ähnliche Aufteilung beizubehalten (d.h. die "Weltzeit" läuft nur im Bildschirm Geoscape, die Kampfrundenzeit nur im Bildschirm Bodeneinsatz usw.).
Eine übergeordnete Zeitsteuerung über verschiedene Bildschirme wäre wesentlich aufwendiger und würde nichts bis kaum etwas bringen - im Labor die Forschungsbalken zu beobachten weil die Zeit auch dort laufen soll ist deutlich weniger Interessant als einen Geoscape zu beobachten, bei dem es echte Überraschungen und neu auftauchende UFOs gibt...

Ich gehe mal davon aus, dass die Klarstellung nicht an die Programmierer gerichtet war. Ich weiß sowas, und Kreks hoffentlich auch ;) Danke dafür.

Genauso passiert es bei uns übrigens auch. Schon jetzt gibt's Klassen für einzelne screens mit (optionalen) methoden wie time_step(), und die wird immer nur beim grade geöffneten Bildschirm ausgeführt. Die Implementierung beim Geoscape guckt dann auf die Zeiteinstellung und macht entsprechend viele Zeitschritte (Luftfahrzeuge bewegen und die Uhr gegenebenfalls anpassen, später selbstverständlich mehr - Bauprojekte, Forschung, etc. abschieben). Der BE würde da vermutlich aktive Animationen (Figuren-Bewegungen, Geschosse, Explosionen, etc.) weiterlaufen lassen.
Die Formulierung "Geoscape-Zeit einfrieren" war natürlich nur eine Vereinfachung (der Effekt ist ja der selbe).

Auch wenn es sehr reizvoll wäre, den Bodeneinsatz in ein eigenes Programm auszulagern, ist der Datenaustausch zwischen Hauptspiel und Bodeneisatz zu umständlich.

PS: Ein paar mehr Kommentare im Source würden nicht Schaden...

In meinem? Wo denn zum Beispiel?

@JohnS: Assets werden jetzt gefunden und geladen. Fehlende Dateien werden geloggt und im Falle von Bildern durch 250x250 Pixel stechendes Magenta ersetzt. Das Dateiformat ist leider noch recht ekelhaft (und kein XML), bin noch nicht dazu gekommen, daran zu arbeiten.
Das aktuelle Format ist bei Quellcode-Repository (assets.json, img/assets.json, scripts/assets.json) einzusehen, aber das ist momentan nichts für schwache Nerven ^^ Grade die vielen IDs stören und sollten unnötig sein... ich werd mir was überlegen, dem zuständigen Code diesen Fakt mitzuteilen.

Update bezüglich des obigen: Habe am speichern und laden rumgewurschtelt und so langsam sieht es ziemlich annehmbar aus. Ich präsentiere, das aktuelle Format:

assets/assets.json

{
  "include_dirs": ["img", "scripts"],
  "assets_here": []
}

assets/img/assets.json

{
  "include_dirs": [],
  "assets_here": [
    {"filename": "geoscape.png", "mime_type": "image/png"}
  ]
}

assets/scripts/assets.json

{
  "include_dirs": [],
  "assets_here": [
    {"filename": "hello_world.py","mime_type": "text/x-python"}
  ]
}

Zur Klarheit, dass sind drei Dateien mit Metadaten für eine Verzeichnisstruktur mit zwei Unterordnern, einer mit einer PNG-Datei und einer mit einem Skript. Anhand dieser kann anderer Code dann die Datei mit einem relativen Pfad (z.B. "img/geoscape.png") öffnen.

Du erklärst zwar immer in den Kommentaren, was du dir bei diesem Teil gedacht hast, aber eine Beschreibung des Quellcodes gibt's nicht wirklich. Die models.py ist ein Beispiel dafür. Da gibst du am Anfang nur an warum etwas nicht funktioniert. Außerdem sind meine zwei Lieblingskommentare in dem File:

99 # This may be overly pessimistic...

Ja, was denn?

104 # magic

Häh?

Es fehlt zu vielen Funktionen eine kurze Beschreibung.

Die assets.py ist dir da schon besser gelungen, da ist überall eine Beschreibung vorhanden, es wäre allerdings noch praktisch, bei der _process_asset_dir zB, welcher Schritt gerade abgehandelt wird, sowie wie das mit dem Errorimage.

PS: Schönes neues Jahr!

Nun, ich bin Anhänger der "Der Code soll klar machen was und wie, die Kommentare sollen nur sagen warum"-Fraktion. Von daher werde ich selten einen Kommentar wie "Gib die Länge des Vektors zurück" zu einer Methode "Vector.length()" schreiben, falls du sowas meinst ;)
Aber es kann sehr gut sein, dass ich selbst nach diesem Maßstab schludere.


... braucht in der Tat eine Beschreibung, wozu der ganze Kram überhaupt dient, wie das ganze aufgebaut ist und was wie einige trickreiche Attribute zu interpretieren sind. Ist mir grade gestern wieder aufgefallen, als ich noch ein Feature reingequetscht habe.


Japp, da gehört entweder Kontext zu (sollte eine Abkürzung werden, mit der Klassen auf sich selbst verweisen können)... oder am besten wird's direkt gelöscht, da die Idee schon länger tot ist, aus den beschriebenen Gründen.

Zu "overly pessimitic":
Kommentare beziehen sich (bei mir und bei fast allem anderen Code, den ich unter die Augen kriege) grundsätzlich auf die folgende(n) Zeile(n). In dem Falle also auf "is_value_type = False". Könnte man sicher noch mehr zu sagen (werde ich auch - ich glaube, mache ich jetzt direkt), dass wäre dann aber allgemeingültiger, gehört also an eine andere Stelle.

Zu "magic":
Wieder die folgenden Zeilen. Hätte ein XXX oder TODO verdient, ich bin mit der Trickserei an der Stelle nämlich alles andere als zufrieden.

Frohes neues!

Nein, da stimme ich dir zu, es geht mir um Dinge wie die von dir erwähnte "Trickserei" zu erklären und solche Dinge.

Inzwischen ist die angesprochene Trickserei verschwunden, und Models wurden größtenteils dokumentiert, wobei man da sicher noch was hinzufügen kann. Das würde ich wahrscheinlich bei Gelegenheit machen, wenn ich das nächste mal über sowas stolper.

Wie sieht's eigentlich mit deiner Einarbeitung aus? Mir scheint, du könntest langsam mit programmieren anfangen ;)

Ein Tipp:
Ihr solltet möglichst früh das Programm unterteilen und Schnittstellen zwischen den Bereichen definieren und dann festlegen, wer welche dieser Teilbaustellen umsetzen soll.

Vorher solltet ihr gar nicht erst versuchen mit mehreren Leuten zu programmieren, sonst werdet ihr früher oder später bei Änderungen durcheinander kommen...

Aber natürlich. Was anderes wäre mir nie in den Sinn gekommen ;)

Ich möchte das Ganze noch auf meinem Linux zum Laufen bringen (derzeit zickt noch 3.2 mit der 2.6 herum) und dann noch ein bisschen am aktuellen Code ein paar Versuche starten.

Für die Zwischenzeit:
Die Bilder der NASA sind frei zugänglich und nach belieben verwendbar, wäre was für den Geoscape, oder? Das Wikipediabild ist zB von der NASA und hat eine "ausreichende" Auflösung:
http://de.wikipedia.org/wiki/Datei:Nasa_land_ocean_ice_8192_jpg90.JPG
dem einem oder anderem wird es vieleicht bekannt vorkommen...

Um mal einen Statusbericht abzugeben... ich gehe mal nach den Stichpunkte der Roadmap vor.


Sind seit geraumer Zeit fix.

Ich habe an den Metaprogramming-Modulen, die das speichern und laden automatisch generieren, weiter gearbeitet. Das Format ist jetzt YAML statt JSON, was ich persönlich lesbarer finde, und es gibt etwas mehr Kontrolle über das Ausgabeformat. Inzwischen gibt's dank dieser Module sowohl Spielstände und Spielsätze, beide auf mehrere Dateien verteilt und definitiv vollständig.
Den einen existierenden Spielsatz habe ich übrigens in kürzester Zeit komplett per Hand geschrieben.
Das funktioniert selbst ohne extra Editor ganz gut wenn man das Datenschema kennt (und da jetzt ein Beispiel existiert, steht in Zukunft nie wieder einer ohne alles da und muss das Schema aus dem Programmcode ablesen).

Auch zu erwähnen wäre, dass auf der Basis ein paar (Kommandozeilen-basierte, aber immerhin) Tools existieren. Bis auf eins sind die alle kleiner als 50 Zeilen und in weniger als einer Stunde entstanden, aber haben sich dennoch als sehr nützlich erwiesen. Bisher gibt's vier:
- Eins um die Formatierung, die Reihenfolge der Einträge, etc. normalisieren.
- Eins um die interne "ID" eines Objektes zu ändern (unterscheidet sich dadurch vom manuellen ändern, dass es alle Referenzen findet und ändert).
- Ein eher internes und experimentelles, das die Daten mit einer Version des Programms lädt und mit einer anderen wieder speichert. Offiziell ist der Zweck, Änderungen in Datendarstellung und dergleichen umzusetzen. Inoffiziell ist es auch schonmal Vorarbeit für ein eventuelles Tool, um Daten von einer Version zur nächsten zu portieren (z.B. Standardwerte für neue Felder hinzufügen).
- Ein sehr nützliches, welches sowohl ungültige IDs als auch unbenutzte Objekte findet.

Wie schon auf dieser Seite gezeigt, hier gibt's wenig neues außer das das Format weniger {} enthält da es jetzt YAML statt JSON ist.

Immer noch kein zentraler Sammelpunkt. Vielleicht leg ich mir nen Server und ne Domain zu...

Nix neues, außer einem verrückten Einfall:
Wie wäre es, KI-Skripte (oder zumindest einige) in eigenen Prozessen laufen zu lassen? Python ist eher mies dran bei Multithreading, aber Multiprocessing ist gut unterstützt.
Mit mehreren Prozessen hätte man auch die Rechenleistung, Dinge wie Pfadfingung und vorrausschauende Planung in Skripten zu regeln.
Außerdem vermeidet man mit Prozessen statt Threads (sprich, explizite Kommunikation statt wildes shared memory) jede Menge Kopfschmerzen beüglich thread-safety.
Dem Gegenüber steht natürlich, dass man irgendwie mit dem Hauptprozess kommunizieren muss. Vor allem sollten Änderungen "atomic" Geschehen. Lässt sich sicher alles regeln, aber wird trotzdem einiges an Grübelei und Experimenten erfordern. Und wird wahrscheinlich gewissen Einfluss auf die Skripte haben.




Nix neues.

Ist weiterhin 2D und soll es bleiben.
Positionen werden immer in Längen- und Breitengrad (mit Minuten und Sekunden, was laut Wikipedia eine Genauigkeit von 30 Metern ergibt) angegeben und nur für die Darstellung umgewandelt.

Zum Luftkampf nix neues, Kollisionen werden erkannt aber nix weiter passiert. Aber immerhin können UFOs und Flugzeuge per Klick ausgewählt und per Rechtsklick auf ein neues Ziel gehetzt werden. Selbstverständlich wird Position und Ziel wie oben beschrieben dargestellt.

Sind vorhanden, werden dargestellt, aber ansonsten nichts viel. Sie interagieren nichtmal mit anderen Geoscape-Objekten.

Im Datenmodell drin (ich könnte den Spielsatz nehmen und in einer Datei unter jeden englischen Text eine deutsche Übersetzung schreiben), es fehlt nur noch Sprachauswahl und im eigentlichen Spiel werden noch keine solcher Texte dargestellt.

Ach ja, zu NASA-Bildern:

Ich habe mich stattdessen direkt an der Quelle (Blue Marble-Projekt) bedient. Daher kommt das aktuell verwendete Geoscape-Bild, und es ist auch eine Topographische Karte vorhanden die man z.B. benutzen könnte um eine akkurate Land/Wasser-Maske zu erstellen.

Und zur Erinnerung, der Quellcode ist offen einsehbar (und Mitarbeit ist willkommen!). Der Beispiel-Spielsatz liegt im Ordner "gameset-default".

Hmm, ehrlich gesagt, sehe ich da nicht so den ganz großen Vorteil. Die Frage ist natürlich, ob man bei einem Rundenbasierten Ansatz bleiben will. Wenn ja, dann dürften sowieso nie 2 AI-Skripte gleichzeitig zu tun haben, sondern alles schön der Reihe nach ablaufen. Oder an was hast du dabei gedacht?

Ja, der BE soll rundenbasiert bleiben.

Ich bin ehrlich gesagt auch nicht überzeugt.
Der einzige Vorteil wären: Skripte, die (zumindest eine Zeit lang) viel zu arbeiten haben, könnten das tun ohne die KI-Runden in die Länge zu ziehen (BE) bzw ohne den Geoscape langsamer laufen zu lassen. Beispiele wären wie gesagt Pfadfindung oder komplizierte strategische Planungen. Und wenn man das schon macht, kann man es sicher auch auf den Geoscape erweitern, wer weiß was den Spielsatzerstellern da so einfällt. Prinzipiell klingt mehr Nebenläufigkeit nach mehr Rechenpower = Freiheit für Skripter, und das wäre gut.
Dem Gegenüber steht natürlich beträchtlicher Aufwand. Und weil die Frage "synchron oder asynchron?" beeinflusst, wie die Skripte geschrieben werden (Änderungen an Spieldaten müssen entweder synchronisiert werden oder sonstwie atomisch werden), sollte sowas entschieden werden, bevor allzu viele Skripte entstehen...

Naja, damit schlage ich mich nochmal herum, wenn ich mich an die Skripte mache. Erstmal steht anderes an:

- Luftkampf (zumindest in Grundzügen - ein einfacher Simulator)
- Spielstand- und Spielsatz-Auswahl (eventuell fang ich bei der Gelegenheit an, Bildschirme aus Dateien zu laden statt den Code per hand zu schreiben).
- Datenkonsistenz/Verifizierung (zur Zeit ist es noch recht einfach, unvollständige oder ungültige Daten zu laden und viel später eine nutzlose Fehlermeldung zu kriegen).

Hmm, also ich bin da skeptisch (auch wenn du erst später darüber nachdenken willst ;)). Das fängt ja schon bei deinem Beispiel Pfadfindung an. Wenn Skripte parallel laufen könnten, dann wäre es nicht mehr möglich, einen Ist-Zustand der Karte zu nehmen, mit einem vergleichsweise einfachen Algorithmus den optimalen Weg zum Ziel zu berechnen, und dann die Einheit zum Ziel zu schicken. Vielmehr müsste ständig geprüft werden, ob der Pfad noch gültig ist (bzw. ein neuer Pfad berechnet werden, weil z.B. eine andere Einheit plötzlich im Weg steht). Ich bin zwar kein AI-Experte, aber ich bin mir ziemlich sicher, das ein solcher Ansatz deutlich rechenaufwendiger ist.

Es gibt 1 Million gute Spiele, die in Echtzeit laufen, aber nur wenige die rundenbasiert sind. Wäre ich damals über ein X-Force gestolpert, was in Echtzeit gelaufen wäre, würdet ihr meinen Posting jetzt nicht lesen. Echtzeitstrategie hat nicht wirklich was mit Strategie zu tun, das ist da eher sekundär. Echtzeit ist immer die Challenge gegen den schnelleren Computer. Das mache ich manchmal, wenn ich gerade nichts im Kopf habe, bis ich dann irgendwann angewidert von einen Computergegner bin, der alle seine 100 Einheiten zeitgleich steuert, während die eigenen Einheiten an allen Ecken doof agieren, wenn man sie länger wie ne Sekunde aus den Augen lässt. Bitte keine Echtzeit, das braucht die Welt nicht mehr, bzw. ich. Da habe ich den ganzen Schrank voll mit. Es fehlen definitiv gute rundenbasierte Spiele, wobei der Fanmarkt da wahrscheinlich kleiner zu sein scheint?

Und ja Echtzeit-Ki braucht einen guten und schnellen Wegefinde-Algoryhmus. Der ist aber im Vergleich zu dem Ki-Algorhytmus eines guten rundenbasierten Spieles ein Witz. Hier sehe ich sowieso noch das größte Defizit in den bisher auf den Markt so rumschwirrenden rundenbasierten Games. Rundenbasierte Ki´s sind schnell vom Menschen ausgetrickst und die meisten rundenbasierten KI´s bekommen bei zunehmender Schwierigkeit meist mehr Resourcen. Also Masse statt Klasse.

Darüber solltet ihr euch auch Gedanken machen, beim Rewrite, was man nachher an KI-Power zusammenbasteln will. Auf jedenfall ne Möglichkeit für die Scripter, wenn nicht sogar nochmal eine eigene KI-Sprache drübergelegt. Dann muss die Ki noch an Informationen kommen, je mehr desto besser, ausserdem sollte die KI ihre Einheiten über die gleichen finalen Routinen steuern, wie der Mensch, und ne gute Portion vom Speicher sollte man ihr auch geben. Will man längerdenkende Ki-Strukturen entwickeln, sollte die KI auch noch Dateizugriff haben.