Come procedere con gli elementi della GUI?

Nota: ho intenzione di creare il mio sistema di interfaccia grafica. Sarà buono per l'apprendimento, leggero, ha solo pezzi di cui ho bisogno, si lega al gioco, ecc.

Stavo pensando a come farlo. Gli elementi che intendo sono:

• Tasti della radio
• Inserisci qui le caselle di testo
• pulsanti
• Sliders
• caselle di controllo

Non sto ancora cercando di farli. Ma più di come sarebbero andati.

Idea

Avrei ogni stato che aveva bisogno di cose, quindi quasi tutti, avrei un contenitore di elementi. Ogni elemento è un pezzo della GUI.

Ognuno di essi ha una posizione, un'immagine, ecc.

La parte su cui mi incantano maggiormente è la loro logica.

La mia idea per quello, per consentire la modularità e la semplicità era di evitare un MainMenuStartButton; un OptionsOneBackButton, ecc. e invece essere in grado di fare il cursore Slider1; o Pulsante Start ;.

Al contrario, ognuno avrebbe una funzione boost :: a una funzione in uno spazio dei nomi della GUI, come Gui :: StartButtonClick o GUI :: ColourSliderHover.

Mi stavo solo chiedendo se questo sarebbe stato eccezionalmente lento o no.

E del resto , esiste un modo semplice e semplice di eseguire la GUI per i giochi? No Qt, wxWidgets o altro.

La GUI non è un problema facile o semplice, specialmente quando si entra nei giochi e nella loro voglia di avere menu dinamici e interessanti.

Una cosa "facile" che puoi fare è provare a usare il middleware. C'è una domanda al riguardo qui .

Se lo farai tu stesso, ci sono alcune cose che suggerirei.

• Gli elementi della GUI generalmente hanno un "genitore", o un altro elemento della GUI o una "finestra", o qualcosa del genere. Puntando verso l'alto o facendo in modo che il genitore sia rivolto verso il basso, puoi impostare stato / posizione / ecc. Su tutto ciò che è figlio.

• È possibile creare elementi della GUI per composizione. Molti widget hanno etichette (praticamente tutte) e potrebbe avere senso rendere il concetto di etichetta un componente o un figlio di altri tuoi elementi dell'interfaccia utente piuttosto che copiare / incollare il codice o provare a ereditare da una classe base con funzionalità di etichetta.

• Molti cosiddetti widget specializzati sono solo pulsanti mascherati. Le caselle di controllo sono solo pulsanti con stati e immagini speciali. I pulsanti di opzione sono solo caselle di controllo con meta-stato (uno solo è attivo in un determinato momento) con altri pulsanti di opzione. Usa questo a tuo vantaggio. In un gioco a cui ho lavorato, le "caselle di controllo" sono state eseguite con pulsanti regolari interamente tramite script e grafica.

• Per il tuo primo progetto, considera di prendere la strada più diretta. Sì, rendi delegati i tuoi eventi realizzabili e assegna ciò di cui hai bisogno sulla creazione dell'elemento (ad esempio onMouseButtonDown, onMouseButtonUp, onHover ecc.), Ma considera semplicemente la codifica difficile di ciò che vuoi che accada altrimenti (ovvero cambia i colori al passaggio del mouse, premi i pulsanti) finché non ottieni qualcosa funzionale. Una volta che sei a quel punto, prendi in considerazione la possibilità di creare quei dati comportamentali (ad esempio, hai una variabile sul pulsante per "premere il suono", o forse considera di avere componenti che i tuoi elementi dell'interfaccia utente usano per definire il comportamento che li colleghi quando li crei.

• i delegati non sono così lenti, probabilmente non avrai così tanti widget che sarebbe un problema, e il codice del menu generalmente non ha comunque un grande impatto. Non mi preoccuperei troppo delle prestazioni a questo punto del gioco. Non scegliere algoritmi e profilo ingenui una volta che il codice è attivo e funzionante.

Negli ultimi anni ci sono state alcune scoperte davvero interessanti nei toolkit tradizionali dell'interfaccia utente. Anche le interfacce di gioco si sono evolute, ma a un ritmo leggermente più lento. Ciò è probabilmente dovuto al fatto che lo sviluppo di un sottosistema UI completo è un'impresa significativa in sé, ed è difficile giustificare l'investimento in risorse.

Il mio sistema di interfaccia utente preferito personale è Windows Presentation Foundation (WPF). Prende davvero il potenziale per la differenziazione dell'interfaccia utente al livello successivo. Ecco alcune delle sue caratteristiche più interessanti:

1. I controlli sono "senza aspetto" per impostazione predefinita. La logica e l'aspetto visivo di un controllo sono generalmente disaccoppiati. Ogni controllo viene fornito con uno stile e un modello predefiniti, che ne descrivono l'aspetto visivo predefinito. Ad esempio, un pulsante può essere rappresentato come un rettangolo arrotondato con un tratto esterno, un colore uniforme o uno sfondo sfumato e un presentatore di contenuti (per presentare la didascalia). Gli sviluppatori (o designer) possono creare modelli di stili personalizzati che modificano l'aspetto e (in una certa misura) il comportamento di un controllo. Gli stili possono essere utilizzati per sovrascrivere semplici proprietà di un controllo, come colore di primo piano / sfondo, modello, ecc .; i modelli cambiano la struttura visiva effettiva.

2. Stili e modelli possono includere "Trigger". I trigger possono ascoltare determinati eventi o valori di proprietà (o combinazioni di valori) e modificare in modo condizionale aspetti di uno stile o modello. Ad esempio, un modello di pulsante in genere avrebbe un trigger sulla proprietà "IsMouseOver" allo scopo di cambiare il colore di sfondo quando il mouse passa sopra il pulsante.

3. Esistono alcuni "livelli" diversi di elementi dell'interfaccia utente che vanno da elementi più leggeri con funzionalità minima a controlli completi di peso elevato. Questo ti dà una certa flessibilità nel modo in cui strutturi l'interfaccia utente. La più semplice delle classi di elementi dell'interfaccia utente UIElement, non ha stile o modello e supporta solo il più semplice degli eventi di input. Per elementi semplici come gli indicatori di stato, questa funzionalità potrebbe essere tutto ciò di cui hai bisogno. Se è necessario un supporto di input più esteso, è possibile derivare da FrameworkElement(che si estende UIElement). I widget tradizionali generalmente derivano Control, il che estende FrameworkElemente aggiunge stile personalizzato e supporto ai modelli (tra le altre cose).

4. WPF utilizza un modello di grafica vettoriale conservato, scalabile e indipendente dalla risoluzione. Su Windows, le applicazioni WPF vengono rese e composte usando Direct3D.

5. L'introduzione di WPF includeva un nuovo linguaggio di programmazione dichiarativo chiamato Xaml. Xaml, basato su Xml, è la lingua preferita per dichiarare "scene" dell'interfaccia utente. In realtà è piuttosto fluido, e sebbene possa sembrare simile a prima vista, è fondamentalmente diverso dalle lingue esistenti come XUL (e molto più potente).

6. WPF ha un sottosistema di testo molto avanzato. Supporta la maggior parte, se non tutte, le funzionalità dei caratteri OpenType, l'antialiasing bidirezionale ClearType, il posizionamento subpixel, ecc.

"Ok, fantastico, ora come è rilevante per lo sviluppo del gioco?"

Quando WPF era ancora in fase di sviluppo (e noto come "Avalon"), frequentavo un corso di progettazione di videogiochi presso la Georgia Tech. Il mio progetto finale era un gioco di strategia a turni e volevo un'interfaccia utente molto capace. WPF / Avalon sembrava una buona strada da percorrere perché aveva un set completo di controlli completi e mi ha permesso di cambiare completamente l'aspetto di quei controlli. Il risultato è stato un gioco con un'interfaccia utente bella e nitida con il livello di funzionalità che normalmente vedi solo nelle applicazioni a tutti gli effetti.

Ora, il problema con l'uso di WPF per i giochi è che è abbastanza pesante e si trasforma nella sua "sandbox". Con ciò intendo dire che non esiste un modo supportato di ospitare WPF in un ambiente di gioco Direct3D o OpenGL. È possibile ospitare il contenuto di Direct3D all'interno di un'applicazione WPF, ma si sarà limitati dal framerate dell'applicazione WPF, che è generalmente inferiore a quello desiderato. Per alcuni tipi di giochi, come i giochi di strategia 2D (screenshot del mio attuale progetto di gioco WPF), potrebbe ancora funzionare alla grande. Per ogni altra cosa, non così tanto. Ma potresti ancora applicare alcuni dei concetti architettonici più avvincenti di WPF nello sviluppo del tuo framework UI.

Esiste anche un'implementazione C ++ / Direct3D open source e non gestita di WPF chiamata "WPF / G (WPF for Games)"] ( http://wpfg.codeplex.com/ ) progettata specificamente per l'uso in giochi su entrambi Win32 e Windows Mobile. Lo sviluppo attivo sembra essere cessato, ma l'ultima volta che l'ho verificato è stata un'implementazione piuttosto completa. Il sottosistema di testo era l'unica area che era davvero carente rispetto all'implementazione WPF di Microsoft, ma questo è meno un problema per i giochi. Immagino che l'integrazione di WPF / G con un motore di gioco basato su Direct3D sarebbe relativamente semplice. Seguire questa strada potrebbe fornirti un framework UI estremamente capace e indipendente dalla risoluzione con ampio supporto per la personalizzazione dell'interfaccia utente.

Solo per darti un'idea di come potrebbe apparire un'interfaccia utente di gioco basata su WPF, ecco uno screenshot del mio progetto per animali domestici:

Vorrei scegliere una GUI immediata, come questa: http://code.google.com/p/nvidia-widgets/

I widget nVidia sono basati su IMGUI (Immediate GUI) di MollyRocket.

Penso che sia semplice quanto una GUI può mai ottenere.

Tutto dipende da quali sono le tue esigenze.

Nel gioco a cui sto lavorando, abbiamo il nostro framework GUI personalizzato. L'ho trovato molto semplice, ma sto ancora facendo tutto quello che voglio. Non so se è uno "schema" che molti altri usano, ma funziona bene per noi.

Fondamentalmente, tutti i pulsanti, le caselle di controllo, ecc. Sono sottoclassi della classe Element; e gli elementi hanno eventi. Quindi abbiamo CompoundElements (che sono essi stessi una sottoclasse di Element), che contengono altri elementi. In ogni ciclo, vengono chiamati tre metodi: processEvent (evento), tick (tempo) e draw (superficie). Ogni CompoundElement chiama quindi questi metodi sui suoi elementi figlio. In tali chiamate (in particolare il metodo processEvent), vengono attivati ​​tutti gli eventi rilevanti.

Tutto questo è in Python (un linguaggio molto più lento di C ++) e funziona perfettamente.

Se hai bisogno di interfacce utente abbastanza sofisticate, la scelta migliore è probabilmente quella di incorporare un renderer HTML: ottieni tutte le primitive UI comuni a cui sei abituato e puoi aggiungere banalmente un'interfaccia utente complessa al tuo gioco che si comporterà come gli utenti si aspettano, hanno un bell'aspetto e funzionano velocemente (perché i browser hanno pipeline di rendering piuttosto ottimizzate a questo punto).

Ci sono alcune biblioteche là fuori per incorporare Webkit nei giochi: Berkelium è quello che raccomando, e sento Awesomium è abbastanza buono (usato da EVE Online) e così è CEF (usato da Steam). Puoi anche provare a incorporare Gecko: è molto più difficile da fare ma ha anche alcuni vantaggi interessanti. Attualmente sto usando Berkelium per tutta l'interfaccia utente del mio gioco (ha sostituito una combinazione di elementi dell'interfaccia utente personalizzati e interfaccia utente nativa e ha ridotto drasticamente la quantità di codice che dovevo scrivere per far funzionare le cose).

Assicurati di aver effettivamente bisogno di un sofisticato sistema di interfaccia grafica per il tuo gioco. Se stai realizzando un gioco di ruolo per computer, ovviamente sarà un requisito; ma per qualcosa come un gioco di corse, non complicare troppo le cose. A volte è sufficiente eseguire il rendering delle trame (immagini di pulsanti personalizzati) e avere alcune istruzioni "if" con coordinate codificate nella funzione di input. Una macchina a stati di gioco (FSM) aiuta con questo semplice approccio. Oppure, da qualche parte nel mezzo, dimentica la complessa gerarchia e l'approccio del grafico della scena e hai solo una classe "Button" che racchiude la trama sopra menzionata e i controlli di input in semplici chiamate di funzioni, ma non fa nulla di complicato.

Inchiodare le vostre esigenze è importante. Se non sei sicuro, ricorda a te stesso YAGNI .

Ecco un esempio (codice sorgente e tutto) di una GUI creata per OpenGL, in particolare per Slick2D chiamata Thingle, che è una porta di Thinlet .

Un'altra interfaccia grafica per Slick2D era SUI che potresti voler controllare.

Seguirei questi esempi e andrei con una GUI basata su XML. Sebbene questi progetti siano vecchi / morti, potresti essere in grado di raccogliere alcune idee da loro.

Penso che uno dei modi migliori per "capirlo" sarebbe quello di vedere come funzionano i framework GUI altamente sviluppati, come Windows Form in .NET.

Ad esempio, sono tutti Controlli, che hanno una posizione, una dimensione, un elenco di controlli figlio, un riferimento al suo genitore, una Textproprietà per qualunque cosa il controllo possa utilizzarlo, nonché varie funzioni scavalcabili e azioni predefinite.

Contengono tutti vari eventi come Click, MouseOvere Resizing.

Ad esempio, quando un controllo figlio viene modificato, invia una notifica nella catena che il suo layout è stato modificato e quindi tutti i genitori chiamano PerformLayout().

Inoltre, il dimensionamento automatico e la disposizione automatica sono caratteristiche comuni di queste GUI, che consentono ai programmatori di aggiungere semplicemente controlli e i controlli principali li regolano o li organizzano automaticamente.

Per motivi di interesse, ho pensato di buttare fuori Scaleform . Fondamentalmente gli artisti possono usare Illustrator, Photoshop ecc., Quindi il designer dell'interfaccia utente usa Flash per impaginare tutta l'interattività. Quindi Scaleform lo trasforma in codice per il tuo motore (questo è il mio modo di comprenderlo perché non l'ho usato). Crysis Warhead usava questo sistema per la loro lobby.