Quando dovresti lanciare il tuo motore di gioco? [chiuso]

Sono uno sviluppatore di software da 5 anni e voglio entrare nello sviluppo di giochi iOS. Ho giocato con l'SDK di iOS per circa 2 anni, frequentando le riunioni di Cocoaheads e sento di avere una buona conoscenza di Object-C, Cacao e persino C e C ++.

Ho un'idea di gioco e so che userò Box2D, ma mi chiedo se dovrei usare cocos2D o meno. Le ragioni principali sono:

1. Potrei voler fare cose, per quanto riguarda la grafica, che non sono disponibili in cocos2d.
2. Se lancio il mio motore di gioco, avrò più controllo.

Naturalmente, il motivo principale per l'utilizzo di un motore di gioco già esistente è il tempo che risparmia e rende le cose difficili più facili; ma per qualcuno che ha le braciole tecniche da fare, ha senso?

La maggior parte degli altri post sarà "fare di un gioco non un motore", ma suppongo che tu abbia in mente un gioco particolare che vuoi creare e vuoi sapere quando è una buona idea iniziare con il codice di qualcun altro base o iniziare da zero.

Non dovresti lanciare la tua tecnologia se non sai che devi lanciare la tua . Può sembrare irriverente, ma è davvero l'unica risposta corretta. Come per la maggior parte delle decisioni, ci sono compromessi. Solo tu puoi determinare per la tua situazione particolare l'analisi costi / benefici.

Dovresti avere una comprensione delle seguenti cose (questo elenco è quasi tutto compreso).

• Quale middleware è già là fuori che potresti usare ("motore" o altro)
• Ciò che quel middleware porta sul tavolo, è saggio.
• Quanto è maturo / provato il middleware, soprattutto se ti interessa il supporto multipiattaforma
• Che tipo di strumenti fornisce o non fornisce il middleware per accelerare lo sviluppo (non scartare gli strumenti con la tua tecnologia)
• Quali limiti ha il middleware (come semplice esempio, Unity 3.x non ha fatto ombre in tempo reale da luci dinamiche su iOS)
• Quali caratteristiche specifiche deve avere il tuo gioco in particolare .
• Quali sono le tue scadenze e quanto tempo dovrai dedicare per arrivare al punto in cui ti porterà il middleware rispetto a quanto costa il middleware.
• Quanto è estensibile il middleware (ad esempio, puoi aggirare il problema dell'ombra su iOS in Unity usando le ombre BLOB. O forse le ombre di proiezione.)

(Si noti che non ho specificato "maggiore controllo" lassù. Questa è una frase caricata che potrebbe variare da "Non mi piace il codice che non scrivo" a "Ho bisogno di essere in grado di vedere, capire e ottimizza tutte le variabili nel motore fisico per ottenere questo particolare effetto. "Il primo non è davvero una considerazione valida, ma il secondo è.)

Personalmente, trovo che implementare la tua tecnologia per un gioco a basso budget non valga quasi mai la pena. La quantità di energia che ottieni i motori economici in questi giorni è ridicola. Non sei nel punto in cui stai decidendo di acquistare un motore multimilionario con tripla A o no. Non sarai in grado di battere quello che, per esempio, Unity ti offre per $ 3k. O Cocos2d per qualunque costo (non è gratuito?).

Ora, se il tuo gioco si concentra principalmente su un tipo di tecnologia che altri motori non sono in grado di fornire o che non sono in grado di fornire a un frame rate ragionevole, allora potrebbe valere la pena indagare su cosa puoi fare. Ciò non significa che tu abbia buttato via completamente l'altro middelware. Solo perché hai bisogno del tuo, diciamo, renderer, non significa che non puoi usare qualche altro middleware per la fisica o il suono o l'interfaccia utente o quello che hai.

Non accendere il tuo motore. Lancia il tuo gioco. Se ti capita di scrivere un motore allo stesso tempo, allora va bene per te, in caso contrario puoi sempre refactoring qualsiasi parte che potresti voler riutilizzare per renderlo più "motore" come.

Le persone spesso sopravvalutano ciò che serve per scrivere la parte "motore" di un gioco. Se fai solo ciò di cui hai bisogno, non ci vorrà molto. La parte difficile è non rimanere bloccati nell'infrastruttura di scrittura e scrivere solo ciò che è assolutamente necessario per risolvere il problema.

Vorrei utilizzare un motore esistente quando:

• Ho una scadenza serrata
• Ho un set di funzionalità fisse noto in modo da poter scegliere un motore per quello

Penso che dovresti semplicemente scrivere il tuo gioco e forse finirai con un motore più tardi . Scrivere il motore grafico (che sembra tutto ciò di cui stai parlando) da zero usando nulla ma OpenGL probabilmente ti farà perdere tempo. È un problema relativamente ben risolto, quindi in genere dovresti cambiare la forma dell'API senza aggiungere molto in termini di nuove funzionalità significative rispetto a qualsiasi altra soluzione di terze parti disponibile là fuori.

Se Cocos2D o qualche altro livello grafico soddisfa i tuoi requisiti ora, utilizzalo. Se le tue esigenze cambiano durante lo sviluppo, puoi scambiare il back-end di rendering in modo relativamente semplice - se credi davvero di avere l'esperienza e i mezzi per creare un motore da solo, dovresti certamente avere tutto ciò che serve per strutturare il tuo gioco in modo tale da sostituire il back-end di rendering è un'operazione relativamente banale.

Costruisci il tuo gioco, consenti alle sue esigenze specifiche di guidare il set di funzionalità del codice che scrivi e scrivi il codice con in mente la riusabilità e la buona architettura. Finirai naturalmente con un "motore" dopo aver terminato alcuni progetti come questo e finirai quei progetti più velocemente perché non ti stai impedendo di impantanarti nel creep di funzionalità a livello di framework.

È molto semplice. Qual è il tuo obiettivo principale: apprendimento o time to market?

Evita di usare una biblioteca se il tuo obiettivo principale è imparare dall'esperienza di implementazione dei concetti risolti dalla biblioteca. Ogni volta che sviluppo un gioco (part-time), il mio obiettivo è puramente l'apprendimento. Non mi importa quanto tempo ci vuole, ecco perché sto facendo tutto da zero! Ora decidi tu.

Dovresti avviare il tuo motore di gioco quando sai che ce n'è bisogno .

Ad esempio, supponiamo che tu non abbia i soldi da spendere su Unity. In alternativa, preferiresti spenderlo sul nuovo hardware. Oppure, ci sono problemi di prestazioni con i motori liberi a vostra disposizione, oppure è necessario per avere un maggiore controllo a un livello basso.

Se ami scrivere software per il gusto di scrivere software, allora ti piacerà scrivere un motore di gioco. Una trappola comune dei programmatori di giochi principianti è quella di rimanere intrappolati a scrivere un motore come un progetto perpetuo. Sinceramente credo che sia nato così tutti questi motori di gioco open source - programmatori di giochi che in realtà non lo hanno fatto

Quindi in quel caso, scrivi il tuo motore.