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] .. [22] [23] >>

Autor Mitteilung
verfasst am: 28.12.2011, 22:58
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: Nedar
Der Bodeneinsatz sollte am Besten wie ein eigenes Programm behandelt werden.

Ehrlich gesagt hab ich bis heute nicht verstanden, wo da der Vorteil liegen sollte (die Idee ist ja schon alt). Nur mal so als Anmerkung - es reicht nicht, einfach nur Soldaten und Items an den Bodeneinsatz zu übergeben. Man braucht Zugriff auf alle Daten (UFOs, Basen, Länder, Skriptvariablen usw.). Sonst schränkt man den Spielsatzersteller (insbesondere den Skripter) stark ein. Diesem Aufwand steht imho 0 Nutzen entgegen.
verfasst am: 29.12.2011, 02:34
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Ich würde sagen auch dann kann man es als eigenes Programm sehen. Allerdings eben ein Programm, das Zugriff auf gewisse Daten hat. Mit eigenes Programm meine ich auch nur, dass man den Bodeneinsatz theoretisch alleine starten könnte, wenn man ihm Zugriff auf ein gewisses Datenpaket gibt (dieses kann ja dann beliebig Daten enthalten). Der Vorteil davon ist, dass man schneller Tests für den Bodeneinsatz durchführen kann. Insbesondere bei KI-Tests kann es doch recht nervig sein, wenn man ständig einen Spielstand laden muss, bei dem der Transporter gleich ankommt.

Da wäre es viel praktischer, wenn man beispielsweise eine XML-Datei hätte, aus der man einen Bodeneinsatz laden kann. In der Datei wären dann alle Daten gespeichert, die man für den Einsatz braucht und man könnte diese auch schnell ändern (beispielsweise, um ein neues Alien einzufügen oder das KI-Skript von einem Alien zu ändern). Und wenn man den Bodeneinsatz aus dem Spiel startet, dann kann man sich diese XML-Datei ja schnell erzeugen lassen (man kann ja eventuell bei jedem Skript noch eine Importliste erstellen, welche Werte aus dem Spielsatz benötigt werden und diese dann bei der Erzeugung der XML-Datei gleich mit hineinladen).

Das wäre zumindest meine Idee zu dem Thema, vielleicht fällt jemandem noch etwas besseres ein.
verfasst am: 29.12.2011, 09:02 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ich sehe das so: Es wird schwer zu rechtfertigen, dafür großen Aufwand zu betreiben. Ich für meinen Teil werde nicht über drei Wochen zehntausend Zeilen Code schreiben, um XML-Dateien zu parsen, um dazu genau das gleiche zu erreichen wie das reguläre laden des Spielstandes und ein paar Klicks.

Andererseits sollte der Bodeneinsatz, und das laden von Daten, ohnehin relativ modular aufgebaut sein. Und dann kann man genausogut eine zweite ausführbare Datei erstellen, die nur den Spielstand (und natürlich Spielsatz, Spielkonfiguration, etc.) lädt, von irgendwo (bestehendes UFO, oder halt ne extra Datei - diesen Kram wird man ohnehin speichern und laden können müssen, wenn man im BE speichern will) einen Bodeneinsatz konstrutiert. Sollte dann natürlich keine Auswirkungen auf den Spielsatz haben. Aber zum testen sollte es reichen, und relativ wenig Arbeit erfordern, mal abgesehen von der Disziplin, modularen Code zu erstellen. Aber da mir das eh ein Bedürfnis ist und es noch ganz andere Vorteile hat... ;)

Das ist aber alles Zukunftsmusik. Da kann man nochmal kurz dran denken, wenn man den BE plant, aber eigentlich sollte jeder sinnvolle Weg, das zu machen, wenig mehr als eine mäßig modular aufgebaute BE-Engine erfordern.
verfasst am: 29.12.2011, 09:59
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Es hängt auch sehr stark von der jeweiligen Aufteilung ab.

Die Verwaltung für den Bodeneinsatz benötigt relativ viele Zugriffe auf die Geoscape-Daten (z.B. Position für Kartenauswahl, Vertrauensänderung je nach Ergebnis und Zerstörung von Kartenstrukturen etc), die reine Durchführung dagegen weniger Abstimmung.

Wenn man die Schnittstelle gut wählt und umsetzt, dann könnte man den Bodeneinsatz auslagern, aber das ist keine triviale Frage und Fehler in dieser Planung würden einiges an Fehlerpotential haben.
verfasst am: 29.12.2011, 10:30 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Zitat: DirkF
Zugriffe auf die Geoscape-Daten (z.B. Position für Kartenauswahl, Vertrauensänderung je nach Ergebnis und Zerstörung von Kartenstrukturen etc)

Mal ganz davon abgesehen, dass sich vieles davon vermutlich ohne großen Aufwand vermeiden lässt (BE-Engine kriegt Kartendaten vorgekaut, statt sie selbst rauszufinden; Ländervertrauensänderungen werden protokolliert und an den Geoscape zurückgegeben damit der die Umsetzt, etc.) sehe ich nicht ganz, wie das (zumindest bei meinem Ansatz) ein Problem wäre. Man würde quasi nur den Teil "Spielstand laden, BE lostreten, auf Ende des BE warten, ohne speichern beenden" automatisieren. Und eventuell ein Skript dazupacken, dass den BE vorher erstellt, was ja ohnehin möglich sein soll. Man müsste allerhöchstens (aber auch das wäre nicht nötig, wenn die BE-Engine nicht allzu kontrollsüchtig ist) noch ein paar Formsachen erledigen - Transporter herzaubern, Soldaten reinteleportieren, Transporter mit Überlichtgeschwindigkeit zum BE schicken.

Aber vielleicht übersehe ich was, oder ihr habt von den vielen potenziellen Problemen noch garnicht die schwerwiegensten erwähnt ;)

Nebenbei: Ich mache mich jetzt daran, den Geoscape auf fixe Zeitschritte umzustellen.
verfasst am: 29.12.2011, 11:28 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Ihr seht nur die statischen Daten. Wieso sollte sich nicht z.B. im Bodeneinsatz das Vertrauen eines Landes ändern, und dieses (noch während des Bodeneinsatzes) dann per Skript XY ein bestimmtes Ereignis auslösen? XY könnte dabei von allen per Skript zugänglichen Größen abhängen, man müsste also alle Daten per XML parsen, nicht nur eingie ausgewählte. Und wie will man events umsetzen? Ein Kartenskript könnte z.B. bei Zerstörung eines bestimmten Objektes ein entsprechendes Event in der Basis auslösen - ich weiß nicht genau, wie man das Eventsystem in einer anderen Programmiersprache umsetzen kann, allerdings dürfte es schwierig sein, dass per XML zu erreichen.

2 andere Anmerkungen. Zum einen, man kann die Skripte beim laufendem Spiel ändern - man muss also nur die Autosave neuladen, um Änderungen zu testen. Hier sollte man eher überlegen, welche Daten immer aus dem Spielsatz geladen werden, und welche nur beim Starten eines Spieles(Spielstandes). Außerdem könnte man ja im Startmenü einen Simulationsbereich ergänzen (gab es früher schonmal für Luftkämpfe).
verfasst am: 29.12.2011, 11:58 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Zitat: Natter
Ihr seht nur die statischen Daten.

Ich für meinen Teil muss mich gegen diesen Vorwurf wehren ;) Ich sage doch, man müsste das ganze Spiel laden (ob nun durch ein seperates XML-Format oder indem man bestehende Spielstände umfunktioniert).

Zitat: Natter
Wieso sollte sich nicht z.B. im Bodeneinsatz das Vertrauen eines Landes ändern, und dieses (noch während des Bodeneinsatzes) dann per Skript XY ein bestimmtes Ereignis auslösen?

Das "noch während des Bodeneinsatzes" ist in der Tat ein sehr guter Einwand gegen den Ansatz "seperates Programm".

Zitat: Natter
Außerdem könnte man ja im Startmenü einen Simulationsbereich ergänzen (gab es früher schonmal für Luftkämpfe).

Wenn man schon dabei ist, ginge das vermutlich auch. Dann bracht das aber auch eine Benutzeroberfläche zusätzlicher zur API, daher etwas komplizierter.
verfasst am: 29.12.2011, 14:23 · Edited by: Nedar
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Ich würde trotzdem sagen, man kann den Bodeneinsatz als eigenes Programm sehen (vielleicht gefällt euch der Begriff Modul besser). Nur dass dieses Programm eben Zugriff auf die "Spielstanddatenbank/Spielsatzdatenbank" bekommt und somit alle Daten lesen und schreiben kann. Ihr habt mich aber überzeugt, dass das mit dem XML keine gute Idee ist. Zuviel Aufwand und keine wirklichen Vorteile. War wohl doch etwas spät, als ich das geschrieben habe.

Besser ist es, wenn man im Spiel auch Bodeneinsätze direkt starten kann (also ohne vorher hinzufliegen oder Soldaten auszurüsten oder ähnliches, Sujin hat ja schon was ähnliches erwähnt). So könnte man beispielsweise auch im Spiel einen Einsatz starten, wo einfach nur eine Miliz in irgendeiner Stadt gesteuert wird, die Feinde abwehren soll, ohne dass die Soldaten der Miliz vorher im Spiel vorhanden wären. Es würde dann also nicht die Nachricht "Bodeneinsatz entdeckt" im Spiel kommen, sondern nur ein kurzer Beschreibungstext und ein Button "Bodeneinsatz starten", ohne die Möglichkeit, die Zeit weiterlaufen zu lassen.
verfasst am: 29.12.2011, 14:41
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Modul ist für die meisten Programmierer was deutlich anderes als Programm ;) Aber völlig abgekapselt wie ein ideales Modul wird es garnicht sein können, wie schon groß und breit diskutiert. Man kann einfach nur darauf hinarbeiten, dass es nicht allzu viele unnötige Abhängigkeiten hat.

Aber das ist für mich soweiso unabhängig von diesem speziellen Anwendungszweck. Das ist ganz einfach ne Sache von Qualität, Wartbarkeit und Robustheit gegen Änderungen in anderen Programmteilen.
verfasst am: 29.12.2011, 14:46 · Edited by: Nedar
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Bin mit den genauen Begrifflichkeiten nicht gut vertraut. Was ich auch eigentlich damit ausdrücken will ist, dass immer nur eines der beiden Module läuft und nie beide gleichzeitig. Es ist also entweder ein Bodeneinsatz oder man ist im Geoscape und kann die Zeit weiterlaufen lassen. Somit sind die beiden zwar von den gleichen Daten abhängig, aber es gibt immer nur einen, der an den Daten etwas ändert oder davon liest. Was anderes wäre, wenn die Zeit während dem Bodeneinsatz weiterlaufen würde, also beispielsweise eine halbe Minute in jeder Runde vergehen würde.
verfasst am: 29.12.2011, 14:49 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Achso! Davon bin ich selbstverständlich ausgegangen. War doch bisher auch immer so (oder? ich könnte schwören...), und es hat nie jemanden gestört oder wurde auch nur angedacht.

Ich sehe aber nicht das Problem damit. Der BE wird definitiv rundenbasiert sein (Echtzeit hat XF ja probiert, gab diverse Probleme und letztlich war es abgeschafft), also könnte man auch nach jeder Runde den BE anhalten (merkt ja keiner solang das Display nicht einfriert) und einfach ein paar Zeitschritte auf dem Geoscape machen. Das ist mehr eine Gameplay-Frage als eine technische.
verfasst am: 29.12.2011, 14:56 · Edited by: Nedar
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Ich sehe da schon eine technische Frage dahinter. Wenn der Geoscape pausiert ist, dann passiert dort nichts. Wenn er aber in jeder Runde weiterläuft, dann kann während dem Bodeneinsatz etwas passieren. Dann müsste man sich auch überlegen, ob man während dem Bodeneinsatz in den Geoscape wechseln kann, da ja dort etwas passiert sein kann, was die Aufmerksamkeit des Benutzers fordert (beispielsweise ein neues Ufo, das abgefangen werden muss).

Deswegen wollte ich nur sagen, dass mit dem derzeitigen System der Bodeneinsatz im gewissen Sinne unabhängig vom Rest des Spiels funktioniert, da er zwar auf die Daten des Spiels zugreift, aber gleichzeitig der einzige ist, der auf die Daten zugreift und diese evtl. ändert. Somit ist eben der Bodeneinsatz ein Unterprogramm/Modul/wasweißich, das alleine für sich selbst arbeitet und halt die Daten eventuell verändert, während es läuft. Deswegen hatte ich es als eigenes Programm bezeichnet.
verfasst am: 29.12.2011, 15:07 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Ah, Fokus für den Spieler könnte in der Tat ein Problem sein. Aber wie gesagt, wenn der Code nicht allzu unmodular ist, sehe ich das relativ locker. Ich hatte sowieso geplant, die Anzeige des BE genauso zu regeln wie alle anderen "normalen" Bildschirme geregelt sind. Dort wird z.B. auch zwischen "Bildschirm neu rendern" und "die Spielwelt einen Zeitschritt weiter simulieren" unterschieden und beides wird nicht vom Bildschirm selbst, sondern von außern gesteuert.

Den BE als weiteren Bildschirm zu behandeln, ist einfach und erlaubt jederzeit, zwischen aktiven Bildschirmen zu wechseln. Eigentlich macht es auch garkeinen Sinn, sowas für den BE neu zu machen. Man muss ja sowieso ins Inventar und ins Menü wechseln können, Widgets positionieren können, etc.
verfasst am: 29.12.2011, 15:31
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Außerdem würde bei einem Weiterlaufen der Zeit während eines Bodeneinsatzes hinzukommen, dass es dann mehrere Bodeneinsätze zur gleichen Zeit geben kann. Das würde das ganze noch etwas komplizierter machen.
verfasst am: 29.12.2011, 15:41 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Es kann mehrere Stellen geben, an denen ein Bodeneinsatz gestartet werden könnte. Aber ich denke nicht, dass es nötig ist, dass man mehrere Bodeneinsätze gleichzeitig erlaubt. Man könnte es sicher regeln, es wäre nur umständlicher (man müsste mehrere Engines laufen lassen, und dem User eine brauchbare UI geben um zwischen denen wechseln zu können).

Aber in jedem Fall guter Einwand, jetzt können wir von Anfang an verhindern, dass ein BE startet während ein anderer noch läuft.
Natürlich ist das alles nur relevant, falls wir entscheiden sollten, dass die Zeit während des BEs weiterlaufen soll. Meinungen dazu?
Wie gesagt, davon bin ich alles andere als überzeugt.
verfasst am: 29.12.2011, 16:45
Grafiker

Registrierdatum: 06.03.2005, 16:04

 Beiträge: 460
Der Vorschlag zur Trennung BE und Hauptprogramm aus meiner Sicht ist, das man die Grafikengine, Physik im BE leichter tauschen kann, als wenn das fest zum Geoscape verdrahtet ist.

Wenn ich im BE bin, erwarte ich eigentlich das die Welt pausiert, und ich evtl sogar im BE speichern kann. Die Benachrichtigung zurück erfolgt doch ohnehin am Ende des Einsatzes, ob der erfolgreich war oder nicht. Die Besonderheiten gelangen doch wie das Beutegut ebenso zurück.

Außerdem würde eine Trennung es Spielsatzerstellern leichter machen abstraktere Spielsätze zu erstellen, wie z.Bsp das man Alien spielt und die Erde besetzt, oder ggf. Unterwassermissionen. Gut beides geht evtl auch mit den jetzigen Mitteln.

Es gibt nicht umsonst so wenige Animationen, weil deren Herstellung extrem arbeitsaufwendig und fehleranfällig ist.
Geoscape und Basis sind zum Großteil statische Sachen, wobei man natürlich auch den BE aus Zeitgründen erstmal in PacMan-Manier abbilden könnte. Ist beides nicht getrennt, wird der Austausch der BE-Engine deutlich komplizierter.
verfasst am: 29.12.2011, 17:30
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
Zitat: JohnS
Der Vorschlag zur Trennung BE und Hauptprogramm aus meiner Sicht ist, das man die Grafikengine, Physik im BE leichter tauschen kann, als wenn das fest zum Geoscape verdrahtet ist.

Diese Teile haben ohnehin nichts mit dem Geoscape zu schaffen. Wenn ich sage, dass ich unnötige Abhängigkeiten vermeiden will, was meinst du wovon ich rede? ;)

Zitat: JohnS
Wenn ich im BE bin, erwarte ich eigentlich das die Welt pausiert, und ich evtl sogar im BE speichern kann.

Für's pausieren des Geoscapes während des BEs bin ich sowieso.
Speichern will ich auch, da werde ich auch drauf achten dass das nicht unnötig erschwert wird.

Zitat: JohnS
Die Benachrichtigung zurück erfolgt doch ohnehin am Ende des Einsatzes, ob der erfolgreich war oder nicht. Die Besonderheiten gelangen doch wie das Beutegut ebenso zurück.

Natter hat nicht ganz unrecht. Alle Änderungen, die in einem Geoscape-Skript sofort passieren würden, sollten logischerweise auch ohne Einschränkungen von BE-Skripten ausgelöst werden können. Und selbstverständlich sollte da kein sichtbarere Unterschied sein (z.B: wenn das wiederum ein anderes Event auslöst). Es gibt IMHO keinen logischen Grund dagegen. Man könnte höchstens mit Arbeitsaufwand argumentieren, und das auch nur, wenn man vor einem bestehenden Programm steht, dass beides zu strikt trennt. Aber wir schreiben's ja extra neu, damit wir sowas vermeiden können.

Zitat: JohnS
Außerdem würde eine Trennung es Spielsatzerstellern leichter machen abstraktere Spielsätze zu erstellen, wie z.Bsp das man Alien spielt und die Erde besetzt, oder ggf. Unterwassermissionen. Gut beides geht evtl auch mit den jetzigen Mitteln.

Sowas soll definitiv möglich sein. Dafür muss man:
- Eine klare Schnittstelle für den BE definieren und sich dran halten.
- Skripten Zugriff auf viele Details geben

Aber man muss nicht dermaßen strikt trennen, dass sämtliche Änderungen außerhalb des BE protokolliert und erst danach umgesetzt werden. Das ist auch wieder enormer Arbeitsaufwand (man müsste auch alle Skripte einschränken, oder Aufwand betreiben um es transparent zu gestalten), und bringt für sowas keinen Vorteil. Der einzige Vorteil wäre, dass man den BE wortwörtlich als seperates Programm (eigene exe, die die Hälfte des Spiels garnicht lädt) laufen lassen kann. Aber davon war nie die Rede und das erachtet wohl auch keiner für sinnvoll.

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?
Aber wo du es ansprichst, wir können und sollten über die Wahl der Grafiformate reden. Ich denke, ich experimentiere als nächstes mit der Organisation und dem Laden von Assets, dann kann ich mehr dazu sagen, was möglich und was einfach ist.
verfasst am: 29.12.2011, 17:49
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Ich bin auch dafür, dass der Bodeneinsatz den Geoscape pausieren sollte. Dadurch wird die Bedienung und die Programmierung um einiges einfacher (auch wenn es sicher seinen Reiz hätte, wenn man beispielsweise in einem Einsatz noch Verstärkung mit einem anderen Transporter holen könnte *grins*).
verfasst am: 29.12.2011, 21:56
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
Ich unterstütze den Antrag! Das bringt doch nichts die Welt im Hintergrund weiterlaufen zu lassen.
verfasst am: 29.12.2011, 23:50 · Edited by: Nedar
Registrierdatum: 23.09.2008, 00:25

 Beiträge: 67
Es gibt ja eigentlich eh keinen Antrag. Ich hatte ja mit der Idee nur eine andere Sache erklären wollen.

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




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

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