Share
Mentre molte delle conferenze Unite di quest'anno si sono concentrate sugli aspetti tecnologici del motore Unity, ci sono stati molti discorsi da parte degli sviluppatori sulle loro esperienze nello sviluppo di giochi con piccoli team che utilizzano Unity. In questo articolo, esaminerò alcune delle grandi idee che gli sviluppatori Unity di tutto il mondo hanno da offrire, insieme ad alcuni suggerimenti tecnici che ho raccolto lungo la strada.
Credito a Bluecadet per l'immagine di anteprima.
Non aver paura di condividere i tuoi disegni.
Ziba Scott, Popcannibal
Le ragazze piacciono i robot Nell'autopsia di Ziba Scott del suo gioco Girls Like Robots, ha attraversato la stanza attraverso i grandi successi e gli errori costosi che Popcannibal ha sofferto sulla strada per la creazione di un gioco di Adult Swim di successo.
Per prima cosa ha sottolineato l'importanza di non avere paura di condividere i progetti di gioco con le persone intorno a te. Inizialmente, l'idea di condividere i suoi primi progetti per Girls Like Robots sembrava pericolosa. Scott ha ricordato che, anche se c'era il timore che condividere i suoi progetti avrebbe portato al furto delle sue idee, è successo il contrario. Quando ha chiesto feedback, le persone intorno a lui aiuterebbero effettivamente a migliorare i suoi progetti sottolineando alcune delle complessità e delle incongruenze che non riusciva a vedere se stesso.
Sulla stessa linea, ha suggerito che la mancanza di pre-produzione danneggia la percezione generale del gioco da parte delle persone che ci lavorano. Nella mente di Ziba esisteva più del gioco che all'esterno per il team da cui ispirarsi. Ha suggerito che se avesse esternalizzato più dei suoi piani per il gioco, avrebbe portato ad una migliore visione condivisa tra tutti i membri del team e un concetto più tangibile per il team di sostenere ed essere motivato da. Ha pensato che solo un po 'di concept art avrebbe fatto molta strada per aiutare la squadra a entusiasmarsi per l'obiettivo finale.
Disporre i tuoi disegni affinché tutti possano scegliere, può essere molto spaventoso, ma farlo costringe il design a reggere il proprio merito. Non solo ottieni feedback preziosi da diversi punti di vista, ma l'atto di mettere il tuo gioco in esame ha l'effetto collaterale di costringerti a esaminare le tue decisioni di progettazione. Ricorda che, mentre il feedback esterno è importante, tu, come designer, prendi la decisione finale.
Avere una "verità" nella realtà che crei.
Richard "Lord British" Garriott, Portalarium
Sindone dell'Avatar: Virtù abbandonate Richard Garriott ha una storia lunga e interessante nel settore dello sviluppo del gioco. Come creatore della serie Ultima e produttore di City of Heroes e Tabula Rasa, ha una notevole esperienza nella creazione di mondi di gioco virtuali ampi e persistenti (infatti, è il ragazzo che ha coniato il termine MMO nel 1997). La sua ultima impresa, Shroud of the Avatar: Forsaken Virtues, è stata costruita usando Unity, che le affermazioni Garriott gli permetteranno di realizzare un gioco 'Ultima-scale' in soli 18 mesi.
Nella sua nota chiave, Garriott ha fornito alcune informazioni su ciò che i suoi oltre 30 anni di esperienza in giochi di ruolo e MMO gli hanno insegnato a creare avvincenti mondi di gioco. Al centro, ha suggerito che ogni mondo di gioco deve avere un po 'di "verità" (prendere in prestito un termine da Stephen Colbert). Questa verità sembrava comprendere tre concetti principali:
Combinati, questi concetti aiutano ad aumentare la profondità percepita del mondo di gioco.
Lo sviluppo di giochi è la ricerca scientifica, non la produzione.
Brian Kehrer, Muse Games
Pistole di Icaro Dopo il successo di Guns of Icarus, il team di Muse Games è stato contattato per sviluppare una versione online. Dopo il loro primo successo ed entusiasti del rinnovato interesse dei finanziatori, è stato redatto un documento di progettazione di 130 pagine. Mentre il loro gioco è cresciuto nel raggio di azione da Guns of Icarus, le loro dimensioni della squadra no. Dopo nove mesi di duro lavoro, si sono trovati a malapena a raggiungere i loro obiettivi.
Fu a questo punto che Kerher decise che qualcosa doveva cambiare. Aveva bisogno di un modo per iterare di più con lo stesso numero di persone. Nel suo discorso, Kerher ha suggerito che Agile è il modo per farlo e ha annunciato Guns of Icarus Online come prova del fatto che il suo approccio può dare risultati molto positivi.
Un componente della metodologia Agile è di avere un pezzo funzionale di software alla fine di ogni ciclo di sviluppo. Per soddisfare questo requisito, Kerher si assicurò che tutte le attività di sviluppo fossero suddivise in attività che potevano essere completate entro un periodo di tempo da due a tre settimane. Queste attività più piccole consentivano l'iterazione di parti più piccole del progetto in un periodo di tempo più breve. I disegni che non funzionavano o che non avevano senso venivano catturati molto presto. Kerher ha sostenuto che, poiché ci sono così tante potenziali soluzioni per una meccanica "divertente", l'unico modo per mettere in evidenza la meccanica ottimale è sperimentare.
Scrivi il codice in modo che il programmatore non abbia bisogno di essere lì.
Gerald Orban e Lance Mueller, Blackbird Interactive
Hardware: Shipbreakers (rinominato in Homeworld: Shipbreakers) Gerald Orban e Lance Mueller di Blackbird Interactive hanno avuto un problema: mentre scrivevano il loro gioco pesante della GUI Homeworld: Shipbreakers, si sono trovati a passare sempre più tempo a modificare i valori e i sistemi di debug per gli artisti di quanto non stessero scrivendo un nuovo codice. Nel loro discorso, passano attraverso il processo iterativo che li ha portati al flessibile, sistema di interfaccia grafica per artisti che ora usano nella produzione.
All'inizio del processo di sviluppo, Orban capì che la GUI in Homeworld: Shipbreakers era di vitale importanza per il gameplay. Ancor più della maggior parte dei giochi RTS, Homeworld aveva più livelli di dati che apparivano, scompaiono, si combinano e si separano a seconda del livello di zoom e di ciò che era sullo schermo. Con centinaia di icone visualizzate contemporaneamente, la prima necessità era di organizzare tutti questi dati in diversi livelli, molto simili a come Google Maps separa il trasporto pubblico, i luoghi e le informazioni sul traffico.
La prima iterazione era in pixel ombreggiato, non forniva WYSIWYG e richiedeva che un programmatore fosse lì per apportare aggiunte o modifiche. Mentre la stratificazione dei dati ha aiutato a segmentare le cose visivamente, non c'erano ganci nell'editor per apportare modifiche, quindi le modifiche ai colori e alle icone dovevano essere apportate dallo sviluppatore tramite codice.
La seconda e la terza iterazione sono state rese leggermente migliori esponendo gli oggetti della GUI da manipolare nella scena. Mentre questo ha permesso agli artisti di trasformare elementi della GUI, volevano ancora un maggiore controllo sull'aspetto e sull'aspetto individuale.
Alla fine, dopo l'ottava iterazione, hanno iniziato ad agganciarsi alla funzionalità di scripting dell'editor di Unity. Ciò consente agli artisti di manipolare la GUI in modo più efficace e consente loro di eseguire il debug dei propri problemi assicurandosi innanzitutto che non vi siano problemi con la configurazione di quel particolare elemento della GUI.
Impazzire e rilasciare velocemente.
David Helgason, fondatore e CEO di Unity Technologies
Una cosa che David Helgason ha sottolineato nella sua nota principale è che le cose si stanno muovendo molto velocemente ora - così velocemente che i giochi molto velocemente stanno superando il ciclo di sviluppo triennale che ha dominato il settore dello sviluppo di giochi negli anni passati. "Primo sul mercato" e "rapido sul mercato" stanno diventando più importanti man mano che emergono piattaforme più informali, spingendo gli sviluppatori verso iterazioni più rapide. Iterazioni più rapide significa giochi più piccoli da spedire, in un lasso di tempo più breve.
Ha ulteriormente rafforzato questa idea, elaborando su ciò che ha definito un "mezzo di intrattenimento". Essenzialmente, le creazioni in diversi mezzi durano diverse lunghezze di tempo prima che diventino dimenticate o irrilevanti. La musica più vecchia tende a rimanere più a lungo dei vecchi film. I film più vecchi tendono a rimanere più a lungo dei giochi tradizionali. E i giochi mobili tendono ad avere l'emivita più breve di tutti i mezzi. Per estrapolare, questo significa che, per i giochi mobili, i tempi per fare soldi sono molto più brevi rispetto ad altri mezzi.
Non è del tutto chiaro se questo sia positivo per l'industria. Poiché i tempi più brevi stanno riducendo i tempi di sviluppo, anche la complessità dei giochi potrebbe diminuire. Invece di progettare giochi meditatamente, l'industria potrebbe assumere una mentalità di "vedere cosa basterebbe". D'altro canto, poiché l'investimento è così basso, un fallimento ha meno impatto e mette più libertà nelle mani dei progettisti per progettare fuori dagli schemi.
Non ossessionare le tattiche di [marketing].
Darren Williams, direttore marketing, Unity Technologies
Williams ha iniziato il suo discorso dicendo quello che sentono molti sviluppatori di giochi indie: il marketing fa schifo. Pensare solo a dove pubblicizzare, come incentivare, obiettivi CPI / CPA e il costo in termini di tempo e denaro solo per far sì che il tuo gioco sia notato è sufficiente per far desiderare a uno sviluppatore indipendente l'intervento di un editore. Williams ha elencato alcuni errori commessi dalle società di giochi e in che modo persino uno sviluppatore indipendente può imparare a godersi il marketing.
Le aziende che commettono errori (o pensano di doverle fare) devono concentrarsi sulle tattiche di marketing. Williams ha parlato delle potenti soluzioni di marketing che esistono ora, ma queste soluzioni richiedono denaro. Invece, ha suggerito di concentrarsi su una crescita più organica prendendo di mira tipi di pubblico specifici, dei quali suggerisce che ce ne siano quattro: Innovatore, Primo Adopter, Mercato di massa, e Ritardatario.
Gli innovatori sono in genere molto consapevoli della tecnologia e hanno un'enorme influenza sui tipi di pubblico sopra di loro. Promuovendo il tuo gioco nelle comunità in cui vivono gli innovatori, stai gettando le basi per una comunità.
Una volta che il tuo gioco Alpha è nelle mani di Innovators, è tempo di iniziare a costruire una community pre-release. Man mano che gli innovatori apprenderanno il tuo gioco, vorranno un sito web o un forum per tornare a dove possono trovare dettagli tecnici e aggiornamenti specifici. Col passare del tempo, Williams ha suggerito di iniziare a rilasciare aggiornamenti di livello superiore, meno tecnici, man mano che gli Early Adopters iniziano ad arrivare.
Con una comunità dietro il tuo gioco, è solo una questione di preparazione per una data di lancio. Williams non è andato direttamente a prendere un gioco dai tipi di pubblico Innovator / Early Adopter al Mass Market, ma ha detto che avere una community pre-release è incredibilmente utile quando si cerca di ottenere supporto per cose come Steam Greenlight e Kickstarter.
Un aspetto dello sviluppo del gioco che gli sviluppatori di Unity non passano molto tempo a preoccuparsi è la gestione della memoria. Questo perché il motore di scripting di Unity implementa un garbage collector che si occupa auto-magicamente di ripulire quegli oggetti fastidiosi che non sono più referenziati dalla scena. Mentre questo garbage collector semplifica la gestione della memoria per lo sviluppatore, ci sono più trucchi e ottimizzazioni che possono aiutare a spremere la maggior parte delle prestazioni dai tuoi script.
La prima cosa da capire sul garbage collector di Unity è che si tratta di usi segna e spazza attraversare alberi di riferimento per trovare oggetti inutilizzati. Quando gli oggetti fanno riferimento ad altri oggetti, questi alberi crescono di dimensioni e richiedono più tempo per essere attraversati. Per mantenere piccole le dimensioni di questi alberi, gli sviluppatori suggeriscono di utilizzare i POD laddove possibile. Poiché i POD non possono fare riferimento agli oggetti, mantiene gli alberi di riferimento molto più piccoli. Un semplice esempio di ciò sarebbe di fare riferimento all'indice in una matrice invece che all'oggetto nella matrice.
Il secondo suggerimento per migliorare la velocità di raccolta dei rifiuti è stato suggerito dagli sviluppatori di utilizzare strutture e array, laddove possibile, anziché le classi o un elenco. Entrambe le strutture e gli array sono allocati in memoria contigua, il che migliora la velocità di accesso e rende più facile la scansione di questi riferimenti per il garbage collector.
Infine, la migliore ipotesi è di non assumere nulla. A volte c'è un'aspettativa che, poiché un pezzo di codice sembra più pulito, è più efficiente. Un esempio di questo è quando si aggiungono due Vector3 struttura insieme. Normalmente, questo sarebbe fatto usando il + operatore (v1 + v2, o v1 + = v2), che finisce per allocare un temporaneo Vector3 per mantenere il valore prima di assegnarlo a v1. Meno memoria è allocata solo aggiungendo v2'S X, y, e z componenti direttamente a v1I componenti.
Mentre Unite 2013 non aveva un tema coeso, il messaggio di fondo in ogni discorso era chiaro: "Vai avanti e crea giochi". Falli rapidamente, rendili divertenti e rendili per tutti. Mentre la tecnologia per rendere i giochi diventa più semplice, la barriera all'ingresso per gli sviluppatori indipendenti diminuisce e ha un effetto democratizzante sul settore. Le iterazioni di sviluppo più brevi spostano il potere dalle grandi aziende ai creatori individuali e, a causa di ciò, gli editori si rivolgeranno agli indipendenti per la prossima generazione di giochi.
Se sei interessato a guardare i video della conferenza Unite, puoi trovare i discorsi di questo e degli anni precedenti a Unity's Unite Archive.
Accentsconagua