Comment aborder les éléments de l'interface graphique?

Remarque: je prévois de créer mon propre système d'interface graphique. Ce sera bon pour l'apprentissage, léger, n'aurai que les bits dont j'ai besoin, les liens avec le jeu, etc.

Je réfléchissais à comment le faire. Les éléments que je veux dire sont:

• Boutons radio
• Saisissez le texte ici
• Boutons
• Sliders
• Cases à cocher

Je ne cherche pas encore comment les faire. Mais plus sur la façon dont ils iraient.

Idée

J'aurais chaque état qui avait besoin de choses, donc presque tous, ont un conteneur d'éléments. Chaque élément est une pièce graphique.

Ceux-ci ont chacun une position, un graphique, etc.

Le morceau sur lequel je suis le plus coincé est leur logique.

Mon idée pour cela, pour permettre la modularité et la simplicité était d'éviter un MainMenuStartButton; un OptionsOneBackButton, etc. et à la place être capable de faire Slider slider1; ou Bouton démarrer;.

Au lieu de cela, chacun aurait une fonction boost :: à une fonction dans un espace de noms GUI, comme Gui :: StartButtonClick ou GUI :: ColourSliderHover.

Je me demandais simplement si ce serait exceptionnellement lent ou non.

Et d'ailleurs, existe-t-il un moyen facile et simple de faire une interface graphique pour les jeux? Pas de Qt, wxWidgets ou quoi que ce soit.

L'interface graphique n'est pas un problème facile ou simple, surtout lorsque vous entrez dans les jeux et leur désir d'avoir des menus dynamiques et intéressants.

Une chose "facile" que vous pouvez faire est d'essayer d'utiliser un middleware. Il y a une question à ce ici .

Si vous allez le faire vous-même, il y a quelques choses que je suggérerais.

• Les éléments GUI ont généralement un "parent", soit un autre élément GUI ou une "fenêtre", ou quelque chose comme ça. Soit en pointant vers le haut ou en ayant le point parent vers le bas, vous pouvez définir l'état / position / etc sur tout ce qui est un enfant.

• Vous pouvez créer des éléments GUI par composition. Beaucoup de widgets ont des étiquettes (presque toutes), et il pourrait être judicieux de faire du concept d'étiquette un composant ou un enfant de vos autres éléments d'interface utilisateur que de copier / coller le code ou d'essayer d'hériter d'une classe de base avec fonctionnalité d'étiquette.

• De nombreux widgets dits spécialisés ne sont que des boutons déguisés. Les cases à cocher ne sont que des boutons avec des états et des images spéciales. Les boutons radio ne sont que des cases à cocher qui ont un méta-état (un et un seul est actif à un moment donné) avec d'autres boutons radio. Utilisez-le à votre avantage. Dans un jeu sur lequel j'ai travaillé, des "cases à cocher" étaient faites avec des boutons normaux entièrement à travers des scripts et de l'art.

• Pour votre premier projet, pensez à emprunter la voie la plus directe. Oui, faites vos délégués d'événements exploitables et attribuez ce dont vous avez besoin lors de la création d'élément (par exemple onMouseButtonDown, onMouseButtonUp, onHover, etc.), mais envisagez simplement de coder en dur ce que vous voulez faire autrement (par exemple, survolez les changements de couleur, appuyez sur les sons des boutons) jusqu'à ce que vous obteniez quelque chose fonctionnel. Une fois que vous êtes à ce stade, envisagez de créer ces données de comportement (c.-à-d. Avoir une variable sur le bouton pour "appuyer sur le son", ou peut-être envisager d'avoir des composants que vos éléments d'interface utilisateur utilisent pour définir le comportement que vous leur attachez simplement lorsque vous les créez.

• les délégués ne sont pas si lents, vous n'aurez probablement pas autant de widgets que ce serait un problème, et le code de menu n'est généralement pas très impactant de toute façon. Je ne m'inquiéterais pas trop des performances à ce stade du jeu. Ne choisissez pas d'algorithmes et de profils naïfs une fois que votre code est opérationnel.

Il y a eu des percées très intéressantes dans les boîtes à outils d'interface utilisateur traditionnelles au cours des dernières années. Les interfaces utilisateur de jeu ont également évolué, mais à un rythme un peu plus lent. Cela est probablement dû au fait que le développement d'un sous-système d'interface utilisateur complet est une entreprise importante en soi, et il est difficile de justifier l'investissement en ressources.

Mon système d'interface utilisateur préféré personnel est Windows Presentation Foundation (WPF). Cela prend vraiment le potentiel de différenciation de l'interface utilisateur au niveau suivant. Voici certaines de ses fonctionnalités les plus intéressantes:

1. Les contrôles sont "sans apparence" par défaut. La logique et l'apparence visuelle d'un contrôle sont généralement découplées. Chaque contrôle est livré avec un style et un modèle par défaut, qui décrivent son apparence visuelle par défaut. Par exemple, un bouton peut être représenté par un rectangle arrondi avec un trait extérieur, une couleur unie ou un arrière-plan dégradé et un présentateur de contenu (pour présenter la légende). Les développeurs (ou concepteurs) peuvent créer des modèles de styles personnalisés qui modifient l'apparence et (dans une certaine mesure) le comportement d'un contrôle. Les styles peuvent être utilisés pour remplacer les propriétés simples d'un contrôle, comme la couleur de premier plan / d'arrière-plan, le modèle, etc.; les modèles changent la structure visuelle réelle.

2. Les styles et modèles peuvent inclure des "déclencheurs". Les déclencheurs peuvent écouter certains événements ou valeurs de propriété (ou combinaisons de valeurs) et modifier conditionnellement les aspects d'un style ou d'un modèle. Par exemple, un modèle de bouton aurait généralement un déclencheur sur la propriété "IsMouseOver" dans le but de changer la couleur d'arrière-plan lorsque la souris survole le bouton.

3. Il existe différents "niveaux" d'éléments de l'interface utilisateur, allant des éléments plus légers avec une fonctionnalité minimale aux commandes lourdes à part entière. Cela vous donne une certaine flexibilité dans la façon dont vous structurez votre interface utilisateur. La plus simple des classes d'éléments d'interface utilisateur UIElement, n'a pas de style ou de modèle et prend uniquement en charge les événements d'entrée les plus simples. Pour les éléments simples comme les indicateurs d'état, cette fonctionnalité peut être tout ce dont vous avez besoin. Si vous avez besoin d'un support d'entrée plus étendu, vous pouvez dériver de FrameworkElement(qui s'étend UIElement). Les widgets traditionnels dérivent généralement de Control, ce qui étend FrameworkElementet ajoute un support de style et de modèle personnalisé (entre autres).

4. WPF utilise un modèle graphique vectoriel conservé, évolutif et indépendant de la résolution. Sous Windows, les applications WPF sont rendues et composées à l'aide de Direct3D.

5. L'introduction de WPF a inclus un nouveau langage de programmation déclarative appelé Xaml. Xaml, basé sur Xml, est le langage préféré pour déclarer des "scènes" d'interface utilisateur. Il est en fait assez lisse, et bien qu'il puisse sembler similaire à première vue, il est fondamentalement différent des langages existants comme XUL (et beaucoup plus puissant).

6. WPF possède un sous-système de texte très avancé. Il prend en charge la plupart sinon toutes les fonctionnalités de police OpenType, l'anticrénelage ClearType bidirectionnel, le positionnement des sous-pixels, etc.

"Ok, super, maintenant comment est-ce pertinent pour le développement de jeux?"

À l'époque où WPF était encore en développement (et connu sous le nom de "Avalon"), je suivais un cours de conception de jeux vidéo à Georgia Tech. Mon projet final était un jeu de stratégie au tour par tour, et je voulais une interface utilisateur très performante. WPF / Avalon semblait être une bonne voie à suivre, car il disposait d'un ensemble complet de commandes complètes et me permettait de changer complètement l'apparence de ces commandes. Le résultat a été un jeu avec une interface utilisateur belle et nette avec le niveau de fonctionnalité que vous ne voyez normalement que dans les applications à part entière.

Maintenant, le problème avec l'utilisation de WPF pour les jeux est qu'il est assez lourd et s'affiche dans son propre "bac à sable". Par cela, je veux dire qu'il n'y a aucun moyen pris en charge d'héberger WPF dans un environnement de jeu Direct3D ou OpenGL. Il est possible d'héberger du contenu Direct3D dans une application WPF, mais vous serez limité par la fréquence d'images de l'application WPF, qui est généralement inférieure à celle que vous souhaitez. Pour certains types de jeux, comme les jeux de stratégie 2D (capture d'écran de mon projet de jeu WPF actuel), cela pourrait encore très bien fonctionner. Pour rien d'autre, pas tant. Mais vous pouvez toujours appliquer certains des concepts architecturaux les plus convaincants de WPF dans le développement de votre propre cadre d'interface utilisateur.

Il existe également une implémentation open source, non gérée C ++ / Direct3D de WPF appelée "WPF / G (WPF for Games)"]] ( http://wpfg.codeplex.com/ ) spécialement conçue pour être utilisée dans les jeux sur Win32 et Windows Mobile. Le développement actif semble avoir cessé, mais la dernière fois que je l'ai vérifié, c'était une implémentation plutôt complète. Le sous-système de texte était le seul domaine qui manquait vraiment par rapport à l'implémentation WPF de Microsoft, mais c'est moins un problème pour les jeux. J'imagine que l'intégration de WPF / G avec un moteur de jeu basé sur Direct3D serait relativement simple. Suivre cette voie pourrait vous fournir un cadre d'interface utilisateur extrêmement puissant et indépendant de la résolution avec un support étendu pour la personnalisation de l'interface utilisateur.

Juste pour vous donner une idée de ce à quoi pourrait ressembler une interface de jeu basée sur WPF, voici une capture d'écran de mon projet pour animaux de compagnie:

Je choisirais une interface graphique immédiate, comme celle-ci: http://code.google.com/p/nvidia-widgets/

Les widgets nVidia sont basés sur IMGUI (GUI immédiat) de MollyRocket.

Je pense que c'est à peu près aussi simple qu'une interface graphique peut jamais obtenir.

Tout dépend de vos besoins.

Dans le jeu sur lequel je travaille, nous avons notre propre framework GUI personnalisé. Je l'ai trouvé très simple, mais je fais toujours tout ce que je veux. Je ne sais pas si c'est un "modèle" que beaucoup d'autres utilisent, mais cela fonctionne bien pour nous.

Fondamentalement, tous les boutons, cases à cocher, etc. sont des sous-classes de la classe Element; et les éléments ont des événements. Ensuite, nous avons CompoundElements (qui sont eux-mêmes une sous-classe d'Element), qui contiennent d'autres éléments. Dans chaque cycle, trois méthodes sont appelées: processEvent (événement), tick (temps) et draw (surface). Chaque élément composé appelle ensuite ces méthodes sur ses éléments enfants. Dans ces appels (en particulier la méthode processEvent), nous déclenchons tous les événements pertinents.

Tout cela est en Python (un langage beaucoup plus lent que C ++), et il fonctionne parfaitement bien.

Si vous avez besoin d'interfaces utilisateur assez sophistiquées, le meilleur choix est probablement d'incorporer simplement un moteur de rendu HTML - vous obtenez toutes les primitives d'interface utilisateur habituelles auxquelles vous êtes habitué, et vous pouvez facilement ajouter une interface utilisateur complexe à votre jeu qui se comportera de la même manière les utilisateurs s'attendent, ont fière allure et fonctionnent rapidement (car les navigateurs ont des pipelines de rendu assez optimisés à ce stade).

Il existe quelques bibliothèques pour intégrer Webkit dans les jeux: Berkelium est celui que je recommande, et j'entends que Awesomium est assez bon (utilisé par EVE Online) et CEF (utilisé par Steam). Vous pouvez également essayer d'intégrer Gecko - c'est beaucoup plus difficile à faire, mais présente également des avantages intéressants. J'utilise actuellement Berkelium pour toute l'interface utilisateur de mon jeu (il a remplacé une combinaison d'éléments d'interface utilisateur personnalisés et d'interface utilisateur native, et a considérablement réduit la quantité de code que j'ai dû écrire pour que les choses fonctionnent).

Assurez-vous que vous avez réellement besoin d'un système GUI sophistiqué pour votre jeu. Si vous créez un RPG informatique, ce sera évidemment une exigence; mais pour quelque chose comme un jeu de course, ne compliquez pas les choses. Parfois, le simple rendu des textures (images de boutons personnalisés) et le fait d'avoir des instructions "if" avec des coordonnées codées en dur dans votre fonction d'entrée peuvent faire le travail. Une machine d'état de jeu (FSM) aide à cette approche simple. Ou, quelque part au milieu, oubliez l'approche hiérarchique et graphique de scène compliquée et ayez simplement une classe "Button" qui regroupe la texture et les contrôles d'entrée mentionnés ci-dessus dans de simples appels de fonction, mais ne fait rien de compliqué.

Clouer vos exigences est important. Si vous n'êtes pas sûr, rappelez-vous simplement YAGNI .

Voici un exemple (code source et tout) d'une interface graphique conçue pour OpenGL, spécifiquement pour Slick2D appelé Thingle qui est un port de Thinlet .

Une autre interface graphique pour Slick2D était SUI que vous pourriez vouloir vérifier.

Je suivrais ces exemples et irais avec une interface graphique pilotée par XML. Bien que ces projets soient anciens / morts, vous pourrez peut-être en tirer quelques idées.

Je pense que l'un des meilleurs moyens de "comprendre" serait de jeter un œil au fonctionnement des frameworks GUI hautement développés, tels que Windows Forms dans .NET.

Par exemple, ce sont tous des contrôles, qui ont un emplacement, une taille, une liste de contrôles enfants, une référence à son parent, une Textpropriété pour tout ce que le contrôle peut l'utiliser, ainsi que diverses fonctions remplaçables et actions prédéfinies.

Ils contiennent tous divers événements tels que Click, MouseOveret Resizing.

Par exemple, lorsqu'un contrôle enfant est modifié, il envoie une notification dans la chaîne indiquant que sa disposition a changé, et tous les parents appellent ensuite PerformLayout().

De plus, le dimensionnement automatique et l'agencement automatique sont des caractéristiques courantes de ces interfaces graphiques, permettant aux programmeurs d'ajouter simplement des contrôles et les contrôles parents les ajustent ou les organisent automatiquement.

Par souci d'intérêt, je pensais que je jetterais Scaleform . Fondamentalement, les artistes peuvent utiliser illustrateur, photoshop, etc., puis le concepteur d'interface utilisateur utilise Flash pour mettre en page toute l'interactivité. Ensuite, Scaleform le transforme en code pour votre moteur (c'est ma compréhension car je ne l'ai pas utilisé). Crysis Warhead a utilisé ce système pour son lobby.