CONSIGLI DA UN AMATORE
// Da zero a dilettante per anni di apprendimento
Starei sicuramente lontano da motori di alto livello come Unity o Torque2D MIT. Sono fantastici per i piccoli prototipi, ma non li prenderei mai sul serio per sviluppare il mio videogioco. Perché dovrei? Qual è il punto a meno che non fosse altro che un semplice remake di SideScroller o Arcade?
La maggior parte dei motori di gioco, delle librerie o dei framework non fanno altro che le attività più semplici con un sacco di codice gonfio con funzioni e caratteristiche che non userete mai.
Quando sono stato nuovo nello sviluppo del gioco anni fa, ho iniziato al top. Motori di altissimo livello. Non niente di troppo alto come RPG MAKER, ma sicuramente alto come Unity e Torque. Poi sono andato più in basso, a XNA e C #, perché aveva così tante risorse e tutorial. Il mio progetto principale aveva bisogno delle prestazioni, o forse sono solo ossessivo-compulsivo nel desiderare prestazioni incredibili nel mio software, anche se non è un grande progetto. XNA semplicemente non lo ha tagliato, e ho avuto molti problemi con il motore che ho letto che avevo bisogno di mal di testa da risolvere. Qual è lo scopo di usare qualcosa di "livello superiore" come XNA / C # quando stai facendo lo stesso lavoro (correggendo bug e problemi XNA) come faresti con il tuo motore in C ++?
Dopo un po 'di apprendimento, alla fine ho appreso come sono progettati i motori di gioco e ho iniziato a esaminare il codice dei motori stessi. Leggendo ciò che la maggior parte dei professionisti ha da dire e le lamentele dei critici dei motori di gioco mi hanno fatto capire: "Perché anche usare un motore?"
Aggiornare il mio C ++ e approfondire alcune filosofie usate in quel linguaggio mi ha aiutato molto. Tuttavia, avevo trascorso così tanto tempo a imparare così tanto che volevo solo iniziare a fare un gioco.
Così ho finito con qualcosa di molto elogiato, era C ++ e livello molto basso: SDL. Sfortunatamente, questo era un mal di testa. È un livello così basso, non vedo quasi alcun motivo per cui utilizzare questa libreria. Preferirei semplicemente imparare OpenGL e farlo da solo. Onestamente, era soprattutto il fatto che avevo bisogno di implementare il mio codice per fare qualcosa di semplice come capovolgere un'immagine (e l'implementazione di altri non funzionava a causa del modo in cui gestivo gli sprite) che mi ha spinto a eliminare definitivamente SDL. È fantastico se vuoi un renderer software, ma IMO preferirei che il cestino andasse più in basso con l'hardware (OpenGL) o superiore (SFML).
Non volendo comprare un altro libro su Amazon e imparare ancora un'altra API, sono andato più in alto. SFML è semplicemente meraviglioso, per non parlare dell'elogiato su Internet. Ho letto quasi un numero infinito di recensioni positive, quasi senza aspetti negativi. Non posso dire lo stesso per SDL. Gestisce tutte le basi estreme, ma lascia il resto a me e alle altre librerie di mia scelta. Da allora mi sono bloccato.
IMO, un motore di gioco è semplicemente stupido. Le librerie di basso livello sono scelte molto migliori sia per i programmatori esperti che per i principianti.
Inoltre, ho imparato di più sui concetti di programmazione e ho affinato le mie capacità di sviluppo software quando sono stato costretto a gestire le cose a un livello inferiore rispetto a quanto abbia mai appreso con i motori di gioco WYSIWYG di alto livello.
Cosa ti dà qualcosa come Unity su XNA? Elaborazione visiva e stampella. I principianti alla fine impareranno che dovrai comunque programmare praticamente l'intero gioco proprio come faresti se avessi il C ++ nudo e gli editor visivi sono inefficienti rispetto a qualcosa che potresti creare tu stesso.
Cosa ti offre qualcosa come XNA su SFML o la tua implementazione di OpenGL e altre utili librerie? IMO, assolutamente niente di buono. Prestazioni peggiori, C # invece di C ++, una pletora di tutorial per principianti ma significativamente meno professionalità, e alcuni risparmiatori di mal di testa che IMO sono ancora una volta una stampella per quello che dovresti semplicemente imparare con C ++. Inizialmente sono stato intimidito dal C ++ e ho adorato il C #, principalmente a causa di sentenze e voci sulle opinioni degli sciocchi che avevano gli stessi problemi che avevo inizialmente con il C ++: volevo solo un programmatore abbastanza bravo. Mi sono reso conto che avevo bisogno di imparare più fondamenti e di affinare le mie debolezze per superare i problemi che avevo con C ++, che C # "rendeva facile". Mi manca mai la semplicità di alcune cose in C #? Nemmeno! So come farlo in C ++ senza problemi.
Se le librerie di basso livello o l'apprendimento di DirectX / OpenGL ti intimidiscono, allora aspetta solo di iniziare a entrare nella complessità della creazione di un videogioco completo.
La mia filosofia sui motori di gioco può essere riassunta in due esempi che spiegano la ridondanza e l'inutilità dei motori, tranne in circostanze isolate.
I neofiti che sono intimiditi con librerie di basso livello, avranno un attacco quando scoprono che anche con un motore di alto livello come Unity (oltre a rendering grafico, riproduzione audio, caricamento di contenuti; cose di base reali) sarà quasi identico a fare un gioco da zero. La complessità sta nell'ingegnerizzare un gioco, non capire l'API o sviluppare le classi per renderizzarle sul display.
Gli esperti che non sono intimiditi dalla complessità della creazione di un gioco completo in qualcosa come Unity, non servono a Unity perché il tempo impiegato per apprendere con fiducia l'API e i requisiti di un motore specifico è probabilmente più un mal di testa e più tempo di quanto sarebbe necessario per codificare le poche classi richieste per eseguire le basi.
Quindi i motori sono inutili per i neofiti, perché i neofiti non possono fare nulla con loro perché mancano delle capacità ingegneristiche. Allo stesso modo, i motori sono inutili per i veterani, perché hanno già le capacità ingegneristiche per farlo senza un motore e potrebbero anche lanciare il proprio 'motore' più efficiente e specifico che passare attraverso il mal di testa dell'apprendimento di entrambe le API del motore di gioco, funzioni e stranezze delle prestazioni. Per non parlare del grande incubo di lavorare con motori che a volte non riesci a toccare perché non sono open source (o anche se lo sono, leggere il codice di altri può essere un incubo a volte).
Diamine, anche alcuni "framework di gioco" di "basso livello" non sono altro che alcune classi per creare una finestra, renderizzare il display e riprodurre l'audio. Questo è qualcosa che un professionista può fare da solo usando altre librerie come SDL / SFML o la propria implementazione di OpenGL / DirectX / OpenAL, in una frazione del tempo necessario per completare effettivamente un videogioco completo.
TLDR;
Se vuoi programmare, impara ad essere un programmatore .
Evita di usare i motori , ma non essere sciocco e ignora le librerie incredibilmente utili.
Se vuoi essere un Game Designer , prova un motore WYSIWYG e fai uscire quei giochi!
Se vuoi essere un programmatore di giochi , evita i motori come la stampella che sono.
Per me , l'utilizzo di motori di gioco di livello superiore ha paralizzato la mia capacità di diventare programmatore. Nel momento in cui ho iniziato a utilizzare librerie di livello inferiore o non utilizzare alcuna libreria, ho iniziato a imparare così tanto che sono passato rapidamente da un principiante totale a qualcuno che ora può creare videogiochi senza riferimenti, tutorial o libri al mio fianco. Solo il mio compilatore e molta ingegneria e pratica.
La quantità di apprendimento che ho acquisito da biblioteche di basso livello in un breve lasso di tempo è stata molto maggiore della quantità che ho guadagnato in un tempo MOLTO LUNGO con MOTORI di livello superiore. **