Se stai parlando da molto all'inizio, e nota che pochissimi motori di gioco principali sono codificate da zero più, e si noti che questo è un esempio e non necessariamente come funziona sempre. . .
Rendering:
Inizia con il rendering di un cubo con ombreggiatura piatta. Aggiungi effetti di illuminazione di base ad esso. Aggiungi un modo per spostare la videocamera. Ora puoi volare intorno a un cubo noioso, sospeso in un vuoto nero infinito. Sìì.
Successivamente, probabilmente vorrai importare un modello. Per lo meno, il tuo artista può montare un modello demo (una teiera è sorprendentemente tradizionale), ma possono avere un modello di gioco reale che possono consegnarti. Ancora una volta, per ora restiamo con un'ombreggiatura piatta, quindi apparirà come se fosse fatto. . . beh, nessuna sostanza realistica, ma una specie di incrocio tra plastica opaca e porcellana. Questo , ma senza una buona illuminazione. E siamo ancora al punto in cui è completamente immobile.
I prossimi tre passaggi principali possono essere eseguiti in qualsiasi ordine.
Innanzitutto, vorrai il terreno. La maggior parte dei giochi moderni divide il rendering in "geometria statica" e "attori", dove la geometria statica include cose che non cambiano (muri, terra, lampioni) e gli attori includono cose che cambiano (giocatori, veicoli, lampioni distruttibili). il concetto di rendering di base è lo stesso per entrambi, ci sono ottimizzazioni che puoi fare per la geometria statica che non puoi fare per gli attori. Avrai bisogno di terreno per gli ingegneri del gioco per andare davvero avanti, quindi se ti stanno aspettando, è tempo di attrezzare almeno il rendering di base del terreno.
In secondo luogo, vorrai texturing. Questo è un argomento enorme e ci sono possibilità che tu raggiunga una pietra miliare, che farai qualcos'altro più critico, per poi tornare su di esso, ripetutamente. Il tuo primo passaggio può semplicemente aggiungere trame al modello. Il tuo secondo passaggio potrebbe aggiungere un miglioramento dell'illuminazione e del comportamento della superficie. Il tuo terzo passaggio può aggiungere ombre (potrei riempire un'intera risposta parlando di ombre). A seconda del tipo di gioco che stai facendo, questo può diventare arbitrariamente complicato. Da qualche parte qui puoi anche passare l'intero motore di gioco al rendering differito.
Terzo, vorrai l'animazione. I tuoi animatori (supponendo che tu non stia vivendo nel 1995) avranno installato impianti di animazione per i loro modelli, costituiti da ossa che attraversano il modello e informazioni su come si muovono le ossa durante determinate animazioni. Probabilmente inizierai con la possibilità di riprodurre animazioni su richiesta, quindi aggiungi la possibilità di mescolare le animazioni insieme.
Una volta fatto tutto ciò, è tempo di lavorare sulla compatibilità. Se stai lavorando a un gioco AAA, hai un modo per testare il tuo codice su molti diversi tipi di hardware - forse è interno, forse ti rivolgi a una società di test, qualunque cosa. Gran parte del codice si romperà su specifiche schede grafiche o specifiche versioni di driver e riuscirai a risolverne il maggior numero possibile.
È anche tempo di considerare l'ottimizzazione. Il rendering è un grosso problema di velocità, quindi ora devi capire come sfruttare l'hardware al livello più profondo per eseguire il più velocemente possibile. Se pensi che ciò possa essere in conflitto con la "compatibilità", hai ragione! Lo fa totalmente! Le migliori ottimizzazioni, troverai, semplicemente non funzioneranno su alcune carte. Devi bilanciare tutti questi fattori.
A questo punto, i tuoi artisti richiederanno nuovi strumenti di texturing o nuove funzionalità di animazione e i tuoi progettisti di livelli vorranno nuove tecniche di rendering del terreno. Torna a "i prossimi tre passaggi principali possono essere eseguiti in qualsiasi ordine" e ripeti fino al termine del gioco.
gameplay:
Salterò le parti che non sono tremendamente visibili visivamente. Per prima cosa, devi aspettare fino a quando non è presente il rendering del terreno, anche se ci sono molte cose di backend che puoi fare fino ad allora.
Una volta che hai capito, imposterai alcune collisioni di base. Questo probabilmente prenderà la forma di volare in una posizione nel gioco, quindi premere un pulsante che fa cadere un cubo. Il cubo cade e colpisce il terreno. Una volta che il cubo atterra costantemente a terra, puoi iniziare a impostare il movimento del giocatore, in modo da poter correre in tutto il mondo come fa un giocatore.
Una volta che la fisica del movimento di base funziona, ti trovi di nuovo in uno di quei segmenti "questi possono essere fatti contemporaneamente":
Il combattimento deve essere implementato. Hai bisogno di cose che possano sparare alle cose e tutte quelle cose devono comportarsi in modo appropriato.
La fisica deve essere implementata. Le collisioni funzionano, ma le collisioni sono solo un piccolo segmento della fisica. Quando qualcuno fa salire una jeep da un serbatoio, tutto deve comportarsi all'incirca come previsto.
Le meccaniche di gioco devono essere implementate. Come fai a sapere quando hai vinto o perso? Con quale frequenza si generano le cose e cosa le controlla? Se i comunisti conquistano un punto di spawn, perché continua a generare veicoli anarchici? Questo genere di cose.
Tutto ciò può richiedere, di nuovo, tempo arbitrario, in base a quante cose i tuoi designer vogliono che tu faccia. Trascorrerai anche un sacco di tempo a rintracciare i bug ("hey, guarda cosa succede quando guido un carro armato sull'ala di questo caccia da combattimento"). Si noti che molto di questo accadrà con un mondo non strutturato, o con modelli che corrono nella posizione di rig del personaggio , o con carri armati che sono solo grandi scatole con la parola "SERBATOIO" goffamente sverniciata.
UI:
L'interfaccia utente può effettivamente iniziare prima che entri il codice di rendering principale, poiché l'interfaccia utente e il rendering del mondo di gioco tendono a utilizzare codepati totalmente diversi. Invece di iniziare con un cubo, inizierai con una casella, quindi aggiungi trame alla casella, quindi aggiungi testo alla casella.
A questo punto, la tua vita viene spesa cercando di ottenere abbastanza tempo per scrivere widget per scopi generici, pur continuando a dedicare abbastanza tempo all'interfaccia utente che i progettisti e gli sviluppatori della meccanica di gioco possano testare il gioco in una vaga parvenza di realismo. Ad un certo punto i tuoi artisti dell'interfaccia utente avranno un'idea coerente dell'interfaccia utente, quindi inizierai a lavorare sugli elementi dell'interfaccia utente finalizzati, mentre testerai quegli elementi dell'interfaccia utente su giocatori reali per assicurarti che siano comprensibili e utilizzabili.
Posso parlarne di più secondo necessità, ma se lo faccio diventerà una risposta megare, quindi per ora non lo farò :)