Olá pessoal! Sou designer de UI / UX, especializado em interfaces de jogos. Também sou humanista: tudo relacionado ao código gera medo e desconfiança inatos, que não consigo superar. Ter medo de uma "magia negra" proger é normal para um designer. Mas há um problema que complica muito a vida.
O fato é que, em nosso trabalho, nós, designers de interface, geralmente precisamos nos aproximar dos sites e aplicativos internos e até entrar um pouco nisso. Essa necessidade é especialmente relevante na fase de prototipagem rápida e precoce, quando você deseja colecionar algo no joelho que possa dar uma idéia do produto final, terá a funcionalidade mínima necessária e também parecerá decente. No entanto, a maioria dos designers (inclusive eu) nem sequer tem o conhecimento mínimo para criar e editar sua própria parte de interface do protótipo, através do código. E isso também é normal para a indústria.
Conhecendo esse nosso recurso humanitário, programadores compassivos (junto com outras pessoas boas) criaram um número suficiente de ferramentas para criar um design e testá-lo em dispositivos reais sem escrever uma única linha de código. Essas ferramentas são facilmente pesquisadas no Google por solicitação do tipo "programa de prototipagem de interface". Estes são Sketch, Adobe XD, Figma, Princípio, InVision, Marvel, etc. Eles são demais. Eles economizam milhões de células projetadoras de nervos (e possivelmente algumas vidas). Centenas de artigos foram escritos sobre eles; eles são merecidamente elogiados por designers de UI / UX em todo o mundo.
No entanto, essas ferramentas são adaptadas principalmente para desenvolvedores de aplicativos Web e móveis. Para os desenvolvedores de jogos (e estamos aqui exclusivamente sobre os desenvolvedores de jogos), eles são inadequados.
"Espere um minuto, qual é a diferença?" Você pergunta. Jogos também são aplicativos, certo? Na verdade não. As especificidades do jogo fazem uma correção significativa no processo de produção.
Vamos acertar.
Em primeiro lugar, aplicativos "comuns" e não relacionados a jogos geralmente são criados com base no princípio de soluções diretas para os problemas do usuário. Por exemplo, quero resolver um problema específico - transferir dinheiro para o cartão de Serege - e, para isso, abro um aplicativo bancário. A rapidez com que posso resolver minha pergunta determina o grau de satisfação com essa interação. Após a transferência, fecho o aplicativo e o esqueço por um tempo. Estou satisfeito, o banco está satisfeito, Seryoga está satisfeito. Este é um caminho linear compreensível do ponto A ao ponto B.
O banco, como eu, está interessado em fechar as tarefas do usuário o mais rápido possível. Ele não os cria especificamente. Esquematicamente, é algo parecido com isto:
No setor de entretenimento (onde a principal receita vem da publicidade), quanto mais o usuário gasta em um serviço, mais lucro pode ser gerado a partir dele. Portanto, o próprio YouTube, sem perguntar, lança o próximo vídeo e rouba os algoritmos que selecionam esse vídeo para seus interesses. Nos jogos para celular, o mesmo. O desejo de se divertir e receber uma dose de dopamina em certo sentido é uma tarefa definida pelo usuário. Mas ela não tem uma solução definitiva e definitiva, que é o que os produtores de conteúdo usam. Queremos que você não se destaque dos nossos jogos. Geralmente.
Portanto, os jogos usam ciclos que lançam aos jogadores novas tarefas e os transferem habilmente de uma atividade para outra. Parece algo como isto:
Essa estrutura já é muito mais difícil de prototipar. Chame este recurso de
emboscada número 1 do jogo . Tem outros
Emboscada nº 2 O jogo é basicamente uma jogabilidade. A interface é apenas uma ligação, uma moldura para um diamante (embora em alguns jogos a interface = jogabilidade, mas não falemos de coisas tristes). Sem essa gema no meio, geralmente é difícil avaliar quão boa ou ruim é a sua interface (e agora não estou falando sobre a aparência). O problema é que a jogabilidade não pode ser integrada às ferramentas de prototipagem; elas existem em diferentes programas, em mundos diferentes. E se não houver jogabilidade, não haverá jogo em si. Não há contexto necessário.
Emboscada nº 3 Nos jogos, existem elementos e / ou animações muito fora do padrão. A paleta de elementos é muito mais ampla do que a encontrada em sites ou aplicativos de escritório. Nem todo programa de prototipagem pode recriá-los.
Emboscada No. 4 Os jogos são feitos nos mecanismos de jogo. As ferramentas de prototipagem são sincronizadas com elas sobre ... nada. Eles simplesmente não foram projetados para isso. Tudo o que foi feito * no nome do programa de prototipagem *, você (ou seu pobre colega) recriará novamente no mecanismo. Do zero. E não é fato que, ao mesmo tempo, seja possível repetir tudo, pelo menos próximo de como estava no protótipo: as capacidades dos programas são diferentes. É por isso que jogadores grandes como Game Insight (
vídeo ) ou Pixonic (
artigo ) examinam ferramentas internas que de alguma forma sincronizam o photoshop, cortando sprites, montando-os no mecanismo, gerenciamento de estilo etc.
Sim, a propósito. Nota marginal. Eu trabalhei apenas com jogos feitos no Flash ou no Unity. O Flash já morreu, por isso será principalmente sobre o Unity. Suponho que tudo o mais ou menos dito é verdade em relação a outros mecanismos de jogos populares, mas isso não é exato.O que leva a essa duplicação de trabalho? Obviamente, o fato de o esforço para desenvolver e oferecer suporte a protótipos de interface mais ou menos
complexos está subindo rapidamente. Que seja relógios humanos de grife relativamente baratos (desculpe pessoal), mas mesmo assim.
Eu não quero dizer que a criação de protótipos de interfaces com ferramentas padrão é estúpida. Claro que não: qualquer trabalho preparatório na produção da interface é melhor que sua ausência. É que o caminho que conhecemos, designers, tem limitações e problemas que podem ser evitados. Mais sobre isso mais tarde.
Existe um cara assim,
Om Tandon . Ele publicou muitos artigos sobre UI / UX de jogos e, em geral, parece um pouco complicado. Pelo menos, ele escreve com muita confiança (a propósito, foi dele que tirei fotos e algumas idéias para este artigo). Aconselho os interessados a ler o ciclo correspondente de seus artigos no LinkedIn (não se esqueça da VPN): a
primeira , a
segunda e a
terceira partes. Você também pode assistir ao
vídeo dele em uma conferência em Londres. É melhor parar e fazer isso agora mesmo antes de continuar lendo este artigo, porque Vou confiar em alguns lugares em seu material.
Apesar de, em geral, a ideia de Ohm - tornar os protótipos o mais próximo possível dos produtos finais o mais rápido e barato possível, eu gosto, em particular, não posso concordar com ele. Por exemplo, ele afirma que, para alcançar o mesmo resultado no protótipo de jogo (Ohm chama de protótipo dev), em comparação com o protótipo, leva várias vezes mais tempo e esforço. São dados dados concretos: são necessários de
5 a
7 dias para criar
esse protótipo usando o Principle (uma das ferramentas populares de prototipagem), e levaria de
20 a 30 dias para a equipe implementar a mesma funcionalidade no mecanismo, de acordo com Ohm. E não se trata de "fazer tudo de acordo com a beleza", mas apenas de obter um resultado idêntico na saída. Na minha opinião, o número é muito exagerado.
Em segundo lugar, os exemplos de protótipos citados por Om ainda são lineares. Estes são tutoriais com uma sequência das únicas ações verdadeiras, ou uma cadeia de telas pelas quais você pode viajar nas direções “lá” e “aqui”, ou uma imitação da microinteração local. Sim, eles parecem deliciosos, mas não vi nenhum ciclo de jogo ou lógica complexa lá.
Em terceiro lugar, nos protótipos de Ohm feitos em Princípio, pelas razões já descritas, não existe e não pode ser a própria jogabilidade. Não há nem 3D como tal! Eles são apenas sobre UI / UX simples, isolados do próprio jogo. Na minha opinião, isso reduz seu valor. Embora Om afirme que essas soluções são adequadas para emular de forma convincente aproximadamente 80% dos gêneros de jogos.
Quarto, o Om um dos principais motivos para o desenvolvimento de um protótipo de interface é seu uso subsequente em pesquisas de usabilidade. Isso é ótimo e correto, mas com que frequência você encontra estudos de usabilidade competentes (pelo menos alguns) em desenvolvedores domésticos de jogos? Esses protótipos são necessários para pequenas equipes e estúdios que não realizam esses mesmos estudos? Se o protótipo de
jogabilidade é uma parte óbvia e obrigatória do desenvolvimento de
qualquer jogo (desde que você não faça papel vegetal de outro projeto), então há algum motivo para se preocupar com protótipos de
"designers" - essa é uma questão em aberto.
Na minha experiência, o mais simples
mapa não interativo
de telas na forma de uma imagem robusta resolve a grande maioria dos problemas de interação e conexões entre telas. Essa imagem é coletada em meia hora e nada além dos modelos desenhados no Photoshop (ilustrador) será necessário. Geralmente, é possível parar.
Em que casos faz sentido passar para um protótipo interativo e altamente detalhado (Ohm chama isso de
alta fidelidade )? Nuuu ... Por exemplo, se o seu cliente precisa dos materiais mais visuais, e não do esquema BW, para aceitar o trabalho. Isso acontece
Ou se você precisar criar uma bela demonstração que possa mostrar aos investidores e dirigir ao telefone.
Ou se a jogabilidade do projeto ou sua parte individual é tão nova que geralmente não está claro como criar interação com ele, e são necessários ciclos constantes de testes de hipóteses.
Ou se você deseja acelerar o processo de tentativa e erro nas interfaces, descarregando os programadores ao longo do caminho.
Ou se você precisar de um produto simulado para testes de usabilidade.
Em resumo, eu não recomendaria criar um protótipo detalhado de um jogo com uma interface por padrão, mas há casos em que é realmente necessário. Apenas decida por que você está gastando seus recursos nisso e que tipo de exaustão planeja receber.
Então, novamente, brevemente. Vejo
três maneiras principais de criar um protótipo da interface do jogo:
1) Limitado a um mapa de telas. Não se preocupe com protótipos interativos se você não entender o que e como deseja testá-los.
2) Faça de um protótipo primitivo (literalmente, imagens de slides com transições) um programa interativo no programa em que será mais rápido. Essa é uma variante para quem entende o que e como deseja verificar, e quem não precisa ser particularmente detalhado ou conectar a interface à jogabilidade (por exemplo, você está interessado apenas na meta parte do jogo). Pode ser assistido no dispositivo.
Mas, se você precisar de algo mais próximo do produto real, objetivamente, essa é a terceira opção, e vamos nos aprofundar nisso com mais detalhes. Para fazer isso,
protótipo da interface diretamente no Unity , caro amigo designer. É mais fácil do que você pensa.
O fato é que a Unity é um ecossistema inteiro, uma enorme combinação. Parcialmente assustador, às vezes monstruoso e desconfortável, mas definitivamente com suas vantagens. Por exemplo, não importa qual recurso adicional você gostaria de fixar no mecanismo, provavelmente ele já está disponível para download na
Asset Store . Às vezes até de qualidade decente. As ferramentas de design não são exceção.
Por exemplo, eu realmente gosto do
DoozyUI , que permite criar telas separadas sem muito aborrecimento, adicionar links e transições entre elas e acelerar rapidamente as animações da interface. Como eles não pagam mais pela publicidade, direi como está: esta é longe de ser a única ferramenta disponível no mercado. E mesmo provavelmente não o melhor. Ele me subornou com um grande número de tutoriais, uma história rica e seu próprio sistema para exibir conexões entre telas. Basta olhar para esta beleza!
No entanto, existem outras ótimas soluções para criar sistemas de tela complexos no Unity sem conhecimento profundo do código. Tudo o que você precisa fazer é investir um pouco do seu tempo em suas pesquisas e se aprofundar na Asset Store.
Em princípio, você pode fazer sem extensões e usar o que o Unity oferece fora da caixa. Apenas para a psique humanitária, será muito mais doloroso. Você precisa entender que, em qualquer situação no início, o neófito da Unity precisará assistir a NN horas de treinamento (ou puxar constantemente os programadores, como no meu caso). Ainda assim, o mecanismo não foi projetado para designers; é um ambiente inicialmente hostil ao nosso irmão. Portanto, muitos designers de UI / UX de jogos nem consideram os recursos do Unity como uma ferramenta para seu trabalho. Mas você não é um desses, é?
Mais uma vez, qual é o lucro da criação de protótipos de interfaces para jogos imediatamente no Unity:
Eles são fáceis de integrar ao protótipo de "jogabilidade" e obtêm uma imagem muito mais holística e impressionante do produto futuro.
Partes de protótipos fabricados no Unity podem ser reutilizadas diretamente em um projeto de "acabamento". Isso não funcionará completamente - os programadores provavelmente oferecerão para colocar suas extensões de design para o Unity em algum lugar mais profundo, mas em partes e telas separadas - é muito possível.
Esses protótipos funcionarão em dispositivos exatamente da maneira que você deseja. Será adequadamente esticada e dimensionada. Considerará franja e áreas seguras. Sem discrepâncias com o resultado final, beleza!
Tais protótipos editam com facilidade e rapidez "rapidamente". Não é necessário repetir o mesmo trabalho primeiro no Princípio, depois na Unidade. Você pode até fazer alguma coisa sem passar pelo photoshop.
Possuir Unity dá ao designer acesso a interfaces tridimensionais e controle da interface a partir do interior do mecanismo.
Além dos bônus diretos, existem os seguintes: conhecer o motor facilita muito a vida em geral e também aumenta seu valor como especialista no mercado de trabalho.
Em geral, eu queria dizer tudo isso.
Colegas, não tenha medo de experimentar! Observe atentamente os mecanismos com os quais você trabalha e seus recursos. Faça mais, incomode, se interesse. Vale a pena.
E para isso não é necessário ser um técnico.