
O ano de 2021 está se aproximando, o que significa que já se passaram quase 4 anos desde que entrei na Pathfinder: Kingmaker development como desenvolvedor de interface. Durante esse tempo, o jogo evoluiu de um pequeno protótipo com funcionalidade mínima para um sistema enorme e complexo. O jogo passou por um lançamento, um ano de correção ativa de bugs e suporte DLC, bem como portado para o console. E agora que o desenvolvimento deste projeto pode ser considerado concluído, é hora de olhar para trás e tentar fazer uma retrospectiva de como as interfaces foram projetadas e construídas.
Decidi começar pela interface principal do jogo, na minha opinião, a partir da ficha de personagem.
Introdução
Computer Pathfinder: Kingmaker é uma adaptação do Pathfinder do jogo de tabuleiro Paizo, que é muito popular no mundo de língua inglesa e um pouco menos em todo o resto. E para que todos os participantes do desenvolvimento, sem exceção, entendessem bem o que estavam fazendo, a equipe teve uma excelente prática: um jogo de tabuleiro semanal baseado no módulo Kingmaker original.

E isso ajudou muito no início do desenvolvimento dessa e de outras interfaces, porque é a ficha de personagem que você segura em papel nas mãos, sentado à mesa.

Retirado daqui: http://runelords.peepersbog.org/index.html
Ao contrário dos meus colegas que eram mais experientes em jogos e desenvolvimento, toda a minha experiência em jogos de RPG de tabuleiro foi reduzida a jogar na minha juventude por restos das regras D'n'D e passar pelo Baldur's Gate numa época em que eu nem sabia que era feito por jogo de tabuleiro. E, claro, essa experiência é uma grande desvantagem quando você precisa transferir um jogo de tabuleiro para um de computador. Porém, agora entendo que naquele momento a falha se transformou em dignidade, pois possibilitou olhar a interface do ponto de vista de uma pessoa que nada sabe sobre o jogo. Em essência, a tarefa se tornou “explicar a si mesmo como funciona”, o que, claro, é muito mais fácil. Afinal, ninguém sabe como usar algo assim, exceto como uma pessoa que acabou de aprender isso. No momento em que a tarefa de projetar a ficha de personagem do jogo foi definida, tudo parecia muito simples:transfira para o formato digital, remova o desnecessário e pronto! E, é claro, estava errado. Quanto mais me aprofundava na estrutura das regras do jogo de tabuleiro, mais claro ficava que o Pathfinder não era um jogo por regras, mas por exceções às regras.
Design de informação
Os dados de entrada eram, em primeiro lugar, a ficha de personagem original, a documentação dos designers do jogo, o Livro de Regras Básico do jogo de tabuleiro e algum layout de interface pronto, em particular, o inventário.
Obviamente, era impossível simplesmente virar a folha de personagem de papel em uma versão de tela.
Na versão para computador, o número de habilidades foi reduzido, mas ao mesmo tempo, a exibição de condições e buffs foi adicionada. Além disso, foram acrescentadas algumas características que, via de regra, não constavam da versão em papel.
Repensar o papel existente, em conjunto com o novo, computador, levou à ideia de dividir a tela em três colunas. Porém, seria mais correto dizer, à ideia de alongar o layout de estoque já existente. O terço esquerdo da tela deveria se tornar um núcleo de informação “transversal” das interfaces do personagem e absorver as características principais. E a parte fundamental deste bloco era para ser um retrato. Ao contrário de outros RPGs modernos, onde a principal representação do personagem é uma boneca 3D, desenhamos um retrato para o papel de identificar o jogador como o herói do jogo. Isso foi enfatizado por várias razões: 1. Este é o gênero, legado espiritual de Baldur's Gate. 2. Um retrato pode expressar emoções mais complexas e caracterizar melhor o personagem, tornando a experiência de jogo mais profunda. Os outros componentes do bloco teve que responder às perguntas "quem?" e qual?":Bom meio-orc caótico, bárbaro, forte e bonito, mas estúpido, bate com um martelo assim, proteção como aquela. Os dois terços restantes foram obrigados a revelar detalhes sobre habilidades e habilidades e história. Como resultado do design da informação, todos os blocos de caracteres possíveis foram agrupados e distribuídos em colunas e páginas. Portanto, havia uma partição lógica.



Claro, isso acabou não sendo um particionamento ideal, mas foi um bom ponto de partida para um layout posterior.
Gostaria de destacar a visualização das progressões das aulas como um tópico separado. A peculiaridade do Pathfinder aqui é que, ao contrário de muitos jogos de um gênero semelhante, o desenvolvimento do personagem aqui não pode ser formalizado em um mapa de desenvolvimento estático. Um jogador pode escolher uma classe diferente em qualquer nível acima e se tornar, por exemplo, um mago de 5º nível e um ladrão de 3º nível, e isso é impossível de prever. Além disso, cada classe possui arquétipos, a escolha de qual substitui algumas das habilidades e não necessariamente no mesmo nível. E algumas das habilidades aparecem na classe somente depois que o jogador decidir sobre a divindade de seu personagem ou origem.
Para a pessoa não iniciada, a descrição de quase todas as classes parece um conjunto de habilidades obtidas em uma ordem aleatória e incompreensivelmente relacionadas entre si. Assim, na etapa de coleta de informações, a tarefa era entender o padrão de organização das aulas e formular uma ideia de como simplificar sua apresentação.
O resultado são várias tabelas de comparação com habilidades e características de classe. Talvez o uso dessas tabelas não seja tanto em si mesmas, mas nas conclusões e observações a que chegamos no processo de compilá-las.
No processo de estudo das estruturas de desenvolvimento de diferentes classes, todas as habilidades foram divididas em grupos:
- Habilidades determinantes que determinam o comportamento da classe ou o aparecimento de habilidades adicionais: escola de magia favorita, domínios, origem, animal de estimação.
- Habilidades com uma classificação, onde a essência da ação não muda, mas suas características aumentam: força, duração, etc.
- Habilidades com um componente comum semelhante. Um paladino, por exemplo, tem auras que dão bônus para coisas completamente diferentes.
- Habilidades parametrizáveis, onde você pode escolher um dos parâmetros. Por exemplo, um oponente favorito.
- habilidades solitários que podem estar relacionados a algo incompreensível.
Optou-se por visualizar tudo o que foi coletado já na fase de coleta das informações para avaliar o tamanho e as características quantitativas.

Essa visualização mais tarde se tornou o esqueleto para as páginas de desenvolvimento de personagens em todas as interfaces. Escrevemos um algoritmo para habilidades de encadeamento. Nem tudo era passível de automação aqui, e combinamos parte dos recursos manualmente para obter um visual agradável.
Além das cadeias de habilidades, as classes afetam a habilidade de usar armadura e operar com armas de um tipo ou de outro, e eu também queria sistematizar de alguma forma essa questão. Porém, aqui a sistematicidade se deu apenas nos grupos de armas, que já eram determinados pelos criadores do tabuleiro. Caso contrário, cada classe tinha algum tipo de acréscimo que desafiava a sistematização. Mais notavelmente, o Clérigo, que empunha qualquer arma simples, além da arma favorita do deus que ele adora. Conclusão: é necessário mostrar a lista completa de armas e marcar qual delas o personagem possui.
Com a bagagem recebida de informações sobre o jogo de tabuleiro, começamos a trabalhar nos layouts de interface.
Marcação de pesquisa
Ter uma divisão lógica dos blocos de informação fornece um bom ponto de partida para começar a projetar algo, mas isso não é suficiente. É muito difícil criar algo sem limitações. Nosso cérebro precisa de uma sistematização constante do ambiente e, se não tiver nada a que se agarrar, isso se torna um problema. Além do particionamento lógico, essa limitação era o sistema de três colunas, que foi gerado pela interface de inventário pré-existente. Agora chegava o estágio de criar uma apresentação visual de informações em blocos separados e uma tentativa de combiná-los de alguma forma. Os blocos que se mostraram bons, do ponto de vista de meus colegas e de mim, fluíram para os layouts a seguir. Outros foram riscados e permaneceram apenas nos arquivos, que obtive especificamente para este artigo.
Abaixo estão algumas das primeiras telas e experiências de layout. Todos eles podem ser combinados tentando espremer toda a ficha de personagem em uma tela. E se os blocos de ataque, defesa e habilidades em geral não tinham muita variabilidade, então os blocos sobre habilidades e buffs continham um número desconhecido de entidades.
Além disso, naquela época, eu subestimei muito o número de opções de habilidade e muitas vezes tentei encaixá-las em blocos muito pequenos. A propósito, ao mesmo tempo, estávamos tentando encontrar uma maneira de colocar buffs no terço esquerdo para que eles também ficassem visíveis na tela do inventário. Ao discutir o bloco de buffs, um momento interessante apareceu: colegas que conhecem profundamente as regras dividiram os estados do personagem (cansado, cego, etc.) e buffs (efeitos positivos ou negativos de feitiços). Isso está escrito nas regras e se integra bem à mecânica. Para a visualização da interface, todas essas entidades eram ícones com texto que alterava os valores de outras estatísticas. E essa discrepância é claramente expressa dentro do código do jogo, onde o código da interface leva a um denominador comum de entidades mecânicas.



Retratos de Baldur's Gate são usados nos layouts.
Após uma série de experimentos e tentativas de encaixar tudo em uma tela, ficou claro que a melhor abordagem seria a paginação e algumas das informações teriam que ser sacrificadas colocando-as em “mais um clique”.
E se toda a árvore de progressão, biografia do personagem e posse de arma pudessem ser despejados sem dor para outra tela, então eu não queria desistir com a exibição de habilidades. Várias outras variantes nasceram, incluindo uma representação radial de um personagem multiclasse. Nós o hackeamos no mesmo dia e não o desenvolvemos, porque não era adequado para personagens em desenvolvimento na mesma classe e tinha uma série de limitações técnicas.





Houve experimentos com habilidades de agrupamento aqui. Foi necessário separar as habilidades chamadas de talento, que o personagem escolhe independentemente da classe, das habilidades especiais, que são únicas para cada classe. Além disso, havia também Traits, o enredo do personagem que o jogador escolhe na mesa para um RPG mais interessante, mas no nosso caso, apenas mais uma forma de influenciar os valores das características. Também queríamos mostrar muitas características, que, no entanto, nem sempre eram úteis em relação a uma classe de personagem particular. Por exemplo, não é muito importante para um mago quão grande é seu Bônus de Ataque Base, ele não o usa ao lançar bolas de fogo. Mesmo assim, alguns blocos já começaram a procurar seu layout quase final com verificação de conteúdo.


Por se tratar de um artigo retrospectivo, agora posso dizer que mesmo essas verificações não podem levar em consideração todas as opções de conteúdo que podem aparecer durante o processo de desenvolvimento. Por exemplo, o bloco de ataque foi projetado para apenas 4 valores e não levou em consideração que, com alguma combinação de classes de personagens e feitiços, eles poderiam se tornar 6. Além disso, no momento do design, todos os participantes tinham certeza de que o layout não se moveria após a obra de arte. Mas isso também acabou sendo uma ilusão. O jogo é difícil de planejar com antecedência, é um processo vivo de criação, desenvolvimento e mudança constantes. E soluções universais e seguras, infelizmente, muitas vezes se parecem com uma planilha do Excel, sem rosto e sem emoção. Eu queria ter menos soluções desse tipo. Então, no final, em alemão, no caso de duas armas na mão,os cabeçalhos começam a ficar juntos e mesmo o ajuste do layout responsivo e o dimensionamento da fonte não conseguem lidar com isso. E a lição aqui é esta: quando o produto está quase acabado, vale a pena afastar-se dele e olhar mais uma vez para as decisões já tomadas, podem já não ser adequadas. Também há refatoração no design.
Mas aprenderemos essa lição um pouco mais tarde. E então, após as primeiras iterações da pesquisa de layout, coletei o primeiro documento de design que poderia ser discutido substancialmente com os colegas. Havia agrupamentos de habilidades, grandes blocos com classes selecionadas, tabelas de feitiços. Na progressão, adicionamos uma corrente sobre o desenvolvimento do livro de feitiços e algumas das características foram completamente abolidas.
Finalizando o design




Os layouts utilizados ícones de League of Legends.
As discussões são sempre um longo processo em nosso país, sobrecarregado por inúmeros confrontos de opiniões e interesses. Não me lembro de uma única reunião que durou menos de 3 horas. Alguns acreditam que é mais importante fornecer o máximo possível de informações mecânicas, outros - que a imersão na história e na atmosfera é mais importante, e os detalhes mecânicos podem ser ocultados mais profundamente. Na maioria das vezes, essas discussões são a única maneira eficaz de quebrar o impasse e, como resultado de uma troca de opiniões, chegar à próxima iteração com novas ideias. As páginas de biografia dos personagens e a árvore de desenvolvimento da classe como um todo foram aprovadas por todos os participantes. Mas da página principal foi decidido remover informações sobre habilidades, tabela de feitiços e outras características numéricas dos personagens. Eles decidiram fazer do enredo do jogo o centro da interface. Para o personagem principal, isso se tornou a "Roda da Visão de Mundo",e para os companheiros, criamos um conjunto de cartas de história, os principais eventos desse personagem, que vão se abrindo para o jogador conforme ele avança. Os buffs neste caso também foram removidos do terço esquerdo, mas receberam espaço suficiente para serem exibidos junto com o nome e o parâmetro de duração. Assim, a tela ficou muito mais limpa, e também mudou o foco para o fato de que este é principalmente um jogo de RPG, e só então mecânico.e só então mecânico.e só então mecânico.


As habilidades foram movidas para uma página separada. Isso tornou possível usar não apenas ícones, mas também os nomes das próprias habilidades. Posteriormente, isso acabou sendo muito importante, pois no final não tivemos tempo e recursos suficientes para desenhar ícones para cada habilidade. Além disso, codificar o significado de cada habilidade em um ícone, e mais ainda, decifrá-lo posteriormente para o jogador, é uma tarefa muito difícil. Mas, novamente, em retrospecto, devo observar que subestimei grosseiramente o número de habilidades no bloco de Habilidades Especiais e superestimei seu número no bloco de Características. Isso resultou em um layout muito desequilibrado desta tela. Que felizmente temos a oportunidade de consertar no próximo jogo Pathfinder: Wrath of The Righteous.

Também em uma página separada tem todas as informações sobre as características de combate do personagem. Esta, mais uma vez, acabou por ser uma decisão muito boa, porque ao final do desenvolvimento, o número de características nele quase triplicou.

Os desenhos acima apareceram imediatamente após aquele encontro. Em seguida, eu vou pular algumas pequenas iterações e mostrar a versão final. Nele, alguns elementos foram ajustados e ilustrações foram selecionadas, levando em consideração o orçamento e o estilo geral.




Design artístico
Este design já foi montado na versão alpha do jogo. Vale a pena fazer aqui alguma digressão importante. Em nossa equipe de interface do usuário, apesar da divisão mais frequente em designers e programadores, usamos esse perfil de desenvolvedores, quando o designer, o designer de layout e o programador são uma pessoa e o artista é outra. Isso permite que você faça a distinção entre as partes técnicas e imersivas da interface. E na época em que o projeto foi finalizado, não havia nenhum artista conosco ainda. Além disso, naquela época estávamos confiantes de que as interfaces seriam escuras, com algum tipo de forro de couro de madeira e botões de bronze. Mas o tempo passou, e quando finalmente encontramos uma pessoa que fosse adequada para nós em espírito e começamos a buscar uma solução para a arte, descobrimos que não queríamos couro e madeira de forma alguma. As cores de nossas interfaces foram invertidas e transformadas em um livro de conto de fadas sobre aventura,liberado da pena de um dos heróis. Mas os elementos de arte introduziram condições e restrições adicionais, que acabaram levando a uma mudança no layout em vários graus e revelando alguns problemas, como, por exemplo, como descrevi acima sobre os ataques. Mas, no geral, acho que as interfaces se beneficiaram muito. Assim, o sentimento geral do jogo tornou-se integral, e a interface deixou de ser apenas uma necessidade necessária, mas passou a fazer parte do jogo.





Concluindo a história sobre a parte da criação de uma interface para PC, gostaria de dizer que, infelizmente, nem todas as decisões de design foram incluídas no lançamento devido a recursos limitados. Alguns não consideramos bem-sucedidos e os estamos revisando como parte do trabalho em um novo projeto, e muitos definitivamente deixaremos. Mas o ciclo de vida do Pathfinder: as interfaces do Kingmaker não terminou aí. Tivemos que transportar para o console.
Portando para console
Pouco menos de um ano se passou desde o lançamento do jogo até o momento em que começamos a portar o jogo para o console. Durante esse tempo, conseguimos adicionar muitos recursos, detalhes, completar muito e ficar desapontado de várias maneiras. Recebemos muitos comentários dos jogadores e identificamos pedras nas quais não queríamos mais tropeçar. Em grande medida, as pedras diziam respeito ao código, muitas coisas se tornaram difíceis de manter e em alguns lugares estavam muito intimamente ligadas à mecânica. Então, abordando as interfaces de console, já acumulamos alguma base de conhecimento, mas também houve um problema. Para nós, esta foi a primeira experiência no desenvolvimento de interfaces para o console. Analisamos cuidadosamente projetos semelhantes, identificamos o que gostamos e o que não gostamos, lemos os Requisitos Técnicos, realizamos várias consultas de equipes mais experientes e iniciamos o desenvolvimento.
A interface do console, ao contrário de um PC, tem um número de características:
- 1. Eles são vistos na TV, sentado no sofá. Isto levou a um aumento no tamanho do texto ao longo do jogo.
- 2. De acordo com o TRC, é necessário ter uma zona de salvaguarda de 5%, na qual conteúdos importantes não devem ser localizados.
- 3. O cursor é uma solução complicada para o console. Portanto, não temos mais uma dica de ferramenta na qual podemos colocar uma descrição de parâmetros e habilidades.
Na primeira "passagem" pelas telas do personagem, tentou-se herdar a disposição e disposição dos elementos.



No entanto, surgiram problemas não resolvidos. O princípio do que e quando permitir alocar não é claro. Por exemplo, se eu permitir que os escores de habilidade sejam destacados na tela principal, devo permitir que eles sejam destacados na página de Progressão?
Onde exibir a descrição do item selecionado? Como rolar por esta descrição sem ir para um novo nível de aninhamento? Casos de controle não intuitivos aparecem. Por exemplo, se um jogador seleciona o elemento mais à direita com o controle esquerdo, a descrição é exibida à esquerda e rola com o controle direito.
Com base nesses problemas, além da suposição de que o console player ainda não é o principal público do jogo de tabuleiro Pathfinder, a conclusão sugere que a apresentação das informações e a estrutura das telas sejam simplificadas.
Então, depois de tentar herdar da versão para PC, a seguinte estrutura foi proposta como um modelo básico para interfaces de tela cheia:

No lado esquerdo, decidimos colocar informações estáticas das quais nenhuma ação ocorrerá.
No lado direito, colocamos a descrição contextual da entidade selecionada, ou seja, na verdade, movemos para lá a tooltip que aparecia na versão para PC quando o cursor era passado por cima. O stick direito do controlador foi usado para rolar pelas informações.
Colocamos todos os elementos de foco (botões, seletores, parâmetros, características com uma descrição) no centro. A movimentação entre eles é realizada pelo DPAD ou pelo direcional analógico esquerdo. No caso de uma grande quantidade de conteúdo, a barra de rolagem sempre tenta se posicionar de forma que o elemento fique visível ao ser selecionado. Portanto, não havia necessidade de um controle de rolagem separado para a parte central.
Para mover entre as telas da ficha de personagem, definimos "amortecedores" R1-L1.
A alternância entre os caracteres é realizada usando o menu do grupo radial quando você pressiona o gatilho direito R2.
Como resultado, dividimos a interface em 7 telas.





Esta interface foi a primeira que portamos para o console e praticamente não sofreu alterações para o lançamento. Porém, tivemos que mudar a parte inferior, que estava reservada para as dicas. A falta de uma lista completa de telas revelou-se muito inconveniente. Enquanto jogávamos, perdíamos constantemente o caminho certo. E o fato de, por exemplo, os companheiros terem uma página de suas histórias, enquanto o personagem principal não, só trazia um transtorno à navegação. Assim, a área de dica acabou se transformando em um menu, por meio do qual o movimento ainda era realizado por pára-choques.





Outra coisa interessante aqui é a navegação de progressão. Ao contrário da grade usual, onde você só pode se mover horizontalmente ou verticalmente, pode haver uma situação em que quando você pressiona "para cima", é difícil avaliar para onde quero me mover. Se houver dois elementos, um exatamente acima do elemento atual, mas duas linhas acima, e o outro uma linha acima, mas 15 ° à direita, qual elemento escolher, o que está mais próximo ou o que está na direção do vetor de movimento do stick? E se a mesma situação ocorrer ao mover-se na diagonal? Para resolver este problema, escrevemos uma navegação que leva em consideração a direção e a distância até o próximo elemento. A prioridade desses parâmetros foi determinada pelos coeficientes, que foram selecionados já manualmente com base em sentimentos.
Ficamos satisfeitos com o resultado final do trabalho nesta interface. Embora, é claro, não parecesse manter o foco no aspecto da trama como na versão para PC. Mas é conveniente tanto em termos de navegação quanto em termos de legibilidade, o que é muito importante quando se joga a dois metros da TV. Além disso, um retrato de altura total é sempre visível aqui, o que, na minha opinião, contribui muito para a atmosfera.
Conclusão
Não cabe a mim julgar se funcionou bem ou não. Você sempre pode fazer melhor ou de forma diferente. Estamos sempre dispostos a receber críticas e sugestões, sempre ficamos em dúvida, mas será que estamos escolhendo a solução certa?
O jogo não é apenas uma fábrica, onde um certo Noname faz sua peça sobressalente em nome da empresa. O jogo é uma coleção de criatividade de desenvolvedores individuais, pessoas, para cada uma das quais, este trabalho se torna parte integrante de suas vidas e parte da vida de outras pessoas, jogadores.
Agradecimentos às pessoas que participaram do trabalho na ficha de personagem:
Mikhail Rotfort - Líder UI
Vasily Levinov - Artista de UI
Vasily Boldyrev - Programador
Nikita Velikovsky - Programador
Maxim Savenkov - Programador
Oksana Merger - Programador de UI
Alexey Gusev - Engenheiro de QA
Alexander Mishulin - Diretor de Criação
Victor Surkov - Diretor de Arte
Oleg Shpilchevsky - Chefe da Owlcat Games
Autor: Pavel Turchin - Desenvolvedor de UI