Bem vindo à mais um level!
É isso galera chegamos novamente na época do SPJam!!! E nós do NextLevel estamos um pouco atrasados em anunciar isso mas ele acontece agora nos dias 16, 17 e 18 de setembro.
O que é?
Para os desavisados, o SPJam é um game jam que acontece todo ano em São Paulo, normalmente em setembro na PUC campus Marquês de Paranaguá organizado por um estúdio brazuca chamado Vortex Games Studio.
Game Jam: Um evento de duração específica onde são apresentadas um conjunto de regras para a produção de um jogo solo ou em equipe.
Como funciona?
- Todos os participantes (e seus grupos) são designados para algumas salas
- Há uma abertura do evento no anfiteatro da PUC
- Os temas são revelados
- Os participantes podem começar a trabalhar
- Eventos para comer e avisos de fechamento da universidade são realizados. Os avisos são dados para que as pessoas que forem retornar às suas casas não fiquem presas do lado de dentro da universidade, que fica trancada durante as madrugadas.
- No último dia a entrega é feita no site
- O fechamento é realizado no anfiteatro, juntamente com prêmios e demais anúncios
Porque é legal participar?
Existem diversas razões para participar, de certa forma essas razões podem ser bem pessoais, no entanto listamos aqui algumas que consideramos potions extras de experiência:
- Interagir com o restante da indústria e hobbistas brazucas
- Fazer amizades com os grupos mencionados acima
- Os desafios de criar um jogo em 48 horas
- A evolução após criar jogos seguindo restrições que, acreditem, só aumentam a criatividade
- Todos os pontos acima trazem um resultado inesperado: diversão infinita (claro se você levar numa boa, leve numa boa ok?)
Algumas dicas
Para aproveitar o evento consideramos de extrema importância que:
- Seja levado numa boa, não é uma competição, mesmo se houver prêmios, todos estão lá pelo mesmo motivo e como companheiros e não como inimigos.
- Se for ficar lá leve: blusa, comida, colchonete, um cobertor, régua de energia, adaptador de tomada, os softwares que usa já baixados, post-its/papel/lápis (brainstorm é massa!)
- Se for sozinho ofereça serviços para quem precisar ou junte-se à um grupo 😀
- Não gaste tempo infinito planejando o jogo, comece o quanto antes
- Não pense grande demais e se pensar reduza o escopo para uma fase ou duas
- Tenha executáveis o mais cedo possível para poder ver se a idéia está funcionando
- Acima de tudo divirta-se!
Aproveitem também e dêem uma conferida no nosso post-mortem de 2014 para mais dicas e insights, esperamos ver vocês lá.
Até o próximo nível!
Missão concluída!
Bem vindo à mais um level!
Enrascadas com atualizações acontecem e as vezes não é possível reverter facilmente se é possível reverter de alguma forma.
A dica de hoje é relacionada ao toolchain do HaxeFlixel, uma grande game engine para jogos 2D que temos utilizado em alguns projetos.
Se por acaso atualizar as ferramentas da qual ela depende usando um haxelib upgrade ou outro comando que de alguma forma altere as versões do OpenFL ou do Lime, o HaxeFlixel irá cesar o funcionamento alegando problemas para encontrar um ou ambos.
De acordo com o blog da game engine o HaxeFlixel 4.1.0 funciona apenas com versões 3.6.1 ou menor do OpenFL e 2.9.1 ou menor do Lime. Essa é a razão dos problemas após o update.
New major versions of OpenFL and Lime have been released yesterday. Installing Flixel 4.1.0 will also install OpenFL 3.6.1 and Lime 2.9.1 because we have locked it to these versions (although older versions still work).
This was necessary because this major release of OpenFL includes breaking changes that make it non-trivial for Flixel to support:
the
drawTilesAPI has been removed – this is the API used by Flixel for rendering on native targets. There is a replacement API calledTilemap, but it doesn’t support all features Flixel needs /drawTilesdid.OpenFL Legacy has been removed – not as much of a problem, Flixel has been compatible with OpenFL Next for a while (although still defaulting to Legacy).
Flixel will definitely be compatible with OpenFL 4 in the future, but this will take some time.
Para a sorte dos seus usuários a ferramenta haxelib, que acompanha o pacote na instalação, consegue dizer qual versão de uma dada ferramenta necessária para a game engine deve ser usada através do comando set.
Finalmente para resolver o problema basta executar os seguintes comandos no seu terminal
haxelib set openfl 3.6.1
haxelib set lime 2.9.1
Após isso tudo deve voltar ao normal e o desenvolvimento dos jogos pode ser continuado.
Por hoje é só, compartilhe seus pensamentos nos comentários e até a próxima fase!
Missão concluída!
Bem vindo à mais um level!
Às vezes frases de efeito podem revelar alguma sabedoria. Vamos começar logo com duas delas (ou pelo menos o que pode-se lembrar delas):
A limitação é o melhor catalisador da criatividade.
Enquanto houver recursos eles serão consumidos.
(Aceitamos referências e autores para melhorar essas frases.)
Voltando ao que interessa, como é possível que limitação alimente a criatividade?
Um trabalhador desempregado que dá um jeito de vender cachorro-quente e, no fim, cria uma rede de fast foods de cachorros-quentes é um bom exemplo. Outro são crianças com poucas massas de modelar que criam incríveis esculturas direto de sua imaginação, mesmo sem as cores desejadas. Indo além, pode-se falar das invenções malucas que surgem por falta de recursos, como casas de garrafa pet, novas formas de armazenar água, enfim, você já deve conseguir imaginar outras ideias.
Normalmente quando há muitos recursos essas ideias não surgem. Isso se deve ao fato de que o dinheiro, recurso natural, ou qualquer que seja esse recurso existe ou pode ser usado em abundância. Logo, não há nenhum fator ou incentivo que demande o melhor uso possível desses recursos.
Se limitação pode ser positiva e gerar criatividade, existiria um meio de forçar barreiras para instigar a criatividade?
Falando em criação de jogos, existem pelo menos as alternativas abaixo:
- Participar de um game jam com regras restritivas: quanto mais, melhor.
- Não ter dinheiro para produzir o jogo.
- Não ter time para produzir o jogo.
- Determinar um tempo para produção de partes ou do jogo completo.
- Escolher ferramentas com recursos limitados.
O ponto da vez é escolher uma ferramenta com recursos limitados. Nesse caso está aqui para tomar esse lugar o Pico-8 .
PICO-8 é um console de “mentirinha” para criar, compartilhar e jogar pequenos jogos e outros programas de computador. Quando ligado, a máquina lhe saúda com um terminal para digitar comandos Lua e provê ferramentas integradas para criação de seus próprios cartuchos. (tradução livre)
Logo na home page, pode notar-se um importante detalhe: “duras limitações com foco em diversão e pequenos mas expressivos designs”. O chamado não pode ser negado, experimente os jogos abaixo e depois decida se quer ou não tentar desenvolver na plataforma.
Parece-nos uma excelente oportunidade de aprendizado, diversão e expressão que podem ajudar a impulsionar uma desenvolvedor de jogos para o próximo nível.
Conte nos comentários como foram suas experiências com o Pico-8 e compartilhe outras formas que acredite serem interessantes para deixar a criatividade rolar solta.
Missão concluída!
Os jogos têm se tornado um interessante meio para a divulgação de conhecimento, ensino, treinamento, e até mesmo propaganda. Devido ao seu potencial de engajamento (“puxa, um jogo! Que legal! Vou dar uma olhada…”), eles têm sido cada vez mais empregados com propósito de ensinar, sendo as vezes chamados de “jogos sérios”. Só que o tiro pode sair pela culatra, uma vez que por mais brilhante que seja o conteúdo transmitido por um jogo, ele não vai ser necessariamente assimilado por ninguém se o jogo for chato, podendo até gerar o resultado oposto: fazer as pessoas desgostarem do assunto (“ah, que droga! Put@ jogo chato! Certamente é por tratar desse assunto besta ai…”).
O fato é que todo jogo, sem exceção, ensina alguma coisa. No mínimo um jogo ensina ao jogador como fazer as ações necessárias para jogá-lo. Bons jogos têm valor em ambos aspectos utilitário e hedônico. O aspecto utilitário é aquele associado com uma curva de aprendizagem relacionada às habilidades necessárias para vencer os desafios propostos e atingir os objetivos oferecidos. O aspecto hedônico é aquele associado aos gostos e preferências dos jogadores, relacionados não apenas aos tipos de tarefas e opções de ação disponíveis, mas também à fantasia, ambientação e personagens. O aprendizado ocorre em qualquer um desses aspectos porque se trata essencialmente da descoberta de padrões.
Segundo Ralph Koster, em seu fantástico livro A Theory of Fun for Game Design, um jogo nada mais é do que um padrão que atiça a curiosidade do jogador, sendo suficientemente diferente a ponto de ser desconhecido e interessante, mas similar a algo já conhecido a ponto de não causar simplesmente confusão. Certamente Koster leu o famoso livro de Mihaly Csikszentmihalyi sobre a sua Teoria do Fluxo. A ideia essencial dessa teoria é que a satisfação (em uma tarefa, mas que facilmente se acumula nas tarefas do dia-a-dia a ponto de definir a satisfação com a vida) tem uma forte relação com o esforço de atenção que alguém intencionalmente coloca em uma atividade, tendo-se em vista que a nossa capacidade de atenção é limitada. Aquilo que é mais interessante (por qualquer motivo, seja ele externo como dinheiro ou alimento ou interno, como o desejo de se divertir) naturalmente atrai a nossa atenção fazendo com que esqueçamos de todo o resto. Depois que algo curioso, interessante é aprendido (chamado pelos autores de “Chunking” a partir da ideia de que algo se torna trivial após ser aprendido pelo sistema nervoso autônomo), não mais requer esforço de atenção e por isso passa a ser desinteressante (por exemplo: você contou quantas vezes trocou a marcha do seu carro na última vez que dirigiu? Provavelmente não. Mas certamente essa tarefa tinha mais da sua atenção na época em que você estava aprendendo a dirigir).
Se você não acredita que a sua atenção é limitada e seletiva, experimente fazer esse famoso teste antes de continuar a leitura. 🙂
As pessoas aprendem mais diretamente com o aspecto utilitário dos jogos porque esse aspecto envolve diretamente a execução de ações sobre o mundo (virtual, no caso). Tais ações precisam ser aprendidas, e o jogador precisa constantemente observar seu resultado para analisar o quão próximo está dos objetivos desejados. Assim, é natural que o aprendizado com jogos ocorra por tentativa e erro, e as vezes até por observação (dos resultados de outros jogando), tal qual como na vida real. Mas o aprendizado ocorre também no aspecto hedônico, uma vez que a fantasia existente no mundo serve como forma de apoio de novos conhecimentos. Afinal, algo novo é mais facilmente aprendido se pode ser comparado com algo que já se sabe, e a fantasia ajuda exatamente nesse sentido. Por exemplo, sentir empatia por personagens facilita assimilar os resultados de suas ações (um vilão é mau não necessariamente porque se veste de preto, mas porque tomas decisões que são consideradas maléficas).
Então, como ensinar com jogos?
Essa é a pergunta-chave: como ensinar conteúdos mais “nobres”, digamos, não necessariamente apenas relacionados apenas com a mecânica ou a fantasia do jogo. Ou, como fazer com que as habilidades aprendidas ao se jogar possam ser extrapoladas para o mundo real? Não há uma resposta simples para essa pergunta. Muitos projetistas erroneamente transformam jogos em testes disfarçados, simplesmente por focalizarem seus esforços demasiadamente na transmissão do conteúdo intencionado ao invés de na diversão proporcioniada pelo jogo. Retomando a discussão sobre a motivação, bons jogos oferecem motivação intrínsica no sentido de que os jogadores jogam porque gostam, porque querem, sem a existência de qualquer motivação externa como dinheiro, presentes, boas notas, etc. Há vertentes que propõem o aprendizado tangencial: o jogo é mais utilizado como meio para deixar o jogador envolvido com o assunto, que pode então ser explorado em mais detalhes em outro contexto (fora da sessão de jogo). Quando o assunto é retomado, em um contexto mais sério (como a sala de aula), o interesse pelo assunto (história da Revolução Francesa, por exemplo) já foi facilitado por experiências satisfatórias anteriores (com a diversão proporcionada pelo jogo Assassin’s Creed, por exemplo).
Mas há também vertentes em que propõem uma mais direta relação entre as habilidades e empatia necessárias no jogo com aquelas do mundo real. Essa é também bastante interessante, mas um pouco mais difícil (até porque o projeto de um jogo assim requer não apenas game designers como também especialistas no conteúdo relacionado, e o jogo precisa ser constantemente avaliado a respeito de sua primitiva máxima: ser divertido antes de ensinar qualquer coisa). A primeira abordagem, a tangengial, pode ser explorada realmente com qualquer jogo. Tetris pode ser utilizado para facilitar uma aula mais séria a respeito da cultura Russa, por exemplo. O fantástico jogo de cartas chamado Once Upon a Time, com uma mecânica simples e uma fantasia baseada em Contos de Fadas, não foi criado para ensinar nada – apenas para divertir. Porém, ele é amplamente utilizado por professores de inglês como forma de exercitar vocabulário e expressão oral. De fato, professores já têm explorado essa ideia há muito, muito tempo, com os mais diversos tipos de jogos.
Mas há jogos que já exploram brilhantemente a segunda abordagem, utilizando em sua mecânica habilidades que são muito próximas àquelas que se deseja ensinar. Vejamos alguns exemplos.
Um exemplo simples é o jogo Space Math, criado por Dabney Blum. Nesse jogo, o jogador controla uma nave alienígena que precisa coletar bolas de energia. O movimento da nave é controlado por equações matemáticas de primeiro, segundo e terceiro graus, que são ajustadas pelos parâmetros definidos em um painel de controle. Nas fases iniciais, uma linha traça o “caminho planejado” para a nave, conforme os parâmetros são ajustados, ajudando o jogador a decidir os parâmetros. Mas nas fases posteriores, essa linha de auxílio não existe mais, e o jogador deve prosseguir sem ajuda. Pode-se observar claramente um mapeamento entre a habilidade no jogo e a habilidade do mundo real (por exemplo, entender como o valor independente da variável x afeta a curva matemática, ou entender como o grau do polinômio modifica seu traçado). Ainda assim, esse não é o melhor exemplo porque o uso da habilidade ainda não está tão bem casado com a fantasia. Teria sido mais efetivo se os parâmetros descrevessem propriedades reais e significativas no jogo (tais como combustível, distância, tempo, etc), e a função auxiliasse o jogador a otimizar seus recursos (ou seja, se a mecânica se adequasse de uma forma melhor à fantasia).
Outro exemplo é o jogo de código-aberto chamado CodeCombat. Nele o jogador controla um aventureiro por meio de instruções precisas em uma linguagem de programação qualquer. Tal como no mundo real, há inúmeras formas de solucionar um problema proposto (pegar todas as gemas, evitando armadilhas ou inimigos, por exemplo), e o jogador aprende com a mecânica como evitar repetir a digitação da mesma instrução várias vezes (utilizando comandos específicos para repetição, tal qual ao programar de verdade). Ainda que esse tipo de jogo tenha uma clara alusão ao aprendizado de programação, o jogador é levado a aprender passo-a-passo (isto é, inicia realmente digitando múltiplas vezes as instruções, e só depois aprende que as estruturas de repetição servem como forma de incluir uma lógica mais “enxuta”). Compare esse jogo com outros similares (como o igualmente fantástico Coding Game), para perceber que não se trata apenas de usar programação como forma de resolver problemas, mas de entender passo-a-passo como o conceito da lógica se aplica no controle de algo que de fato resolve o problema (e esse é o verdadeiro aprendizado do jogo CodeCombat: a lógica, independente de linguagem – na minha humilde opinião).
Finalmente, há o exemplo que eu acho mais brilhante: o jogo The Bézier Game, criado por Mark MacKay. Esse jogo é um puzzle em que o jogador deve preencher uma figura com linhas retas e curvas utilizando um número máximo de pontos de interseção (que conectam trechos retos e curvos). Ao clicar para colocar um novo ponto de interseção, o jogador pode segurar o botão do mouse pressionado e arrastar o ponteiro para fazer curvas diversas. Uma fase é concluida com sucesso se o jogador conseguir preencher (isto é, desenhar) a figura proposta utilizando no máximo todos os pontos de interseção disponíveis (ou menos, caso em que o jogador aumenta a pontuação obtida com a solução). A habilidade envolvida nessa mecânica (habilidade de planejar e traçar curvas utilizando pontos para a distorção de retas) é *exatamente* a mesma necessária para entender as chamadas Curvas de Bézier, que advém de um importante conceito matemático amplamente utilizado na computação gráfica. A mecânica desse jogo seria mais genial apenas se esse método de interação já não tivesse sido pensado e utilizado em contextos mais sérios, como o desenho dentro de ferramentas de edição gráfica como Photoshop ou o Gimp, por exemplo. 🙂
Esse vídeo é um trecho do filme “Meu Tio” (título original francês: Mon Oncle), uma comédia de 1958 dirigida por Jacques Tati (imdb: http://www.imdb.com/title/tt0050706/). O filme é sobre um senhor que visita a irmã e o sobrinho, e tem dificuldades com a tecnologia que os cerca. No trecho, o senhor tenta utilizar/explorar a cozinha da casa e falha miseravelmente.
Esse vídeo é uma ótima metáfora para a UX (Experiência de Usuário) provida na maioria dos sistemas computacionais modernos, seja no aplicativo que você usa pra se lembrar de tomar seu remédio ou naquele jogo que baixou no final de semana.
Alguém poderia argumentar que como o objetivo do filme é o humor, as interações são exageradamente incongruentes. No entanto, também é fácil argumentar que se trata de uma sátira às dificuldades reais que experimentamos com tecnologia no dia-a-dia (desde 1958 e ainda hoje). Os pontos que vou discutir a seguir advêm do fato de que grande parte dessas dificuldades decorrem do pouco esforço dos projetistas em preparar as interações para que não sejam confusas para os seres humanos.
O dispositivo de choque
Logo na entrada da cozinha, há um dispositivo cuja função é difícil de determinar. Primeiramente porque não se parece com nada que já vimos em uma cozinha, então não é trivial fazer correlações com experiências passadas. Em segundo lugar, sua localidade não é de muita ajuda como indicação de seu uso. Se estivesse próximo de uma mesa, talvez sua intenção fosse servir como descansador de pratos. De fato, ele parece mais com uma barreira que impede o acesso ao que se encontra atrás (cujo uso também é nebuloso). O que torna ainda mais parecido com uma barreira é o fato de que ele dá um choque quando tocado.
O choque pode ter sido intencional (se for realmente uma barreira) ou não (caso ainda pior, já que não há proteção alguma para esse efeito adverso da eletricidade, potencialmente necessária para qualquer outro fim). Barreiras são formas de proteger o usuário contra erros ou ações que podem causar danos. São importantes em muitas interações, mas as vezes o excesso de zelo também é prejudicial.
Um exemplo do nosso dia-a-dia pode ser uma aplicação que permite utilizar o flash da câmera no celular como lanterna. Você abre a aplicação, liga a lanterna, usa pra achar algo que estava procurando, e então toca no botão “voltar” do seu celular. A aplicação pergunta: “Tem certeza que quer sair?”, e impede a si mesma de ser fechada até você selecionar a resposta “Sim”. Essa pergunta, que seria uma importante proteção no Microsoft Word, por exemplo, caso você tivesse clicado em sair sem gravar seu texto, é completamente inútil no aplicativo de lanterna e simplesmente atrasa o usuário. Para completar, o usuário está acostumado com o uso do botão voltar, que é físico no dispositivo e amplamente utilizado para fechar aplicações. Enjuriado com a pergunta, ele pressiona novamente esse botão, e a aplicação simplesmente fecha a mensagem com a pergunta voltando para seu estado “natural” (aberta, com a luz ligada, que na verdade é pouco natural com relação a tudo o que o usuário já aprendeu anteriormente em outras aplicações). É, só faltou o choque para virar uma piada em um filme.
O resto da cozinha também dá choque?
Experiência é justamente o que a palavra significa: qualquer conhecimento, sabedoria ou perícia adquiridos em atividades práticas ou cognitivas. Assim, ela decorre da nossa interação com o mundo. Então, qualquer interação produz experiências e atualiza constantemente a nossa percepção individual do mundo. Ora, por isso é tão natural que após levar um choque o senhor do vídeo se preocupe se outras coisas no ambiente também dão choque.
O problema na interação ilustrada no vídeo é que não é fácil saber a causa do choque. Poxa, a tal barreira estava na altura das mãos, qualquer pessoa poderia tê-la tocado daquela mesma forma. Se o choque tinha um caráter de proteção, o usuário não teve feedback apropriado sobre o que fez de errado, e logo não tem como aprender a evitar fazê-lo novamente no futuro. Obviamente não é a cor, dado que toda a cozinha é essencialmente branca. Talvez seja o formato fino e curvado, mas ai é então mais natural pensar que coisas como maçanetas também darão choques. E nesse caso, vai se ter ainda mais confusão quando não se receber choques de maçanetas…
Apesar do choque ser uma experiência desagradável, essa confusão pode acontecer também em interações agradáveis ou pragmática (que têm um caráter utilitário, de fazer ou resolver algo) e nesse caso vai ser ainda mais frustrante porque o indivíduo não conseguirá saber como alcançar seus objetivos (por exemplo, quero só cozinhar um ovo!). No nosso dia-a-dia também há inúmeros exemplos, pois a falha em fornecer feedback de ações e manter padrões nesses feedbacks é a mais comum. Aplicações que não diferenciam botões de outros elementos visuais (elementos que permitem executar ações x elementos que apenas apresentam informações), ou que não diferenciam um botão que pode de um que não pode ser clicado/tocado, são exemplos bem comuns.
Por que as maçanetas não servem pra abrir o armário?
A falha em manter padrões de interação é bastante grave. No mundo em que vivemos, maçanetas são amplamente utilizadas para abrir e fechar portas, janelas e armários. Além disso, do ponto de vista cognitivo e motor, algo que pode ser pegado (isto é, que você pode fechar as mãos ao redor) atribui grande “significado” (leia a respeito de affordances na Wikipedia) sobre a ação de puxar. De fato, maçanetas costumam dar mais significado sobre a ação de puxar do que a de empurrar (tanto que as portas de segurança em cinemas usam barras verticais, que naturalmente são mais fáceis de serem empurradas, principalmente em um cenário de emergência). Assim, o fato no vídeo de que as maçanetas não abrem os armários vão contra não somente o que é cognitivamente mais natural como também vão contra todos os padrões culturalmente estabelecidos. É uma receita adicional para confusão.
Infelizmente isso acontece muitíssimo no nosso dia-a-dia. Em um shopping de São Paulo, o quiosque para pagamento do estacionamento é touch-screen e apresenta na tela um teclado para digitação do CPF (para quem pede a nota fiscal paulista). O botão CANCELAR e o botão OK estão em uma posição invertida ao que a maioria dos sistemas tradicionalmente utiliza. Mas, o pior é que o botão CANCELAR é muito maior do que o botão OK. Observando as interações das pessoas, já vi muitos selecionarem CANCELAR apenas porque estão com pressa e o maior botão tem grande significado de ser a ação mais importante naquele contexto.
Empurrar ou puxar: as características dos objetos qualificam as ações mais significativas
Por que os botões no fogão acendem luzes em lugares distantes do fogão?
Para completar a confusão, basta você oferecer o feedback no lugar errado. No vídeo, ao apertar algum botão no que parecer ser o fogão (uma inferência minha, dada a indicação de cor preta – a única essencialmente diferente do restante da cozinha), uma luz se ascende em um painel com três luzes, distante do fogão/equipamento utilizado, e um zumbido é emitido. O cérebro humano foi ajustado pela evolução para tentar identificar padrões. Então, mesmo que tenha sido uma coincidência (painel de luzes+zumbido não têm nada a ver com o fogão/equipamento utilizado), o usuário vai concluir que essa relação existe. Principalmente porque não teve nenhum feedback da ação no próprio equipamento que foi o foco da ação. Se tal equipamento desse por si só esse feedback, a possível relação infundada seria mais facilmente descartada.
De todas as formas, supondo que realmente exista essa relação, a interface está muitíssimo mal projetada a ponto de causar confusão. No fogão há vários botões e manivelas, espalhados pela superfície, enquanto que no painel há apenas três luzes dispostas verticalmente. Por que a ação em um botão no canto superior direito acende uma luz no meio de um painel distante? Simplesmente não faz sentido. Sugiro que nesse momento você vá até o seu fogão e veja como ele foi projetado. Certamente ele tem botões que acendem cada boca de cozimento. Talvez ele tenha ilustrações ao redor de cada botão (bolinhas vazias e uma cheia é a escolha mais comum). Mas pode ser que os botões, sem legenda alguma, estejam dispostos da mesma forma que as bocas, de forma que você é naturalmente capaz de entender qual botão acende qual boca. A escolha pela ilustração é mais comum quando os botões não podem ser arranjados em uma forma similar às bocas (por motivos de espaço provavelmente), mas a escolha de design de manter os botões nas mesmas posições relativas às bocas faz muito sentido (com ou sem legenda). Você certamente iria perceber isso com facilidade em um cenário de falta de energia, em que você precisa acender uma boca de fogão sem ser capaz de enxergar a legenda ilustrativa (ou se ela já se apagou com o tempo de uso). Claro, você pode argumentar que já decorou qual botão acende qual boca, e é natural que as interações se tornem mais fáceis com o uso. Porém, a facilidade de uso deve estar presente desde as primeiras interações para que o usuário não se desmotive de utilizar algo difícil e confuso.
Legendas relacionam os botões com as bocas que acendem
Exemplos do dia-a-dia também são muito comuns. Em minha experiência pessoal, os aplicativos de fotos em celulares são confusos quando se precisa enviar fotos para outras pessoas. Um aplicativo que eu utilizo é muito intuitivo para tirar fotos e para listá-las. É também intuitivo enviar uma única foto para alguém, pois basta segurar o dedo sobre a foto (interação que é padrão no sistema operacional Android) para aparecer um menu com as opções de envio. Porém, por tentativa e erro, eu descobri que segurar o dedo sobre o nome da foto é diferente de segurar o dedo sobre a miniatura (thumbnail) da foto! Somente a segunda opção exibe menus que permitem selecionar mais de uma foto para envio. Essa interação deveria estar sempre disponível no mesmo menu de contexto, ou deveria haver claramente um botão para isso em algum lugar da mesma tela em que as fotos são listadas (até porque nem todos os usuários estão realmente acostumados com os padrões de interação do sistema operacional, então facilitar aqui também seria uma boa ideia).
Como foi que o armário abriu?
Em uma cena do vídeo o senhor se aproxima do armário e ele se abre, liberando uma jarra esférica. Mas, como o armário abriu? Foi pela proximidade ou foi por se ter pisado em algo? Novamente, aqui se recai na questão do feedback de ações. Se o armário abriu por algo que o usuário fez, ele precisa ser capaz de perceber isso para poder repetir a ação quando desejar. Mesmo que seja algo totalmente automatizado, ainda assim precisa haver uma relação com propósito de uso (será que o armário leu a mente do usuário e percebeu que ele queria fazerum suco?), para que o usuário saiba identificar as situações em que tal automatismo deve ocorrer.
Adicionalmente, automatismo precisam ser configuráveis. Nada é mais frustrante para um usuário humano do que ter um sistema computacional que toma decisões que parecem arbitrárias e que não podem ser contestadas. Tenho um exemplo bem pessoal, que é uma interface humano-computador ainda que não seja de um sistema de software. Meu carro tem um sistema que acende os faróis automaticamente, conforme o nível de iluminação. A ideia é bem bacana, já que ele acende e apaga os faróis sozinho quando eu entro e saio de um túnel. Eu sei poucos detalhes sobre como ele mede o nível de luminosidade (há uma matriz de sensores no parabrisa), mas do ponto de vista de um usuário médio isso não deveria mesmo importar. Só que é bem comum que esse sistema julgue que deve acender os farois em ocasiões em que eu julgo que não deveria. Por exemplo, agora que há o horário de verão, se é por volta das 18:00 e eu entrei em um túnel, ele acende e não apaga mais mesmo após eu sair do túnel. Talvez a programação conclua que já é de noite, mesmo tendo bastante iluminação. Ou, se o parabrisa está um pouco mais sujo, ele também acende mesmo as 15:00, se o dia está um pouco mais nublado. Até ai, tudo bem, já que esses erros são pouco frequentes. O problema é que uma vez que ele acende os farois, eu não posso desligá-los! Não há opção para isso, a não ser que eu desligue completamente o sistema automatizado (que eu não queria fazer, já que ele é bacana na maioria dos casos). As opções que me restam é deixar ligado, ou avançar para a lanterna baixa (isso ele permite) ao menos pra não incomodar os demais motoristas desnecessariamente.
Por que a jarra quica/pula quando cai?
Novamente, eis uma questão sobre o uso de padrões. Após abrir o armário no vídeo, o senhor tem acesso a uma jarra e a um copo. A jarra tem um formato esférico e – curiosamente – quica/pula quando cai. Talvez isso seja uma proteção contra acidentes (algo potencialmente bacana, mas que derrubaria o líquido da mesma forma). Isso é intencional? Não se sabe. As caraterísticas da jarra ajudam a entender um pouco (o formato esférico, e o material branco – provavelmente plástico), mas o senhor basicamente descobriu essa “função” por acaso. Ao pegar o copo ele tenta fazer a mesma coisa e o copo se quebra.
Sim, esse exemplo é bem mais forçado. O copo não tem as mesmas características da jarra e então é mais difícil o senhor ter se confundido a respeito de eles terem também o mesmo comportamento. Porém, jarras e copos têm funções muito próximas (armazenam líquidos), e por isso faz algum sentido imaginar que teriam comportamentos semelhantes. É também por isso que a piada é potencialmente engraçada, pois até o humor requer relação com algo que já se sabe para ser compreendido.
Há então dois pontos aqui, que podem ser úteis no nosso contexto de projetistas de sistemas para pessoas. Primeiramente, padrões são importantes pois ajudam às pessoas a entenderem mais facilmente como usar um novo produto ou fazer uma nova tarefa. Isso já foi citado anteriormente e não deveria requerer mais nenhuma exploração da minha parte. Mas há também a questão de que funções desnecessárias as vezes podem trazer problemas. No caso da jarra, a tal “função desnecessária” era quicar como uma bola, e o problema foi o usuário ter achado que isso acontecia também no copo. No mundo real, funções desnecessárias implementadas em um sistema computacional podem apenas ocupar espaço (tanto como dispositivos em um equipamento de hardware como em bytes no software que precisa ser baixado), já que o usuário não vai, ou melhor, não devia utilizá-las. Mas, principalmente, elas podem também causar confusão. Imagine um sistema web para a venda de bilhetes de cinema que, na mesma tela da venda, apresenta trailers de outros filmes que não são o filme cujo ingresso está sendo comprado. Qual é o propósito dessa função no contexto atual? O máximo que ela irá fazer é distrair o usuário até que a venda seja cancelada por tempo expirado (timeout). Claro que o usuário deve ser capaz de navegar pelos filmes existentes para escolher um para assistir, mas esse é um contexto diferente do contexto de venda.
Concluindo
Não importa o quão evoluída e útil é uma tecnologia, problemas na interação – como os ilustrados nesse vídeo – prejudicam a experiência dos usuários e podem fazer com que eles desistam de tentar usar ou adquiram resistência a novas tentativas futuras. Esse problema é especialmente grave no contexto de sistemas de entretenimento, já que os usuários não são obrigados a usar o sistema que você projetou (não é trabalho, é lazer). No caso de sistemas de software, há também o fato de que comumente os usuários têm escolhas, podendo facilmente baixar outro sistema similar para usar no lugar do seu. Não há mágica: para evitar esses problemas você precisa primeiramente conhecer os erros mais comuns, mas principalmente avaliar as suas escolhas de design com os usuários, ouvindo-os a respeito de suas dificuldades e sugestões de melhoria. O design de sistemas interativos é inerentemente… interativo. 🙂
Bem vindos à mais um Level
Existe um estigma com os jogos que tentam ensinar e divertir ao mesmo tempo, normalmente eles pendem mais para um lado ou mais para outro. Além desse fator de equilíbrio que é extremamente difícil há a questão do preconceito contra jogos que se declaram educativos ou que tem esse objetivo de forma mascarada.
Mas então será que não é possível produzir jogos que sejam educativos ou tenham algum fator de aprendizado e ainda assim sejam jogos incríveis. Pois bem, aqui vão alguns exemplos que conseguiram chamar nossa atenção.
Languinis
Um puzzle match-3 no qual as gemas se transformam em letras quando combinadas, a partir dai é preciso formar palavras, quanto maiores mais poderoso o combo e a pontuação. Uma ideia aparentemente simples que foi muito bem executada.
O jogo tem como mote a libertação do povo languini (parecidos com mayas, astecas ou incas) preso pelo deus fênix após fracassarem na missão de nomear todas as coisas existentes.
Dentro do jogo – Languini
O visual do jogo casa muito bem com a premissa das letras através de seus personagens, cada máscara de um languini é uma letra do alfabeto, um detalhe muito bacana e que ajuda na mistura diversão aprendizado.
A máscara-letra
Além disso o jogo não se apresente nenhuma vez como educativo, ele o faz quase que através de uma inércia planejada, uma vez que o ponto de aprendizado aqui é conseguir formar palavras e para tal você provavelmente vai acabar buscando várias delas no dicionário. Esse é o ponto em que percebemos o quão bem feito é seu game design, o jogador acaba não percebendo a intenção de ensinar uma vez que ela foi misturada dentro do gameplay onde o objetivo não é apontado como aprender (esse fica subentendido) mas sim libertar os languinis através de combos com gemas e palavras.
Alphabear
Assim como Languinis, Alphabear é um puzzle de palavras no qual o aprendizado é mascarado e nesse caso é tão escondido que até danifica levemente a experiência do jogo em si.
Nesse jogo ao juntar várias letras próximas uma área é liberada fazendo com que ursinhos fofos brotem no espaço aberto, caso os ursos estejam próximos eles crescem de tamanho. O ponto do aprendizado estaria também em formar grandes palavras, o problema desse jogo com relação ao Languini é falta de exigência de que as palavras façam sentido para serem aceitas, ao descobrir isso o jogador pode esquecer de formá-las e simplesmente ir juntado letras que sejam aceitas pelo jogo.
Mesmo com esse pequeno detalhe existem alguns pontos do game design que ajudam a prender o jogador e ainda ensinar como ursos fofos que ajudam com poderes que lhe darão mais pontos, palavras maiores são difíceis de formar se não forem reais, quanto maiores os ursos maior a pontuação.
Apesar de algumas falhas e de ser um jogo puramente em inglês (Languinis tem pacotes de línguas com pt-br) o jogo ajuda no aprendizado do inglês de forma disfarçada e possui ursos fofos que podem atrair não somente adultos mas também crianças.
Alguns jogos antigos
Não é de hoje que se fala em criar jogos que ensinam ou softwares de ensino com jogos, sim há uma diferença a qual não comentaremos agora, e é muito interessante analisar vários deles antes de iniciar a produção de um novo jogo com algum grau de aprendizado.
Um desses jogos é o Bit-bot Math’s Voyage da Sanctuary Woods, esse jogo educativo de 1995 tinha como objetivo ensinar matemática de forma interativa para crianças entre 5 e 8 anos. Apesar da baixa qualidade das imagens, a resolução não era muito boa em ’95, as atividades eram razoavelmente divertidas e era possível entrar no flow aprendendo matemática sem perceber.
Caixa do Bit-bot’s Math Voyage (CD-ROM)
Aparentemente a década de 90 teve uma grande quantidade de jogos com algum teor educativo e além do robozinho matemático Bit-bot outro personagem bem carismático que ensinava inglês, cores, lições de moral, lógica, entre outros, era o Putt-Putt. Esse personagem era um conversível roxo com aparência dos cartoons de domingo e seus jogos eram adventures point-n’-click, bem famosos durante sua década.
Assim como todos os jogos do Putt-Putt a Humongous Entertainment aparentemente tentava com todos seus outros jogos ensinar de forma subentendida e portanto era muito difícil se entediar com os jogos e ainda assim foi é possível aprender. Aqui é um ponto de experiência própria, as pessoas me questionam muito como aprendi inglês “sem nunca estudar”, na verdade eu sempre estudei desde pequeno de forma agradável e gradual e esse jogos me ajudaram no processo sem ao menos eu ficar trancado em aulas chatas com pessoas desinteressadas.
Um dos jogos do Putt-Putt
Conclusão
Jogos educativos não precisam ser chatos e muito menos se auto declararem como educativos, além disso ser educativo não deve ser algo pejorativo, mesmo com uma sociedade que ainda vê esses jogos com maus olhos é possível esconder propósitos de aprendizado em horas de diversão. Tome como base outros jogos que atingiram esse estágio de excelência e bom game design!
Missão cumprida
Notas:
Sempre que usamos uma IDE para criar um software, normalmente um conjunto de regras é gerado para que os códigos-fonte sejam compilados em um binário. Mas e quando não queremos depender de uma IDE específica? Neste caso, podemos usar o comando make!
Bem vindos à mais um Level
Têm se falado muito do Unity como a tentativa de ser “A” ferramenta para desenvolvimento de games, tanto indie como até inclusive em empresas maiores.
No entanto ela não é a única ferramenta criada e mantida por desenvolvedores “parrudos”, por assim dizer , dentre essas ferramentas existe uma cujo anúncio dos últimos dias fez um certo barulho.
O projeto de colocar Haxe/OpenFL para rodar nos consoles e por consequência poderíamos usar engines baseadas na tecnologia, ex: HaxeFlixel.
Dê uma olhada na post do Gamasutra para a reportagem e entrevista.
Mas porque isso é importante?
Uma tecnologia toda Open Source com um eco sistema de outras ferramentas Open Source é um prato cheio para toda a comunidade de desenvolvimento de jogos, principalmente os indies.
Para quem possuí poucos recursos significa poder iniciar toda uma cadeia de desenvolvimento gratuitamente, lançar os jogos nas plataformas abertas e quando possível adquirir os dev kits das plataformas desejadas apenas para realizar os ajustes finais.
Espera um pouco você disse dev kits?
Apesar do fato de que o combo Haxe/OpenFl é Open Source, isso não significa que os kits de desenvolvimento de plataformas como WiiU, PS4 e XboxOne são também. Infelizmente ainda é necessário adquirir um destes para conseguir testar o jogo e de qualquer forma o programa de desenvolvimento dessas empresas não é de graça. Mas até aí a Apple e o Google também cobram, a vantagem destes é que eles são menos onerosos nos nossos bolsos.
O que tem de bom além do valor?
Se o fato de ser grátis, enquanto não adquiridos os programas dos consoles, não é o bastante pense nessas vantagens:
* A linguagem Haxe é parecida com Actionscript, muito mais fácil de dominar do que C++ e ainda assim tão poderosa quanto.
* Multi-plataforma com a adição dos consoles. Além de que hoje é possível exportar para web, desktop e mobile.
* Engines baseadas em irmãs do mundo flash com uma boa gama de ferramentas à nossa disposição. HaxeFlixel, HaxePunk e Flambe são três exemplos.
Nem tudo é um mar de cogumelos verdes…
Toda boa notícia vem com seus problemas:
- A solução ainda está sendo desenvolvida e não há prazo para quando irá funcionar.
- O projeto é Open Source e não é havia exatamente uma empresa por trás, a Wayforward está apoiando neste momento mas como não é movido pelos lucros pode ser que as coisas andem mais devagar. O lado bom desse ponto é que apesar da velocidade as ferramentas estão focadas em serem o melhor possível e não em arrancar dinheiro dos criadores de jogos.
- Mais ferramentas para estudar e avaliar o potencial.
- Ter que pagar os dev kits, embora isso seja uma exigência das grandes empresas e não da turma do Haxe/OpenFL, ainda é uma tristeza.
Conclusão
Em termos de negócio pode ser um bom investimento já que o público final fica maior com menos dinheiro gasto. Mas se você é um indie também pode ser bacana para manter seus jogos à espera de um dia se tornarem os mais novos títulos dos nossos amados consoles.
Missão cumprida
Bem vindo à mais um level!
Pode parecer super cliché mas inspirações para jogos podem surgir até de coisas tão banais como a realidade. Todos sabemos o quão interessante e maravilhosa, simples ou até sem graça a realidade pode ser, depende de como cada pessoa a interpreta. No entanto não devemos descartar o fato de que a vida em si é bem mais complexa do que uma leve olhada pode captar. Vamos optar por fazer engenharia reversa em algumas idéias para apresentar como a inspiração para um jogo pode surgir da realidade.
Lemmings da DMA
Lemmings é um jogo onde você deve guiar um rebanho de seres de cabelos verdes e roupões azuis de uma entrada para uma saída em diversos cenários, cada um deles possui tarefas específicas que o jogador determina pelo bem do grupo, ou seja, focado no objetivo de mantê-los vivos até a saída. Onde será que você já viu esse comportamento antes? Esse tipo de comportamento pode ser observado em vários grupos de organismos na natureza….
Que tal formigas?
Formigas cortadoras de folhas
Formigas vivem em sociedades gigantescas, tem divisão de tarefas, agem por um bem comum…. igual os lemmings! Ou será que é o contrário?! Uma excelente fonte de inspiração, dúvida? Elas possuem um jogo criado por Will Wright e Justin McCormick: SimAnt (Maxis – 1991) Vamos avançar um pouco no tempo, que tal The Last of Us (Naughty Dog – 2013), os fungus que dominam a raça humana tem inspiração na vida real e adivinha quais animais fazem parte da lista de possíveis infectados? Formigas, é claro!
Formiga infectada com o fungo cordyceps
Dê uma lida na matéria da scientific american
Que tal então plantas e jardinagem?
Não fomos muito longe das formigas mas esse ponto possui um exemplo ligeiramente famoso.
Olimar e os pikmins
Pikmin da Nintendo por Shigeru Miyamoto. Ele pode não ter sido criado todo através da visão de seu mestre com relação à jardinagem.
O que nos importa aqui é como a visão de um jardim foi transportada para o jogo, mesmo que de forma alienígena, estando presente em praticamente todos os artefatos do jogo, inclusive em parte dos protagonistas os pikmins e no “jardineiro” Olimar.
Leia mais na máteria da NintendoLife
Que tal então tráfego aéreo?
Flight control da Namco Bandai
E não é só de formigas, jardinagem e fungus que as inspirações da vida real surgem.
Coisas banais como nosso controle de tráfego aéreo também podem tornar-se um jogo de potencial. Temos por exemplo o Flight Control da Namco Bandai para dispositivos móveis, no qual tudo que você precisa fazer é orquestrar quem deve pousar e decolar evitando colisões.
Pode parecer ridículo, mas minhocas usando armas bizarras para matar umas as outras também não é o que chamamos de normal (Worms). Logo pegar o dia a dia de uma torre de controle que precisa autorizar pousos e decolagens é bem justo.
Há muito mais na vida real para criar jogos do que a maioria de nós utiliza, e é possível se manter no óbvio como Flight Control ou transformar um jardim em zona de guerra alien como Pikmin, o importante é possuir uma bom deck de inspirações na manga para que seu game design e por fim seu jogo tornem-se mais interessante e divertido.
Missão concluída!
Bem vindo à mais um level!
Fontes as vezes podem ser uma dor de cabeça tremenda na criação de jogos e faz uma enorme diferença usá-las apropriadamente.
Mas não falaremos de suas vantagens ou criação, falaremos de como usar uma fonte customizada, ou seja, criada por você ou sua equipe.
Para isso você provavelmente terá um arquivo de fonte, .ttf por exemplo, e uma textura, como um .png.
Importe ambos no Unity e selecione a textura. Deve aparecer algo assim:
Mudando a textura
Selecione sua textura (o png) e:
- Mude o Texture Type para Texture
- Marque o Alpha is Transparency
Altere o restante conforme suas necessidades e clique em apply.
Para poder usar nossa textura customizada precisamos separar a fonte de seus sub-componentes, quais? Expanda a setinha ao lado da fonte para visualizar o Font Material e o Font Texture, que iremos substituir.
O font texture funciona da mesma forma que a nossa textura ou uma textura de um objeto do jogo (tijolos e água) e o material simula as propriedades desse objeto juntamente com a textura lhe conferindo um visual mais atraente.
Selecione a fonte (.ttf) acesse o menu de opções do asset, acima do botão open, e selecione Create Editable Copy.
Se sua fonte for dinâmica (geralmente é) você precisará selecionar outra opção Character de acordo com os símbolos da fonte. Unicode para chars universais, ascii ou um custom set (com sua lista de chars)
Fonte depois de criar cópia editável
Lembre-se: Quando separar a fonte ela não pode ser “colada”de volta, então se precisar da fonte original mantenha-a por perto.
Ele vai separar em três itens: a fonte, o material e uma textura. Delete a textura.
Agora selecione o material (ex: cst_material) e substitua o font texture pela fonte customizada (ex: nossa_fonte) e mude o Shader para UI > Default. Vai ficar assim:
Material com textura customizada
Se selecionar a fonte (ex: cst_font) o campo Default Material deve aparecer como o que acabamos de mudar, caso contrário basta atribuir nosso material à essa fonte.
Agora toda vez que você usar essa fonte com um objeto da UI basta alterar o material para o seu “cst_material” e o Color para branco. O branco vai funcionar como transparente, o efeito é de blend multiply, ou seja, as cores escurecem a cor da textura.
Usando a fonte e material
Pronto você já consegue usar fontes malucas com bordas e outros efeitos legais 😉
Next Level 