Modifiche e impostazioni: modifica e persistenza delle variabili di runtime

La maggior parte delle aziende ha un editor o un sistema di controllo variabile per modificare le cose nei giochi, ma ci sono soluzioni middleware a questo problema? Ho scritto due di questi sistemi in passato e ho lavorato con cinque, forse sei diversi, ma nessuno di questi era disponibile.

Ognuna di queste soluzioni coltivate in casa ha avuto problemi, che vanno dal dover continuare a cercare valori, al non essere in grado di salvare lo stato attuale delle variabili.

Esistono librerie / app di controllo per variabili di configurazione / runtime mature?

Generalmente codifico in C ++, ma penso che un editor di impostazioni / variabili maturo dovrebbe probabilmente essere basato su socket (e quindi in una certa misura dal linguaggio agnostico) poiché tutto l'hardware di sviluppo attuale, a parte le cose di Nintendo, fornisce un meccanismo per parlare con i server. Anche l'implementazione del codice dovrebbe essere piuttosto semplice (mi piace l'articolo hot_var / TweakableConstants condiviso da Oskar, ma non è un pacchetto)

Mi piace quello che Noel ha proposto sul suo blog. Un tweaker variabile basato su telnet . Utilizzando telnet è stato in grado di utilizzare qualsiasi client telnet per modificare le variabili. Successivamente hanno costruito una gui attorno al protocollo. Sembra sufficientemente semplice, che probabilmente non vale una libreria di middleware ma guardare il suo codice potrebbe essere utile.

Non sono d'accordo con il suo sentimento anti-Lua comunque. Una console Lua remota sembra semplicemente fantastica.

Forse l'idea di Costanti modificabili soddisfa le tue esigenze. È così utilizzabile infatti che penseresti che avresti bisogno di una soluzione complessa per avere un controllo efficace delle variabili di runtime, ma in realtà l'implementazione è quasi troppo semplice. Anche la discussione originale su questa tecnica è una lettura interessante.

Esempio:

glClearColor( H(1.0f), H(1.0f), H(1.0f), H(1.0f) );

La Hmacro si espande in qualcosa del genere HotValue(x, __FILE__, __LINE__, __COUNTER__). Ciò registra il valore in alcuni registri globali. Quindi avere una funzione come RefreshHotValues()quella che si chiama a intervalli regolari. La funzione cerca ogni voce nel registro, analizza il file sorgente specifico e ricarica il valore attivo.

Quando modifichi il codice sorgente effettivo, hai la persistenza proprio lì.

Ovviamente questo non funzionerà dove H()non viene valutato ogni frame, ma ci sono modi per risolverlo come discusso qui .

Potresti espandere questa idea a una soluzione basata su socket, forse. Potrebbe esserci un notevole sovraccarico di prestazioni per chiamare HotValue()ogni frame, ma poiché puoi facilmente compilare la macro sostituendola completamente con la costante, questo non è un problema.

AntTweakBar è davvero utile per quello che vuoi fare, tuttavia, il più delle volte, vorresti avere metodi che 'compilano' in rilascio con alcune macro o simili.

Da una domanda sul debug in tempo reale , arriva la risposta di David McGraw su AsyncSocket per sviluppatori iOS. Vedi la sua risposta per ulteriori informazioni.

La gestione delle impostazioni sembra essere una di quelle cose che sono state rifatte da zero per ogni gioco, probabilmente a causa di quanto sia relativamente semplice e dell'alta variabilità nei tipi di impostazioni necessarie. Supponendo di avere una buona configurazione di back-end di archiviazione (SQL / qualunque cosa), è possibile codificare una soluzione affidabile per la gestione delle impostazioni in un giorno o due, quindi non sembra esserci una reale necessità aziendale per una soluzione middleware. Metterlo in cima a qualunque cosa tu usi per la memorizzazione delle informazioni dei giocatori è che penso che il modo migliore per andare nella maggior parte dei casi.

Ultimamente ho pensato a una cosa del genere, e penso che sarebbe un ottimo candidato per un'app Android abbinata a una piccola libreria in qualsiasi lingua tu voglia . L'app sarebbe un set personalizzabile di pulsanti, pulsanti, menu a discesa, ecc. (Qualsiasi widget desiderato) e invierebbe le azioni via WLAN (o USB se si desidera complicare le cose) alla libreria. La libreria avrebbe generato un thread separato dal gameplay e avrebbe saputo quali controlli sul telefono Android corrispondevano a quali variabili nel gioco (le avresti impostate nel tuo codice di avvio) e avrebbero una connessione all'app Android.

Quindi, pasticciare con il tuo gioco è facile come toccare le cose sul telefono. Potresti anche avere alcune caselle di testo sul telefono che mostrano valori variabili in tempo reale dal gioco, oppure potresti avere la libreria in avanti stdino stderrverso un'area di testo scorrevole sul telefono. Le opzioni sono infinite!

L'unica vera preoccupazione è con la velocità. Se la velocità e il tempo di reazione sono cruciali, allora agganceresti il ​​telefono tramite USB e adb (debugger Android) supporta l'inoltro delle porte tramite USB al telefono. Ma per il resto, la WLAN avrebbe solo un ritardo molto piccolo, che a mio avviso sarebbe molto accettabile.

Non credo sia stata scritta una cosa del genere, ma ho preso in seria considerazione la possibilità di scriverla. (Non sono ancora abbastanza avanti nello sviluppo dei miei giochi per averne ancora bisogno)

Naturalmente, quelli di voi che sono utenti Apple possono probabilmente fare lo stesso con i propri dispositivi iDevices. Personalmente trovo che lo sviluppo di iOS sia un ordine di grandezza più difficile dello sviluppo di Android e, naturalmente, l'app di cui sopra potrebbe essere facilmente pubblicata sul mercato Android per una facile distribuzione mentre Apple probabilmente non consentirebbe uno strumento di sviluppo nell'app store, quindi io sentire la piattaforma Android che si adatta meglio a questo strumento.