'N (paar) Platformer aus Spaghetticode

[Jan125]

Ich habe eine sehr unorthodoxe Arbeitsweise.
Manchmal starte ich ein Projekt, programmiere ein paar Tage für 45 Minuten dran rum, und vergesse es dann wieder.
So lief es auch hier.

Nach insgesamt 3 Anläufen in 2D-Platformern mit verschiedenen Philosophien hab ich nun etwas zusammengeschustert, was hoffentlich nach Bereinigung und Lizenzänderung (mehr dazu später) als eine sehr simple Basis für zukünftige Projekte dienen kann.
Doch nun eine kleine Aufzählung zu den vorrausgehenden Projekten:

Projekt 1
Arbeitstitel: Lineart.
Philosophie: Bugs = Features.
Das wohl Feature-kompletteste der ganzen Projekte, wenngleich auch das mit dem höchsten Spaghetticodeanteil.
Strukturen waren mir noch nicht bekannt, oder sie wurden willig ignoriert. ("Pff, brauch ich doch nicht, ich kann mir das merken!!!")

Durch solchen Spaghetticode gab es mehrere Probleme:
-Das Ganze war langsam.
-Partikel und Objekte wurden in statischen Arrays behandelt.
-Das Ganze war sehr fehlerbehaftet, einige dieser Fehler wurden jedoch Aufgrund der Philosophie als Features eingearbeitet.
-Das Ganze war effektiv unwartbar.
Man fiel mitunter durch eine Plattform, wenn die Y-Geschwindigkeit größer war als die Platformdicke.
Also änderte ich die Solidität dieser Plattformen so, dass sie nur bei einem Actor, der sich NICHT in der Luft befindet überhaupt als solide erkannt werden können.
Auch Y-Bugs existierten, so steckte man auch gerne mal in einer Platform, oder wurde in einen Abgrund teleportiert.

Aufgrund der Unwartbarkeit habe ich dieses Projekt dann verworfen, aber der "Code" schwirrt immer noch irgendwo auf meiner Festplatte rum. Herausgekommen ist ein erstes angewandtes Verständnis für PureBasic, sowie eine Routine für ControllerToKeyboard()-Funktionen.

Projekt 2
Arbeitstitel: Dinomassacre.
Philosphie: Floats = Doof, nutze nur Integer.
Der Start eines Art-Themas, welches ich auch heute noch weiter verfolge. Den kleinen grünen Kerl werdet ihr noch öfter sehen.

Mittlerweile hatte ich mich mit Strukturen angefreundet, war jedoch ein erklärter Gegner von Floats.
Diese Ära dauerte eine relativ lange Zeit an, und ich habe folgende Errungenschaften... errungen:
-Pixel-basierte Kollisionen.
-Ein Kamerasystem.
-Ein dynamisches Actor-System.
-"Bots".
-Eine erste Bekanntschaft mit Servern, leider nur Crashes.
Im Allgemeinen war dieses Projekt relativ effizient und auch zu einem gewissen Grad angenehm zu warten. Dennoch wuchs der Code mit der Zeit so an, dass neue Features (Scriptsystem, richtige Animationen) zu schwierig zu implementieren gewesen wären.
Ein paar wichtige ältere Features waren auch rausgeflogen, ohne Hoffnung auf Wiedereinführung. (Controller-Support, dynamische Maps, Partikel)
Weiterhin hatte ich den Fehler gemacht und keine konsistenten Archive von der Versionshistorie angelegt, Das Projekt ist also nur noch halb erhalten.
Schlussendlich sah das Ganze dann aber trotzdem süß aus:


Projekt 3
Arbeitstitel: Unbetitelt.
Philosphie: Alles dynamisch!!!
Nur ein 2-Wöchiger Test von Sprites, Kameras, Kollisionsroutinen, und Stresstests.
Es wurde nicht wirklich viel Neues gelernt, dennoch diente es zur Erprobung von für mich neuen Routinen.
Leider keine Bilder vorhanden. :<

Projekt 4
Arbeitstitel: Awoo! (Bitte schlagt mich nicht.)
Philosphie: Floats = Megakrass.
Zwischendurch lernte ich noch Menus kennen, und wollte ein möglichst subsystemunabhängiges Programm schreiben, und so fing ich erstmal mit PB-Version 5.00 an, da dort Dx7, Dx9, und OpenGL unterstützt wurden.
Nach Problemen mit Transparenz (das Ganze soll ja schließlich nicht vollständig aus dem letzten Jahrhundert kommen) sowie der fehlenden Bool()-Funktion bin ich dann auf 5.24LTS gewechselt, und relativ zufrieden damit.
Sich mit den einzelnen Bugs der OpenGL und DirectX11-Subsysteme auseinanderzusetzen war nervenaufreibend, da beide (und ganz besonders DirectX11) Bugs, Memory Leaks, etc.. aufweisen, die bei DirectX9 schlichtweg nicht vorhanden sind.
Das Ganze ist größtenteils wieder eine Regression von den vorherigen Projekten, jedoch wurde mehr auf eine wartbare Struktur geachtet. (Ja, die anderen Projekte waren noch schlimmer.)


Ihr dürft euch davon gern mal ein eigenes Bild machen, Source natürlich mit dabei. :3
Ich habe mich entschieden, das Ganze erstmal unter einer unglaublich restriktiven Lizenz zu zeigen, jedoch wird dies nach der Fertigstellung geändert werden.

Steuerung:
AD - Bewegung links rechts.
JL - Nach links und rechts gucken.
S - Boost.
Tab - Dauerhafter Boost wenn gedrückt gehalten.
Space - Springen. In der Luft nochmal drücken für 'nen Doppelsprung. :3
Shift - Gedrückt halten für Sprintmodus.
Esc oder 1234 auf der Nummernleiste eingeben - Menü anzeigen.
F1 bis F12 bieten auch Zugriff auf die Menü-Funktionen.
Pfeiltasten - Direkte Positionsverschiebung des Spielers.

https://drive.google.com/file/d/1xfA_Io ... sp=sharing


Alles ist noch ein ewiger WIP, Verbesserungsvorschläge und eventuelle Dev-Wünsche sind gern gesehen.

[RSBasic]

Schau ich mir heute Abend mal an. Sieht jedenfalls interessant aus.

[RSBasic]

Ich habe es mal getestet. Schau mal cool, aber wenn ich mit Leertaste springe und Pfeil nach oben drücke, dann ist es manchmal möglich, nach oben und dann aus dem Level zu fliegen bzw. bin dann auf dem "Dach" des Levels.

[Jan125]

Ups, das packe ich gleich mal in die Steuerung mit rein, das war für's Debugging.
Mit F9 kannst dich resetten.

Meine Hauptsorge gilt momentan eig. der Spriteanzeite, auf einigen Systemen funktioniert ToggleSpriteBackfaceCulling() nicht ordnungsgemäß.

[DarkSoul]

Buuuuuuugs...

- Bei gleichzeitiger Links- und Rechtsbewegung sollte die Spielfigur stehen bleiben. Sie läuft jedoch manchmal nach rechts.

- Das Abwärtslaufen auf einem Rechtsgefälle ist mit starken Rucklern verbunden.

- Gelegentlich versagt die Kollisionserkennung und ich kann durch Wände laufen. Das beruhigt sich erst wieder, wenn ich die Schaurichtung wechsle. Das passiert speziell bei Bewegungen und Kollisionen während Sprüngen.

- "Boost" während eines Sprunges möglich.

- Das hinauflaufen auf einer schrägen Kante im 45°-Winkel ist buggy bzw. extrem langsam (habe die Leveldatei dafür modifiziert)

Ansonsten sehr gelungen.

[Jan125]

- Bei gleichzeitiger Links- und Rechtsbewegung sollte die Spielfigur stehen bleiben. Sie läuft jedoch manchmal nach rechts.

Dürfte am Keyboard-Ghosting liegen, das ist systemspezifisch. D:

- Das Abwärtslaufen auf einem Rechtsgefälle ist mit starken Rucklern verbunden.

Wie ich das löse, dass der Player am Boden klebt wenn er 'ne Treppe runter läuft bin ich mir noch nicht sicher.

- Gelegentlich versagt die Kollisionserkennung und ich kann durch Wände laufen. Das beruhigt sich erst wieder, wenn ich die Schaurichtung wechsle. Das passiert speziell bei Bewegungen und Kollisionen während Sprüngen.

Also durch die Wände sollte es eig. nicht gehen, nur dass es eventuell kurz an einem 45° Winkel an der Decke stecken bleibt passiert manchmal.
Könntest du mir da ein paar mehr Infos geben?

- "Boost" während eines Sprunges möglich.

Soll so! :P

- Das hinauflaufen auf einer schrägen Kante im 45°-Winkel ist buggy bzw. extrem langsam (habe die Leveldatei dafür modifiziert)

Jau, der Code ist dafür momentan nicht ausgelegt.
Eventuell wäre ein Workaround möglich, indem man das .png für die Player-Collision anpasst, bzw. unten links und rechts abrunden. Ich teste das nachher mal.

[DarkSoul]

Dürfte am Keyboard-Ghosting liegen, das ist systemspezifisch. D:

Doch nicht auf den WASD-Tasten. Habe es extra nochmal ausprobiert: Nein, nein, nein...

Das Abwärtslaufen auf einem Rechtsgefälle ist mit starken Rucklern verbunden.

Genauso wie beim Linksgefälle, wo das nicht auftritt.

Also durch die Wände sollte es eig. nicht gehen, nur dass es eventuell kurz an einem 45° Winkel an der Decke stecken bleibt passiert manchmal.
Könntest du mir da ein paar mehr Infos geben?

Ganz genau habe ich as auch nicht orten können. Aber wenn du stecken bleibst, kannst du weiter hineinlaufen. Zumindest ist das bei mir so.

Jau, der Code ist dafür momentan nicht ausgelegt.
Eventuell wäre ein Workaround möglich, indem man das .png für die Player-Collision anpasst, bzw. unten links und rechts abrunden. Ich teste das nachher mal.

Die Kollisionsmaske von der Grafik zu trennen ist schon der richtige Weg. Aber für grundlegende Bewegungen sollten keine Workarounds erforderlich sein.

Dann ist deine Kollisionserkennung noch nicht ausgereift. Rampen bis 45° sollten eigentlich kein Problem sein. Eine Möglichkeit, mit schrägen Ebenen umzugehen:
Ausgangssituation: Laufmodus. Weder Fall- noch Springmodus sind aktiv.
1. Spieler drückt Taste rechts auf einer schrägen Ebene
2. Spieler 1px (oder wie viel auch immer, ich sage jetzt 1px als Beispiel, was natürlich zu lahm ist) nach rechts versetzen, sofern möglich. Falls nicht, keine Bewegung durchführen und bei Schritt 4 weitermachen.
3. Luft nach oben? Nein? Spieler 1px nach oben versetzen.
4. Luft nach unten? Wenn ja: Wieviel?
<=2px? -> entsprechend nach unten versetzen, im Laufmodus verbleiben
> 2px? -> In Fallmodus übergehen (und Zyklus für Zyklus weiter fallen, bis Boden erreicht wird. Dann wieder Laufmodus oder Totmodus oder was auch immer.)
Unendlich viel? Da ist kein Boden mehr. Hier ist es wichtig, dass der Spieler spätestens dann stirbt, woanders wieder eingeworfen wird oder sonstwas passiert, sobald der untere Levelrand deutlich überschritten wird. was diesen endlosen Fall begrenzt. Das fehlt nämlich bisher. Auch dann einprogrammieren, wenn die Situation eigentlich nicht vorkommt, da sonst der Spielstand zerstört wird, falls der Spieler durch einen Bug doch mal nach unten herausfällt.
(2px = maximales Gefälle, das noch nicht als Fall gewertet wird. Je größer, desto steiler ist das Gefälle, auf dem noch gelaufen statt gefallen wird.)
5. Spieler hat entgültige Position für den Zyklus. Damit weitere Gamelogik berechnen (Gegnerkollisonen usw.)
6. Geänderte Spielszene rendern. Bewegung ist jetzt sichtbar.

Der Spieler läuft dadurch zwar quasi im "Zickzack" auf einer geraden Ebene, aber das macht nichts, weil die Spielerposition erst dann weiter ausgewertet wird, wenn die entgültige neue Position für den aktuellen Zyklus feststeht. Grafisch ist das natürlich nicht zu sehen, weil die Spielgrafik einmalig am Ende auf diese neue Position versetzt wird.

Lust nach unten sollte immer geprüft werden, nicht nur bei Spielerbewegungen. Grund: Die Spielszene ändert sich z.B. insofern, dass der Klotz, auf dem der Spieler still steht, unter diesem wegbricht. Fehlt die permanente Überwachung auf Luft nach unten, würde der Spieler in der Luft schweben und erst fallen, sobald er bewegt wird.

Aber keine Bange: Du bist nicht der erste, wo das nicht so perfekt ist. Ich habe schon als Kind auf dem alten Gameboy solche Bugs erfolgreich gefunden, wo der Spieler in der Wand stecken bleibt oder "aus dem Level fliegt". Das bedeutete meistens freier Fall in den für die Spiellogik reservierten Speicherbereich, der als grafisches "Chaoslevel" gerendert wurde und durch das Umherbewegen darin stürzte das Spiel dann recht schnell ab, da die ausgelösten Interaktionen diese Bereiche überschrieben. Das geht sogar bei gängigsten Gameboyserien, wie Super-Mario, Zelda und Donkey-Kong. Ich fand das immer total spannend, solche Fehler zu finden und als Abkürzung auszunutzen. Manchmal habe ich sogar Outtake-Levelfragmente gefunden, die von den Entwicklern erstellt, aber dann nicht verwendet wurden. Lustig waren auch eigentlich unerreichbare Levelelemente, die ich dann doch irgendwie erreichen konnte, um dann festzustellen, dass sie gasförmig (ohne entsprechende Kollisionsmap) sind. Bei Marioland habe ich auch immer Bugusing betrieben, um trotz Pilz unten langlaufen zu können (wo man nur klein durchpasst), wo die ganzen Boni waren. Das waren Zeiten.... Da wusste ich noch nicht, was "Bug" bedeutet.... und man hatte viel Zeit, um die Logik durch irgendwelche unsinnigen Spielzüge zu überlisten nach dem Mottio "Das muss doch auch anders gehen...". Der Preis dafür: Ganz am Ende von einem Zeldaspiel fehlte mir eine Flöte, die ich aufgrund von völlig verschalteter Spiellogik nicht mehr bekommen konnte, so dass ich den Endgegner nicht spielen konnte. Besonders Ecken und ungewöhnliche Levelelemente waren fast immer dazu verdammt, potentielle Bugs zu beherbergen.