Cosa devo considerare quando valuto le librerie, i motori e i framework per creare un gioco?


10

Ho intenzione di fare un gioco. Ho notato che ci sono molti motori di gioco, librerie e framework disponibili là fuori, e ho qualche problema a decidere quale usare.

Sono già abbastanza bravo con alcuni linguaggi di programmazione, ma ce ne sono altri che non conosco affatto. Non sono contrario all'apprendimento di nuovi linguaggi di programmazione, se ciò può aiutare, ma il mio vero obiettivo è solo quello di creare il mio gioco.

Quali criteri dovrei usare per confrontare motori, librerie e framework l'uno con l'altro, così da poter decidere quale mi permetterà di essere il più produttivo per finire il mio gioco?


11
Per quello che vale, uso un approccio in due fasi: (1) sceglierne uno arbitrariamente; (2) deplorare la decisione in seguito. Il vantaggio è che ti fa superare rapidamente il primo passo.
Cameron Fredman,

2
Non dovrebbe essere una domanda Wiki della community?
Marton,

Sono contento che questo sia trasformato in una domanda Wiki della community, ma non ho opzioni disponibili per farlo. Immagino che CW sulle domande sia una cosa solo moderatore, oggigiorno.
Trevor Powell,

@Marton Perché pensi che dovrebbe essere un CW?
MichaelHouse

1
@ Byte56 Perché questa domanda sorge sempre, quando qualcuno vuole iniziare lo sviluppo del gioco. Ci sono già molti framework / motori là fuori e una voce Wiki "cosa da considerare" così generica sarebbe davvero utile. Penso che risponderebbe a molte domande "quale motore dovrei usare" che appariranno su questo sito. Quest'ultima frase in realtà renderebbe tali domande "non costruttive".
Marton,

Risposte:


14

È un po 'come scegliere una macchina o un computer. O praticamente tutto ciò che ha caratteristiche assortite, alcune delle quali ti interessano molto, altre non ti dispiace e altre che potresti non voler includere.

  1. Fai un elenco delle funzionalità che ti interessano. Ad esempio supporto 2D / 3D, illuminazione, fisica, usa un linguaggio che conosci bene, ecc.
  2. Classificali in base all'importanza per te, in base al tuo progetto attuale.
  3. Cerca le tue opzioni e, per ciascuna opzione, cerca di classificare le loro caratteristiche di supporto in base al grado di allineamento con gli obiettivi del tuo progetto.
  4. Usa quello più adatto ai tuoi obiettivi. In alternativa puoi selezionare i primi e dare loro un test drive. Implementa alcune semplici funzionalità del tuo gioco e vedi quale ti piace di più.

Penso che molto di tutto questo si riduce a sapere davvero cosa vuoi. Ciò significa che dovrai avere una buona idea del gioco che stai realizzando. Il che probabilmente significa che avrai bisogno di un piano abbastanza dettagliato su come implementare il tuo gioco e su cosa includerà. Come bonus, avere tutte queste informazioni dettagliate ti aiuterà a completare il tuo gioco. È molto più facile seguire un piano e controllare le cose da un elenco piuttosto che avere un'idea per un gioco e iniziare a scrivere codice.


3

Per prima cosa dovresti avere almeno un'idea approssimativa di quale sarà il tuo gioco e di cosa avrà bisogno. Ci sono le solite domande come se il tuo gioco avrà bisogno o meno di fisica. Poi ci sono le domande correlate, che riguardano principalmente l'ambiente in cui il tuo gioco verrà sviluppato e funzionante e quanto commerciale sia o meno il tuo gioco.

  • Quali piattaforme supporterai? Su quale piattaforma stai sviluppando il tuo gioco?
  • In quali linguaggi di programmazione intendi implementare il tuo gioco?
    • Ciò è influenzato dalle piattaforme che intendi supportare.
  • Che tipo di grafica, audio e input avrà il tuo gioco?
  • Il tuo gioco è freeware o open source o è commerciale?
    • Se open source, vorrai diventare commerciale in seguito, con il tuo gioco o con un altro gioco che utilizza il motore del tuo primo gioco?

Se hai intenzione di utilizzare solo Windows, le librerie basate su DirectX e C # sono candidati validi. Se vuoi essere multipiattaforma, allora dovresti guardare le librerie basate su OpenGL e C / C ++ o Flash se il tuo gioco è in 2D e puoi permetterti gli strumenti di Adobe. Come la tua piattaforma, il tuo linguaggio di programmazione influenzerà le tue librerie disponibili. Un programma scritto in C ++ avrà difficoltà a chiamare una libreria Java.

Se il tuo gioco è commerciale, puoi prendere in considerazione l'acquisto di un motore come Unity. Se il tuo gioco è freeware o open source, ti consigliamo di concentrarti su librerie che sono anche open source, o almeno gratuite per progetti non commerciali. Naturalmente anche le biblioteche open source sono utili ai progetti commerciali. Quando guardi le librerie open source assicurati di controllare la loro licenza. Alcune licenze richiedono di rendere open source parti del proprio software a seconda di come si utilizza una libreria. Limitare te stesso alle librerie open source porrà ovviamente un altro limite su quali librerie puoi usare.

Quando guardi una biblioteca, assicurati di verificare quanto sia attivo il suo sviluppo e la sua comunità. Mi fiderei di una biblioteca ben nota e attivamente gestita da più di una ospitata sulla pagina web dell'università di qualcuno che non è stata aggiornata dal 1999.

Un'ultima domanda, specialmente se questo non è il tuo primo progetto di gioco, è se ci sono aspetti del tuo gioco che ti serviranno per sapere che dovrai lottare se provi a farlo da solo. Perché questi aspetti in particolare sono candidati per la ricerca di una biblioteca. Se il tuo gioco ha bisogno del rilevamento delle collisioni e sai che non puoi implementare tu stesso il rilevamento delle collisioni (come io non posso), prendi in considerazione la raccolta di un motore fisico e sfrutta le funzionalità di rilevamento delle collisioni al suo interno.


1
  • La biblioteca fa quello che ti serve?
  • È specializzato per fare ciò di cui hai bisogno? Quanto disordine è attaccato ad esso?
  • Come è progettato? Vuoi vomitare quando lo vedi? Se sì, allora probabilmente non è la scelta migliore per la tua salute e sanità mentale.
  • È abbastanza flessibile per le tue esigenze? Non è bene notare che la libreria non funziona dopo che hai già scritto metà del codice con esso.
  • Quanto è futura la biblioteca? Lo sviluppatore sta aggiungendo funzionalità nel tempo? Sta aggiustando le cose? Sta migliorando le cose? Questo può fare la differenza se è probabile che lo sviluppo del tuo gioco stia prendendo alcuni anni. Non così importante per i piccoli progetti che uscirai tra un mese.
  • La dimensione è appropriata? Per i piccoli progetti può fare una grande differenza se il giocatore deve scaricare 20 MB o 200 MB. I progetti più grandi sono probabilmente abbastanza grandi che la dimensione del middleware fa poca differenza.

1

Oltre alle funzionalità specifiche del gioco che le persone hanno commentato, dovresti anche considerare alcune domande generali.

  1. struttura di supporto - anche se il motore di gioco è perfetto, forse il supporto è troppo costoso o inesistente.
  2. quanto è facile imparare - potresti non voler qualcosa di troppo grande, poiché il tempo per imparare potrebbe essere proibitivo.
  3. copre i tuoi piani futuri - potresti non voler investire tempo nell'apprendimento di un motore perfetto per ora, ma solo per riapprendere da zero un nuovo motore per il prossimo progetto. O forse lo vuoi.
  4. licenza - se stai realizzando un gioco a codice chiuso, assicurati che la licenza del motore non lo apra.

0

Un breve cheat sheet per valutare librerie, framework, motori e SDK e scegliere il meglio

  • Le librerie, i framework, i motori SDK e così via sono strumenti che hanno lo scopo di risolvere i problemi per te o di aiutarti a risolvere i problemi e soddisfare determinati requisiti.
  • Valutare significa capire quale soddisfa i requisiti più elevati.

Pertanto, prima ancora di iniziare a valutare, è necessario essere chiari in quale scenario ci si trova e quali requisiti si hanno / si desidera avere perché queste sono le domande alle quali dovrebbe rispondere la valutazione.

Lo scenario definisce la provenienza dei requisiti (chi decide cosa è un requisito e cosa non lo è).


Gli scenari tipici sono:

Lo scenario più avido del progetto

Da solo o insieme ad alcuni amici, vuoi creare il tuo (forse primo) gioco. Perfetto, puoi decidere tutto da solo e sei limitato solo alle decisioni tecniche e ai requisiti tecnici di base (se si tratta di un gioco per cellulare, un gioco per PC, un gioco per console, un gioco Web, ....). Puoi decidere quello che vuoi.

I requisiti impliciti saranno che potresti voler imparare qualcosa di specifico (una lingua, un quadro / motore specifico)

Lo scenario dello studente

I requisiti possono venire dal tuo insegnante. Requisiti tipici che avevo in quel caso: il gioco deve avere alcuni elementi fisici e supporto di rete multiplayer. O deve essere scritto in C ++. Quindi la valutazione diventa facile. Stai cercando un motore di gioco che ti permetta di scrivere codice in c ++ e che possa già includere un motore di rete e fisico.

Un requisito più malvagio (vita reale): tutto deve essere scritto da zero (ma è consentito l'uso delle librerie). Quindi non è permesso nessun editor (es. Unity3D). Quindi non stai cercando engine / sdks ma librerie.

Lo scenario di gioco indie

Vuoi fare soldi con il gioco in seguito. Pertanto dovrai venderlo in qualche modo che ti porta a verificare su quali requisiti provengono dal negozio in cui vuoi vendere il tuo gioco.

Permette giochi Java, giochi HTML5, ....)

Richiede di includere librerie specifiche (se sì, in quali lingue sono disponibili quelle librerie)

Google Playstore ti richiederà di scrivere il tuo gioco come gioco Android, Apple AppStore ti richiederà di scrivere il tuo gioco come app iOS. Oppure hai l'obbligo di scegliere un motore multipiattaforma.

Lo scenario professionale

Non hai solo un negozio che fornisce requisiti, ma molto probabilmente un editore o un cliente ha la propria immaginazione di requisiti. In questo scenario avrai anche un team più grande di sviluppatori impiegati. A seconda delle loro competenze emergono nuovi requisiti (i nostri programmatori possono scrivere solo c ++, quindi non possiamo usare un motore di gioco Java / Android puro senza che abbiano bisogno di (molto) tempo per imparare qualcosa di nuovo).

Non vado nei dettagli per questo scenario, una volta che sei riuscito a formare un team di dipendenti e trovare un cliente / editore sai già cosa stai cercando per valutare le cose.


Come faccio a decidere quali sono i miei requisiti quando sono un più hobbista o indi e nessun altro me lo dice?

Fai domande a te stesso riguardo ai tuoi obiettivi e al tuo gioco?

  • Quale dovrebbe essere il mio gioco? mobile, pc, web (html / Js), quali controller userò (touch screen, giroscopio, game pad)

  • Cosa c'è di nuovo nel mio gioco e cosa hanno anche altri giochi. Quelle parti che hanno anche altri giochi (rendering, audio, gestione degli input) saranno eseguite dalla maggior parte degli strumenti (motori di gioco) che puoi trovare o è facile raggruppare librerie con quella funzionalità nel tuo gioco o motore di gioco.

  • Qual è la dimensione del mio progetto: uccelli arrabbiati o skyrim? Angry Birds può essere eseguito in quasi tutti gli strumenti e skyrim sarebbe limitato a strumenti ad alte prestazioni con (presunti) anni di personalizzazione aggiuntiva (i motori per terreni ad alte prestazioni non sono facili)

  • Il mio unico obiettivo è solo quello di fare una partita? sì? perfetto, puoi usare qualcosa di molto avanzato come Unity, Unreal, ... avere un editor utile e una grande comunità che ti fornisce tutorial e risponde alle tue domande. Elimina l'onere della gestione di attività di basso livello come il caricamento delle mesh, l'implementazione delle proprie funzioni matematiche, ....

  • Il mio obiettivo è imparare qualcosa di specifico? sì? cosa vuoi imparare?

  • Quale lingua dovrei scegliere? Se l'obiettivo è ancora solo quello di fare il tuo gioco scegli quello che tu / la tua squadra conosci meglio? Se vuoi imparare una lingua specifica, sceglierai uno strumento in quella lingua.

  • Lo strumento X avrà prestazioni sufficienti per il mio gioco? Forse non lo saprai mai. Anche nelle grandi produzioni la fase di ottimizzazione e lucidatura richiede molto tempo ed è un grande aiuto per farlo. Inizia a preoccuparti delle prestazioni quando si verificano problemi di prestazioni. Non sai come funzionerà lo strumento se non per raggiungere i suoi limiti. Tutto sul sito web dello sviluppatore degli strumenti è solo una supposizione approssimativa. Dopo anni di valutazione degli strumenti ho smesso di credere a qualsiasi cosa dal sito web degli sviluppatori.


Rispondere a tali domande ti porta ai requisiti. La valutazione sta trovando un elenco di strumenti e TEST (non solo la lettura della homepage) ciò che lo strumento può fornire o meno.


I requisiti non sono tagliati nella pietra ma sono dinamici. Verranno e verranno durante lo sviluppo. Se il gioco ha bisogno di fisica o no, ad esempio, dipende dal design. Se il design cambia, anche il requisito può cambiare.

Prendi i requisiti che hai e inizia. I requisiti mutevoli sono il pane quotidiano della sofferenza, ahm, sviluppatori felici indipendentemente dalle dimensioni del progetto e dal livello di esperienza.


0

Vai qui .

Nonostante il numero di motori di gioco disponibili, in realtà non hai molte scelte.

  1. restrizioni di licenza. Alcuni motori ostacolano la tua capacità di rilasciare il tuo prodotto senza prima pagare grandi commissioni di licenza, ad esempio Unity , utilizzato per addebitare un costo aggiuntivo da compilare su iOS, ad esempio (questo cambiato nel 2016 )
  2. piattaforme. Ti interessa il targeting per più piattaforme? Quale?
  3. 2D o 3D? Alcuni motori soddisfano il 2D.
  4. Richiede fisica? Alcuni motori forniscono fisica
  5. FPS, RTS? Potrebbe essere saggio utilizzare un motore specializzato per il tipo di gioco che stai creando.
  6. Ovviamente ti piacerebbe lavorare nella tua lingua preferita. Non ti piace C? Quindi non usare Allegro!
  7. Sei un grande progettista, fan di OOP? Modelli di "uso eccessivo" OGRE noti
  8. Sviluppo attivo? Dovresti considerare il compromesso tra la disponibilità di funzionalità bleeding edge (DX11 / OGL 4) e la stabilità di un motore il cui sviluppo è diminuito un paio di anni fa
  9. Base utenti? Una grande base di utenti di solito significa forum migliori, quindi più facili da rispondere alle tue domande
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.