Unity3D, quanto codice scrivi? [chiuso]

Sono curioso di conoscere il flusso di lavoro durante la creazione di un gioco in Unity3D?

Genera molto codice per te?

La mia comprensione è che descrivi il gioco in Unity e fai script sul back-end per fare la logica. Un po 'come usare Unity per descrivere i pupazzi e usi un linguaggio di scripting come il burattinaio.

Unity3D è costituito da un motore di gioco più un editor 3D (abbastanza rudimentale). Fornisce mesh, trame, shader, terreno, telecamere, animazioni, sistemi di particelle, campioni audio e altri tipi di oggetti utili nei videogiochi. Include PHYSX (un motore fisico proprietario di proprietà di Nvidia) e Mono (l'implementazione open source di Common Language Runtime, aka .NET).

Quanto di questo che usi dipende da te. Puoi rappresentare tutte le tue strutture dati come oggetti Unity, costruire il tuo mondo nell'editor di Unity, attivare la fisica e lasciare che gli eventi seguano il loro corso, con un minimo di script. In alternativa, potresti spegnere il motore fisico, costruire il tuo mondo in modo algoritmico e programmare esplicitamente tutto il comportamento e la fisica degli oggetti.

Puoi scegliere di programmare il comportamento interamente in Mono (usando una delle lingue C #, JavaScript o Boo), oppure puoi scriverlo in un'altra lingua e collegarlo al tuo progetto Unity. (L'integrazione effettiva con gli oggetti di gioco deve essere tramite Mono, ma questo può essere un livello abbastanza sottile se vuoi.)

Il flusso di lavoro è molto simile a quello di qualsiasi motore di gioco. Gli artisti creano modelli, trame e animazioni, gli specialisti dell'audio producono suoni, i programmatori scrivono shader e comportamenti.

La comunità di programmatori Unity è molto utile, sia a answers.unity3d.com e forum.unity3d.com . (E forse qui allo Stack Exchange?)

Il modo migliore per scoprirlo è provarlo : la versione base è gratuita e ottieni un periodo di prova di 30 giorni per la versione "Pro".

Unity3D è più un wrapper / libreria che un motore di gioco "trascina e rilascia". Non genera codice né viene fornito con script "standardizzati".

Ad esempio, Unreal ha una videocamera in prima persona predefinita, un controller dei personaggi, un rilevamento delle collisioni e un'intelligenza artificiale.

Non hai nulla di tutto ciò in Unity3D. Quello che ottieni da Unity3D è un loop di gioco, un sistema di entità basato su componenti, una libreria matematica completa, mezzi per caricare media, gestione di mesh, telecamera, GUI in modalità immediata, shader, rendering pipeline e altre funzionalità di basso livello. Inoltre un bel redattore. Devi solo preoccuparti di funzionalità di alto livello. Ad esempio, devi ancora codificare la tua videocamera in prima persona (se non stai utilizzando quella predefinita). Tuttavia, non è necessario occuparsi del calcolo dei vettori di ricerca e simili.

Unity3D non genera alcun codice per il tuo gioco, rigorosamente (genera codice per l'esecuzione del gioco, per essere più accurati, ma nessuno per il tuo gameplay)

Dovrai utilizzare l'API per definire il tuo gioco. Puoi guardare gli esempi forniti con Unity3D e riutilizzare quel codice; ci sono un paio di script predefiniti, ma di solito devi personalizzarli per soddisfare le tue esigenze.

Si crea il gioco tramite script; scrivi script per comportamenti, progetti il ​​livello in Unity3D e assegni tali comportamenti a entità (o oggetti di gioco). È molto flessibile, ma richiede ancora uno sforzo per scrivere un gioco. Lo confronterei con Flash per 3D.

La superficie di Unity3D sembra super facile e quasi tutto è pre-costruito, ma nulla di tutto ciò è vero. Se ignori di usare script già esistenti (che esistono per ogni motore, punto negativo contro Unity) e plugin che descrivi come in qualche modo ultra potenti, cosa che sicuramente non sono, Unity è solo un'interfaccia di programmazione con l'editor.

Hai la maggior parte del codice per conto tuo. L'ho sperimentato in 2 progetti diversi.

L'analogia con il flash è giusta, ma non capisco davvero la tua analogia con i burattini.

Le cose belle dell'unità sono:

• multipiattaforma: questo è un vantaggio molto grande, direi il motivo più grande.
• Motore e implementazione di alta qualità, intendo usare oggetti di gioco Unity ecc.
• Molto facile creare un gioco semplice da zero, quindi è un vantaggio per la realizzazione di prototipi.

Le cose cattive:

• Impossibile collegarsi con C ++ o C, quindi il tuo progetto potrebbe funzionare solo su Unity. Con C # si potrebbe sostenere che funzionerà su XNA, ma C ++ sarebbe stato carino. Con questa osservazione intendo che non è uno strumento che professionisti veterani o autodidatti userebbero, dal momento che non hai un controllo totale sulla tua applicazione, ma questo non significa che ci sono cose che non puoi fare con Unity. D'altra parte, un team con una grande idea e artisti di talento possono fare cose fantastiche senza bisogno di programmatori esperti.
• È abbastanza nuovo, quindi ovviamente nessuno sa dove porterà questo strumento.

La cosa che non mi piace di Unity è che sembra che tutto il duro lavoro sia stato fatto, quindi i programmatori hanno molto meno valore. D'altra parte è ottimo per insegnare rapidamente alle persone come costruire cose velocemente.

Quindi, per concludere: Unity (o uno strumento come Unity) è più adatto agli artisti che non riescono a contattare grandi programmatori, ma sanno comunque fare un po 'di script di gioco. Naturalmente puoi creare un gioco completo, aggiungere un IA realistico, fare un codice net-mmo e cosa no, ma le grandi aziende non userebbero Unity.

La programmazione dei modelli consente di proporre una soluzione adatta a 3/4 degli strumenti di sviluppo in modo che si adatti a quei creatori di giochi "indipendenti". Apprezza uno strumento particolare e apprezza anche gli artisti, ma non i programmatori (tranne quelli del team di unità, ovviamente).

Unity è una buona scorciatoia per i non programmatori, ma devono capire che i videogiochi provengono da righe di codice e che non puoi fare tutto solo con uno strumento fantastico. Ad un certo punto è necessario sapere qualcosa sulla programmazione di basso livello.

Avendo in mente un progetto personale, non userei Unity, perché non mi piace C # o Boo (Panda è bravo con Python, quindi perché preoccuparsi di un software commerciale?), E perché se mostro il mio progetto ed è fatto con unità, sarà molto meno impressionante.

Unity richiede di eseguire la sceneggiatura, ma senza tutte le piastre di caldaia. In un tipico gioco OpenGL, dovrai inizializzare le matrici e le telecamere come un matto. In Unity, crei uno script per dire il comportamento di qualcosa, quindi collegalo a un oggetto per farlo comportare.

Se generando molto codice per te, includeresti funzioni predefinite che puoi usare per semplificarti la vita per quanto riguarda il rilevamento delle collisioni e i calcoli di rotazione (Libreria), quindi sì, ci vuole un sacco di codice fuori dall'immagine e dà hai ottimizzato le versioni a portata di mano e sei pronto per partire. Principalmente funzioni che ti serviranno specificamente per lo sviluppo di giochi in tutte le build.

Può sembrare ridondante dirlo, ma nella mia esperienza, quando Unity3D non è impegnato a schiantarsi o a costruirlo, mi semplifica la vita lasciandomi cambiare ciò che voglio e lasciare la matematica basata su Quaternion alle persone che hanno un master in matematica e ancora fidarmi di me abbastanza da cambiarmi quello che voglio.

Non scriverà nulla per te, piuttosto ti aiuterà nel modo in cui pensa sia meglio e ti permetterà di scrivere quello che vuoi.

In una parola, flessibile