Unity3D, quanto código você escreve? [fechadas]

Estou curioso para saber o fluxo de trabalho ao criar um jogo no Unity3D?

Isso gera muito código para você?

Meu entendimento é que você descreve o jogo no Unity e faz scripts no back-end para fazer a lógica. Assim como você usa o Unity para descrever os bonecos e usa uma linguagem de script como mestre dos bonecos.

O Unity3D consiste em um mecanismo de jogo e um editor 3D (bastante rudimentar). Ele fornece malhas, texturas, shaders, terrenos, câmeras, animações, sistemas de partículas, amostras de áudio e outros tipos de objetos úteis nos videogames. Inclui o PHYSX (um mecanismo físico de propriedade da Nvidia) e o Mono (a implementação de código aberto do Common Language Runtime, também conhecido como .NET).

Quanto disso você usa depende de você. Você pode representar todas as suas estruturas de dados como objetos do Unity, criar seu mundo no editor do Unity, ativar a física e permitir que os eventos sigam seu curso, com o mínimo de scripts. Como alternativa, você pode desligar o mecanismo de física, construir seu mundo por algoritmo e programar explicitamente todo o comportamento e a física dos objetos.

Você pode optar por programar o comportamento inteiramente em Mono (usando um dos idiomas C #, JavaScript ou Boo) ou pode escrevê-lo em outro idioma e vinculá-lo ao seu projeto do Unity. (A integração real com os objetos do jogo deve ser via Mono, mas pode ser uma camada bastante fina, se você preferir.)

O fluxo de trabalho é praticamente o mesmo de qualquer mecanismo de jogo. Artistas criam modelos, texturas e animações, especialistas em áudio produzem sons, programadores escrevem sombreadores e comportamento.

A comunidade de programadores do Unity é muito útil, tanto em answers.unity3d.com como no forum.unity3d.com . (E talvez aqui no Stack Exchange?)

A melhor maneira de descobrir é experimentá-lo : a versão básica é gratuita e você obtém um período de avaliação de 30 dias da versão "Pro".

O Unity3D é mais um invólucro / biblioteca do que um mecanismo de jogo 'arrastar e soltar'. Ele não gera código nem vem com scripts "prontos para uso".

Por exemplo, a Unreal possui uma câmera em primeira pessoa padrão, controlador de caracteres, detecção de colisão e IA.

Você não tem nada disso no Unity3D. O que você obtém do Unity3D é um sistema de entidades baseado em componentes, uma biblioteca abrangente de matemática, que significa carregar mídia, manipulação de malhas, câmera, GUI de modo imediato, shaders, pipeline de renderização e outras funcionalidades de baixo nível. Além de um bom editor. Você só precisa se preocupar com a funcionalidade de alto nível. Por exemplo, você ainda precisa codificar sua própria câmera em primeira pessoa (se não estiver usando a câmera padrão). No entanto, você não precisa lidar com o cálculo dos vetores de observação e outros.

O Unity3D não gera nenhum código para o seu jogo, estritamente (ele gera código para executar o jogo, para ser mais preciso, mas nenhum para o seu jogo)

Você precisará usar a API para definir seu jogo. Você pode ver os exemplos que acompanham o Unity3D e reutilizar esses códigos; existem alguns scripts predefinidos, mas geralmente você precisa personalizá-los para atender às suas necessidades.

Você cria o jogo através de scripts; você escreve scripts para comportamentos, projeta o nível no Unity3D e atribui esses comportamentos a entidades (ou objetos de jogo). É muito flexível, mas ainda requer esforço para escrever um jogo. Eu compararia com o Flash for 3D.

A superfície do Unity3D parece super fácil e quase tudo é pré-compilado, mas nada disso é verdade. Se você ignorar o uso de scripts já existentes (que existem para todos os mecanismos, pontos negativos em relação ao Unity) e plugins que você descreve como ultra poderosos, o que eles definitivamente não são, o Unity é apenas uma interface de programação com o editor.

Você tem a maior parte do código por conta própria. Eu experimentei isso em 2 projetos diferentes.

A analogia com o flash está certa, mas eu realmente não entendo sua analogia com os fantoches.

As coisas boas da unidade são:

• plataforma cruzada: essa é uma vantagem muito grande, eu diria o motivo maior.
• Mecanismo e implementação de alta qualidade, quero dizer, usando objetos de jogo do Unity etc.
• Muito fácil de fazer um jogo simples do zero, então isso é uma vantagem para a criação de protótipos.

As coisas ruins:

• Não é possível vincular com C ++ ou C, portanto, seu projeto pode funcionar apenas no Unity. Com o C #, pode-se argumentar que funcionará no XNA, mas o C ++ teria sido bom. Com esta observação, quero dizer que não é uma ferramenta que profissionais veteranos ou autodidatos usariam, já que você não tem controle total sobre sua aplicação, mas isso não significa que há algo que você não pode fazer com o Unity. Por outro lado, uma equipe com uma ótima idéia e artistas talentosos pode fazer coisas incríveis sem precisar de programadores experientes.
• É muito novo, então, obviamente, ninguém sabe aonde essa ferramenta levará.

O que não gosto no Unity é que parece que todo o trabalho é feito, então os programadores são muito menos valiosos. Por outro lado, é ótimo para ensinar rapidamente às pessoas como construir coisas rapidamente.

Então, para concluir: o Unity (ou uma ferramenta como o Unity) é mais para artistas que não conseguem alcançar grandes programadores, mas ainda sabem fazer um pouco de script de jogo. É claro que você pode criar um jogo completo, adicionar IA realista, fazer um código de rede mmo e o que não, mas as grandes empresas não usariam o Unity.

Os modelos de programação permitem propor uma solução que se adapte a 3/4 das ferramentas de desenvolvimento, para que ela se ajuste aos fabricantes de jogos "independentes". Ele valoriza uma ferramenta específica e também valoriza artistas, mas não programadores (exceto os da equipe da unidade, é claro).

O Unity é um bom atalho para os não programadores, mas eles precisam entender que os videogames vêm de linhas de código e que você não pode fazer tudo apenas com uma ferramenta incrível. Em algum momento, é necessário saber algo sobre programação de baixo nível.

Tendo em mente um projeto pessoal, eu não usaria o Unity, porque não gosto de C # ou Boo (o Panda é bom com python, então por que se preocupar com um software comercial?) E porque se eu mostrar meu projeto e pronto, unidade, será muito menos impressionante.

O Unity exige que você escreva, mas sem todos os clichês. Em um jogo típico do OpenGL, você precisará inicializar as matrizes e as câmeras como loucas. No Unity, você cria um script para informar o comportamento de algo e, em seguida, anexa-o a um objeto para que ele se comporte.

Se, ao gerar muito código, você incluiria funções pré-criadas que podem ser usadas para facilitar sua vida com relação aos cálculos de detecção e rotação de colisões (Biblioteca), então sim, isso exige muita codificação da imagem e fornece você otimizou as versões disponíveis e pronta para uso. Principalmente as funções necessárias para o desenvolvimento de jogos em todas as compilações.

Pode parecer redundante dizer isso, mas na minha experiência, quando o Unity3D não está ocupado travando ou construindo, está facilitando minha vida, deixando-me mudar o que eu quero e deixando a matemática baseada em Quaternion para as pessoas que têm mestrado em matemática. e ainda confia em mim o suficiente para me mudar o que eu quiser.

Ele não escreverá nada para você; em vez disso, ajudará da maneira que achar melhor e permitirá que você escreva o que quiser.

Em uma palavra, flexível