Hui ganz schön was los hier. So schnell kann man gar nicht antworten.

@DirkF
Da DelphiX ohnehin ersetzt werden sollte, sehe ich es weniger als ein Hindernis an wenn man es nicht portieren kann. Ich kann noch nicht wirklich beurteilen wieviel aufwand es tatsächlich sein wird, aber zumindest einzelne Units konnte ich problemlos verwenden.
Da hier aber offensichtlich alle von Grund auf neu anfangen wollen, weiß ich nicht ob ich da überhaut noch etwas versuchen soll.

@sujin
Schön dass es dich noch gibt.

Oh ich hatte zwischen tutagx und XForce keine Verbindung hergestellt (hätte ich mal das unterste angeklickt) und weiter gesucht und dann angenommen https://bitbucket.org/web_cartel wäre dein Projekt.

Ja, dass du ein rewite wolltes war mir klar, nur nicht was "wir" wollen.
Ich hab halt den Eindruck das hier jeder eine andere Vorstellungen davon hat wie "XForce 2" werden soll.
MADetter z.B. wünscht sich Nachschub im Bodeneinsatz, das setzt vorraus dass der Geoscape wehrend des Bodeneinsatzes erreichbar ist und weiterläuft. Für Andere ist/war es klar dass der Geoscape pausiert und nur nach dem Bodeneinsatzes ein paar Daten auswertet. Für mich war klar dass das Spiel auch unter Linux laufen soll, für Kamor ist das wohl kein Ziel. Hier wird sich aber erst mal um die Umsetzung Gedanken gemacht, nicht aber über die gemeinsamen Ziele und die Logistik. Das meinte ich mit besserer Planung.

Ich verstehe was du meinst, aber nur den Bedarf eines Spielsatzes abzudecken birgt jedoch auch die Gefahr das man wieder eine Engine entwickelt die nur 2 Partei unterstützt oder so. Der Spielsatz sollte also nicht zu minimalistisch sein.

Und ja in einer neuen Sprache entwickeln ist alles andere als Produktiv. Aber ein unproduktiver Programmierer ist besser als überhaupt keiner.


@Kamor
Danke, ebenso :)

Wenn man ein paar mal zwischen Game und Info hin und her springt geht der Speicherverbrauch ganz schön hoch.

Wie erkennst denn das Spiel welches Land nun wo ist? In der mask.txt sind ja
Ich glaube du überprüfst an einer langen internen Liste die Koordinaten.
Zumindest in diesem Fall (es wird nichts dynamisch generiert) hätte ich nur 2 Bilder verwendet, die angezeigte Deutschlandkarte und eine 8Bit-Bitmap einer verschiedenfarbige Karte ohne Grenzen.
Die mask.txt kann dann ganz simpel sein und per Tool erstellt werden:

# Collor: IdStr 
1: button_Quit
3: button_Info_HowTo
4: button_Info_About
11: state_BW
12: state_Bayern
13: state_Berlin

Im Spiel verwendest du sowas in der Art (KA wie nun in C# die Syntax genau wäre):

var Arreas = yaml.load("mask.txt");
var index = screen.getCollorAt("GermanyMap.bmp", click.X, click.Y);
// Farbe "0" => nix anklickbar => zurück
if (index == 0) return;

string[] parts = Arreas[index].Split("_");

switch (parts[0])
	{
	    case "button":
                // irgend welche Button-Aktionen ausfüren
		break;
	    case "starte":
		print(getText(parts[1]));
		break;
	}

Wenn nun zB. irgendwo hingeklickt wird wo auf der unsichtbaren Karte der Farbwert 3 ist, so wird eine Info angezeigt oder so. Ist die Farbe "11", wird die Übersetzung von "BW" ausgegeben.
So braust du nicht nur weniger Bilder und Positionen angeben, sondern bist auch sehr flexibel und mehrsprachig.

Zoombarer Text ist natürlich sehr schön.

Rest muss ich mir nochmal anschaun.

Wenn du auf Game clickst, wird derzeit das Spiel komplett neu gestartet. Da müsste eigenlich stehen Restart Game. Das geht auch an die Datei-Ebene dann, da werden sämtliche Ressourcen neu geladen. Dann wird die Maske neugeladen und alles neu berechnet. Die ganzen alten Instanzen, z.B. der Bitmaps, die sich da vorher so rumgeflegelt haben, werden dann automatisch durch den Garbage Collector gefressen. Der hinkt aber natürlich immer etwas hinterher, so dass es kurzfristig zur höheren Speicherlast kommt. Speicherfreundlicher wäre also wahrscheinlich, erst das alte Game zu schließen, ne Sekunde zu warten und dann neu durchzustarten.



Zuerst wird der definierte Bereich überprüft, also ein Rechteck. Das ist ein reiner Zahlenvergleich. Bei einem positiven Ergebnis wird dann geprüft ob die Area transparent geschaltet ist. Falls ja wird dann das Pixel der Bitmap in der Area auf transparent untersucht. Du musst aber berücksichtigen, das zuvor der Mausclick mehrere mal schon umgerechnet wurde.

Der Mausclick wird umgerechnet vom größenveränderbaren sichtbaren Screen auf den festen nicht sichtbaren Screen. Im diesen Screen werden die definierten Areas überprüft. Das ist eine Liste und die Werte der Areas kommen direkt aus der mask.txt. Die mask.txt dient hier nur einmal der vereinfachten Initialierung einer Maske. Die Maske kann auch jederzeit zur Laufzeit manipuliert werden. Aufjedenfall muss der Mausposition dann noch auf die Area umgerechnet werden und dann noch auf die Pixelposition im Bitmap.

Hier der Code um die Mausposition zum hintern fixen Screen weiterzureichen.

        private void IMG_MouseUp(object sender, System.Windows.Input.MouseButtonEventArgs e)
        {
            // Mausposition in Relation zur Page ermitteln
            // Page und Bitmap sind von der Größe identisch, Bitmap füllt immer die gesamte Page aus
            // deshalb können Größen und Position direkt in Bezug zur Page ermittelt werden
            System.Windows.Point p = e.GetPosition(this);

            // Hinweis Debug-Meldungen über MessageBox vor Ermitteln der MausPosition sind zu vermeiden, da Benutzer dadurch die Mausposition verändert
            // MessageBox.Show("System.Windows.Point :" + p.ToString());

            // Page aktuelle Höhe und Weite
            double sh = this.ActualHeight;
            double sw = this.ActualWidth;

            // Backscreen Höhe und Weite
            // hier über direkten Zugriff auf das Backscreen Objekt <----------------------- TODO
            int th = Screen.bitmap.Height;
            int tw = Screen.bitmap.Width;
            // MessageBox.Show("ScreenHigh:" + sh + "|ScreenWidth" + sw + "|BackScreenHigh" + th + "|BackScreenWidth" + tw);

            // Umwandlungsfaktoren für Höhe und weite berechnen
            double fh = sh / th;
            double fw = sw / tw;

            // Mausposition entsprechend des ermittelten Factors im Backscreen berechnen
            double sx = p.X;
            double sy = p.Y;
            double tx = sx / fw;
            double ty = sy / fh;
            // MessageBox.Show("ScreenX:" + sx + "|ScreenY" + sy + "|BackScreenX" + tx + "|BackScreenY" + ty);

            // Umwandlung nach Int mit zwei Stellen gerundet
            // TOCHECK falls Werte <0 oder >= BackscreenHeight/Width müssten die hier noch abgefangen werden
            int x = ((int)(tx * 100) / 100);
            // if (x < 0) x = 0;
            // if (x >= tw) x = tw - 1;
            int y = ((int)(ty * 100) / 100);
            // if (y < 0) y = 0;
            // if (y >= th) y = th - 1;
            // MessageBox.Show("X:" + x + "|Y" + y);

            // click an backscreen weiterreichen
            backscreen.click(x, y);
        }

Ja, ich stell das Ganze bald mal hoch zum reingucken.

@Andiana @sujin @DirkF
Natürlich können wir auch ein ReWrite machen, also exakt dieselben abstrakten Konzepte und äquivalente/identische Algos machen.
Oder wir schreiben ein Spiel, dass genauso aussehen, sich anfühlen kann, wie XForce gerade, aber je nach Spielsatz sich auch meinen skurilen Fantasien wie Interaktion zwischen Geospace und Bodenkampf bei Langzeitgefechten genügt.

Ich werde so oder so hier mit basteln wenn ihr mich lasst, und ehe wir untereinander nicht wenigstens halbwegs ein gemeinsames Commitment abgeben, wohin wir gehen wollen, spielt es auch garkeine Rolle, ob und was ich mir halt noch so wünsche. Aber ich habe nicht das Gefühl, dass wir gerade ernsthaft in einer Beschlussfindungsphase sind was wir machen wollen.
Wir reden hier über Techniken und Konzepte um uns zu beschnuppern, bestenfalls oder ein Gefühl dafür zu kriegen, wer sich auf welche Art einbringen will.

Für mich speziell macht das auch Sinn. Denn ich muss mich ohnehin zuerst in eine Sprache einarbeiten, in der ich nachher was ausdrücken will. Ein gemeinsames Commitment zur Entwicklungsumgebung ist darum für mich nützlicher als das was (ich hab so an allem Spass glaube ich).

Ich weiß, man wählt idealerweise die Werkzeuge erst, wenn man weiß was man machen will. Aber dafür experimentiert Kamor ja schon munter. Und Andiana kräftig mit. Und beide sind vermutlich deutlich erfahrenere/bessere SW-Entwickler als ich.
Aber egal was ihr beide vorschlagt, es wird für ein ReWrite oder für ein erweitertes X-Force 2 taugen.

WENN ihr euch aber schon jetzt bereit fühlt, können wir alle zusammen inklusive den Entwicklern der 1. Stunde diskutieren was wir machen wollen, um das ganze wieder zu beleben. Und uns danach dann (vorbehaltlich der Realität) dazu auch verlässlich bereit erklären. Und dann gehts los.

Oder ich arbeite mich einfach mal in C# und Kamors Konzepte ein, und überbrücke die Zeit solange. :p

Hmm, also ich habe lange nicht mehr bei Lazarus vorbei geschaut, aber ich sehe eine Portierung nach wie vor kritisch. Ich persönlich würde vermuten, dass eine Rewrite in Qt (C++) für mich einfacher wäre, als das Projekt in Lazarus zum laufen zu bringen. Ein riesen Problem ist natürlich DelphiX - die Isoengine, sämtliche Fenster, Textfelder etc. basieren darauf und sind zum Teil von Jim_Raynor selbst geschrieben (inklusive Problemstellungen wie vernünftiger Zeilenumbruch etc.). Selbst wenn man das irgendwie hinbekommen sollte - es ist imho sinnvoller bei sowas nicht mehr auf Eigenentwicklungen zu setzen. Mit Qt ließe sich das z.B. viel einfacher und flexibler lösen (man bräuchte wohl auch keine eigene "Skriptsprache" für Fenster und einen entsprechenden FormDesigner mehr).
Die Skriptengine (PascalScript) hat auch ihre Beschränkungen. Und soweit ich weiß, wird sie auch nicht mehr weiterentwickelt. Ein weiteres Problem aus der Vergangenheit war, dass Delphi eine vergleichsweise kleine Community hatte. Das machte es deutlich schwerer Hilfe zu bekommen oder neue Programmierer zu finden. Das Problem bliebe mit Lazarus bzw. würde wohl noch verstärkt.

Auf mich braucht niemand zu warten, ich habe so viele andere Projekte am Laufen und geplant, dass ich auf lange Zeit nicht mehr in diese Richtung arbeiten werde.


Ja, das macht mir auch Sorgen. Klar, wie MADetter sagt, man kann sich gut damit die Zeit vertreiben, aber letztlich ist es auch nicht viel mehr als das.


Ich verstehe ebenfalls was du meinst, muss aber widersprechen. Zu versuchen, alle möglichen Spielsätze abzudecken, muss zwangsläufig scheitern. "You Ain't Gonna Need It". Natürlich muss, wie gesagt, die Engine erstens Spielsatz-agnostisch bleiben und zweitens wartbar und leicht zu erweitern sein. Wenn dann jemand etwas braucht, was es nicht gibt (weil bisher kein Spielsatz so etwas gemacht hat), dann sollte es kein großer Akt sein, das auch zu ermöglichen.

Natürlich kann und sollte deshalb in weiser Voraussicht die Architektur so gewählt werden, dass allgemein diese Arten von Änderungen leichter zu machen sind. Aber sich zum Wohle eines hypothetischen Spielsatzes, dessen genaue Anforderungen man noch gar nicht wirklich kennt, an allen Ecken und Enden zu verrenken, ist nicht sinnvoll. Den Bodeneinsatz zum Beispiel erst einmal so zu schreiben, dass es nur zwei Konfliktparteien gibt, ist in Ordnung, solange das eine bewusste Entscheidung und man eine grobe Vorstellung hat, was später geändert werden muss, falls ein Spielsatzautor daherkommt, der mehr Parteien braucht.

Das erfordert natürlich, dass immer Programmierer zur Verfügung stehen, aber das ist ja ohnehin für das fortbestehen nötig.

Sehe ich nicht so. Die Spielsätze unterliegen einzig und allein dem Scripter. Das ist im Prinzip nur eine oder auch mehrere Klassen, die der Scripter selber instanziert. Name und Architektur unterliegen alleine dem Scripter. Die Engine will mit Spielsatzdaten nichts zu tun haben. Sie unterstützt aber beim serializieren (speichern) und deserializieren (laden) einer Klasse (Spielsatzdaten).



In dieser Phase meiner Programmierung ist das für mich kein Ziel. Aber guckst du hier. ;-)

http://www.csscript.net/

Die binden da das .Net 4.5 auf Linux-Systemen ein und erlauben Scripting in C# sogar auf Kommando-Ebene. Also ist es wahrscheinlich auch möglich, meine ausführbare Datei dort zu starten und die Script-Ebene zu bedienen. Das das Projekt dann evtl. auch noch auf Linux auf Compilerebene zu bearbeiten ist, ist dann nochmal ein anderes Thema. Das ist dann aber definitiv eine Aufgabenstellung, die an die Linux-Freaks gerichtet ist.

Ansonsten gibt es immer noch die Variante mit einer virtuellen Maschine.

Hier wie versprochen der Quellcode.

http://www.kamorspace.de/xforce/EngineX-VisualStudio.zip

und nochmal der Link auf die ausführbare Variante

http://www.kamorspace.de/xforce/EngineX.zip

Verdammt, jetzt lasse ich mich doch in eine Diskussion um technische Details rein ziehen.



Wenn die Engine mehr ist nur als eine lose Sammlung einzelner Hilfsfunktionen, dann hat sie Architektur, und diese färbt auf alle Spielsätze ab. Wenn die Engine Geoscape und Bodeneinsatz anbietet, dann müssen die irgendwie kommunizieren (und das alles auf dem Spielsatz ab zu laden, löst das Problem nicht). So etwas meine ich.

Aber ja, der Spielsatz sollte weitläufig autonom sein und die Engine mehr wie eine Bibliothek von schon fertigen, aber nicht verpflichtenden, Komponenten benutzen. Grade deshalb rate ich von einer kanonischen Klasse "Spielsatzdaten" in der Engine an. Was ein Alien ist, welche globale Daten nötig sind, usw. sind Dinge, die von Spielsatz zu Spielsatz variieren können. Wenn ich mich Recht erinnere, hat z.B. der Spielsatz "Das Tagebuch des William Walker" von Kreks ein viel ausgefeilteres Produktions-System, dass das Konzept von "Alphatron" quasi obsolet macht.

Habe ich hier schon mal Werbung für Entity-Component-Systeme gemacht?

@Kamor, @Sujin

Bitte helft mir hier mal weiter und klärt mich mal ein wenig auf. :-)

Was versteht ihr jeweils unter:
- Einer Engine und ihren Funktionsumpfang?
- Welchen Grad an Freiheit sollte das Skripting (theoretische Flexibilität des Spielsatzes) haben?
- Welchen Grad an Freiheit würdet dem Spielsatz-Designer präsentieren/bzw. durch eine Skripting-Sprache/Skripting-Gui transparent machen?

Erstmal nur so als konzeptionelle Bestandsaufnahme.

Ich glaube nämlich, dass ich es so gar nicht verstehe und ihr beide stark unterschiedliche Antworten auf die Fragen da oben habt.

Edit: Mein Frage ne halbe Stunde zu lange im Fenster vergessen. Ja. sujin, lass dich bitte bitte in die Diskussion über Architekur mit rein ziehen - wenigstens als Inspiration. :-)

Ja, du hast recht Sujin und ich habe da unterschiedliche Vorstellungen und reden da auch aneinander vorbei.

Die Engine hat nichts mit dem Rewrite zu tun. Sie ist nur ein Objekt, eine Api, eine Sammlung von Funktionen, dich ich baue, um einen Spielsatz-Designer zu ermöglichen, mit wenig Aufwand seine Idee für einen X-Force Rewrite oder auch anderes Spiel umzusetzen.

Der Spielsatz-Designer bzw. Scripter bekommt einen maximalen Grad an Freiheit. Die extremste Form wäre er lässt nur das Scripting laufen und bindet noch nicht mal meine Prototyp-Engine ein. Der ganze Rewrite kann auch auf jeder beliebigen anderen Engine laufen. Skripter können auch die riesige Engine .NET Framework selber ansprechen. Das dürfte aber den einen oder anderen Skripter abschrecken.

Dann gibt es noch eine Ebene. Die Manipulation von Spielsatzdaten für genau das eine Game.

Also im Beispiel

X bastelt an der Engine und bietet eine Schnittstelle an
Y scriptet auf der Engine, nutzt diese Schnittstelle und bastelt sein Spiel (z.B. den Rewrite)
Z manipuliert Spielsatzdaten, verändert Bildschirmmasken und ändert, evtl. auch mal ein wenig ein Script.

Dabei kann Z immer Y konsultieren und ihn zum Beispiel um Hilfe fragen Problemen beim Spielsatz-Erstellen. Auch kann er Wünsche an Y weitergeben.

Y selber bastelt das eigentliche Spiel (den Rewrite), geht auf Wünsche und Vorschläge von Z ein und konsultiert selber bei Problemen oder für Vorschläge X, der an der Engine bastelt.

Also eine Symbiose von X-Y-Z oder auch

Engine-Coder
Game-Scripter
Spielsatz-Designer

Denkt jetzt aber nicht das der Coder an oberste Stelle steht. Der Coder kommt mit seiner Engine nur voran, wenn diese Engine auch eingesetzt werden. Er braucht den Dialog zum Skripter und ist auch abhängig vom Spielsatz-Designer. Man könnte diese Kette übrigens noch erweitern.

Engine-Coder
Game-Scripter
Spielsatz-Designer
Grafiker und Soundersteller (Musiker)

Dabei ist Soundbastler nicht so primär wichtig fürs Coding. Aber für den Spielsatz-Designer und auch den Skripter ist der richtige Sound pures Gold.

Bei einem Grafiker ist die Abhängigkeit zum Engine-Coder wesentlich höher. Grafik ist die Essenz, das ein und alles für ein Spiel und sollte am Ende der Kette möglichst einfach einzubinden sein.

Grafiker malt sein Bild, egal welches Format.
Spielsatz-Designer legt das Bild in seine Ressourcenliste gibt ihm ein Namen und verknüpft das Bild vielleicht schon als Startbild in einer Maske für sein Game. Auch hier werden möglichst viele Formate unterstützt.

Skripter lädt mit einem Befehl diese Liste ein und ist verantwortlich für das Startskript, kann dabei aber auf Befehle der Engine zugreifen.

Coder erlaubt dem Skripter gleich beim Instanzieren der Resourcenliste in einem Abwasch die Ressourcen aus der Ressourcendatei einzulesen. Mit einem Befehl.


Wenn jetzt aber nicht genug Leute da sind, um diese Kette zu füllen, geht das Projekt früher oder später in die Hose. Kreks war z.B. voll aktiv hier mit seinem Spielsatz, dabei hat er sogar die Kette vom Grafiker bis zum Game-Skripter bedient. Ganz oben fehlte aber immer mehr ein Coder, der die Engine weiter voranbringt. Das ist jetzt kein Vorwurf an irgend jemanden hier. Wir alle sind Menschen und sollten unsere Lebenszeit so verbrauchen dürfen, wie wir es wollen. Und sowohl Dirk wie auch Natter sagen beide, das das Chaos im Coding nicht mehr schön ist. Ich habe da selbst auch reingeguckt. Kommentierung des Codes ist dort eher mangelhaft, auch wenn schon nachgearbeitet wurde. Wenn dann also Kreks auch noch versucht auf C# einen Rewrite ganz oben angefangen zu coden, kann er nur noch aus zeitlichen Gründen daran kapitulieren.

Es ist dann auch nicht wirklich fair irgend jemand hier eine Schuld zuzuweisen das es nicht weitergeht. Das Ganze kann nur im Team geschafft werden, wobei jeder zu jederzeit das Recht haben sollte, sich eine Auszeit zu nehmen oder ganz auszusteigen, weil

… Geburt
Lebensuhr=0;
while (Lebensuhr<Lebensende)
{
Lebensuhr++
}
… Tod

Buddhisten setzen da noch ein while Schleife drumherum mit Reinkarnation, das liesst sich dann nicht ganz so hart. ;-)

Meine Position ist folgende: Es soll ein Programm geben, dass ein Fenster erstellt, den Benutzer einen Spielsatz wählen lässt, und dann die Kontrolle an den Einsprungpunkt (ein "Skript") des Spielsatzes übergibt. Die eigentliche Engine macht von sich aus nichts, sondern fungiert als Bibliothek, stellt Komponenten zur Verfügung für alle möglichen Konzepte, die für mehr als einen Spielsatz nützlich sind.

Der Spielsatz macht im Einsprungpunkt unter anderem folgendes:

- Lädt den Rest des Spielsatzes von der Festplatte, vermutlich mithilfe einer API die von der Engine zur Verfügung gestellt wird.
- Lädt und konfiguriert die Komponenten der Engine. Da diese Komponenten zumeist austauschbar und voneinander unabhängig sein sollten, muss hier vielleicht eine Art dependency injection passieren, um die Komponenten miteinander zu verkabeln, die miteinander interagieren müssen.
- Lädt und konfiguriert Spielsatz-spezifische Komponenten, die im Prinzip ähnlich wie die der Engine sind, nur halt nicht für andere Spielsätze nützlich.
- Setzt alle interessanten Daten auf. Dinge wie die Weltkarte, die Staaten, die Arten von Gegenständen und Aliens und UFOs und und und.
- Registriert Hooks/Callbacks (was wir in X-Force meist Skripte nennen) für alle möglichen Events.
- Macht auch sonst alles, was so anfällt, wie immer mit der Möglichkeit, häufig anfallende Aufgaben an die Engine zu delegieren.
- etc. etc.

Da das alles sehr viel Aufwand ist und etwas Programmierkenntnis erfordert, sollte der Aufwand für Leute, die nichts Skripten wollen und keine eigenen Komponenten schreiben müssen, minimiert werden: Eine minimale Vorlage, die einfach in den Spielsatz kopiert werden kann und eine Auswahl an Komponenten lädt und Defaults hat, wie es Daten lädt und was für Dinge es so in der Spielwelt gibt:

import engine

engine.do_your_thing()

Aber grundsätzlich soll jeder Spielsatz alles ändern können, was nicht gerade fundamental in die Erstellung des Fensters oder die Rendering-Methode (also ob OpenGL, DirectX, oder eine höhere Bibliothek wie Qt) eingreift.

Hm. Das klingt nicht als ob ihr deutlich aneinander vorbei redet. Was ich verstanden habe

Es gibt die Ebenen:
- Engine (Abstraktion von System, Grafik-Lib, Sound-Lib, Controls und I/O allgemein, Speicherverwaltung, und Bereitstellung von Callbacks/Hooks/dynamischer Erweiterungen für nächsthöheres Layer)

- Game-Logic-Layer (Library prinzipeller Spiel-Konstrukte: Geospace und Geospace-Gefecht, Wirtschafts- & Rescourecen-Management-System, Konstrukt-System (Basis), rundenbasierter Bodenkampf und konfigurierbares Event- und Datenmanagement zwischen den Spielkonstrukten, Callbacks/Hooks/dynamischer Erweiterungen für nächsthöheres Layer)

- Spielsatz-Logik-Layer (alle lustigen Skripte oder speziellen serialisierten Klassen, die Events, Daten und Zustände der Spiel-Logik konfigurieren können)

- (Creation Kit-Schmierschicht: Spiel-Satz-"Out-of-Box"-Konfigurator für typische X-force-Scenarien, mit ggf. vereinfachter Skriptsprache und/oder netter GUI, der Dinge ins Spielsatzlogic-Layer übersetzt, die man sich zusammenklickert)

- "Design-Layer" - Bilder & Sound, Texte... Content eben, der an die Logik geklebt wird... vielleicht als kleine Content-DB.

Ich hoffe ich habe das so richtig verstanden.
-------------------------

Je weiter unten man in diesen Layern eine Implementierung ansetzt, umso starrer wird das Spiel, aber umso handbarer längs Stabilität und ggf. Effizienz, könnte ich mir vorstellen.

Und wir müssen eine Vorstellung haben, was auf welcher Ebene landen soll. Und dann können wir sogar sinnvoll die geeigneten Technologien, Grad des ReWrites, etc. festlegen.

Ich habe jetzt noch nicht so tief in die Unterwäsche des aktuellen Spiels geschaut.

@sujin und @kamor... und eigentlich an alle :-)
könnt Ihr mir bitte einen kurzen Überblick geben was aktuell wo angelegt ist (und ob es diese Layer gibt, und ich das richtig kapiert habe?) und ob und wie es Sinn macht die aktuelle Einteilung für ein ReWrite oder ein X-Force 2 beizubehalten?

EDIT: Und wenn ich euere Kommentare richtig verstanden habe, ist die "Engine von sujin" meine Schichten: "Engine" und "Game-Logic-Layer", während "Kamors Engine" mein "Game-Logic-Layer" nicht umfasst? ... *schmunzelt* Begrifffindung scheint mir doch eine wichtige Sache zu sein für mich als Neuling.

Das musst du im Detail die Veteranen mit foltern. Aber ich meine ursprünglich kommt X-Force aus dem reinen Hardcoded Bereich und hat dann immer mehr versucht zu dynamisieren. Im Skripting muss man dort. z.B. Hardcoding erst deaktivieren, wenn man mit seinen Ideen vom ursprünglichen Spiel abweichen muss. Musste ich z.B. machen bei der Länderfinanz-Berechnung.

Ansonsten gibt es eine neue Version als Download. Links sind die gleichen, wie oben gepostet.

Ich bin wesentlich weiter im Scripting, aber noch nicht da, wo ich hin will. Mir fehlt noch der Schritt mein Script sauber an die Game Klasse zu binden. Wenn das geschafft ist, dann kann ich euch erste kleine Beispiel-Skripte hier posten, die ihr bei euch OutofttheBox starten könnt.

Ansonsten sind im Hardcoded-Screen schonmal erste Tests in Sachen Hover/Tooltip und Area-Manipulation zu sehen.

Die Verzögerung die Aussehen, wie ein Rechenpowerproblem leiten sich ab aus.

Hover/Tooltip - Timer ist auf 2 Sekunden eingestellt.

Eine weitere Sekunde Verlust kommt noch, weil der Frontscreen jede Sekunde den Backscreen fragt, ob was verändert wurde. Hier muss definitiv ein Call-Back hin, dann kann Backscreen den Frontscreen zeitnah informieren.

Als nächstes kommt ein zweite Layer im Backscreen, wo die Print-Ebene von der Area-Ebene getrennt wird.

Falls du dich auf den X-Force-Quellcode beziehst - Kamor hat recht, ursprünglich war alles hardcoded. Via PascalScript ist es aber möglich geworden so ziemlich jede API-Funktion für Skripte verfügbar zu machen(benötigt aber entsprechende Handarbeit - daher wurde die Skriptsprache meist nur bei konkretem Bedarf ausgebaut). An einigen Stellen wurde der Quellcode so umgestellt, dass dynamische Änderungen möglich worden. Z.B. waren anganfs alle Fenster/Layouts direkt mit festen Zahlen im Quellcode verankert. Das wurde dann auf xml-Dateien umgestellt. Die AI war früher ebenfalls fix, das wurde geändert und durch den aufruf von zugewiesenen AI-Skripten ersetzt.

Ansonsten müsstest du schon etwas konkreter nachfragen.

PS: Ich würde auch dafür plädieren, dass die Engine selbst viele Funktionen standardmäßig bereitstellt. Nur bei Bedarf sollten entsprechende Funktionen per Skript überlagert werden können (der Mechanismus dafür könnte natürlich besser werden, als bisher über globale Variablen ^^). Sonst wird die Einstiegshürde für Spielsätze zu hoch.

@Natter

Die Einstiegshürde würde ich ggf. dadurch dämpfen, dass wir einen Creator bereit stellen, oberhalb meiner "Game-Logik"-Ebene, vielleicht auch oberhalb des Experten-Gameset-Skriptings. Der Creator generiert dann entsprechende Gamesets. Wenn der Creator dann auch noch direkt Skripte dazuladen kann an den üblich verdächtigen Stellen, ist der Reiz die Skript-Methodik zu erlernen da. Und irgendwann baut man dann direkt an seinem Spielsatz rum, und benutzt den Creator nur fürs Skelett.

Wenn man auf Lücken in der Skripting-Methode trifft, kann man dann neue Game-Logik-Module entwerfen. Je nachdem kann die ja hard-Coded sein, oder ebenfalls per Dynamik generiert, ggf. sogar mit der gleichen Skriptsprache (nur anderem Befehlssatz) wie das Spielsatz-Skripting... aber es ist eben eine andere Ebene und wir sollten das nicht vermischen.

Und ja, wir sollten schon viele und vielseitige Geme-Logik-Module bereitstellen.

Das was ich als Engine bezeichne, da sollte niemand von den Spiele-Satz-Erstellern bis runter greifen müssen... außer er will was grundlegend anderes: wabenförmiger Bodenkampf, statt orthogonales Grid, 3-D-visualisierung der Basis, Ein paar coole Rauch/Fog-Effekte für mit Giftgas belegte Felder, 3D-Ufo-Kampf per Flugsimulator... :-)

Ich glaube, du wirfst da zwei verwandte, aber unterschiedliche Dinge durcheinander. Ja, es sollte genug Funktionalität mitgeliefert werden, dass ein guter Spielsatz wie in X-Force zu (fast) 100% aus Daten bestehen kann. Aber die Möglichkeit für Spielsätze, etwas wegzulassen, zu modifizieren, zu ersetzen, oder hinzuzufügen, sollte immer und überall von Anfang an dabei sein und nicht erst als verspätetes Anhängsel. Ich bin auch überzeugt, wenn man das durchdacht angeht, muss das gar nicht schwer sein.

@Kamor
Du scheinst eine strikte Trennung zwischen "Skripten" (die nur ein paar Dinge machen können und an Events gekoppelt sind) und "Game-Logik-Modulen" (die offenbar grundsätzlich alles machen können) anzustreben. Ist das, und die Charakterisierung der beiden Arten, korrekt? Wenn ja, dann habe ich nicht nur philosophisches Widerstreben dagegen, sondern auch technische Einwände. Um mich kurz zu fassen: Gutes eingeschränktes scripting ist schwer, und da eh tiefgreifende Eingriffe in die "Engine" möglich sind, wird für viele Skripter der Übergang von "schnell mal ein Skript" zu "neues Game-Logik-Modul" ein fließender sein. Jedenfalls sollte das so sein, der einzige Grund dagegen wäre, wenn die Engine zu kompliziert und komplex ist --- aber das sollte man eh vermeiden. Vor dem Hintergrund kann man die Unterscheidung auch direkt sein lassen und stattdessen schauen, dass Skripter genug Komfort-Funktionen haben, dass sie die gleiche API wie der Rest der Software-Torte benutzen kann.

Soll sie auch, aber nichts was mit Spielsatz-Logik zu tun hat. Dafür sind die Skripte da. Skripting kann dabei auf mehreren Ebenen passieren. Von einfach bis Komplex.

Die Engine bietet Befehle an, wie

myGame.loadRessources(myressources.txt);
myGame.LoadMask(mymask.txt);
myGame.BuildScreen();
…

Jemand der keine Ahnung vom Skripten hat, kann hier alleine über zwei Textdateien seinen eigenen individuellen Startscreen bauen. Auch das Einladen eines eigenes Fonts sollte für Neulinge zu schaffen sein.

Bitmap b = myressources[x].bitmap];
string s = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!,:-";
font = new Font(b, 10, 4, s);

Dann muss da halt nur noch das Bitmap passen, gleiche Buchstaben wie im String, 10 Buchstaben in der Reihe und 4 Spalten. und

print(font, "Mein Spiel", 50, 10);

Erfahrende Skripter können die Maske per Klassenzugriffe manipulieren x ist hier der index auf die area z.B.

mask.area[x].viewable = false; // nicht mehr sichtbar
mask.area[x].clickable = true; // dort darf jetzt geklickt werden

oder irgendwie so in der Art

for (int x=0;x<1024;x++)
{
Mask.area.rec.X=x;
Game.changed=true; bzw. WinForms.Reload();
System.Threading.Thread.Sleep(1000); // 1 Sekunde schlafen
}

Wobei ich hier auch noch Befehle reinarbeiten will, die Area-Manipulation vereinfachen Hier wird ein Bitmap transparent gemacht

 Bitmap makeabitmaptransparent(Bitmap b)
 {
b.MakeTransparent(b.GetPixel(1, 1));
 return (b);
 }

Es sollen weitere Bitmap-Manipulation, wie Infrarot, ausgrauen, heller oder dunkler machen hinzukommen.

Dies kann aber auch schon ohne Hardcoding passieren, weil es keine wirklich Trennung zwischen C#-Coding und C#-Skripting gibt. Ich kann Syntax von der Coding-Ebene zur Skript-Ebene Copy-Pasten und umgekehrt.

Areas sind zudem auch schon eine Art von Sprites, sie dienen gleichzeitig als Buttons. Es ist auch geplant direkt mit dem Print-Befehl in Areas reinzuschreiben.

z.B.
PrintArea … schreibt entweder 1 zu 1 in die Area oder passt sich dabei an die Größe der Area an
oder PrintNewArea … legt gleich eine Area an.
Das man da dann noch
ButtonPrintNewArea …
Daraus machen kann, ist dann nur noch ein Flag. -> Area.clickable=true;

Weiterhin ist ja geplant das es mehrere Bildschirmlayer gibt.
Für drag and drop oder wenn Areas wie Sprites vorne rumflattern soll.

Wenn die Skripter noch höher wollen, können sie sich im ganzen #Net-Framework austoben oder auf andere X-beliebige Bibliotheken, Engines und was es da sonst noch so gibt.

So ist es zumindest geplant und teilweise auch schon umgesetzt.



Ich habe eine neue Version hochgeladen, evtl. schaust du da mal rein. Aber ganz grob sieht das so aus.

Engine instanziert sich und hält Klassen bereit, wie z.B. die Game-Klasse oder Font-Klasse
Engine startet das Script.
Script startet eine neue Windows-Anwendung mit Fenster und Game-Klasse.
Script hat aber auch genauso die Freiheit, sich z.B. ne Konsole zu starten oder eine eigene-Iso-Engine zu laden.

Die Frage ist halt - was ist Spielsatzlogik? Ein paar Beispiele was in X-Force per Spielsatz gesteuert werden kann, bzw. normalerweise einen vernünftigen (?) default hat, aber bei Bedarf auch per Skript steuerbar ist:

- Einheiten-AI
- GUI
- Schadensberechnung im Bodeneinsatz (Trefferwahrscheinlichkeit, Einfluss Panzerung etc.)
- Forschungsfortschritt
- Erzeugung von UFOs und Bodeneinsätzen
- Alphatron-Map
- Earth-Globus (Textur)
- Missionsbeschreibungen
- Schwierigkeitsgrad der Gegner
- Wegfindung im Bodeneinsatz
- Finanzen
- Ländervertrauen

Das sind jetzt nur ein paar Dinge die mir gerade einfallen. Die Variante der AI-Skripte zeigt da imho schon einen ganz brauchbaren Weg. Es gibt ein Standardverhalten, und nur wer will, schreibt seine eigenen Skripte.
Ich habe überhaupt nichts dagegen, von Anfang an auf Modifizierbarkeit zu achten (ich hab ja selbst in X-Force an vielen Stellen die programmlogik so geändert, dass die Spielsatzersteller mehr Einfluss bekamen). Das kann aber nicht alleiniger Maßstab sein. Denn ganz ehrlich - wenn jemand wirklich alles ändern will, warum sollte er dann den Umweg über X-Force 2 wählen - er könnte auch gleich eine beliebige Entwicklerumgebung nutzen, und sein Eigenes Spiel programmieren. Man sollte nicht den Vorteil einer funktionierenden und erprobten Engine unterschätzen. Selbst so ist der Aufwand für einen vernünftigen Spielsatz hoch. Wenn sich jeder über die Formel zur Trefferwahrscheinlichkeit monatelang Gedanken macht (und damit erreicht, dass Spieler ständig von Bugs ausgehen, weil sich ein Spielsatz nicht so verhält wie erwartet - ein weiteres Problem, wenn man zu viel verändert), dann gibt es am Ende vielleicht eine flexible Engine aber nie einen einzigen fertigen Spielsatz.

Also zusammengefasst - Flexibilität von Anfang an berücksichtigen - ja unbedingt! Aber noch mehr Augenmerk muss auf ein gutes funktionierendes default-Verhalten gelegt werden, und auf eine einstiegsfreundliche Entwicklungsumgebung für Spielsatzersteller, die viel zulässt, auch ohne Skripting- oder Programmierkenntnisse. Denn davon profitieren alle Spielsätze, selbst die, die dann doch manches anders machen. Gutes Beispiel dafür ist wieder die AI - für Anfänger ist eine Auswahl im Spielsatzeditor möglich, nur wer will schreibt maßgeschneidertes Verhalten.

Gibt eine neue Version zum Downloaden. Das Scripting kommt langsam in Fahrt. Ein Gamescreen kann jetzt dynamisch geladen werden. Ihr könnt auch mit der Maske rumspielen, oder eigene Ressourcen einbinden.

reference system.windows.forms.dll;
reference system.drawing.dll;
using System;
using System.Media; // für Beep
using System.Windows.Forms; // für Forms-Fenster
using System.Drawing; // für Bitmaps
void main()
{
SystemSounds.Beep.Play();
Game myGame=new Game();
myGame.loadRessources("myressources.txt");
myGame.loadMask("mymask.txt");
myGame.buildScreen();

Data data=new Data();
data=myGame.load("spielstand.txt");
data.Text="Hallo Spielstand";
data.Counter++;
myGame.save(data, "spielstand.txt");

int x = myGame.ressource("fontx");
if (x != -1)
{
Bitmap b = myGame.ressource(x); // Bitmap b = new Bitmap(myGame.ressource(x));
string s = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!,:-";
Font myFont = myGame.loadFont(b, 10, 10, s);
if (myFont != null)
{
myGame.print(myFont, "DEUTSCHLAND", 50, 10); // geladener Font hat nur Großbuchstaben
myGame.printchar(myFont, 'X', 400, 530);
myGame.printchar(myFont, 65, 950, 700); // Char als ASCII übergeben
}
}
WinForms myWin=new WinForms(myGame);
Application.EnableVisualStyles();
Application.Run(myWin);
// Scripting läuft hier erst weiter wenn WinForm geschloßen wird
// Form muß hier auf eigenen Thread gestartet werden oder Script geht in eigenen Thread?
// System.Threading.Thread.Sleep(5000); // hier wird nochmal 5 Sekunden gewartet

// myGame.changed=true; // Veränderung das Flags wird bemerkt und ausgegeben, obwohl WinForm geschlossen wurde.
// myWin.Show(); // Funktion lässt sich ansprechen, erzeugt aber Fehler weil Forms schon zu ist
}
// Achtung Kommentierung funktioniert noch nicht einwandfrei im "pre-parser" im oberen bereich, ab der main ist der preparser nicht mehr aktiv

Mein Ziel ist folgender Workflow.

1. Die Engine startet ScriptX und die Kontrolle geht über ein Startscript an die Scripter.
2. ScriptX durchsucht das Script und alle included Scripts nach include Befehlen.
3. Dann werden aus allen Scripts, die benötigen References ausgelesen und in einer großen Assembly referenciert (doppelt genannte References werden aussortiert)
4. Dabei sollte es keine Konflikte mit den Namensräumen geben, da diese in jedem Script individuell über using Direktive angesprochen werden.
5. Jedes der Scripte muss dabei noch durch einen Preparser, der References und Include Befehle entfernt und derzeit noch einen gemeinsamen Namensraum setzt.
6. Dann wird diese vorbereitete Liste (ein Array von Textscripten) an den Compiler weitergereicht. Der macht daraus ein Packet (eine Assembly)
7. Wenn der Compiler keine Fehler wirft, steht alles was im Skripting steht in einer ausführbaren assembly zur verfügung.
8. Daraus dann eine .exe Datei zu machen ist nur ein Flag -> Makeexe=true.

Im Prinzip könnte es also eine mygame.exe geben und eine enginex.exe (enginex.dll).

Natter hat Recht und jetzt kann ich auch endlich das fassen, was mich die ganze Zeit schon unterbewusst stört.

Nach allem, was ich hier von Kamor lese, und nach dem was ich aus dem aktuellen Download entnehmen kann, ist diese "EngineX" sehr low level, besonders im Bereich Rendering. Zu low level, um wirklich interessant zu sein für produktives Spieleprogrammieren. Andererseits hat ist sie "opinionated" was einige andere Aspekte angeht, die auf vergleichsweise hoher Ebene angesiedelt sind. So wird eine konkrete (und nicht sehr allgemeine) Rendering+GUI Methode vorgegeben, es wird eine kanonische Klasse für Spielsatzdaten vorgeschrieben, das Datenformat für Dinge wie Asset-Listen etc. ist in Stein gemeißelt. Und Skripting allgemein wird auch vorneweg genommen. Ob die Design-Entscheidungen bezüglich aller diese Dinge so richtig sind, weiß Gott allein (meine bescheidene Vermutung ist "nein"), sie auf dem untersten Layer ein zu betonieren, ist also Schwachsinn. Es ist eine Sache, zu experimentieren und erst mal überhaupt was lauffähiges zu produzieren, und ganz was anderes, dabei in eine Spaghetti-Architektur abzurutschen.

Ich habe auch noch keine Vorschläge oder Gedanken gesehen, wie "Module" und Skripte dann wirklich eingebunden werden sollen. Welche Form nimmt nachher der Code an, der z.B. die Länderfinanzierung macht, und wie wird er eingebunden und kommt z.B. an die Ergebnisse des Bodeneinsatzes? Und wie wird der Bedarf für diese Interaktion mit dem Verlangen nach Modularität in Einklang gebracht?

Tut mir leid, dass ich so schimpfe ^^ Ich fürchte, du schlitterst gerade in die "Engine bauen ohne Spiel zu bauen" Ecke ab, oder vielleicht auch in die "Hack über Hack über Hack bis es irgendwann läuft" Designschule.