Harald Hoppelhase

[Specialist]

Die Bäume / Häuser wären nicht so schnell weg. Es hängt etwas davon ab wie weit entfernt du sie im Hintergrund platzierst.
Überleg mal. Ein Hase hat eine Körperhöhe von vielleicht 30cm, 40cm? Deine Blätter sind also irgendwas um die 1m in der Höhe voneinander entfernt. Vielleicht auch etwas mehr. Eichen werden aber 20 bis 30 Meter hoch, Fichten auch gerne mal 50m. Und es muss ja nicht realistisch sein. Du kannst die Bäume auch 100m hoch machen und es wäre vermutlich für die Spieler völlig in Ordnung.

[Schrompf]

Ich habe gestern beim Stammtisch live den Harald ausprobieren können und war echt beeindruckt. Ein sehr rundes Erlebnis, schöner Grafikstil und ein martialisches knöchernes BRRRKK, wenn man zu tief fällt. Ne Online-Highscore, ein Tutorial, und wirklich beeindruckend: ein prozeduraler Levelgenerator, der mit Kenntnis der möglichen Sprünge echt passende Levelpfade erstellt.

Paar Ideen zur Verbesserung:
a) Die Sprünge in der Höhe sind mir ein bisschen zu perfekt auf die Sprunghöhe abgestimmt. Es passt zwar, aber da man optisch nur so auf halber Höhe des Zielblattes ankommt, fühlt es sich an, als ob man scheitern würde. Wenn der Sprung ein paar Pixel über das Zielblatt führen würde, so dass man auch optisch die Höhe erreicht, würde sich das Gameplay für mich noch etwas schlüssiger anfühlen.

b) Die Pflanze wächst schon ganz superfluffig elegant, da müsste es doch gehen, dass die Blätter rein optisch kurz federn, wenn man drauf springt. Kein Gameplay, sondern rein optisch, nur ein kurzes Wippen.

[Jonathan]

Hey, vielen Dank fürs Anspielen und für dein nettes Feedback!

Das mit den Blättern klingt gut, so ein bisschen Bewegung kriegt man da gewiss rein. Ich schaue mal, was sich machen lässt.

Währenddessen: Ich musste feststellen, dass ich mit einer einzelnen Versionsnummer wohl nicht mehr auskomme. Jedesmal wenn sich die Spielbalance ändert, wird ja die Highscore nutzlos, weil die Voraussetzungen nicht mehr gleich sind. Deswegen ist jeder Eintrag fest mit einer Versionsnummer verbunden. Gleichzeitig wird diese auch genutzt um im Hauptmenü Servernachrichten anzuzeigen - hauptsächlich um auf neue Versionen hinzuweisen, aber vielleicht auch für temporäre Nachrichten wie Feiertagsgrüße (weil, warum denn nicht).

Jetzt ändert aber nicht jede neue Version die Spielbalance. Es könnte also ein Featureupdate mit besserer Grafik und wackelnden Blättern geben, aber die Highscoreliste soll gleich bleiben - und schon brauche ich zwei unterschiedliche Versionsnummern. Alternativ könnte ich natürlich major / minor Versionen machen, aber aktuell ist die Version halt einfach ein String ohne festes Format. Hach...

[Schrompf]

Hehe, da kann man doch was hacken. Mach ne Version im Format "ZifferZiffer...RestRest...", dann kannst Du ne Zahlkonvertierung draufjagen und gleichzeitig das Ding als String vergleichen. String-Unterschiede == MinorVersion, Zahl-Unterschiede == MajorVersion, macht die Highscore kaputt. Und eine Version mit optisch wippenden Blättern wäre dann ne "23a"

[Alexander Kornrumpf]

Hey, vielen Dank fürs Anspielen und für dein nettes Feedback!

Das mit den Blättern klingt gut, so ein bisschen Bewegung kriegt man da gewiss rein. Ich schaue mal, was sich machen lässt.

Währenddessen: Ich musste feststellen, dass ich mit einer einzelnen Versionsnummer wohl nicht mehr auskomme. Jedesmal wenn sich die Spielbalance ändert, wird ja die Highscore nutzlos, weil die Voraussetzungen nicht mehr gleich sind. Deswegen ist jeder Eintrag fest mit einer Versionsnummer verbunden. Gleichzeitig wird diese auch genutzt um im Hauptmenü Servernachrichten anzuzeigen - hauptsächlich um auf neue Versionen hinzuweisen, aber vielleicht auch für temporäre Nachrichten wie Feiertagsgrüße (weil, warum denn nicht).

Jetzt ändert aber nicht jede neue Version die Spielbalance. Es könnte also ein Featureupdate mit besserer Grafik und wackelnden Blättern geben, aber die Highscoreliste soll gleich bleiben - und schon brauche ich zwei unterschiedliche Versionsnummern. Alternativ könnte ich natürlich major / minor Versionen machen, aber aktuell ist die Version halt einfach ein String ohne festes Format. Hach...

Ich darf darauf hinweisen dass "und schon brauche ich zwei unterschiedliche Versionsnummern." kein Naturgesetz ist sondern ein Artefakt der hier beschriebenen Architekturentscheidungen. Ich weiß du machst das als Hobby, aber (und hier spreche ich tatsächlich aus Erfahrung) in der realen Welt willst du ein System haben mit dem du Nachrichten anzeigen kannst, das nicht von einer Versionsnummer - oder auch nur überhaupt einer Aktion des Users abhängt, realistisch macht dein Hauptmenü einen HTTP request. (Keine Ahnung, ob du das mit deiner Ideologie vereinbaren kannst, ich finde es jetzt nicht schlimmer als highscores über HTTP abzuwickeln).

Was die Highscores angeht: alles im Leben hat Vor und Nachteile, aber es gibt einen Grund dass viele Leute semantic versioning (https://semver.org/) machen. Würde hier auch funktionieren.

[Jonathan]

kein Naturgesetz ist sondern ein Artefakt der hier beschriebenen Architekturentscheidungen.

Joah, sicherlich. Letztendlich war die Lösung aber trivial: Vorher hatte ich eine globale Konstante für die Versionsnummer, jetzt hab ich halt 2 und musste einmal "Suchen & Ersetzen" auf die Highscore.cpp anwenden - 2 min Arbeit, das wars.

Semantik Versioning kenn ich und darauf habe ich mit dem "Major / Minor" angespielt, aber es bedeutet halt minimal Extra-logik. Aber all das summiert sich eben, der ganze Versions-/Highscore-/Onlinekram hat jetzt schon fast mehr Logik als das eigentliche Spiel (ausgenommen die Pflanzengenerierung natürlich). Bei meinem aktuellen Restzeitbudget muss dann eben alles so schnell und einfach wie möglich gehen, ob die Lösung schön ist ist mir dann etwas weniger wichtig.

Die Menü-Nachricht funktioniert ansich exakt so wie von dir beschrieben. Ein HTTP-Request, man kriegt ein JSON zurück, in dem steht die Textnachricht plus Formatierung (Farbe und Schriftgröße), und das wird dann im Hauptmenü angezeigt. Aber, der HTTP-Request enthält halt die aktuelle Versionsnummer, der Server liefert dann entsprechend andere Daten aus, damit man in alten Versionen Werbung für die neuen machen kann. Diese Abhängigkeit von der Versionsnummer könnte also trivial entfernt werden, aber da das quasi der einzige Grund für die ganze Logik ist, mag ich es, wie es ist.

Dieses ganze "Nachrichten im Menü"-Anzeigen ist ja überhaupt auch nur der blöden Online-Highscoreliste geschuldet. In der leisen Hoffnung, dass irgendwann mal ein paar Leute halbwegs kompetitiv werden und tatsächlich motiviert sind die globale Highscore zu knacken, gibt es halt das Problem von unterschiedlichen Versionen. Wenn du der letzte Depp bist, der noch die alte Version spielt, trittst du halt nicht mehr gegen andere an, also muss es dafür eine Warnung geben, also musste ich die Menütexte einbauen.

Aber ein Spiel, das auf Punktejagt basiert und nicht in einer Spielhalle steht, macht halt irgendwie nur mit Online-Highscoreliste Sinn, und die macht nur Sinn, wenn Punkte vergleichbar sind, also wenn alle die selbe Version spielen, und schon hat man 20 nervige Features die eingebaut werden müssen, weil es vorher einfach irgendwie keinen Sinn macht. Das war zumindest meine Sichtweise.

Aber ist schon ok, meine Engine hat viele neue Features bekommen, die ich dann Stück für Stück in andere Spiele migrieren kann. Landvogt könnte ja bestimmt auch ein paar Online-Features vertragen und jetzt ist der ganze Technologiestack da und kann recht leicht übernommen werden.

[Alexander Kornrumpf]

"der ganze Versions-/Highscore-/Onlinekram hat jetzt schon fast mehr Logik als das eigentliche Spiel" ... "aber da das quasi der einzige Grund für die ganze Logik ist, mag ich es, wie es ist." ... "und schon hat man 20 nervige Features die eingebaut werden müssen,"

Merkste hoffentlich selbst.

Es ist natürlich 100% deine Entscheidung aber wenn du weniger nervige Logik in non-gameplay Elementen haben willst, zeig halt die letzten 5 News an, egal was.

Dass du das Problem theoretisch auch mit deiner Nemesis, dem Zwangsupdate, lösen könntest ist dir hoffentlich in seiner Ironie auch nicht entgangen.

[Jonathan]

"der ganze Versions-/Highscore-/Onlinekram hat jetzt schon fast mehr Logik als das eigentliche Spiel" ... "aber da das quasi der einzige Grund für die ganze Logik ist, mag ich es, wie es ist." ... "und schon hat man 20 nervige Features die eingebaut werden müssen,"

Merkste hoffentlich selbst.

Das bezog sich auf unterschiedliche Dinge. Deinem "in der realen Welt willst du ein System haben mit dem du Nachrichten anzeigen kannst, das nicht von einer Versionsnummer - oder auch nur überhaupt einer Aktion des Users abhängt" stimme ich ja prinzipiell zu, aber halt in diesem Fall nicht. Weil es in erster Linie um einen Versionscheck geht und erst in zweiter Linie um ein News-Anzeige-System. So gesehen wird also aus gutem Grund gegen generelle Richtlinien verstoßen, was ja das Funktionsprinzip von Richtlinien ist ("mach es immer so, außer du hast einen guten Grund es anders zu tun"). Daher kein Widerspruch.

Es ist natürlich 100% deine Entscheidung aber wenn du weniger nervige Logik in non-gameplay Elementen haben willst, zeig halt die letzten 5 News an, egal was.

He? Ich glaube wir reden hier ein bisschen aneinander vorbei. Das Problem mit den verschiedenen Versionsnummern war ja am Ende sehr schnell gelöst, ich hatte nur in Echtzeit darüber berichtet wie ich eigentlich gerade erst was anderes kleines einbauen wollte und dann auf ein Problem gestoßen bin, was ich dann doch erst lösen musste. Ist halt immer nervig. Aber zum Glück gab es eine sehr schnelle und robuste Lösung, also ist alles gut.

Dass du das Problem theoretisch auch mit deiner Nemesis, dem Zwangsupdate, lösen könntest ist dir hoffentlich in seiner Ironie auch nicht entgangen.

Ne, also ein kleines Problem durch ein gewaltiges Problem zu ersetzen ist jetzt wirklich keine Lösung :D (Mal ganz davon abgesehen dass automatische Updates per Hand implementiert auch eine Menge Arbeit sind).


Anyways, ich hab mir mal angeschaut, wie man die Blattanimation wohl korrekt berechnen würde:

https://www.hindawi.com/journals/mpe/2023/2138819/

Aber ich glaube ich baue doch erstmal eine Fuddellösung ein und gucke, ob ich nicht damit schon zufrieden bin :D

[Alexander Kornrumpf]

Realistisch hast du zwei Alternativen:

- Du zeigst einen unverbindlichen Hinweis auf ein Update an. Den kannst du aber auch dann anzeigen, wenn der User das Update schon gemacht hat und sparst dir dann die Versionschecklogik komplett. Viele mindestens AA Titel machen das auch so. Ich würde dir empfehlen die Versionschecklogik rauszuwerfen, weil ich deiner Meinung bin, dass man möglichst wenig Logik haben will. Den "guten Grund es anders zu machen", sehe ich hier nicht. Die News angezeigt zu bekommen, dass es eine neue Version gibt, obwohl man diese schon hat, ist ein sehr kleiner Schaden, wenn überhaupt, den ich bei begrenzten Resourcen in Kauf nehmen würde (was wie gesagt viele kommerzielle Titel auch tun). Die Zielgruppe die sich dein Hobbyprojekt runterläd wird in der Lage sein zur Not selbst Versionsnummern zu vergleichen (unter der Annahme, dass du die installierte Version anzeigst, was eh immer eine gute Idee ist).

- Du erzwingst ein Update. Dazu gibt es verschiedene Wege, müssen wir aber nicht groß diskutieren, willst du eh nicht tun.

Von außen sieht es so aus, als hättest du dich auf einen vermeintlichen middle-ground eingeschossen, der dir den Nachteil mitbringt, dass du Versionscheck-Logik drin hast, ohne den Vorteil, dass du dich auch wirklich darauf verlassen kannst, dass alle die gleiche Version haben. Ich halte das für die schlechteste aus beiden Welten. Du musst mir nicht zustimmen, du kannst sowieso machen was du willst, aber es ist mir schon ein Anliegen wenigstens das Argument transportiert zu haben.

[Jonathan]

Für mich wird die Diskussion hier ein bisschen philosophisch, da es wirklich kein so großes Problem ist wie du glaube ich denkst. Der Versionscheck ist wirklich einfach, ich hätte das vermutlich gar nicht hier erwähnen sollen. Es gibt einfach 2 globale Variablen, die Spielversion und die Highscoreversion, die jeweils an unterschiedlichen Stellen an den Server geschickt werden, der dann darauf antwortet. Das ist weniger Logik als ein einzelner Absatz in dieser Diskussion hier, und das Optimierungspotential für eine bessere Umsetzung ist so minimal, dass es sich nicht lohnt darüber nachzudenken. Wenn alles in der Zukunft irgendwann mal eskaliert, kann man das sicherlich machen, jetzt aber halt eher nicht.

Das, worüber ich mich eigentlich beschwert habe, waren halt alle anderen Schritte. Also nichts davon ist für sich genommen wirklich viel Arbeit, aber man muss halt alles irgendwie mal gemacht haben. Angefangen davon, dass ich kein GUI-Element für Texteingabe habe, Leute aber halt ihren Namen eintippen können sollen. Aber jetzt ist ja alles drin was ich haben wollte, für die Zfx-Action isses zwar ein bisschen spät, aber das macht ja nix. Ich werde die nächste Tage mal die pre-final Version hochladen um letztes Feedback zu sammeln und dann ist das Projekt im wesentlichen fertig und ich bin eigentlich auch ziemlich zufrieden mit allem was jetzt drin ist. Dieses ganze Polishing macht halt schon nochmal viel aus, auch wenn es viel Arbeit ist.

[Alexander Kornrumpf]

Für mich wird die Diskussion hier ein bisschen philosophisch, da es wirklich kein so großes Problem ist wie du glaube ich denkst. Der Versionscheck ist wirklich einfach, ich hätte das vermutlich gar nicht hier erwähnen sollen. Es gibt einfach 2 globale Variablen, die Spielversion und die Highscoreversion, die jeweils an unterschiedlichen Stellen an den Server geschickt werden, der dann darauf antwortet.

Na klar. Wenn wir dieses Feature in Isolation betrachten ist "Es gibt einfach 2 globale Variablen, die Spielversion und die Highscoreversion, die jeweils an unterschiedlichen Stellen an den Server geschickt werden," ganz bestimmt eine einfache und überschaubare Lösung. Dennoch programmieren wir größere Anwendungen in der Regel (?) nicht nach dem Pattern "Es gibt einfach [n] globale Variablen [...] die jeweils an unterschiedlichen Stellen [verarbeitet werden]". Ist doch merkwürdig. Irgendwo muss es da einen Phasenübergang geben, sodass die lokal immer einfachste Lösung nach diesem Pattern nicht das global einfachste Gesamtergebnis erzeugt. Das ist das was mich an Software Development interessiert und das ist die Art von Frage zu der ich hoffte hier am konkreten Beispiel etwas beitragen zu können. Es steht dir natürlich frei das langweilig und philosophisch zu finden und dich in deinem Projekt auf andere Fragen zu konzentrieren.

[Jonathan]

Das ist das was mich an Software Development interessiert und das ist die Art von Frage zu der ich hoffte hier am konkreten Beispiel etwas beitragen zu können. Es steht dir natürlich frei das langweilig und philosophisch zu finden und dich in deinem Projekt auf andere Fragen zu konzentrieren.

Prinzipiell finde ich was du schreibst alles gut und es ist auch cool, dass du dich mit deiner Erfahrung so einbringst, aber ja, in diesem Fall war das einfach ein eher unwichtiges Problem, dass mich nicht eigentlich interessiert. Ich möchte lieber über Gamedesign etc. reden. In der Zukunft mag das wieder ganz anders aussehen.

[Jonathan]

a) Die Sprünge in der Höhe sind mir ein bisschen zu perfekt auf die Sprunghöhe abgestimmt. Es passt zwar, aber da man optisch nur so auf halber Höhe des Zielblattes ankommt, fühlt es sich an, als ob man scheitern würde. Wenn der Sprung ein paar Pixel über das Zielblatt führen würde, so dass man auch optisch die Höhe erreicht, würde sich das Gameplay für mich noch etwas schlüssiger anfühlen.

Hmmm - Die Kollisionsabfrage funktioniert halt so, dass man wenn man kurz unter dem Blatt ist, auf das Blatt hochrutscht (weil man intern erstmal durchs Blatt durchfällt und dann im Korrektionsschritt darauf "landet"). Das hat den Nebeneffekt, dass wenn man sehr kurz "runter" drückt um nach unten zu fallen, oder wenn man vom Blatt runterhoppelt, man sich nochmal umentscheiden und zurückhoppeln, bzw. die Fallen-Taste nochmal loslassen kann und dann wieder am Blatt ist - was ich eigentlich nett finde. Ich würde das eigentlich ungerne anfassen (wer weiß, was kaputt gehen könnte :D, die aktuelle Mechanik ist seit Monaten getestet), wie sehr stört es denn? Vielleicht können sich auch andere dazu äußern.

[Jonathan]

Release 0.2.2

Soooo,
ich brauchte von den ganzen Weihnachtsfeierlichkeiten eine kurze Auszeit und hab jetzt mal die aktuelle Version zusammengeschnürrt und hochgeladen. Das Anspielen im Stammtisch hat mir sehr weiter geholfen, meine größte Sorge war, dass Leute das Spiel nicht zum laufen kriegen oder es nicht gut genug erklärt ist. Scheint für nicht-casuals aber jetzt ok zu sein.

Download: https://jonathank.de/games/hase/download/Hase_0.2.2.zip (27 MB)

Zur Debatte stehen noch ein bisschen die Sounds. Bitte zweimal ausprobieren, einmal per "Harald Hoppelhase Deutsch.bat" und einmal per "Harald Hoppelhase Deutsch Alternative Sounds.bat"). In "data/sounds/music/" liegt auch noch ein weiteres Konzeptstück, ("musictime.mp3").

Neben der Musik ist sonst nur der Jump-Sound unterschiedlich. Ihr könnt die Sounds auch selber anpassen ("assets.txt", bzw. "assets_de_alt.txt", etc.). - bei doppelten Angaben wird jeweils die letzte verwendet und "include" referenziert halt eine weitere Datei, so kann man recht leicht Überschreibungen / Anpassungen vornehmen. Die Asset-Datei kann man per Kommandozeile ändern (siehe bat-Dateien).

Wie gesagt, Sounds / Musik sind so noch eine Frage. Ansonsten würde ich das Spiel als fertig ansehen.

Außerdem neue Features:
- Man kann die Tastatursteuerung in der config-Datei anpassen
- Blätter wackeln, wenn man auf ihnen landet (danek für die Idee, Schrompf)

[mtorc1]

Herzlichen Glückwunsch zum Release. Ich habe mich auf das Spiel schon gefreut gehabt, muss ich sagen.
Ich mag die Grafik sehr gerne. Ich glaube, ich war nie ein großer Freund von "gemalt"-Looks in Spielen. Ich muss aber sagen, er passt hier einfach sehr gut. Der Hase ist echt putzig, er ist sehr schön animiert, ergänzt sich gut mit dem Hintergrund bzw. dem Rasen am Boden. Das ist in sich sehr stimmig und gefällt. Was mir sehr gefällt ist die Todesanimation und der Sound beim Sterben. Musste etwas schmunzeln.
Ich finde die "alternativen Sounds" überhaupt nicht gut. Das Glockenspiel ist richtig schlimm, das verleiht so einen kindlichen Touch + nach 2 Durchläufen dreht man durch :) Die etwas ruhigere, dezentere Musik passt in meinen Augen deutlich besser. Ich empfinde das Spiel damit auch als entspannend.
Ich habe etwas gebraucht bis ich die Sprunghöhe antizipieren konnte. Aber wie hier im Thread schon thematisiert: keiner hat die Geduld Anleitungen durchzulesen, ich genauso. Blöd, da stand ja eigentlich alles drin. Mittlerweile klappt das aber ganz gut und ich habe auch den Eindruck, dass die Sprünge fair sind.
Was ich sehr schön gemacht finde, ist das Pflanzenwachstum. Das schaut alles sehr organisch/natürlich aus. In meinen Augen definitiv über dem, was man sonst in einem Hobbyspiel erwartet.
Alles in allem: sehr schönes Projekt, danke fürs Teilen. Sowohl ich als auch die Freundin hatten Spaß beim Spielen.

[grinseengel]

Prima das du am Ball geblieben bist seit der ZFX Action. Das kann ich von meinem Projekt nicht behaupten. Ich muss mal sehen das ich das auch irgendwie als spielbare "kleine" Variante fertig stelle. Ist sonst schade um die Zeit.

Nach Weihnachten bin ich jetzt mal dazu gekommen dein Hoppelspiel zu testen. Der Hase ist wirklich schön gemalt und die restlich Grafik passt seht gut zusammen. Die Bedienung ist sehr gut. Ich bin auf Anhieb damit klar gekommen und konnte mich auch gleich im Score verewigen.

Gemein sind die verschwindenden Blätter. Die machen das Gameplay natürlich spannender und es droht immer der Zeitablauf wenn man sich zu lange ausruht.

Hübsches kleines Spiel für Zwischendurch und natürlich Glückwunsch zum spielfertigen Release.

[scheichs]

Spiel und Präsentation gefallen.
Das knackige Geräusch beim Aufprall, garniert mit dem leichten Zucken sind natürlich das i-Tüpfelchen.
Super gemacht!

P.S. Das war C++ mit OpenGL?

[Alexander Kornrumpf]

Typo im Welcome Screen ("Thank zou").

Präsentation ist ansonsten schon beeindruckend.

Ich habe aber sofort die Lust verloren, als ich im Tutorial die power-up Mechanik "Möhre" zum ersten Mal erleben durfte (also nach ca. 30 Sekunden). Sorry, ist keine objektive Kritik natürlich, nur ein Geschmacksurteil. Das müsste Zeitbasiert sein (also man sammelt die Möhre ein, sie aktiviert sich sofort und man hat dann für x Sekunden "Superkräfte").

Ich habe vermutlich im Ganzen weniger als eine Stude Super Mario in meinem Leben gespielt, aber da funktionieren die Powerups so, wenn ich mich richtig erinnere. Ich vermute es hat einen Grund.

[Jonathan]

Vielen Dank für's Anspielen :)

Zu den Möhren: Darüber sie zeitbasiert zu machen habe ich nie gedacht. Aber ich finde die Idee tatsächlich hier auch gar nicht so gut, wenn man bedenkt wofür die Möhren gut sind (Das Tutorial ist ja eine sehr gestellte Situation in der es einzig um die Steuerung eht).
Die Möhren sind quasi Extra-Leben. Spielmechanisch kann man die zum Beispiel mit der Rückspielfunktion mancher Rennspiele vergleichen. Alle Sprünge im Spiel sind ohne Möhre zu schaffen, aber wenn man einen Fehler gemacht hat oder für einen besonders knappen Sprung nicht gut genug ist, kann man eine Möhre benutzen. Das nimmt ein wenig die Frust raus, beim ersten kleinen Fehler direkt zu sterben. Und dafür ist es halt wichtig die Möhren erst bei Bedarf zu aktivieren.
Andere Spiele haben Jetpacks oder Trampoline mit denen man quasi ein bisschen Höhe geschenkt bekommt (und Supersprung auf Zeit wäre ja sehr ähnlich). Sowas könnte man sich hier auch überlegen, aber irgendwo hatte ich dann einfach keine Lust mehr weitere Features einzubauen sondern wollte das Spiel abschließen.

[Jonathan]

Gibts noch irgendwelche Meinungen bezüglich Musik / Soundeffekte?

[Schrompf]

Hmpf. Es gibt so schnell Situationen, wo man in ner Sackgasse landet. Ein einziges Blatt irgendwo faltet sich zusammen und wenn man dann einen Sprung verfehlt, ist das Spiel vorbei. Man stirbt nicht unbedingt, aber es gibt selbst mit Supersprung - sollte man noch einen haben - keinen Weg mehr nach oben. Wie wär's, wenn sich Blätter wieder entfalten, wenn der Hase ein Stück unter ihnen zurückfällt?

Außerdem: sieht aus, als hättest Du den ZBuffer aus Versehen noch an. Eine Möhre hat hier gerade einen rechteckigen Ausschnitt aus einem Ei geschnitten, als beide auf dem selben Blatt lagen.

[Jonathan]

Hmpf. Es gibt so schnell Situationen, wo man in ner Sackgasse landet. Ein einziges Blatt irgendwo faltet sich zusammen und wenn man dann einen Sprung verfehlt, ist das Spiel vorbei. Man stirbt nicht unbedingt, aber es gibt selbst mit Supersprung - sollte man noch einen haben - keinen Weg mehr nach oben. Wie wär's, wenn sich Blätter wieder entfalten, wenn der Hase ein Stück unter ihnen zurückfällt?

Hmm, ja das ist schwierig.
Ursprünglich hatte ich deshalb den Fallschaden eingebaut. Wenn ein Blatt verschwindet schafft man entweder den Sprung nach oben oder man fällt runter und stirbt und das Spiel ist sofort vorbei. Es waren dann aber viele Spieler sehr davon genervt wie einfach man sterben kann, also habe ich den Fallschaden etwas reduziert. Ich wollte auch mal einbauen, dass alle Blätter (langsam) verschwinden, das würde auch bei etwas kleinerem Fallschaden dazu führen, dass man früher oder später einfach zu tief abstürzt und dann stirbt.

Blätter nachwachsen zu lassen finde ich komisch - dann gibt es ja gar keine Herausforderung durch ihr verschwinden, es wird einfach nur ein bisschen nerviger weil man warten muss und es dann ansonsten ohne Strafe neu versuchen kann. Ich mag auch prinzipiell die Idee, dass man nach einem falschen Sprung halt verloren hat und dann nicht nochmal von etwas weiter unten einen neuen Versuch starten kann - wobei hier die Möhren natürlich die Extraleben sind. Ich würde das gerne so lassen und lieber dafür sorgen, dass der Spieler in diesen Situationen einfach stirbt - nur ist irgendwie weder mehr Fallschaden noch "alle Blätter verschwinden" so eine richtig gute Lösung...

Außerdem: sieht aus, als hättest Du den ZBuffer aus Versehen noch an. Eine Möhre hat hier gerade einen rechteckigen Ausschnitt aus einem Ei geschnitten, als beide auf dem selben Blatt lagen.

Hmm, ja,aber wegen dem ganzen Alphablending von den halbtransparenten Pinselstrichen muss ich aber auch die Z-Tiefe aller Sprites richtig setzen und die Renderreihenfolge manuell anpassen damit das richtig aussieht. Andererseits weiß ich eigentlich gar nicht, wieso ich dann noch den Z-Buffer brauchen sollte. Danke für den Hinweis, ich schau mal rein und überlege mir, wie gründlich ich das lösen möchte.

[Schrompf]

Wenn Du sowieso schon die Sprites in der richtigen Reihenfolge aufeinander renderst, brauchst Du den ZBuffer einfach gar nicht. Mach ihn global aus und fertig. Durch Deine ganzen AlphaBlend-Pixel wird der Dir eh nie was bringen.

[Jonathan]

Ich habe jetzt eingebaut, dass man die Tastatursteuerung anpassen kann. Allerdings nur per config-File mit Keycodes, ich hatte echt keinen Bock die ganze GUI dafür zu schreiben - die dann eh niemand benutzt.

Aber was sind eure Vorschläge für die Standardbelegung? Bisher benutze ich Pfeiltasten / Leertaste / Alt. Während dem Stammtisch (glaube ich) meinte jemand, Alt wäre eine Blöde Taste, weil die ja auch für alle Arten von Shortcuts benutzt wird (Alt+Enter, z.B.). Aber was wäre die kanonische Standard-Steuerung? Ich mag eigentlich die Idee, Zeige- und Mittelfinger zu verwenden, deswegen fände ich z.B. Strg+Shift komisch. Und ich würde halt gerne irgendwelche Tasten benutzen, die total offensichtlich sind, Y/X sind beispielsweise auch sehr gut erreichbar, aber unintuitiv, außerdem funktioniert dass dann nur auf deutschen Tastaturen^^

[Jonathan]

Es hört einfach nie auf :D

Wir arbeiten ja zu zweit am Spiel. Nik macht Soundeffekte und Musik, ich alles andere. Eigentlich hatte ich bloß gesagt "Hey, ich hab ein neues Projekt, magste was beisteuern?". Mir hätten ein paar Sounds und eine dudelige Hintergrundmusik eigentlich gereicht, aber Nik ist halt kreativ und ambitioniert und wollte sich ein bisschen austoben. Soll mir recht sein, dann wird das Spiel halt besser :D

Neuster Streich: Dynamische Musik. Je höher man kommt, desto spannender wird es. Nun, die einfachste Variante ist es, ein Lied auszufaden und ein neues anzufangen. Das ist aber auffällig und nervig und nicht toll. Variante zwei ist, zwei Stücke gleichzeitig laufen zu lassen und über zu blenden (so dass man im Rhythmus bleibt und keinen plötzlichen Übergang hört). Das ist aber auch nicht besonders elegant.

Variante 3 also: Man kann an zahlreichen vordefinierten Stellen mit musikalisch sinnvollen Übergangspassagen die Stimmung und das Tempo der Musik ändern. Das sieht dann so aus:

Die Stücke sind in kleine Schnipsel zerlegt (die jeweils aus ein paar Takten bestehen) und es gibt eine Graphenstruktur die dir sagt, auf welche Art man sie aneinander Reihen kann. Nach ein bisschen herumexperimentieren hab ich mich entschieden die Stimmung / das Lied an die Kanten zu schreiben, ein Übergang kann theoretisch also auch von verschiedenen Stücken in verschiedenen Kontexten benutzt werden. Intern wird einfach gespeichert, in welchem Lied man sich gerade befindet und welcher Schnipsel gerade gespielt wird und so kann man sehr leicht den nächsten passenden Schnipsel einreihen. Das aktuelle Lied kann jederzeit gewechselt werden, auswirken tut es sich dann sobald der aktuelle Schnipsel vorbei und der nächste herausgesucht wird. Man reagiert also nicht in Echtzeit auf Änderungen, sondern nur an musikalisch sinnvollen Stellen.

Das ganze erfordert entsprechende Datenstrukturen, ein neues Dateiformat um den Graphen zu definieren, Arbeit am Soundsystem um Sounds nahtlos aneinander zu Reihen und natürlich komplettes Neu- und Umschreiben der Musik. Insgesamt kein Hexenwerk, aber schon ein paar Tage Arbeit. Wir werden das System sicherlich nicht bis an seine Grenzen im Hoppelhasen ausreizen, aber auch für die Zukunft ist es ja nett, wenn man gute Werkzeuge hat um die Musik dynamisch ans Spielgeschehen anzupassen.

[Schrompf]

Krasse Fäkalie. Ein komplexes System und jemand, der es mit Daten befüttern kann. Sehr cool!

[Jonathan]

Das Spiel ist "fertig", das drumherum noch nicht.

Ich wollte einen Installer bauen. Für die lieben Casuals. Darüber haben wir ja hier schon gesprochen.

Zusätzlich braucht es aber noch eine Anleitung, um ein paar Dinge klarzustellen, die im Tutorial nicht so ausführlich erwähnt werden. Dank Post-Install Skripte kann ich die auch gleich nach dem Installieren öffnen. Viele werden die dann vielleicht trotzdem gleich wieder schließen, aber zumindest weiß dann jeder, das es eine Anleitung gibt. Weil, wer schaut schon ins Installationsverzeichnis. Und außerdem gibts im Spiel jetzt auch einen Button um die Anleitung direkt aus dem Spiel heraus zu öffnen. Das gefällt mir konzeptionell eigentlich schon sehr gut.

Aber was nun? Eine simple Textedatei? Ist bisschen Oldschool. Eine PDF? Prinzipiell nett, aber das soll ja niemand ausdrucken. Nein, um sie am Bildschirm zu lesen, bedarf es schon einer vernünftigen HTML-Datei. Aber ich mag auch die Idee, dass eine PDF self-contained ist. Eine Datei, man kann sie rumkopieren, alles kein Thema. Das muss doch auch mit HTML gehen. Tut es auch, man kann den ganzen bootstrap css code natürlich oben einfügen. Zusätzlich kann man für Bilder (und sogar Schriftarten!) als URL einen Base64 encoded data string angeben. Und schwups hat man alles in einer einzelnen Datei, die natürlich offline funktioniert und keinerlei externe Ressourcen verlinkt.

Ist das alles Zeitverschwendung? Ja vielleicht. Aber andererseits mag ich es auch einfach, wenn Dinge nett und vernünftig gemacht sind...

[Jonathan]

Ehh, super volle Woche bisher, finale Version dauert noch.

Hab verschiedene Installer probiert, ist alles viel komplizierter als man so denkt. Vor allen Dingen, weil ich eigentlich zweisprachig will. Nicht nur für die GUI, sondern dann halt auch fürs Spiel.

Die Lokalisation läuft über Asset-Dateien. Die enthalten eigentlich Dinge wie "Spielermodell" oder "Menü-Hintergrund" als TEXT-ID - STRING Zuordnung, und waren ursprünglich dafür da, Dateinamen nicht im Code anzugeben und leichter austauschbar zu machen. Später kamen dann auch alle In-Game String dazu ("SPIEL-STARTEN-TEXT") und wenn man jetzt unterschiedliche Assetdateien benutzt kann man alle Strings und potentiell alle geladenen Dateien austauschen (man kann also alle Grafiken und Modelle etc. lokalisieren). Funktioniert toll und ist super simpel, das einzige Problem ist, es geht nicht zur Laufzeit, sondern nur beim Laden (sonst ist es nicht mehr simpel ;) ).

Also gibt es bat-Dateien die das Spiel mit unterschiedlichen Parametern starten um die richtige Asset-Datei pro Sprache zu laden. Das Spiel selber hat jetzt ein nettes Icon, die bat-Dateien nicht (weil geht nicht so einfach) und der Durchschnittsuser kriegt es daher vermutlich nicht hin das Spiel in seiner Sprache zu starten, weil er nicht einfach auf eine Desktopverknüpfung klicken kann. Hmg.

Der Installer sollte da eigentlich Magie machen und das irgendwie an die Systemsprache anpassen etc., das hab ich aber spontan nicht hinbekommen. Daher die neue Lösung: Es gibt ein Fenster, das beim ersten Start die Auswahl der Sprache erlaubt. Das erforderte ein paar Umbauten, weil wie gesagt, die Asset-Datei ganz am Anfang geladen und danach nicht mehr ersetzt werden kann und das ganze recht tief in der Engine steckt. Kann man alles lösen, braucht aber halt Zeit, deshalb ist Harald nicht pünktlich zum Wochenende fertig geworden.

Aber bald ist es soweit :D

[Schrompf]

Ich will Dich ehrlich nicht aufhalten, aber... meinste nicht, dass ne dynamische Lösung nicht doch besser wäre? Windows hat auch ne hübsche WinAPI-Funktion zum Detektieren der Systemsprache, womit Du beim Starten gleich die richtige Datei laden könntest. Und es ist echt knuffig, wenn man irgendwie in die Ecke des Hauptmenüs ne Fahne hängen kann, mit der man die Sprachen durchschaltet.

Der Standard dafür sind oder waren übrigens die GNU gettext utilities. Da stehen die Sprachen als Id-Value-Paare in einer .po-Datei, die etwa so aussieht:

Code: Alles auswählen

msgid ""
msgstr ""
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n!=1;\n"

# ---------------------- generic stuff --------------------------
# Language names for menus, logfiles etc.
msgid "TXT_SPRACHE_ENGLISCH"
msgstr "Anglais"

msgid "TXT_SPRACHE_DEUTSCH"
msgstr "Allemand"

msgid "TXT_SPRACHE_SPANISH"
msgstr "Espagnol"

msgid "TXT_SPRACHE_PORTUGUESE"
msgstr "Portugais"

# ------------------------- Menu text -------------------------------
# Main menu, button caption "Continue Story"
msgid "TXT_MENU_STORY_WEITER"
msgstr "Reprendre l'histoire"

# Tooltip for that
msgid "TXT_MENU_STORY_WEITER_HINWEIS"
msgstr "Charge la dernière sauvegarde du mode Histoire."

Das Bemerkenswerte hieran ist, dass sie an Mehrzahlformen gedacht haben. Du kannst also Textteile je nach Anzahl auswählen. Also z.B. "ein Spielstand" vs. "3 Spielstände", oder auch krude Möglichkeiten wie z.B. im Russischen, wo es zwei Pluralformen gibt: 1, 2 bis 4, 5 bis 20, 21 bis 24, 25-30 und so weiter. Die "Plural-Forms"-Zeile am Anfang kann logische Operationen, womit Du sowas abbilden kannst.

Das Internet, natürlich Übersetzungsfirmen und selbst engagierte Spieler:innen können mit dem Format umgehen und liefern Dir dann manchmal eine Übersetzung für ihre Lieblingssprache. So sind wir zu Türkisch und Portugiesisch gekommen, und evtl. kriegen wir demnächst 10 Jahre nach Release sogar Koreanisch. Keine Ahnung, wie sie das mit den Fonts gelöst haben, unsere Splatter-Fonts können mit Mühe und Not europäische Zeichen und kyrillische. Denn danach habe ich sie ausgewählt.

Alter-Mann-Anekdoten beiseite, dafür gibt's dann fertige CommandLine-Tools, die Du Dir einfach per Custom Build Step im VS oder CMake in die Builds einbauen kannst. Die übersetzen .po in .mo - Binärdateien. Und die kannst Du dann mit vielen Libs und Sprachen laden und verwenden. Der Klassiker ist die von i18n selbst, in Java und furchtbar-java-artigem C++ verfügbar, aber boost hat auch eine Lib dafür, und ich hab mir die von dort extrahiert und zu nem SingleHeader konvertiert. Kann ich Dir gern irgendwohin posten, wenn Du magst.

Einziges Problem ist, dass Du da anscheinend auch Zeugs drin speicherst, was mit Lokalisierung gar nix zu tun hat. Aber nuja... hält Dich ja niemand auf, ein getrenntes System für so Config-Gedöns auf INI-Basis weiter zu betreiben.

[Alexander Kornrumpf]

Windows hat auch ne hübsche WinAPI-Funktion zum Detektieren der Systemsprache, womit Du beim Starten gleich die richtige Datei laden könntest.

Ich persönlich hasse das, wenn Spiele das machen. Der erste Gang ist dann immer ins Menü um zurück auf Englisch zu stellen. Die Lokalisierung ist ja meistens doch nicht auf dem Niveau des Originals.

Der Standard dafür sind oder waren ...

Nach meiner Beobachtung ist der neue Standard, jetzt nicht für das Format aber für die Übersetzung selbst, das was man heute "AI" nennt. Ja, kann man diskutieren, aber die ökonomischen Anreize sind eindeutig. Und es ist ja nicht so, dass die Lokalisierung früher auf Harry Rowohlt Niveau war, siehe oben.