Perché uno sviluppatore di giochi dovrebbe scrivere il proprio motore invece di utilizzare quelli esistenti?

Ho osservato che molti sviluppatori di giochi grandi e famosi spesso sviluppano i propri motori. Esempi includono Valve, Crytek, Ubisoft, Epic Games e Square-Enix.

Potrebbe semplicemente essere perché possono, o è probabile che i motori esistenti non soddisfino abbastanza requisiti, quindi svilupperemmo i nostri? Riesco a malapena a immaginare un gioco che richiede un motore specifico. Simili a Unity o Unreal sono semplicemente sufficienti per realizzare qualsiasi tipo di gioco; anche se non lo sono, hanno il codice sorgente, che può essere modificato per soddisfare anche alcune esigenze straordinarie.

Perché uno sviluppatore di giochi dovrebbe scrivere il proprio motore invece di utilizzare quelli esistenti?

Esistono diversi motivi per cui uno studio può scegliere di "costruire" invece di "acquistare" la propria tecnologia:

• Tecnologia legacy; uno studio potrebbe aver iniziato a costruire la propria toolchain prima che esistesse un middleware esistente per esso.
• Requisiti specifici; uno studio può avere una particolare raccolta di requisiti che non è adatta al middleware esistente o
• Preoccupazioni di bilancio; uno studio potrebbe non essere in grado di sostenere le spese o gli obblighi contrattuali del middleware esistente.
• "Non costruita qui sindrome;" la leadership tecnica degli studi potrebbe essere cauta (ragionevolmente o irragionevolmente) nei confronti della tecnologia che non hanno costruito e quindi non comprendono completamente.

In generale, ha senso possedere e controllare le cose fondamentali per il successo della tua attività e esternalizzare quelle che non lo sono.

Per alcuni studi, l'aspetto del design o della narrazione dei loro giochi potrebbe essere la risorsa fondamentale che si aspettano di capitalizzare per il successo. Per quegli studi, ha senso semplicemente acquistare la tecnologia che permetterà ai loro progettisti di realizzare la visione appropriata.

Per altri, la tecnologia può essere la base per il successo. Gli studi che creano MMO, ad esempio, dovranno generalmente costruire tale infrastruttura da soli perché è fondamentale per il loro successo (e il middleware esistente è generalmente inappropriato, almeno per titoli più grandi, "AAA").

Nota che alcuni degli studi che hai elencato (Crytek ed Epic in particolare) hanno praticamente smesso di provare a dominare direttamente le forze nel mercato dei giochi, e quasi sicuramente fanno molto di più come venditori di middleware che come sviluppatori di giochi.

come detto da Josh Petrie :

" Non costruita qui sindrome ;"

Sto anche scrivendo il mio motore, e suppongo che la ragione sarà diversa per ogni sviluppatore là fuori, ma in realtà - in genere non mi piace lavorare nel codice di altre persone. Sono compulsivo, nel senso che se sento di poterlo costruire da solo, allora non ha senso accontentarsi di qualcos'altro .

Ho testato vari tipi di motori di gioco, rendering API e simili, in particolare Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, ecc. Molti altri ... Volevo iniziare a scrivere giochi - Ho scaricato molto cercando un buon confort e punto di ingresso ben documentato ...

Il mio problema, tuttavia, era al momento in cui non avevo idea di cosa stesse succedendo sotto il motore. Volevo un buon controllo e volevo un quadro che conosco come il palmo della mia mano. Mi è venuta l'idea "HEY! Penso che l'unico modo per imparare come funziona e capire è provare a costruire il mio motore interamente e completamente da zero. La maggior parte della mia storia di programmazione era con soluzioni Web ed elaborazione - per me è stato un gioco di palla completamente nuovo.

È quello che ho finito per fare.

Quindi ho scelto di configurare XNA poiché conoscevo già C # e ho iniziato a pensare a come o dove avrei dovuto iniziare. Avevo bisogno di un'idea.

Ho deciso che, in ogni caso, sarei passato direttamente al 3D .

Abbattere le nozioni di base è stato bello - la roba batch di sprite, ma mentre progredivo ho scoperto nuove barriere e ostacoli - il mio primo vero è stato il limite batch . Il mio obiettivo era quello di costruire un gioco che potesse rendere in qualsiasi momento almeno 10000 entità nel frustum della vista.

Ho intrapreso un nuovo viaggio nell'implementazione di Shader Based Instancing (e ho imparato HLSL mentre ero lì), ho abbandonato gli oggetti Model ed Effect incorporati di XNA per scrivere invece i miei sostituti. Inizialmente ho avuto difficoltà a comprendere i flussi VBO; Ho rotto le cose - sono andato online facendo domande sull'istanza e ho continuato fino a quando ho finalmente capito cosa stava facendo la GPU. Ha pagato; ora avevo oltre ventimila entità di test che si ingrandivano nel mio viewport dopo un paio di giorni di debug del mio VBO con PIX (dxsdk).

Ora avevo "qualche" idea di come funzionavano le pipeline di rendering, ma non avevo ancora finito - ho finito per creare il mio stato di gioco, camera, effetti post e oggetti entità, allontanandomi dalla pipeline di contenuti XNA costruendo la mia caricatori (avversione personale verso la cosa XNB), ha creato una complessa catena di geometria ordinata in profondità e separata dallo stato di fusione e ha anche istinto sprite e testo proiettati nella scena di gioco.

Ho continuato ad aggiungere, aggiustare, cambiare e sperimentare continuamente questo per quasi un anno intero. Alla fine, è uscito abbastanza bene. Ora ho capito cosa sta succedendo sotto il cofano, perché l'ho creato - il mio bambino.

Ora il mio motore era per lo più stabile e quasi finito. Non è perfetto: lo scripting è noioso e la GUI non è stata affatto eccezionale. Ma l'ho ancora amato. Migliaia di righe di codice, risorse e media - racchiuse in un repository git privato da 2 GB e tutti i mal di testa che ho dovuto affrontare cercando di fare un tipo di sviluppo che non avevo mai fatto prima. Ogni ostacolo che ho superato è stata una lezione appresa e un sollievo.

Ho realizzato quasi tutto ciò che volevo.

Ma alla fine - ho deciso che era tempo di metterla giù. Per quanto mi accontenti di scrivere un motore così grande da solo, con i consigli della rete e altri amici di Gamingev, ho deciso che lo farò di nuovo tutto da capo - e lo farò meglio - perché ora questa volta lo so per lo più cosa sto facendo.

Quel progetto è ancora nascosto nel mio repository GIT.

Il mio secondo passaggio nello scrivere un nuovo motore (questa volta su MonoGame) sta procedendo bene. Quando qualcosa si rompe, è più facile da risolvere. Meno confusione. Spero di mostrare pubblicamente il mio gioco quest'anno, perché tendo ad essere un po '"troppo" attaccato al mio codice.

Alla fine, scrivendo il mio motore è come ho imparato "come" farlo, pur potendo dire che conosco e capisco esattamente cosa fa ogni componente e come dovrebbero funzionare. In realtà odio leggere il codice di altre persone, specialmente per grandi progetti non documentati. Voglio che tutto ciò che uso sia costruito da me.

Questo sono solo io però. Dubito che userò mai un motore prefabbricato, probabilmente perché penso che sia solo più divertente per me scrivere i miei framework piuttosto che sedermi e gestire il codice di qualcun altro - il pieno controllo.

Il motivo chiave assoluto per scrivere il tuo motore (e mi sorprende che nessuno lo abbia ancora chiamato) è per il debug .

Se hai scritto un gioco grande e complicato, e c'è un bug di crash in esso, e hai il codice sorgente (e hai intimamente familiarità con quel codice sorgente in virtù di averlo scritto), allora puoi semplicemente collegare un debugger a il processo e trova la causa dell'arresto anomalo. Fatto.

Se stai usando il motore disponibile in commercio di qualcun altro e non hai il codice sorgente per quel motore (normalmente non lo fai), allora il debug di eventuali problemi che si presentano - anche all'interno del tuo codice - sta andando essere monumentalmente più difficile. E se incontri un bug all'interno del motore stesso, non sarai in grado di risolverli da solo. Ti piacerebbe essere a una settimana dalla data di uscita e chiedere a qualcuno di scoprire un bug di crash nel motore che stai utilizzando, un bug di crash che non puoi correggere perché è all'interno di un motore proprietario a cui non hai il codice sorgente? L'ho visto accadere: non hai altra scelta che presentare una richiesta di assistenza urgente al venditore e spero che possano (e sono interessati a) risolvere il problema per te, mentre ti scarabocchi intorno,

Lo sviluppo del gioco è difficile, ma il debug è più difficile per ordini di grandezza. Nel mio libro, tutto ciò che rende più difficile lo sviluppo del gioco ma che facilita il debug è un'enorme vittoria netta.

Ci sono ottime risposte qui ma mancano un importante punto aggiuntivo.

Molti dei motori con licenza di oggi sono nati come motori dedicati .

Prendiamo Unreal come esempio perché è così onnipresente.

Oggi quando pensi a Unreal tendi a pensare a un motore che sei in licenza e che puoi usare invece di dover costruire il tuo, ma non è sempre stato così, e una volta il motore Unreal non esisteva nemmeno come un'entità separata.

C'era una volta un gioco chiamato Unreal . Gli sviluppatori di esso hanno deciso di costruire il proprio motore anziché concederne uno esistente . Avanzamento rapido attraverso diverse iterazioni e quel motore diventa il motore Unreal che conosciamo oggi.

Il punto è che si tratta di un problema con galline e uova. Ogni pezzo di middleware che puoi ottenere in licenza è iniziato da qualche parte, e spesso non è nato come middleware (a volte non è stato nemmeno scritto con l' intenzione di diventare middleware e il suo stato attuale è effettivamente un incidente ). Le persone scrivono i propri motori perché alla fine qualcuno deve scrivere il motore e il motore dedicato di oggi potrebbe diventare un middleware con licenza di domani.

Ci sono altri motivi per cui uno studio può scegliere di "costruire" invece di "acquistare" la propria tecnologia:

• Nuove piattaforme : nuovo sistema operativo mobile, console o controller. Pensa a leapmotion, google glass, ecc. Il supporto multipiattaforma è difficile
• Nuove meccaniche di gioco e / o editor di gioco : pensa a FEZ, alcuni anni fa (2D vs 3D)
• Mancanza di buoni editor di giochi open source gratuiti . Mancanza di una buona documentazione sulla fonte esistente di vecchi giochi
• Evoluzione degli strumenti nella toolchain di studio (o aggiungine di nuovi)
• Prezzi del motore e guerre di licenza

Concordo anche con richieste / esigenze specifiche e prezzi dei motori e guerre di licenza costringono alcuni studi a lanciare alcuni motori.

I buoni motivi per "comprare" o "usare" altri motori sono:

• Riutilizzo del codice : un motore già utilizzato in altri giochi è più testato, più stabile e può avere la maggior parte delle funzionalità necessarie, a partire dal primo giorno.
• Estendi : puoi estendere alcuni motori open source.
• Gratuito : o quasi gratuito, dal momento che anche i motori open source gratuiti, hanno bisogno di un po 'di tempo per gli sviluppatori per imparare.

Motivo storico (principalmente).
Che è legato al prezzo.

Ogni gioco che hai visto con Unreal o CryEngine negli ultimi anni ha dovuto pagare un'enorme quantità di denaro. Soprattutto se vuoi ottenere il codice sorgente (es .: volevi UE, non solo UDK.)

Ma questo è cambiato. Ora tutti possono permettersi motori ancora più grandi, con l'inizio della corsa ai prezzi.
Cosa significa...

• Vedrai molti più giochi usando sia UE4 che CryEngine.
  Tuttavia, non saranno giochi AAA come sono stati.
• I requisiti e le esigenze personalizzati per ciascun progetto non andranno via.
  Guarda il motore Warhammer40k / COH su Relic o quello usato dai generali su EA.
  Quindi, anche se chiunque può permettersi i motori più grandi, non offre necessariamente una scelta migliore.
• Ce ne sono altri sul mercato. Come unità.
  La gente lo adora per la sua facilità d'uso, prestazioni veloci e l'enorme negozio di risorse.
  Naturalmente, Unity è in grado di implementare su quasi tutte le piattaforme.

Quindi si Bisogni, prezzi in passato e così via.

E l'organizzazione del team?

Dietro le cose di debug ci sono la documentazione e il supporto, non il codice, perché alla fine non volevo che il mio gruppo di costruzione toccasse il codice del mio motore. Potrebbe essere un casino.

Quindi, ho bisogno di un gruppo di supporto per farlo. Ma questo aumenta i costi: più persone, più posti, più telefono, più amministrazione ...

Una soluzione a questo potrebbe essere quella di esternalizzare ... a un'azienda di middleware, rilasciando risorse per la mia attività di creazione di giochi, ovvero per il gruppo creativo e gli scrittori.

Per un'azienda in fase di avvio non è una cattiva opzione da usare e non costruire. E, dopo aver ottenuto una massa critica di entrate, potrebbe essere, proprio così, vorrai costruire il tuo motore ...

bene. per la maggior parte dei giochi che utilizzano il proprio motore creato dai loro sviluppatori. spesso. non possono fare cose con un motore di terze parti. così si fanno i propri per rendere più semplice lo sviluppo del proprio gioco. o almeno possibile.

e molti giochi che usano il proprio motore in generale. lavorare meglio. perché sono più personalizzati e adatti al 100% al loro compito. e il gioco stesso si sente diversamente. è davvero facile giocare e dire che è fatto da. motore irreale o altro. più motore personalizzato in generale e dovrebbe risultare in un gioco unico. sembra unico e funziona in modo univoco e dovrebbe funzionare meglio di un gioco creato su un motore prefabbricato.

La mia risposta differisce da quelle esistenti, quindi la aggiungo anche se è tardi:

Se prendi l'esempio Valve dalla domanda, o la serie Witcher, il processo era:

• Licenza di un motore
• Modifica / adatta il motore al tuo scopo
• Rilascia il gioco e genera denaro
• Crea il tuo motore per il prossimo gioco

Lo stesso approccio è adottato da quasi tutti gli sviluppatori finanziariamente ragionevoli che sviluppano il proprio motore. Modificando un motore, acquisiscono la conoscenza di come funziona un motore e si imbattono in vincoli di progettazione derivanti da un motore con licenza. Alla fine hanno le conoscenze interne necessarie per creare un motore, i soldi per finanziare la creazione di un motore e un progetto che beneficerà di un motore dedicato. A quel punto la ragione per costruire un motore è: perché è la cosa intelligente da fare.

il mio insegnante di programmazione ci ha detto di usare solo API / metodi / classi / funzioni che sai come costruire

perché se non sai come costruirlo e stai usando le possibilità lavorative di qualcun altro, non sai come funziona e quando non sai come funziona qualcosa, allora sei molto più incline a errori e problemi e colpendo muri di confusione

l'apprendimento di cose semplici può comportare strani problemi, per non parlare di qualcosa di complesso come un motore di gioco, specialmente quando si suppone che utilizzi quel motore di gioco per far funzionare il tuo gioco, il che può portare a molti risultati e problemi inaspettati

e il motore di gioco non segue il codice logico o qualsiasi altra logica quando viene costruito, certo che ci sono alcune cose che ci si può aspettare, ma in realtà tutto sarà costruito sulla base della comprensione e conoscenza di qualcun altro del linguaggio di programmazione o di come funziona un sistema

per esempio, se scelgo di scrivere un'equazione matematica, posso scriverla in tanti modi in cui posso rappresentarla con polinomi, o calcolo differenziale o geometria di base o algebra o qualunque cosa mi piaccia, ma a volte scrivo in una certa forma / formato perché voglio per essere in grado di manipolare ciò che è facilmente disponibile, come se avessi pianificato di fare molta manipolazione del vertice, potrei scrivere questo modello matematico usando la geometria di base, tuttavia se volessi cambiare la curva usando i gradienti potrei concentrarmi sul calcolo differenziale per essere in grado per manipolare facilmente i gradienti ecc. e lo stesso vale per qualunque cosa io abbia intenzione di avere un accesso più facile

e a volte l'attuale motore di gioco potrebbe non darmi la flessibilità di ciò che intendo fare o forse ti dà quell'opzione, ma è molto difficile farlo perché il motore di gioco si concentra sulle forze fisiche come principale fonte di movimento e manipolazione di oggetti nel gioco

comunque spero di aver chiarito cosa stavo cercando di sottolineare