Ich habe beschlossen, meinen Beitrag zum letztjährigen Wettbewerb unter neuen Namen fertig zu entwickeln. Originalthread hier:
viewtopic.php?t=5647
Ursprünglich war das Spiel ja von "I have got some Balls" inspiriert, während der Entwicklung ist davon aber nicht mehr viel übrig geblieben. Ich plane aber eine Homage an diese Inspiration nach wie vor unter dem Titel "I have got 2 Balls" ("2", weils ein "Nachfolger" ist) einzubauen, allerdings im Rahmen einer Kampagne des Hauptspiels. Andere Kampagnen gehen dann stärker in andere Richtungen.
Angefangen habe ich mit dem Hauptmenü, hier ein erster Screenshot:
Bei der Arbeit stellte sich wieder einmal heraus, dass ich 2D Grafik wirklich nicht besonders gut kann (hauptsächlich äußert sich das in meinem Zeitaufwand für halbwegs passable Ergebnisse). Und aktuell habe ich einfach keine Lust, mehrere Stunden an einer Titelgrafik zu basteln. Daher ist alles noch etwas spartanisch. Ich werde sicherlich alles was man aktuell sieht nochmal überarbeiten, aber zumindest kann man hier schonmal mein Konzept so grob erkennen: Eine Murmelbahn ist ja etwas, was man zuhause selber bauen kann, zum Beispiel in seiner Werkstatt aus Holz. Daher der hölzerne Hintergrund. Die coole Variante hat vielleicht eine 3D Szene, mit eingeschnitzten Nuten, durch die physikalisch simulierte Murmeln rollen. Einzelne Submenüs könnten auch Kameraschwenks in einzelne Teile der Werkstatt sein. Die Levelauswahl sind Zettel, die an eine Wand gepinnt wurden, jeweils mit Vorschaubild und Name.
Für den Namen wollte ich gerne etwas halbwegs simples, deutsches. "Murmeln" kann sowohl als plural Substantiv oder eben als Verb verstanden werden, beides passt ganz gut.
Aktuell schreibe ich meine GUI Klassen um. Denn alles muss per Gamepad steuerbar sein, und dafür benötigt es eine Fokus-Mechanik um mit dem Gamepad Buttons auswählen zu können. Und bei der Gelegenheit hab ich ein paar weitere, größere Änderungen angefangen. Es dauert also noch eine Weile, bis es neue Features geben wird.
Murmeln
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Murmeln
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
- Schrompf
- Moderator
- Beiträge: 5313
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Murmeln
Cool! Die GUI mitm Controller, das ist nicht ganz einfach, aber mit Fokus klappt das gut, glaube ich. Viel Erfolg!
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- TomasRiker
- Establishment
- Beiträge: 120
- Registriert: 18.07.2011, 11:45
- Echter Name: David Scherfgen
- Wohnort: Hildesheim
Re: Murmeln
Man braucht nicht unbedingt eine Fokus-Mechanik. Es gibt auch den Ansatz, dass man mit dem Controller den Mauszeiger von Element zu Element bewegt. Also nicht direkt den Mauszeiger steuern (das wäre zu fummelig), sondern von Element zu Element "snappen" lassen, mit derselben Logik, die du beim Fokus-Ansatz nutzen würdest. Ich kenne mindestens ein Spiel, wo das so gemacht wird.
Re: Murmeln
Ja, ziemlich genau so habe ich das bei Harald Hoppelhase gemacht - der Maus Cursor wird auf die Mitte vom nächsten Widget gesetzt und wenn man einen Controller-Knopf drück, wird das Mausklick-Event ausgelöst. Der Controller steuert quasi die Maus, und die Maus interagiert mit der GUI. Allerdings bedeutet das quasi, dass der visuelle Widget-Fokus Effekt immer "Mauszeiger ist über Widget" ist. Ja, man könnte Mauszeiger ausblenden und dann noch einen separaten Effekt abspielen, aber dafür müsste es ja wieder eine explizitere Fokus Mechanik geben.
Wirklich wichtig wird korrekter Fokus aber bei Eingabe-Widgets die übers Anklicken hinausgehen. Ein Slider will z.B. auf die Pfeiltasten reagieren. Eine Textbox muss die Tastatur abfragen und Text einfügen. Dafür darf aber nur ein Element Widget die Eingabe verarbeiten - nämlich das, welches gerade den Fokus hat. Ansonsten erscheint geschriebener Text ein allen Textboxen gleichzeitig...
Wiedemauchsei, ich habe das allermeiste jetzt umgesetzt und es funktioniert sehr schön. Tatsächlich waren einige Dinge etwas kniffeliger als gedacht: Man will ja z.B. sicherstellen, dass immer nur genau 1 Widget den Fokus haben kann. Ich lasse Widgets ihren Fokus nicht selber verwalten, denn wenn sich Fenster überlagern reich ein "Cursor über Bounding Box" Test nicht mehr aus, und auch wenn man den Fokus zum nächsten Element wechseln will, muss man die ja kennen. Ich könnte die globale Liste aller Widgets haben und darüber den Fokus verwalten, aber ich habe mich für eine hierarchische Lösung entschieden: Jedes Window kennt den Fokus seiner Elemente, ist eines davon ein Subwindow, kennt dieses wiederum sein Fokus-Element. Wenn ein Window jetzt ein anderes überlagert, brauch ich all dessen Child-Widgets also nie beachten. Außerdem kann ich recht nett das nächste Widget finden, ist das letzt Element in einem Window fokussiert, dann ist das nächste in der Liste eben das erste Child im nächsten Subwindow des Parent-Windows (man springt eine Ebene hoch, geht eins weiter, und springt dann wieder runter). Das Windows einen Fokus haben und nicht nur Eingabewidgets ist natürlich auch nett für Dinge wie "Fenster automatisch in den Vordergrund holen".
Es gibt dabei allerdings eine Reihe Fallstricke. Hier mal der Code um den Fokus weiter zu schalten: (Ich spare mir mal umfangreichere Erklärungen auf eventuelle Nachfragen auf, weiß nicht, wie interessant das hier für die meisten ist)
Es ist also mehr, als einfach durch einen Container zu iterieren. Für manche Spezialfälle kann man sogar leicht in eine Endlosschleife kommen, wenn man nicht aufpasst. Aber das ist jetzt alles gelöst und bisher funktioniert es recht gut und sollte auch in Zukunft mit recht komplexen Interfaces robust zurecht kommen. Damit hab ich dann eine zukunftssichere Lösung und brauche keine Angst zu haben, dass wenn ich jetzt an dieser einen Stelle noch dieses eine Widget einfügen oder anders ausrichten will, alles zusammenbricht.
Wirklich wichtig wird korrekter Fokus aber bei Eingabe-Widgets die übers Anklicken hinausgehen. Ein Slider will z.B. auf die Pfeiltasten reagieren. Eine Textbox muss die Tastatur abfragen und Text einfügen. Dafür darf aber nur ein Element Widget die Eingabe verarbeiten - nämlich das, welches gerade den Fokus hat. Ansonsten erscheint geschriebener Text ein allen Textboxen gleichzeitig...
Wiedemauchsei, ich habe das allermeiste jetzt umgesetzt und es funktioniert sehr schön. Tatsächlich waren einige Dinge etwas kniffeliger als gedacht: Man will ja z.B. sicherstellen, dass immer nur genau 1 Widget den Fokus haben kann. Ich lasse Widgets ihren Fokus nicht selber verwalten, denn wenn sich Fenster überlagern reich ein "Cursor über Bounding Box" Test nicht mehr aus, und auch wenn man den Fokus zum nächsten Element wechseln will, muss man die ja kennen. Ich könnte die globale Liste aller Widgets haben und darüber den Fokus verwalten, aber ich habe mich für eine hierarchische Lösung entschieden: Jedes Window kennt den Fokus seiner Elemente, ist eines davon ein Subwindow, kennt dieses wiederum sein Fokus-Element. Wenn ein Window jetzt ein anderes überlagert, brauch ich all dessen Child-Widgets also nie beachten. Außerdem kann ich recht nett das nächste Widget finden, ist das letzt Element in einem Window fokussiert, dann ist das nächste in der Liste eben das erste Child im nächsten Subwindow des Parent-Windows (man springt eine Ebene hoch, geht eins weiter, und springt dann wieder runter). Das Windows einen Fokus haben und nicht nur Eingabewidgets ist natürlich auch nett für Dinge wie "Fenster automatisch in den Vordergrund holen".
Es gibt dabei allerdings eine Reihe Fallstricke. Hier mal der Code um den Fokus weiter zu schalten: (Ich spare mir mal umfangreichere Erklärungen auf eventuelle Nachfragen auf, weiß nicht, wie interessant das hier für die meisten ist)
Code: Alles auswählen
void Window::focus_next()
{
int new_focus = m_focussed_child;
bool loop_around = m_main_window; // whether we jump out of this window and continue in parent, or we loop around. TODO: better criterion?
do
{
new_focus += 1;
// jump back to the beginning of the list
if( new_focus >= m_children.size() )
{
if( loop_around )
{
if( m_focussed_child == -1 ) // we went through the full list and found nothing
{
new_focus = -1;
break;
}
// if there was a focus previously, we will always find at least one input widget
else // loop back to the beginning
{
new_focus = 0;
}
}
else
{
change_focus(-1); // deselect everything before parent selects something new. most of the cases, this is redundant, but this can prevent infinite loops if the parent has only 1 child
m_parent->focus_next();
return; // don't change any focus in this window
}
}
// exit criterium if no input widget is found
if( new_focus == m_focussed_child ) // either this was an
break;
}
while( ! dynamic_cast<InputWidget*>(m_children[new_focus].widget.get()));
change_focus(new_focus);
// if we just selected another window, we should also select the first widget inside it
if( auto window = dynamic_cast<Window*>(m_children[new_focus].widget.get()) )
window->focus_next();
}
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
Re: Murmeln
Und hier als Video:
Ein weiterer, kleiner GUI-Test: Das Ingame-Menü wird hier einfach mal im Hauptmenü unten angezeigt. Neu sind "Text-only" Buttons, vorher mussten Buttons immer auch ein Sprite haben (wichtig für die Bounding Box, damals). Außerdem sieht man 2 unterschiedliche Arten von Effekten, die Text-Buttons ändern ihre Farbe, die Level-Buttons kriegen diesen Glow im Hintergrund.
Fonts und Sprites sind natürlich alle noch hässlich, aber man sieht was technisch möglich ist. Zwischendrin wird auch mit den Pfeiltasten zwischen Elementen hin- und hergeschaltet, und das funktioniert auch genau so mit dem Gamepad. Im Screenshot sieht man was passiert, wenn man die Maus schnell bewegt, es gibt so ein gewisses Nachglühen vom Fokus-Effekt, was ich eigentlich ganz schick finde. Wenn das ganze jetzt noch mit passenden, subtilen Sounds hinterlegt wird, sollte sich die GUI damit eigentlich schon ziemlich fluffig anfühlen. Ein Whoosh-Sound beim Auswählen und ein richtig saftiges und befriedigendes Klicken beim Betätigen.
Ich hab auch mal aus Spaß nach Text-Rendering per Signed-Distance-Function geschaut. Das ist super, weil man damit leicht Rahmen um einzelne Glyphen legen kann. Einfach die nächst größere Schriftart im Hintergrund darunter zu legen funktioniert da nämlich nicht. Für SDFs muss man einiges umbauen, aber wenn man das einmal eingebaut hat, kann man per Shader direkt allerhand coole Effekte machen; animierte Rahmen mit Gradienten und all das. Ich habe einen der Autoren des Papers angeschrieben, aber in der automatischen Antwort kam nur zurück, dass er seit Corona durch Longcovid arbeitsunfähig ist und es nicht absehbar ist, wann er antworten kann. Autsch :'(
Die nächste Erweiterung wären dann 3D Modelle als GUI-Elemente. Dann können Buttons auch inklusive Echtzeitbeleuchtung wirklich gedrückt werden. Die Layout-Engine verwaltet dann nach wie vor 2D Positionen, nur fürs Rendering gibt es eben eine zusätzliche Transformation, die man entsprechend Rückwärts auf die Cursorposition anwendet. Das müsste sich also alles relativ leicht integrieren lassen. Wie das aussehen kann, zeigt zum Beispiel Dungeon Siege 1, wo die Menü-Elemente an so einer Kette aufgezogen wurden:
https://youtu.be/U497Mpscsa4?list=PLwUw ... bjJy-&t=34
Aber mal schauen, das sind alle zukünftige Erweiterungen. Ich denke, ich werde mich jetzt erstmal wieder um das eigentliche Spiel kümmern!
Ein weiterer, kleiner GUI-Test: Das Ingame-Menü wird hier einfach mal im Hauptmenü unten angezeigt. Neu sind "Text-only" Buttons, vorher mussten Buttons immer auch ein Sprite haben (wichtig für die Bounding Box, damals). Außerdem sieht man 2 unterschiedliche Arten von Effekten, die Text-Buttons ändern ihre Farbe, die Level-Buttons kriegen diesen Glow im Hintergrund.
Fonts und Sprites sind natürlich alle noch hässlich, aber man sieht was technisch möglich ist. Zwischendrin wird auch mit den Pfeiltasten zwischen Elementen hin- und hergeschaltet, und das funktioniert auch genau so mit dem Gamepad. Im Screenshot sieht man was passiert, wenn man die Maus schnell bewegt, es gibt so ein gewisses Nachglühen vom Fokus-Effekt, was ich eigentlich ganz schick finde. Wenn das ganze jetzt noch mit passenden, subtilen Sounds hinterlegt wird, sollte sich die GUI damit eigentlich schon ziemlich fluffig anfühlen. Ein Whoosh-Sound beim Auswählen und ein richtig saftiges und befriedigendes Klicken beim Betätigen.
Ich hab auch mal aus Spaß nach Text-Rendering per Signed-Distance-Function geschaut. Das ist super, weil man damit leicht Rahmen um einzelne Glyphen legen kann. Einfach die nächst größere Schriftart im Hintergrund darunter zu legen funktioniert da nämlich nicht. Für SDFs muss man einiges umbauen, aber wenn man das einmal eingebaut hat, kann man per Shader direkt allerhand coole Effekte machen; animierte Rahmen mit Gradienten und all das. Ich habe einen der Autoren des Papers angeschrieben, aber in der automatischen Antwort kam nur zurück, dass er seit Corona durch Longcovid arbeitsunfähig ist und es nicht absehbar ist, wann er antworten kann. Autsch :'(
Die nächste Erweiterung wären dann 3D Modelle als GUI-Elemente. Dann können Buttons auch inklusive Echtzeitbeleuchtung wirklich gedrückt werden. Die Layout-Engine verwaltet dann nach wie vor 2D Positionen, nur fürs Rendering gibt es eben eine zusätzliche Transformation, die man entsprechend Rückwärts auf die Cursorposition anwendet. Das müsste sich also alles relativ leicht integrieren lassen. Wie das aussehen kann, zeigt zum Beispiel Dungeon Siege 1, wo die Menü-Elemente an so einer Kette aufgezogen wurden:
https://youtu.be/U497Mpscsa4?list=PLwUw ... bjJy-&t=34
Aber mal schauen, das sind alle zukünftige Erweiterungen. Ich denke, ich werde mich jetzt erstmal wieder um das eigentliche Spiel kümmern!
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
- Schrompf
- Moderator
- Beiträge: 5313
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Murmeln
Sehr cool, scheint gut zu funktionieren! Aber kann das sein, dass die großen Bildchen-Buttons in der Mitte erst sehr nah bei ihrer Mitte reagieren?
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: Murmeln
Hmmm, ja, also im Detail passiert folgendes: Buttons können bei mir ein Sprite-Hintergrund (der Knopf ansich) und einen Text (die Beschriftung) haben - optional auch nur 1 von beiden. Für den Levelknopf hab ich jetzt aber ein Hintergrundbild (den Zettel), das Vorschaubild für das Level und den Text darunter - also 3 Elemente. Intern ist jetzt der Zettel ein Window, der Name nur ein Text-Label und das Levelvorschaubild ist der Button, der dann keinen Text hat. Also ja, das Level wird erst ausgewählt, wenn die Maus über dem Vorschaubild ist, und noch nicht, wenn man bloß über dem Zettel ist. Zusätzlich gibt es natürlich die Blendanimation, die den Fokus leicht verzögert.
Vielleicht mache ich eine neue Compount-Button Klasse, mit der dann alles 3 als Button zählt. Dann könnte ich auch als Animation vielleicht ein Wackeln des ganzen Zettels einbauen. Aber mal schauen.
Vielleicht mache ich eine neue Compount-Button Klasse, mit der dann alles 3 als Button zählt. Dann könnte ich auch als Animation vielleicht ein Wackeln des ganzen Zettels einbauen. Aber mal schauen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/