¿Cómo abordar los elementos de la GUI?

Nota: planeo hacer mi propio sistema GUI. Será bueno para el aprendizaje, liviano, solo tengo partes que necesito, se vincula con el juego, etc.

Estaba pensando en cómo hacerlo. Los elementos que quiero decir son:

• Botones de radio
• Introduzca texto aquí cuadros
• Botones
• Deslizadores
• Casillas de verificación

Todavía no estoy buscando cómo hacerlos. Pero más de cómo irían.

Idea

Tendría cada estado que necesitara cosas, por lo que casi todos tienen un contenedor de elementos. Cada elemento es una pieza GUI.

Cada uno tiene posición, un gráfico, etc.

Lo que más me atora es la lógica de ellos.

Mi idea para eso, permitir modularidad y simplicidad era evitar un MainMenuStartButton; un OptionsOneBackButton, etc. y en su lugar poder hacer Slider slider1; o botón de inicio ;.

En cambio, cada uno tendría una función boost :: a una función en un espacio de nombres GUI, como Gui :: StartButtonClick o GUI :: ColourSliderHover.

Me preguntaba si esto sería excepcionalmente lento o no.

Y para el caso, ¿hay alguna manera fácil y sencilla de hacer GUI para juegos? Sin Qt, wxWidgets ni nada.

La GUI no es un problema fácil o simple, especialmente cuando entras en juegos y su deseo de tener menús dinámicos e interesantes.

Una cosa "fácil" que puede hacer es intentar usar middleware. Hay una pregunta sobre eso aquí .

Si lo va a rodar usted mismo, hay algunas cosas que sugeriría.

• Los elementos GUI generalmente tienen un "elemento primario", ya sea otro elemento GUI o una "ventana", o algo así. Ya sea apuntando hacia arriba o haciendo que el padre apunte hacia abajo significa que puede establecer el estado / posición / etc. en todo lo que es un hijo.

• Puede construir elementos GUI por composición. Muchos widgets tienen etiquetas (casi todas), y podría tener sentido hacer que el concepto de etiqueta sea un componente o un elemento secundario de sus otros elementos de la interfaz de usuario que copiar / pegar el código o intentar heredar de una clase base con funcionalidad de etiqueta.

• Muchos de los llamados widgets especializados son solo botones disfrazados. Las casillas de verificación son solo botones con estados e imágenes especiales. Los botones de radio son solo casillas de verificación que tienen metaestado (uno y solo uno está activo en un momento dado) con otros botones de radio. Usa esto para tu ventaja. En un juego en el que trabajé, las "casillas de verificación" se hicieron con botones normales completamente a través de secuencias de comandos y arte.

• Para su primer proyecto, considere tomar la ruta más directa. Sí, delegue sus eventos accionables y asigne lo que necesita en la creación de elementos (es decir, onMouseButtonDown, onMouseButtonUp, onHover, etc.), pero considere codificar lo que quiere que suceda de otra manera (es decir, cambiar el color del cursor, presionar los botones) hasta que obtenga algo funcional. Una vez que esté en ese punto, considere hacer esos datos de comportamiento (es decir, tener una variable en el botón para "presionar sonido", o tal vez considere tener componentes que sus elementos de la interfaz de usuario usen para definir el comportamiento que simplemente se les adjunta cuando los crea.

• los delegados no son tan lentos, probablemente no tendrá tantos widgets que sería un problema, y ​​el código del menú generalmente no es tan impactante de todos modos. No me preocuparía demasiado por el rendimiento en este punto del juego. No elija algoritmos y perfiles ingenuos una vez que tenga su código en funcionamiento.

Ha habido algunos avances realmente interesantes en los kits de herramientas de interfaz de usuario principales en los últimos años. Las IU del juego también han evolucionado, pero a un ritmo algo más lento. Esto es probable porque desarrollar un subsistema de interfaz de usuario con todas las funciones es una tarea importante en sí misma, y ​​es difícil justificar la inversión de recursos.

Mi sistema de IU favorito personal es Windows Presentation Foundation (WPF). Realmente lleva el potencial de diferenciación de UI al siguiente nivel. Estas son algunas de sus características más interesantes:

1. Los controles son "sin aspecto" por defecto. La lógica y la apariencia visual de un control generalmente están desacopladas. Cada control se envía con un estilo y una plantilla predeterminados, que describen su apariencia visual predeterminada. Por ejemplo, un botón puede representarse como un rectángulo redondeado con un trazo externo, un color sólido o un fondo degradado y un presentador de contenido (para presentar el título). Los desarrolladores (o diseñadores) pueden crear plantillas de estilos personalizados que cambian la apariencia y (hasta cierto punto) el comportamiento de un control. Los estilos se pueden usar para anular las propiedades simples de un control, como el color de primer plano / fondo, la plantilla, etc. Las plantillas cambian la estructura visual real.

2. Los estilos y las plantillas pueden incluir "Disparadores". Los disparadores pueden escuchar ciertos eventos o valores de propiedad (o combinaciones de valores) y alterar condicionalmente aspectos de un estilo o plantilla. Por ejemplo, una plantilla de botón generalmente tendría un activador en la propiedad "IsMouseOver" con el propósito de cambiar el color de fondo cuando el mouse pasa sobre el botón.

3. Hay algunos "niveles" diferentes de elementos de interfaz de usuario que van desde elementos más livianos con una funcionalidad mínima hasta controles completos de peso pesado. Esto le brinda cierta flexibilidad en la forma en que estructura su IU. La más simple de las clases de elementos de la interfaz de usuario UIElement, no tiene estilo ni plantilla y solo admite los eventos de entrada más simples. Para elementos simples como indicadores de estado, esta funcionalidad podría ser todo lo que necesita. Si necesita un soporte de entrada más extenso, puede derivar de FrameworkElement(que se extiende UIElement). Los widgets tradicionales generalmente se derivan Control, lo que extiende FrameworkElementy agrega estilo personalizado y soporte de plantillas (entre otras cosas).

4. WPF utiliza un modelo de gráficos vectoriales retenido, escalable e independiente de la resolución. En Windows, las aplicaciones WPF se representan y componen utilizando Direct3D.

5. La introducción de WPF incluyó un nuevo lenguaje de programación declarativo llamado Xaml. Xaml, basado en Xml, es el lenguaje preferido para declarar "escenas" de IU. En realidad, es bastante hábil, y aunque puede parecer similar a primera vista, es fundamentalmente diferente de los lenguajes existentes como XUL (y mucho más potente).

6. WPF tiene un subsistema de texto muy avanzado. Admite la mayoría de las funciones de fuente OpenType, si no todas, el antialiasing bidireccional ClearType, el posicionamiento de subpíxeles, etc.

"Muy bien, ahora, ¿cómo es esto relevante para el desarrollo del juego?"

Cuando WPF todavía estaba en desarrollo (y conocido como "Avalon"), estaba tomando un curso de diseño de videojuegos en Georgia Tech. Mi proyecto final fue un juego de estrategia por turnos, y quería una interfaz de usuario muy capaz. WPF / Avalon parecía una buena ruta a seguir porque tenía un conjunto completo de controles con todas las funciones y me permitía cambiar por completo la apariencia de esos controles. El resultado fue un juego con una interfaz de usuario hermosa y nítida con el nivel de funcionalidad que normalmente solo se ve en aplicaciones completas.

Ahora, el problema con el uso de WPF para juegos es que es bastante pesado y se presenta en su propio "sandbox". Con eso quiero decir que no hay una forma compatible de alojar WPF dentro de un entorno de juego Direct3D u OpenGL. Es posible alojar contenido Direct3D dentro de una aplicación WPF, pero estará limitado por la velocidad de fotogramas de la aplicación WPF, que generalmente es más baja de lo que desearía. Para algunos tipos de juegos, como los juegos de estrategia 2D (captura de pantalla de mi proyecto de juego WPF actual), aún podría funcionar muy bien. Para cualquier otra cosa, no tanto. Pero aún podría aplicar algunos de los conceptos arquitectónicos más convincentes de WPF al desarrollar su propio marco de interfaz de usuario.

También hay una implementación de código abierto, C ++ / Direct3D de WPF llamada "WPF / G (WPF for Games)"] ( http://wpfg.codeplex.com/ ) que está específicamente diseñada para su uso en juegos en Win32 y Windows Mobile. El desarrollo activo parece haber cesado, pero la última vez que lo revisé, fue una implementación bastante completa. El subsistema de texto era el área que realmente faltaba en comparación con la implementación WPF de Microsoft, pero eso no es un problema para los juegos. Me imagino que integrar WPF / G con un motor de juego basado en Direct3D sería relativamente sencillo. Seguir esta ruta podría proporcionarle un marco de interfaz de usuario extremadamente capaz e independiente de la resolución con un amplio soporte para la personalización de la interfaz de usuario.

Solo para darte una idea de cómo podría ser una interfaz de usuario de juego basada en WPF, aquí hay una captura de pantalla de mi proyecto favorito:

Me gustaría una GUI inmediata, como esta: http://code.google.com/p/nvidia-widgets/

Los widgets de nVidia se basan en IMGUI (GUI inmediata) de MollyRocket.

Creo que es tan simple como una GUI puede ser.

Todo depende de cuáles sean sus necesidades.

En el juego en el que estoy trabajando, tenemos nuestro propio marco GUI personalizado. He descubierto que es muy simple, pero sigo haciendo todo lo que quiero que haga. No sé si es un "patrón" que muchos otros usan, pero funciona bien para nosotros.

Básicamente, todos los botones, casillas de verificación, etc. son subclases de la clase Elemento; y los elementos tienen eventos. Luego tenemos CompoundElements (que son una subclase de Element), que contienen otros elementos. En cada ciclo, se llaman tres métodos: processEvent (evento), tick (tiempo) y draw (superficie). Cada CompoundElement llama a esos métodos en sus elementos secundarios. En esas llamadas (particularmente el método processEvent), activamos cualquier evento relevante.

Todo esto está en Python (un lenguaje mucho más lento que C ++), y funciona perfectamente bien.

Si va a necesitar interfaces de usuario bastante sofisticadas, la mejor opción es probablemente incrustar un renderizador HTML: obtendrá todas las primitivas de interfaz de usuario comunes a las que está acostumbrado y puede agregar trivialmente una interfaz de usuario compleja a su juego que se comportará de la misma manera. los usuarios esperan, se ven geniales y corren rápido (porque los navegadores tienen canales de renderizado bastante optimizados en este punto).

Existen algunas bibliotecas para integrar Webkit en los juegos: Berkelium es la que recomiendo, y escuché que Awesomium es bastante bueno (usado por EVE Online) y también lo es CEF (usado por Steam). También puede intentar incrustar Gecko: es mucho más difícil de hacer, pero también tiene algunas ventajas interesantes. Actualmente estoy usando Berkelium para toda la interfaz de usuario de mi juego (reemplazó una combinación de elementos de interfaz de usuario personalizados y una interfaz de usuario nativa, y redujo drásticamente la cantidad de código que tenía que escribir para que todo funcionara).

Asegúrate de que realmente necesitas un sistema GUI sofisticado para tu juego. Si está haciendo un juego de rol de computadora, obviamente será un requisito; pero para algo como un juego de carreras, no compliques demasiado las cosas. A veces, solo hacer texturas (imágenes de botones personalizadas) y tener algunas declaraciones "if" con coordenadas codificadas en su función de entrada puede hacer el trabajo. Una máquina de estado de juego (FSM) ayuda con este enfoque simple. O, en algún lugar en el medio, olvide el complicado enfoque de la jerarquía y el gráfico de escena y simplemente tenga una clase de "Botón" que empaqueta la textura mencionada anteriormente y las verificaciones de entrada en llamadas a funciones simples, pero no hace nada complicado.

Clavar sus requisitos es importante. Si no estás seguro, solo recuérdate YAGNI .

Aquí hay un ejemplo (código fuente y todo) de una GUI construida para OpenGL, específicamente para Slick2D llamada Thingle, que es un puerto de Thinlet .

Otra GUI para Slick2D fue SUI que es posible que desee consultar.

Seguiría estos ejemplos e iría con una GUI basada en XML. Aunque estos proyectos son antiguos / muertos, es posible que pueda obtener algunas ideas de ellos.

Creo que una de las mejores formas de "resolverlo" sería echar un vistazo a cómo funcionan los frameworks de GUI altamente desarrollados, como Windows Forms en .NET.

Por ejemplo, todos son controles, que tienen una ubicación, tamaño, lista de controles secundarios, una referencia a su padre, una Textpropiedad para lo que el control pueda usar, así como varias funciones reemplazables y acciones predefinidas.

Todos contienen varios eventos como Click, MouseOvery Resizing.

Por ejemplo, cuando se cambia un control secundario, envía una notificación en la cadena de que su diseño ha cambiado, y todos los padres luego llaman PerformLayout().

Además, el dimensionamiento automático y la organización automática son características comunes de estas GUI, lo que permite a los programadores simplemente agregar controles y los controles principales los ajustan o arreglan automáticamente.

Por el bien de los intereses, pensé en tirar Scaleform . Básicamente, los artistas pueden usar ilustrador, photoshop, etc., luego el diseñador de la interfaz de usuario usa Flash para diseñar toda la interactividad. Entonces Scaleform lo transforma en código para su motor (bueno, eso es lo que entiendo porque no lo he usado). Crysis Warhead usó este sistema para su lobby.