Spieleprogrammierung mit Pascal - Nützliches und nicht so Nützliches

[jammernich]

Hallo liebe Lazarusnutzer,

ich möchte hier gerne mal ein Thema zur Diskussion stellen. Es geht um Units rund um Grafikprogrammierung, aber eher Frameworks und Engines zur Spieleerstellung.
---
zur Anregung:
https://github.com/neslib/Neslib.Sdl3
leider für Delphi
---
Meine Kenntnisse reichen noch nicht aus um etwas ähnliches wie Bare.Game(SDL2, veraltet) oder PasSFML selbst zu programmieren. Z.b. mit SDL3 ein Game-Framework/eine "kleine" Engine programmieren - und zwar mit den bekannten SDL2 bindings von PGD oder den SDL3-bindings von Nutzer Mathias. SFML bietet da von Haus aus Objektorientierung und Klassen für C++ und PasSFML unterstützt nur die ältere Version 2.4. CSFML für Freepascal ist wieder nur procedural.. ZenGL ist auch ein schönes Projekt, leider mit viel russischen Kommentaren. Castle Game Engine gefällt mir, aber es ist mir auch schon zu komplex und ich mag nicht dass man VS Code als Editor auch nur vorgeschlagen bekommt. Das finde ich blödsinnig für ein Pascal-Projekt. Wenn man UI oder auch ein komplexes Spiel programmieren möchte kommt man an OOP nicht vorbei oder vorsichtig ausgedrückt nicht drumherum. Das ist meiner Meinung nach ein Nachteil von Lazarus. Man muss sich beinahe alles selbst beibringen, dann basteln, und kommt.. so geht es mir gerade.. gar nicht erst erst in den Genuss sich das eigentliche Spieleprojekt kümmern zu können.

Gerade beschäftigt mich beim Thema Spieleprogrammierung, dass die Hürden so hoch sind, erst recht wenn man OOP noch nicht vollständig beherrscht, dass man vielleicht wirklich mit C# besser dran ist. Die gängigen Engines Unity und Godot nutzen das beide. Außerdem gibt es echt einen Haufen Bücher sowohl für die aktuellen Sprachstandards von C# als auch für die Engines, was auch ein Vorteil ist.

Welche Units und Komponenten nutzt ihr für Spieleprojekte mit fpc/Lazarus?
Was hilft euch beim lernen von Objektorientierter Programmierung mit fpc?

ich möchte dass hier gerne teilen, besonders geholfen hat mir bis jetzt ein englischsprachiges Buch "How to program effectively in Delphi for AS/A Level Computer Science" von Kevin R. Bond. Das gibt es auch als günstiges ebook. Ich habe früher im Unterricht TP6/7 und Delphi 1 gehabt.. wir haben damals aber kaum "Object Pascal" gelehrt bekommen, sondern hauptsächlich Standard-Pascal.

[af0815]

Schon mal das Framework gefunden ? https://castle-engine.io/

[Stevie]

Offensichtlich schon:

... Castle Game Engine gefällt mir, aber es ist mir auch schon zu komplex und ich mag nicht dass man VS Code als Editor auch nur vorgeschlagen bekommt. Das finde ich blödsinnig für ein Pascal-Projekt...

Aber vielleicht schaust Du Dir mal folgendes Video an: https://www.youtube.com/watch?v=hPmJB0mS-GA. Darin wird im Live Coding mit der FP IDE ein SDL-"Space Invaders Clone" programmiert. Zugegeben, mit 4h Laufzeit bei zweifacher Geschwindingkeit ist das Video nicht gerade handlich, aber wenn man es auf halber Geschwindigkeit abspielt und kleinere Abschnitte zerlegt, ist es eine sehr interessante Dokumentation für Pascal- und Spieleprogrammierungs-Fans...

[af0815]

Habe ich glatt überlesen mitten im Text.

[TSchnuckenbock]

zur Anregung:
https://github.com/neslib/Neslib.Sdl3
leider für Delphi

Ich habe mir das Projekt von Erik van Bilsen (neslib) mal runtergeladen und in meinem recht aktuellen Delphi geöffnet. Die Beispiele (Examples) ließen sich alle durchkompilieren und meine Stichproben waren auch lauffähig ohne Zicken.
Einen kleinen Blick habe ich auf den Code geworfen. Erik verwendet gerne neueste Delphi-Features. Ich bin da mehr old-school unterwegs.
Aber wenn man vermutlich die Doku liest, auch was SDL generell anbelangt, sollte man es hinbekommen, die Beispiel-Projekte anfangs mal ein bischen zu erweitern und da etwas drin rumzuprobieren, also z.B. mal eine "Line" mehr rein programmieren usw.
Die "Apps" haben scheinbar alle die selbe Struktur.

Code: Alles auswählen

TApp = class(TSdlApp)
  private
 	....
  protected
    function Init: TSdlAppResult; override;
    function Iterate: TSdlAppResult; override;
    procedure Quit(const AResult: TSdlAppResult); override;
  end;

also drei Methode überschreiben und los geht's.

Für Hobby-Programmierer gibt's die Delphi Community-Edition kostenlos. Läuft glaube ich ein Jahr, dann ist finito und man muß sich eine neue Community-Edition holen und installieren. Das nervt einige Leute.

Interessant ist, daß Erik (neslib) für das SDL-Projekt unter anderem sein "Chet"-Projekt genutzt hat, mit dem man C/C++-Code umtoasten kann auf Pascal-Code. Das habe ich bei Programmierung von Pascal-Headern auch schon eingesetzt (parallel zu h2pas aus Lazarus).

Und weil heute Freitag ist und man sich Freitag etwas "Creative-Friday" gönnen kann, schaue ich mir jetzt mal Mathias sein SDL-Package an.

[Mathias]

Welche Units und Komponenten nutzt ihr für Spieleprojekte mit fpc/Lazarus?

Wen ich jetzt ein Games coden würde, würde ich SDL3 in Kombination mit OpenGL verwenden.

zur Anregung:
https://github.com/neslib/Neslib.Sdl3
leider für Delphi

Auch eine spannende Variante, das ganze SDL in eine classe zu packen. Mir persönlich ist die pure Variante sympatischer. Wen man die pure C-Bindung verwendet, kann man sich die ganzen Infos zu SDL3 auch in C-Programmen holen, oder bei Fragen sich im offiziellen SDL Forum wenden. Und die Pflege wird auch einiges komplizierter sein, wen alles so eingekapselt ist.

[corpsman]

Also ich nutze für meine Spiele eigentlich immer nur
- dglOpenGL.pas und die OpenGLContext Komponente zum Rendern
- bass.pas für Musik
- Lnet für Netzwerk sachen
und wenns unbedingt ein Joystick support sein muss, dann kommt noch SDL mit dazu.

Damit dass alles sauber geht habe ich natürlich noch jede Menge "wrapper" und helfer gemacht damit ich die oben genannten besser nutzen kann:
- OpenGl
- Netzwerk
- SDL Joystick und SDL runtime gelinkt

Wenn ihr nun noch sehen wollt, was ich damit alles so gebastelt habe:

FPC Atomic die Nachprogrammierung des Klassikers von 1997
Config TD Ein Multiplayer Tower Defence Clon
FPC_DOOM ein Sourceport der DOOM Engine
Greenfoot for Lazarus Die Nachprogrammierung der Java Version mit Lazarus und OpenGL

Und noch ettliche weitere gelistet in meinen Miniprojects

[Mathias]

Mir ist auch mal eine Idee durch den Kopf gegangen. Die Konfiguration für ein Games in einer LCL-App machen und sobald man Run drückt wird die Konfiguration in eine Datei gespeichert. Anschliessend startet man ein SDL-Programm im Vollbildmodus, welches die Konfiguration aus der Datei holt. Und sobald gameover ist, beendet sich das SDL-Programm und man ist wieder im LCL-Programm.
So ist man im reinem Spiel die ganze LCL-Last los und man kann SDL voll ausreizen.

[jammernich]

Hallo zusammen,

Offensichtlich schon:

... Castle Game Engine gefällt mir, aber es ist mir auch schon zu komplex und ich mag nicht dass man VS Code als Editor auch nur vorgeschlagen bekommt. Das finde ich blödsinnig für ein Pascal-Projekt...

Aber vielleicht schaust Du Dir mal folgendes Video an: https://www.youtube.com/watch?v=hPmJB0mS-GA. Darin wird im Live Coding mit der FP IDE ein SDL-"Space Invaders Clone" programmiert. Zugegeben, mit 4h Laufzeit bei zweifacher Geschwindingkeit ist das Video nicht gerade handlich, aber wenn man es auf halber Geschwindigkeit abspielt und kleinere Abschnitte zerlegt, ist es eine sehr interessante Dokumentation für Pascal- und Spieleprogrammierungs-Fans...

Das video fetzt! Danke für den link

Die Castle Game Engine ist mir zu komplex.

Mir ist auch mal eine Idee durch den Kopf gegangen. Die Konfiguration für ein Games in einer LCL-App machen und sobald man Run drückt wird die Konfiguration in eine Datei gespeichert. Anschliessend startet man ein SDL-Programm im Vollbildmodus, welches die Konfiguration aus der Datei holt. Und sobald gameover ist, beendet sich das SDL-Programm und man ist wieder im LCL-Programm.
So ist man im reinem Spiel die ganze LCL-Last los und man kann SDL voll ausreizen.

Das nutzen viele alte Spiele.

[jammernich]

zur Anregung:
https://github.com/neslib/Neslib.Sdl3
leider für Delphi

Ich habe mir das Projekt von Erik van Bilsen (neslib) mal runtergeladen und in meinem recht aktuellen Delphi geöffnet. Die Beispiele (Examples) ließen sich alle durchkompilieren und meine Stichproben waren auch lauffähig ohne Zicken.
Einen kleinen Blick habe ich auf den Code geworfen. Erik verwendet gerne neueste Delphi-Features. Ich bin da mehr old-school unterwegs.
Aber wenn man vermutlich die Doku liest, auch was SDL generell anbelangt, sollte man es hinbekommen, die Beispiel-Projekte anfangs mal ein bischen zu erweitern und da etwas drin rumzuprobieren, also z.B. mal eine "Line" mehr rein programmieren usw.
Die "Apps" haben scheinbar alle die selbe Struktur.

Code: Alles auswählen

TApp = class(TSdlApp)
  private
 	....
  protected
    function Init: TSdlAppResult; override;
    function Iterate: TSdlAppResult; override;
    procedure Quit(const AResult: TSdlAppResult); override;
  end;

also drei Methode überschreiben und los geht's.

Also das finde ich auch sehr interessant, wie er das aufgebaut hat. Bare.Game ist ein ähnliches Projekt, da kann man viel über Aufbau und Struktur lernen

hier der link: https://github.com/sysrpl/Bare.Game

[BeniBela]

Ich habe Spiele ganz einfach mit Canvas und der VCL (TImage/TShape) gemacht: https://benibela.de/games_de.html

Und wenn jetzt jemand glaubt, dass sei zu langsam, das lief perfekt unter Windows 98 auf einem 25 Jahre alten PC. Da war ich noch nicht einmal ein Teenager. Damals wusste ich noch nicht so richtig was Arrays sind und habe viel mit FindComponent('name' + inttostr(i)) gearbeitet und selbst das war schnell genug

[Warf]

Spiele Entwicklung ist so ein kleines Seiteninteresse von mir, insbesondere wenn man sich die verschiedenen Level anschaut.

Ganz simple Grafiken mit SDL, OpenGl etc. Kann man sich sehr schnell rein arbeiten und was einfaches produzieren. Spiele wie Pong, Asteroids, Space Invaders, selbst Ray Casting Shooter wie Doom sind Recht einfach und schnell gebaut.
Das sieht man auch an frühen spielen, die oftmals von 1-2 Entwicklern gebaut werden konnten.
Das geht mit Lazarus auch absolut super.

Damit bekommt man aber nur Recht simple Sachen hin. Wenn man ein größeres und grafisch aufwendiges Spiel mit Physik und co machen will braucht man eine engine. Man kann auf Basis von den primitiven (OpenGL, SDL, etc.) sich eine eigene engine schreiben, aber das dauert und ist je nach Spiel sehr aufwendig. Insbesondere eine gute Performance zu erreichen.
Wenn man sich historisch die Spiele so rund um die 90er bis Anfang 2010er anschaut hatten die meistens eigene engines und da hat man dann plötzlich Teams von duzenden Entwicklern plus Grafik und Sound designer und co.
Klar kann man das theoretisch auch in Lazarus machen, aber das ist nix was man mal eben als privat Projekt machen kann.

Seit einigen Jahren gibt es allerdings vor allem auch Drittpartei engines oftmals mit Asset Stores und co, wie unity, unreal oder auch Godot, mit denen die Spiele Entwicklung wieder viel einfacher wird, und seit dem ist die Indiespielscene absolut explodiert. Mittlerweile kann eine Privatperson grafisch und physikalisch aufwendige spiele in seiner Freizeit bauen ohne dafür ein team an Festangestellten Entwicklern und Designern haben zu müssen.
Der Nachteil ist, diese engines geben die script sprachen Recht fix vor. Unity ist C#, unreal ist C++, Godot ist python(artig)

Da gibt es für Pascal nur castle. Die hab ich noch nicht benutzt, aber ich sag's mal so, es hat einen Grund warum es sich normalerweise auf ein paar engines runterläuft. Es bildet sich eine Community, es gibt Ressourcen und assets für diese engines.
Und am Ende des Tages lern ich lieber vielleicht ne neue Programmiersprache (denn sind wir mal ehrlich so große Unterschiede gibt's da nicht) und hab dafür eine engine mit vielen Beispielen, assets und co.

[af0815]

Also das finde ich auch sehr interessant, wie er das aufgebaut hat. Bare.Game ist ein ähnliches Projekt, da kann man viel über Aufbau und Struktur lernen

hier der link: https://github.com/sysrpl/Bare.Game

So nebenbei, wurde von sysrpl dort schon seit fast 10 Jahren nichts mehr gemacht (Der User ist im englischen Forum trotzdem aktiv), daher sehe ich das mal als totes Pferd an.

[jammernich]

Seit einigen Jahren gibt es allerdings vor allem auch Drittpartei engines oftmals mit Asset Stores und co, wie unity, unreal oder auch Godot, mit denen die Spiele Entwicklung wieder viel einfacher wird, und seit dem ist die Indiespielscene absolut explodiert. Mittlerweile kann eine Privatperson grafisch und physikalisch aufwendige spiele in seiner Freizeit bauen ohne dafür ein team an Festangestellten Entwicklern und Designern haben zu müssen.
Der Nachteil ist, diese engines geben die script sprachen Recht fix vor. Unity ist C#, unreal ist C++, Godot ist python(artig)

Da gibt es für Pascal nur castle. Die hab ich noch nicht benutzt, aber ich sag's mal so, es hat einen Grund warum es sich normalerweise auf ein paar engines runterläuft. Es bildet sich eine Community, es gibt Ressourcen und assets für diese engines.
Und am Ende des Tages lern ich lieber vielleicht ne neue Programmiersprache (denn sind wir mal ehrlich so große Unterschiede gibt's da nicht) und hab dafür eine engine mit vielen Beispielen, assets und co.

Hallo Warf,
diesen Überlegungen kann ich nur zustimmen. Die Situation ist momentan günstig: Unity und Godot unterstützen beide C# (https://docs.godotengine.org/en/stable/ ... d-in-godot). Das ist schon sehr attraktiv, es gibt sogar Bücher die das c# erlernen über Unity angehen. Also wenn man nicht Castle GE benutzen möchte und auf Lazarus setzt bleibt einem gar nichts anderes übrig als sich mit SDL / OpenGL zu beschätigen, aber dieser "Do It Yourself"-Aspekt hat auch seinen Reiz! Im englischen Forum gab es einige Verbesserungsvorschläge an den CGE Entwickler Michalis. Da haben Unity/Godot ganz andere Ressourcen verfügbar - mehrere Entwickler, auch Designer und wahrscheinlich viel Geld.

Benutzt jemand von euch Raylib oder BGRAGames für Lazarus?

Vielen Dank an Alle, die ihre Projekte hier zeigen! Das motiviert mich sehr

[Warf]

Eine Sache die bei mir schon Recht lang auf der langen Bank liegt ist tatsächlich mal GDNative wrapper für FPC zu bauen. Man kann mit GDNative sehr gut in anderen Sprachen Godot benutzen, ich selbst bevorzuge mittlerweile C++ über die Godot Sprache, einfach wegen starken Typchecking und Compiler und co.

Und da die API der scriptsprache praktisch nur die Klassenstruktur der internen c++ Architektur abbildet kann man Infos über das eine Recht trivial in das andere überführen.

Das einzige was man da schauen müsste ist wie man das Speicher management abbildet, damit man die Referenzzählung innerhalb von Godot nicht mit dem manuellen Speicher management von Pascal vermischt.