Einfaches Framework für Minigamesammlung & beispielgame

[ASecondGuy]

Ein paar Leute fanden die Minigame Sammlungs Idee gut. Ich hatte sowas vor paar Jahren schonmal gemacht. Das alte ding hab ich schnell mal geupdatet. Gehört natürlich zum Issue #12

[RedstoneMedia]

Prinzipiell finde ich die Idee Minispiele dynamisch aus einem Ordner zu laden und aus einer .ini Config die Metadaten zu lesen ziemlich gut. Würde aber eine base Scene für Minispiele machen von der Gerbt wird, sonst kann man die schlecht vereinheitlichen (das kann man aber auch noch in ner zweiten PR machen). Außerdem wofür ist bitte schön "EmptySzene" ?

Edit: Ach ja und versuch am besten Mal die ganzen leeren Zeilen zu entfernen (denke mal du hast da Code rausgelöscht aber vergessen die Zeilenumbrüche zu entfernen).

[BjoernAkAManf]

Habe ein paar Kleinigkeiten hinzugefügt und es auf dem CI commit aufgebaut.

Wer das keine Mini Game mal spielen möchte: https://github.com/BjoernAkAManf/Suffragium/actions/runs/2390186088

[joshua-Ig]

Minispiele sind nice, aber ich würde vorschlagen, dass man (wie z. B. bei Fortnite) in Game zu den Spielen hingehen kann und sie dann startet. Dann können Leute immer noch drumherum Sachen bauen, die nicht unbedingt ins mini spiel Format passen.

Außerdem würde ich eine Art Readme hinzufügen in der beschrieben ist wie man die game.cfg gestalten muss (habe aber auch kein plan wo so was hingehört)

[Joshix-1]

Man kann ja erstmal machen, dass man die Minispiele in einem Menü auswählt. Eine Lobby in der man zu den Minispielen hingeht kann man ja später immernoch machen

[ASecondGuy]

@RedstoneMedia Bei den meisten Sachen davon hab ich mir was gedacht. Dass die einzelnen Games mehr Freiheiten haben sollten die per get_tree().change_scene() geladen werden. Gameübergreifendes wird dann vom Gamemanager oder anderen Autoloads gemacht. In die andere Richtung (Also von Manager zum Game) geht die Kommunikation Über signale oder mit has_method(). Die Leere Szene ist ein Platzhalter weil man ja ne Mainscene braucht. Die wird dann durch das geladene game ersetzt. Das wäre dann die Szene wo eine Overworld (wie von @joshua-Ig vorgeschlagen) implementiert wäre. Der Code ist größtenteils aus nem alten Projekt kopiert und geupdated. Ich hatte nicht so viel Zeit den groß zu verschönern.

[Joshix-1]

Sieht als Anfang nicht schlecht aus. Du solltest das aber mal mit https://github.com/Scony/godot-gdscript-toolkit linten und formatieren. Da gibt es ein paar kleine Code-Style-Probleme

[ASecondGuy]

Mach ich sobald ich wieder am PC bin. Das Beispielgame werd ich dann auch gleich bissl ausbauen. In Richtung Standardisierung fehlt da noch einiges. Die config könnte auch noch Kommentare vertragen.

[RedstoneMedia]

Ich weiß nicht, ob es sich lohnt so ein Beispiele Game auszubessern. Ich mein das ist ja praktisch nur dafür da, um dem Developer nen besseren Überblick zu geben und damit man sich ggf. Code kopieren kann um schnell anzufangen.

[ASecondGuy]

Das war schlecht formuliert. Das Gameplay wird nur minimal ausgebaut. So dass man gewinnen und verlieren kann. Mindestens eins von den beiden wird jedes Spiel brauchen also sollte das auch im Beispiel sein.

[ASecondGuy]

So. Das sollte das gröbste gewesen sein denke ich. Feedback natürlich gerne willkommen.

[BjoernAkAManf]

Error handling sollten wir definitiv machen:

siehe https://github.com/BjoernAkAManf/Suffragium/commit/62f7a72dcf4c4c5c83c2287d3e11aa9c570c02d6

[Joshix-1]

Bei dem Test-Spiel sollten die Balloons mehr in ein eigenes Skript. Find den Code des Testspiels zurzeit nicht wirklich Clever. Hab mich mal versucht das zu verbessern, da dies mein erster Versuch mit Godot ist weiß ich nicht wie gut das alles ist. Meine Changes sind hier: https://github.com/Joshix-1/Suffragium/commit/3dfe924a3f30952476df0b738459f2c5c1a764e5

[ASecondGuy]

Das von @BjoernAkAManf schaut sinnig aus. Ich kuck dass ich das bald bei mir reingemerged bekomm. @Joshix-1 Das sieht größtenteils nach Geschmackssache und dem formatierungs ding aus das ja eh bald automatisch geht.

[Joshix-1]

Das sieht größtenteils nach Geschmackssache

Joa, kann gut sein. Wenn dir die Änderungen nicht gefallen musst du die nicht übernehmen. Ich find die aber nicht schlecht. Du solltest sie also wenigstens einmal testen.

das ja eh bald automatisch geht

Das musst du weiterhin lokal machen. Und manche Sachen werden nicht automatisch gefixt

[Joshix-1]

Jetzt sind hier ja auch die ganzen Änderungen von #14 drin. Das verwirrt und sollte nicht so sein.

[ASecondGuy]

Ja da ist wohl was falsch gelaufen. Wie fixe ich das?

[MarioLiebisch]

Da alles linear ist, wohl am einfachsten per git rebase -i main. Du bekommst eine Datei bzw. Auflistung aller commits und kannst dort dann auswählen, was mit Commits passieren soll. Du suchst einfach die raus, die nicht von dir sind, und markierst die mit d für drop.

Wenn es die letzten Commits sind, würde ich dann der Einfachheit eben vor dem git push noch eine andere (sinnvolle) Änderung per Commit hinzufügen.

Dadurch werden die Branches abweichen (lokal gegen Server), weshalb ein git push nicht mehr funktionieren wird. Wenn du das aber mit git push --force umgehst, wird auch die Serverseite dann umgeschriebenn.

[Joshix-1]

Ich find bei dem Ballon-Spiel nicht gut, dass da Pop the $COLOR balloon steht, obwohl es mehrere Ballons dieser Farbe geben kann.

[ckanitz]

@ASecondGuy please add a readme / documentation explaining how to add a new game. I'd suggest to place either a README.md explaining the steps for both, gamemanager.gd and gamedisplay.gd or a samenamed .md for each of those (GAMEMANAGER.md + GAMEDISPLAY.md) at the same folder as the scripts.

And with the vote at https://github.com/letsgamedev/Suffragium/issues/18 in mind please consider to write future commit messages in english.