È una buona idea semplificare un motore di gioco basato sui personaggi fino al punto in cui non è necessario imparare script / programmazione?

Ricordo, e penso ancora, che non si può nemmeno realizzare un gioco 3D prototipato per testare comportamenti semplici senza usare strumenti giganteschi come l'unità o conoscere una programmazione C ++ estesa, modelli di progettazione, un motore 3D decente o di base, ecc.

Ora mi chiedo, dato che conosco la programmazione, se sono ancora più fortunato di quelli che hanno bisogno di imparare la programmazione prima di sapere come fare qualcosa. Perfino i motori con script come Unity non sono adatti ai bambini, e secondo me tendono a dettare il loro modo di fare le cose. Questo non è il caso di motori come Ogre o Irrlicht.

Ora sto pensando che i giochi basati sui personaggi occupino una grande parte del mercato dei giochi. Pensi che sia una buona idea creare un motore di gioco orientato al controllo del personaggio che consenta di costruire l'IA solo escludendo qualsiasi altra cosa?

Quando dico prototipo, intendo anche "generico", nel senso che si può scegliere rapidamente da una serie di parametri di gioco come il gestore della scena, il POV della videocamera del lettore, i controlli, alcune collisioni / fisica molto basilari e l'integrazione dello sterzo base (ad esempio OpenSteer). L'idea principale è quella di creare un sandbox AI ma in 3D, in modo che possa essere dimostrato senza i vincoli 2D (e anche renderlo più adatto al prototipo in 3D per un progetto 3D anziché in 2D).

Mi piace molto il motore di gioco sottovalutato di Blender. (http://www.blender.org) Il modello sensore-controller-attuatore è davvero facile da seguire anche per i non programmatori ed è possibile creare un gioco ragionevolmente completo (spostare un personaggio animato, sparare con un'arma, distruggere obiettivi , mostra il punteggio, tieni traccia della salute, ripristina il livello o passa a uno nuovo) senza alcuna programmazione.

Certo, alcune cose richiedono la programmazione (in particolare ottenere l'input del mouse per un FPS.) Tuttavia, il frullatore incorpora già Python e gli script Python sono collegati molto bene al modello, quindi non è mai necessario sostituire gli attuatori dei sensori con Python. Invece, passi da un controller 'pass-through' molto semplice a uno script Python completo in grado di leggere tutti i sensori della scena e passare il controllo a tutti gli attuatori.

È abbastanza fattibile creare un prototipo di gioco in pochi giorni a Blender (l'ho fatto per un progetto in un museo per bambini locale l'anno scorso).

Naturalmente, nulla sostituisce il buon vecchio know-how di programmazione e, alla fine, uno sviluppatore deve comprendere la programmazione.

Indipendentemente dal meccanismo di input, alla fine della giornata è ancora necessario impostare un modo per dire al gioco qual è la logica. "Scripting" è un buon termine colloquiale per questo. Quindi sostanzialmente non sono d'accordo con l'affermazione che puoi semplificare qualcosa al punto in cui non hai bisogno di sapere "scripting".

Detto questo, non tutti gli script devono essere eseguiti con un linguaggio di programmazione testuale. C'è stato del lavoro (ma non molto) per creare un sistema di scripting visivo. Lo strumento di scripting di livello di Unreal, Kismet, ne è un ottimo esempio. Il motore di origine ha un meccanico simile, ma utilizza entità nel mondo anziché su un piano piano.

Fondamentalmente hai delle caselle da trascinare in un tipo di ambiente che ha input e output. Se hai bisogno di un qualche tipo di uscita ramificata hai una scatola che ha un input e più output. Questi output possono andare ad azioni a cui sono collegati dati (ad es. "Passare a questo punto", "dire questa riga", "porre questa domanda", ecc.). Di solito è una barriera significativamente più bassa all'ingresso per ottenere qualcosa in esecuzione in un linguaggio visivo poiché non devi conoscere parole chiave o sintassi, hai solo un set limitato di caselle da cui scegliere tutti hanno comportamenti definiti e collegali insieme.

Tuttavia, credo che i motori di scripting visivo non valgano davvero la pena. Devi essere in grado di pensare in modo strutturato e logico per poter dire con successo al motore cosa vuoi fare. Se riesci a pensare in quel modo, passare da scatole con input / output a istruzioni di ramificazione di base e chiamate di funzioni in un linguaggio di scripting non è un grosso problema. In effetti, dopo un po 'la parte visiva è probabilmente un ostacolo. Inoltre, c'è molto più lavoro sul lato motore delle cose. Devi fare cose come implementare annulla, copia / incolla, forse hai alcune funzionalità di livello superiore per l'organizzazione dei tuoi script. Con una lingua testuale puoi lasciare tutto questo all'IDE.

Sarà in generale un compromesso. Se vuoi veramente rimuovere la necessità di eseguire qualsiasi tipo di script, in genere parlerai di creare una sorta di interfaccia che metterà insieme gli script in background (o semplicemente collegherà oggetti logici o cosa no). Ci sono interi giochi in cui è questo il punto, un ambiente ben definito in cui trascini la funzionalità per vedere come interagisce con esso.

Alla fine della giornata, tuttavia, sarà sempre un compromesso. Quanto più semplice si tenta di rendere l'interfaccia tanto più semplicistico le cose create attraverso tale interfaccia.