Come costruire un motore di gioco

Costruire un motore di gioco (motore di gioco di base) è in realtà piuttosto semplice. un motore di gioco di base è solo un ciclo, quindi mentre raccomanderei linguaggi di programmazione ad alte prestazioni come il c o il c++ si possono usare anche altri linguaggi che supportano il looping e le funzionalità di base, per esempio Java per ottenere una facile distribuzione cross platform.

il primo passo è progettare e realizzare il motore principale. questo è il ciclo. Per esempio il ciclo principale generalmente contiene sempre cose come Input, Logic, UserInterface(visual), e sound. mentre può essere raccomandato di aggiungere anche stati di loop per cose come fisica, ai, collisioni, ecc. un loop può essere fatto prima di avere o sapere come qualcosa verrà usato. così si può creare come questo per esempio in Cx* (lingua speciffic, ma l'idea principale dovrebbe essere chiara)

#include

#include

#include //questo include tutte le tue librerie nel ciclo, non hanno bisogno di esistere ancora. questa linea speciale include una libreria chiamata Logic.h. si raccomanda di fare tali librerie per mantenere il tuo codice pulito e facilmente mantenibile. potete anche usare #include "UI.h" in questo modo potete semplicemente usare un altro file. non è necessario usare librerie, ma farlo rende il tutto più modulare, poiché potete semplicemente collegare una libreria diversa con le stesse funzioni e cambierà l'intero comportamento.

int main()

{

Input.Start(); Logic.Start(); UI.Start();//utilizzatelo per impostare le giuste valute e per avviare cicli secondari per compiti in background come il vostro motore sonoro (questo è facile da fare su un altro thread, quindi a meno che non stiate lavorando su una macchina singlelethreaded è consigliato impostarlo in un ciclo separato e usare trigger come un bool o un int per cambiare lo stato), etc.

bool GameEngineRunning=true;

while(GameEngineRunning)

{

Input.Update();

Logic.Update() ;

UI.Update();//aggiorna (esegue le funzioni predefinite per ciclo ed esegue azioni/imposta trigger.

}

return 0;

}

questo potrebbe essere un motore di gioco funzionante e potresti renderlo più semplice. nelle librerie come l'input si può per esempio ottenere l'input da tastiera e rimandare indietro in una variabile pubblica se ha ottenuto qualcosa e se sì cosa (nella maggior parte dei casi si controlla solo nel momento, quindi questo non controlla ancora lo stream perché si vuole prevenire le attese. un flusso potrebbe essere aggiunto per esempio da Logic, o qualsiasi cosa avrebbe bisogno del flusso per aggiungere i valori chiave a una variabile stringa quando si aspetta tale input, l'input gestisce solo ciò che viene immesso in quel momento esatto, a meno che non si abbia un gioco in terminale (come un gioco tattico come gli scacchi) o tale dove il frame rate del gioco non è importante. L'uso della struttura della libreria ti aiuta in questo, poiché ora puoi usare lo stesso motore per giochi che non hanno bisogno di un frame rate continuo, come lo useresti per un gioco dipendente dal frame rate, cambiando solo la libreria di input e usando una libreria logica ben progettata o modificata.

esempio di progetti gameloop:

mantenere questa parte il più semplice possibile all'inizio. quindi il ciclo chiama per lo più solo funzioni e possibilmente (intelligente da fare) un bool che può essere usato per chiuderlo senza usare funzioni forzate che il vostro linguaggio di programmazione potrebbe avere.

un motore di gioco più complesso in generale ha parti extra come fisica, collisione, distruzione, ai, ecc. Inoltre dovreste cercare di rendere le cose il più possibile multithreaded se potete farlo in sicurezza. per esempio potete fare in modo che il motore di gioco cerchi di usare una gpu per il rendering e persino rendere le parti di rendering della cpu su un thread diverso se avete una logica pesante o sistemi di fisica/distruzione. potete usare l'ai per prevedere cosa sta per succedere e renderizzare i frame anche quando la cpu non può tenere il passo. anche cose come ai (creature, ecc.), a e particelle di base della fisica o effetti dovrebbero essere il più possibile multithreaded dal momento che quelli in generale sono tra le cose più intense per la cpu. e in molti giochi tendono a rallentare la velocità del gioco. se per esempio minecraft, che è un buon esempio dal momento che è un motore abbastanza primitivo creato abbastanza come descritto sopra, inoltre non supporta originariamente il multi threading. Questo gioco ha effettivamente limiti di entità costruiti in e in generale ottiene molto del suo lag da entità. anche a causa della generazione del mondo, ma questo è solo quando si genera. minecrafts GUI e renderer del mondo è effettivamente scritto molto meglio per quel gioco rispetto alla maggior parte dei renderer. questo è il motivo per cui sembra molto meglio di molti remake (in motori di gioco normali) ed è in generale sempre limitato dalle prestazioni della cpu singlecore, quindi anche una gpu di 12 anni è in grado di tenere il passo con i frame. Questo è anche a causa di alcune cose algoritmiche che funzionano come una predizione che predice ciò che si può vedere.

per rendere il motore più autonomo, si può anche aggiungere la gestione dei file, in questo modo si può per esempio fargli leggere un file principale che può essere qualsiasi cosa che verrà aperta usando il motore. questo file mostra tutti gli altri file e risorse che dicono al motore cosa fare e come apparire, ecc. Questo può anche permetterti di usare una singola copia condivisa del motore per risparmiare spazio su disco. potrebbe anche essere esteso per avere certe librerie di shader e texture condivise. le opzioni per salvare e caricare sono anche ottime da aggiungere. e come ultimo passo puoi anche fare un editor per creare giochi per il tuo motore senza codificarli tu stesso nel motore o nei file usati.

Alcuni anni fa ho fatto anche io il mio motore per linux. Anche se potrebbe essere compilato per altre piattaforme per lo più (tranne che per alcune parti dell'input e dell'output dato che quelle usavano funzioni specifiche di linux. questo motore era in grado di fare tutte le cose di base, comprese alcune cose extra e il multi threading. tuttavia sembra che io abbia cancellato i miei file, compresi i diagrammi ecc. o li abbia spostati da qualche parte, non lo so. così ho usato alcuni esempi da internet. le immagini mostrate non sono il mio lavoro, ma dovrebbero comunque contenere il link da dove le ho prese.

in generale un motore di gioco più complesso ha solo quelle funzioni di base più sviluppate o più aggiunte. se vuoi vedere come funziona un motore di gioco complesso/avanzato, e conosci abbastanza bene i linguaggi di programmazione (molti motori sono scritti in più lingue) puoi guardare il motore di gioco GODOT Motore di gioco gratuito e open source 2D e 3D

godotengine.org

godotengine/godot

github.com/godotengine/godot

questo è un motore di gioco completo di fascia alta, che non solo è molto più leggero dei motori di gioco generali di fascia alta, ma è anche open source, quindi puoi vedere il codice. anche se se hai intenzione di fare reverse engenear, allora dovresti iniziare a guardare i primi changelog, perché quelli ti mostrano come è iniziato il motore. inizia in piccolo e le cose vengono aggiunte al design modulare. anche blender aveva un motore di gioco opensource incorporato.