Banner left   Banner center   Banner right

Germanenglish Home · News · Diary · Screenshots · Documentation (Wiki) · Downloads · Guestbook · Forum

Home · Benutzer registrieren · Suchen · Statistik · FAQ · Benutzerliste

Zur Zeit online: keiner ausser dir

 X-Force - Fight For Destiny - Forum —› Quellcode / Programmierung —› [Rewrite] Planung + Organisation

Seite: << [1] [2] 3 [4] [5] [6] [7] [8] [9] [10] >>

Autor Mitteilung
verfasst am: 30.12.2011, 15:18
Grafiker

Registrierdatum: 06.03.2005, 16:04

 Beiträge: 460
Zitat: Nedar
Zitat: JohnS
Es gibt nicht umsonst so wenige Animationen, weil deren Herstellung extrem arbeitsaufwendig und fehleranfällig ist.

Was hat das mit den Interna des BE zu tun?


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.
verfasst am: 30.12.2011, 16:39
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Zitat: JohnS
Reicht doch zu sagen hier hab ich die neuste vom Geoscape generierte xml und fütter damit meine BE.

Ü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.
verfasst am: 30.12.2011, 20:02
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Zitat: sujin
Ob nun die Geoscape-Zeit einfriert und der BE

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...
verfasst am: 30.12.2011, 20:38 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
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).
verfasst am: 31.12.2011, 16:08
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
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...
verfasst am: 31.12.2011, 16:17
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Zitat: Kreks
PS: Ein paar mehr Kommentare im Source würden nicht Schaden...

In meinem? Wo denn zum Beispiel?
verfasst am: 31.12.2011, 19:35 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
@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.
verfasst am: 01.01.2012, 19:29 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
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.
verfasst am: 02.01.2012, 12:07
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
Zitat: sujin
In meinem? Wo denn zum Beispiel?

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!
verfasst am: 02.01.2012, 12:39 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Zitat: Kreks
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.

Zitat: Kreks
Es fehlt zu vielen Funktionen eine kurze Beschreibung.

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.

Zitat: Kreks
models.py

... 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.

Zitat: Kreks
Da gibst du am Anfang nur an warum etwas nicht funktioniert.

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!
verfasst am: 02.01.2012, 17:59
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
Zitat: sujin
"Gib die Länge des Vektors zurück"

Nein, da stimme ich dir zu, es geht mir um Dinge wie die von dir erwähnte "Trickserei" zu erklären und
Zitat: sujin
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.
solche Dinge.
verfasst am: 02.01.2012, 18:45 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
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 ;)
verfasst am: 03.01.2012, 08:45
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Zitat: sujin
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...
verfasst am: 03.01.2012, 13:11
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Aber natürlich. Was anderes wäre mir nie in den Sinn gekommen ;)
verfasst am: 04.01.2012, 15:49
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
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...
verfasst am: 05.02.2012, 20:29 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Um mal einen Statusbericht abzugeben... ich gehe mal nach den Stichpunkte der Roadmap vor.

Zitat: sujin
Zeitschritte

Sind seit geraumer Zeit fix.
Zitat: sujin
Spieldaten

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.
Zitat: sujin
Assets

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.
Zitat: sujin
Grafiken

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

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.
Zitat: sujin
Geopolitik, Arbeitsmarkt und Handel

Zitat: sujin
Forschung

Zitat: sujin
Bodeneinsatz

Zitat: sujin
Items

Nix neues.
Zitat: sujin
Geoscape

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.
Zitat: sujin
Luftkampf

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.
Zitat: sujin
Basen

Sind vorhanden, werden dargestellt, aber ansonsten nichts viel. Sie interagieren nichtmal mit anderen Geoscape-Objekten.
Zitat: Kreks
Sprachunterstütztung

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:
Zitat: Kreks
Die Bilder der NASA sind frei zugänglich und nach belieben verwendbar, wäre was für den Geoscape, oder?

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".
verfasst am: 07.02.2012, 20:22
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: sujin
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.

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?
verfasst am: 07.02.2012, 21:22 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
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).
verfasst am: 07.02.2012, 23:45 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: sujin
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.

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.
verfasst am: 08.02.2012, 23:36 · Edited by: Kamor
Registrierdatum: 20.07.2005, 00:01

 Beiträge: 203
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.

Seite: << [1] [2] 3 [4] [5] [6] [7] [8] [9] [10] >>




Du musst dich registrieren um auf dieses Thema zu antworten.
Login :: » Name » Passwort

Ladezeit (sec.): 0.015 · Powered by miniBB 1.6 with parts of 1.7 © 2001-2003