spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Gute Idee!
Da ich nur mit DirectX arbeite, suche ich regelmäßig was Brauchbares.
Relativ gut gelungen finde ich die GUI, die beim DX-SDK dabei ist.
Aber die ist außen Hui und innen Pfui. Verwenden tue ich sie deswegen nicht.
Ebenso wenig CEGUI (heavy, genau).

Lange Vorrede, kurzer Sinn, meine Anforderungen wären folgende:

Elemente wie in der Windows-GUI, also Eingabefelder, Buttons, Dropdowns, Listen, Treewiews usw..
Anders gestyled natürlich (variable Themes), aber mit dem typischen Maus- und Tastaturverhalten.
Benutzerfreundlich, intuitiv, performant. Typische Spiele-GUIs reagieren imho meist sehr träge.

Eine Stand-alone-Library DLL, bzw. eine statische Lib wäre 'ne feine Sache.

* Cross Platform
* Buttons, Treeview, Dropdowns, Themes, Shortcuts
* GUI-Events

Zunächst: Ich suche noch eine gute Lib, weil mir Cegui und MyGUI auch nicht so zusagen, hab also durchaus Interesse.

- Plattformunabhängig: Am besten für DX/Ogl/Sonstiges. Sollte man ja recht leicht so designen können, dass man Logik, Eingabe und Anzeigen trennt und für jedes eine hand voll Module mitliefert, damit man die Lib mit den Technologien benutzen kann, die man eh schon hat.
- Kein Nachbau von der Windows/Linux,/Sonstwas Oberfläche. Welches Spiel benutzt verschiebbare Fenster oder Treeviews? Klar kann man das unterstützen, aber für das normale Spiel, ist sowas vollkommen überflüssig. Es soll eine Ingame GUI sein, und da sind ganz andere Dinge wichtig. Zum Beispiel eine exzellente Unterstützung, für eigene Widgets. Nehmen wir die HP und Mana-Anzeige in Diablo: Die kann man sonst wohl für kein anderes Spiel benutzen, aber sie sind ganz offensichtlich Teil der Gui. Oder ein typisches Inventar, dass man per Drag'n'Drop benutzen kann.
- MFC: Wieder das Beispiel Lebensenergie: Ich möchte natürlich möglichst einfach die aktuelle Lebensenergie des Spielers darstellen und nicht in jedem Frame mein Spielerobjekt suchen und dessen Lebensenergiewert in das Lebensenergieanzeige-Widget kopieren.
- Themes und variable Größen: Man muss in der Gui definieren können, was wo angezeigt werden soll und wie sich das ganze Verhält, wenn die Fenstergröße sich ändert. Also wie man es halt von wxWidgets oder Qt kennt: Objekte können immer kleinst möglich sein, sich beliebig ausdehnen, falls Platz ist, ein bestimmtes Größenverhältnis zu anderen haben und so weiter.

Oh und wenn man Spaß hat, kann man natürlich noch verschiedene Endgeräte unterstützen. So im Sinne von: "Mal hab ich ne Maus, mal nur Tastatur, mal einen XBox oder Wii-Controller". Da kann man sich dann überlegen, wie man durch Menüs navigiert, wie man Eingaben macht (Bildschirmtastatur) und so weiter. Wobei ich fürs erste nur Interesse an PC Spielen habe, also Tastatur + optional Maus.

Hier auch ein paar Ideen.

Ein Tabellencontrol werden imo relativ viele Spiele, z.B. zur Serversuche brauchen. Treeview ist denke ich eher unwichtig.

Zur Positionierung und Skalierung wäre Layoutunterstützung zwar komfortabel, die Frage ist, ob relative (zur Bildschirmgröße) Positionierung nicht ausreichen würde. In diesem Fall sollte man aber eine Zentrierung auswählen können (, sodass die ausgewählte Position relativ zum Zentrum ist).

Ein Animationssystem halte ich für relativ wichtig. Diese sind zwar nur eine "Spielerei", lassen aber die Gui gleich professioneller aussehen und sind außerdem ein Feature, das recht wenig Guis haben. Der Benutzer der Lib könnte zum Beispiel eine Animation auswählen, die die Elemente nacheinander zu ihrer ausgewählten Position fliegen lässt.

Eine "3D-Gui" wäre ganz schön, das heißt, das die Gui-Elemente optional auch Teil der 3D-Welt sein können, wie das manche Guis schön haben. Es wäre also gut, wenn die Interfaces die der Benutzer der Library implementieren müssen / können das unterstützen. Der Aufwand in der Implementierung sollte größtenteils sehr gering bleiben, weil in einem 3D-Spiel lediglich eine Matrix übergeben werden müsste (habe das selbst ausprobiert).

btw. Ich hab mich vor ein paar Jahren mal an eine andere Gui für die TB-Engine gesetzt (mit 3D), das ganze beim Wechsel zu Ogre jedoch abgebrochen. Ein Containersystem, die Positionierung und die Buttons (click+hover) hatte ich damals schon implementiert (auch im 3D-Bereich). Wenn du willst kann ich dir den Code schicken, ist allerdings kein sehr guter Programmierstil gewesen.

Es ist schon ewig her, dass ich CEGUI verwendet habe. Aber was mich am meisten genervt hat war:

Es war nur mit ganz viel gehacke möglich Bilder Pixelperfekt darzustellen. Sämtliche Bilder wurden skaliert und sehen verwaschen aus, genauso wie die Schriften wenn sie kleiner werden.
Sowas kann man wirklich niemandem zumuten:

Ich hoffe die haben mittlerweile was dran getan. Screenshots kann man sich auf der Webseite leider nicht anschauen ohne sich anzumelden.

Also ich denke das wäre auch eine sehr wichtige Anforderung an ein GUI Framework:
Entweder Vektorgrafiken oder die Möglichkeit GUI Elemente Pixel-perfekt aus Bildern darzustellen. Damit das was die Grafiker entwerfen auch wirklich im Spiel ankommt!

Eigentlich ist das schon fast selbstverständlich würde ich sagen...

• cross platform
  
• schnell erlernbar!
  
• Übersichtlichkeit (z.B. durch namespaces)
  
• Kapselung, mit klaren Trennungen und Schnittstellen, so dass man auch nur Teile benutzen kann ohne lauter unnötiges Zeug zu initialisieren
  
• Style-Objekt o. ä. um Elementen einheitliches Aussehen zu geben
  
• effizientes Event-System dass einfach zu benutzen ist (schwer hinzukriegen )
  

Vielleicht ist auch folgende Frage interessant: Soll es wirklcih eine ingame GUI sein, oder doch eher eine "Hauptmenü"-Gui.

Ingame GUI wäre für mich z.B. alles, was Text anzeigt. Also ein Fenster, dass die aktuellen Charakterwerte zeigt, ein klassisches EgoShooter Hud mit Gesundheit/Munitionsanzeige und Radar, aber zum Beispiel auch die Namen, die über Charakteren in der Spielfwelt fliegen oder Icons, die anzeigen, dass man mit diesem Objekt etwas machen kann. Also irgendwie alles, was nicht die eigentliche Szene, sondern Metainformationen über die Szene zeigt.
Hauptmenü-GUI wäre dann ein klassisches Fenster mit Buttons, Listen und so weiter. Eben das, was man z.B: auch mit Qt machen könnte (so ist es auch bei z.B: Hedgewars gemacht).

Am besten wäre natürlich beides, weil in Rollen- oder Strategiespielen der Übergang ja sehr fließend ist, und es wäre merkwürdig, dafür 2 getrennte Systeme zu benutzen.

Das bedeutet natürlich einen enormen Planungsaufwand, weil eine solche GUI ohne gutes Design vermutlich schnell untergehen würde. Andererseits sind Benutzeroberflächen etwas schrecklich nerviges, die eigentlich niemand programmieren will, die aber jeden direkt stören, wenn sie nicht gut umgesetzt sind.Es wäre sehr schön, dafür eine gute Bibliothek zu haben.

Für die Planung wäre es evtl. gar nicht schlecht, eine möglichst große Liste an Features zu sammeln, was GUIs so alles können können könnten. Wobei mri grad auch einfällt, dass David von einer "minimalistischen" GUI gesprochen hat. Aber Minimalität und Felxibilität müssen sich ja nicht ausschließen.

Als ich neulich in die Verlegenheit gekommen bin auch ein wenig GUI zu benutzen habe ich das au schnell mit den minimalsten Elementen selbst gemacht. Die Elemente die ich drin habe sind:

• Button
• Textelement
• Inputfeld
• Image
• Checkbox
• Box (eine Art Fenster)

Ist sehr auf das Spiel zugeschnitten, aber bei ~700 Zeilen auch nicht der riesen Aufwand für das was es kann. Die Elemente wären aber auf jeden Fall die, die ich erwarten würde (und vielleicht noch ein paar mehr). Das, was ich intensiv genutzt habe waren neue Features von C++. Also z.B std::function, std::bind und lamda Expressions. War also kein Eventsystem nötig und teilweise Sachen haben sich damit sehr vereinfacht.

Tja...da fängst ja schon wieder an . A sagt X gehört da rein während B meint das X ja nur die wenigsten brauchen und Y viel wichtiger wäre.

Ich bin auch schon lange auf der Suche nach einem "gescheitem" GUI System und bin zu dem persönlichen Schluss gekommen, dass die herkömmlichen Ansätze zu unflexibel sind um wirklich ohne Probleme übertragbar zu sein. Für mich sind die Anforderungen:
-die komplette GUI muss on-the-runtime anpassbar sein (per editor/editorelement).
-Eventsystem um Reaktionen von der GUI anstoßen zu können.
-Queryinterface damit die GUI bestimmte Werte von der Logik erfragen kann.
(-am besten vektorgrafikbasiert)

Hieraus ergeben sich einige Konsequenzen:
-es müsste komplett skriptdriven sein, wobei am besten ein GUI-Element jeweils durch ein Skript definiert wird.
-alle GUI-Elemente (auch der Editor/das Editorelement ansich) würden nur als Skript existieren.
-verschiedene bereits existenze GUI-Elemente könnten einfach zu einem neuen Element mit interner Dynamik zusammengefasst und als eigenes Skript gespeichert werden.
-die Schnittstellen zwischen GUI und Logik würde sich auf "QueryValue","ThrowEvent","HandleEvent","renderBatchedGUI" reduzieren, wobei renderBatchedGUI eine Reihe von vordefinierten Aktionen verarbeitet (draw2DImage,drawText,drawLine etc.)

Wenn einer von euch ein solches System entwickelt oder kennt, bitte sofort bei mir melden. Ich bin bereit das Ganze zu unterstützen wo ich nur kann!