Unreal Engine: Epic valuta altro linguaggio da affiancare a C++ e Blueprint

Tim Sweeney sta pensando a dei cambiamenti strutturali per la sua creazione, Unreal Engine 4. Su Reddit, infatti, chiede il parere della community a proposito dell’opportunità a introdurre un linguaggio intermedio tra C++ e Blueprint, ovvero il metodo di scripting visuale interno a Unreal Engine 4.

“Ne abbiamo discusso molto internamente e l’idea ci piace”, ha scritto il CEO di Epic Games. “Vediamo l’introduzione di un altro livello di programmazione come una decisione che è vincolante per tutto ciò che faremo per un decennio o più, quindi non dobbiamo prendere decisioni affrettate”.

Unreal Engine 4

In altre parole, Sweeney vuole andare alla ricerca di una soluzione intermedia tra un linguaggio di alto livello come C++ e una soluzione meramente visiva come il Blueprint incluso in Unreal Engine 4. La nuova soluzione intermedia deve essere in grado di dialogare con i linguaggi già esistenti in Ue4. “Ci piace la semplicità di C # ma non va bene la mancata corrispondenza tra i contenitori di C # con le strutture di dati e il codice gestito in runtime di C++. Ciò rende difficile condividere i dati tra i mondi C # e C ++. UnrealScript aveva una corrispondenza molto più diretta tra i due mondi, tuttavia il carico dei dati di mirroring era significativo”.

Quindi Sweeney, come ragionando a voce alta insieme alla community, passa a valutare tutte le opzioni a disposizione per realizzare questo cambiamento: “Amiamo la semplicità di Python, ma presenterebbe problemi simili a UnrealScript e diffidiamo della digitazione dinamica. Anche Lua potrebbe essere una soluzione. Generalmente, invece, siamo spaventati da JavaScript”.

“Esiste anche la possibilità di creare un linguaggio personalizzato, come lo era UnrealScript, elaborato per interagire con il motore e risolvere i problemi di gioco. Ma vorremmo che tutti voi vi esprimeste in proposito”.

Per altri dettagli sul funzionamento di Unreal Engine 4 consultate il nostro speciale qui e qui

In un altro post, va a esaminare le soluzioni adottate dalle tecnologie rivali. “Frostbite ha fatto un passo in avanti con il codice incaricato del gameplay multithreading, che si traduce in maggiore scalabilità. Tuttavia questo espone i programmatori della parte gameplay a dover gestire molte tipologie di dati e alla complessità della sincronizzazione che si crea con il multiprocessing della memoria condivisa”.

Unity sta portando avanti una direzione interessante con il loro ECS (Entity-Component System), che mira a eludere al sovraccarico di C # spostando i dati dagli oggetti di alto livello collegati da puntatori a un layout dei dati molto più snello. Ciò che è sconosciuto riguarda come questo approccio possa incidere nella programmazione del gameplay per via del data model più ristretto. Per esempio, nutro dei dubbi che questo approccio possa scalare al punto da poter andare bene a un team che lavora su un grosso gioco multiplayer”.

“Un’altra possibile direzione potrebbe essere quella del ‘message-passing concurrency’ nello stile di Erlang, che esegue una simulazione dei nodi nei data center, all’interno di un modello in cui multithreading e calcolo distribuito fanno parte dello stesso framework”. Secondo Sweeney, però, questo approccio porterebbe alla negoziazione di troppe interazioni richiedendo protocolli molto elaborati e portando a eccessiva complessità in fase di debug.

Trovare il giusto equilibrio in tutto questo non è facile, perché la tecnologia deve adattarsi alle esigenze sia di piccoli team di sviluppo dove tutti i programmatori si conoscono molto bene tra di loro sia alle esigenze di grossi studi dove tantissimi programmatori sviluppano componenti concepite in maniera indipendente tra di loro ma che devono dialogare insieme nel prodotto finale.