Publicado em

Mudar é preciso

php-7

Mudar sempre é preciso, porém mudar nunca é fácil, ainda mais quando se trata de mudar uma base tecnológica que vem se aprimorando já a alguns anos, porém, mudar é preciso.

Já dizia Dom Hélder Câmara que é preciso mudar para permanecer o mesmo.

“Feliz de quem entende que é preciso mudar muito pra ser sempre o mesmo.” – Dom Hélder Câmara

Em tecnologia, esse tipo de mudança implica em modificar processos, melhorar e desenvolver novas tecnologias, habilidades e conhecimentos, para continuar sendo uma empresa de tecnologia que entende o que faz.

O processo é constante já que tecnologia muda a todo momento. Contudo, há algumas partes que permanecem por mais tempo do que as outras. Essas partes compõe, pelo menos parcialmente, as bases do negócio.

Pra nós, uma das bases que utilizamos chegou no momento de mudança, de um necessário upgrade a fim de mantê-la viva e funcional. Essa base é o PHP.

Nos bastidores de uma migração

Já tem algum tempo que a nova versão do PHP – a 7 – está disponível, inclusive com suporte no web-server que utilizamos na maioria dos nossos projetos. Porém, como tudo que é novo e tende a quebrar no início, resolvemos esperar a tecnologia estabilizar antes mesmo de considerar migrar a base de código de PHP 5 para PHP 7.

Um pouco disso é cautela. Decorre da experiência acumulada em anos de trabalho com desenvolvimento de software. Um pouco é comodismo. Imagina ter que ‘trocar’ milhares e milhares de linhas de código, métodos, classes e funções para um novo padrão assim de cara. O desânimo logo vem à mente, antes mesmo de se começar!

Mas mudar é preciso e se você não muda, ou evolui, por livre e espontânea vontade, irá por livre e espontânea pressão. Conosco foi um pouco das duas coisas.

Com o framework que utilizamos para fazer testes unitários em código PHP terminando o suporte ao PHP 5 em 2018, tivemos a necessidade de considerar a migração para o PHP 7. Caso contrário, eventualmente ficaríamos sem conseguir efetivamente utilizar essa tecnologia e isso não é uma boa opção.

É claro que a versão antiga do framework ainda existe, é muito estável e poderíamos continuar utilizando-a. Porém, teríamos que correr o risco de no futuro precisarmos de uma função que não estava implementada e termos que implementá-la nós mesmos. Isso não é um problema, óbvio, mas pode gerar custos indesejados.

Da mesma maneira, é possível que a versão baseada no php 7 evolua ao ponto de oferecer novos métodos de teste, muito superiores aos existentes na versão do php 5. Isso tornaria a migração muito atrativa. Então, adotando a política do “better late than never“, resolvemos estudar a nova versão da linguagem e ver o que poderíamos tirar de proveito.

E aqui vem o “livre espontânea vontade”. O PHP 7 não é um php feito do zero, que ignora o que tem antes. Ao contrário, é apenas uma evolução da linguagem, adicionando novas funcionalidades.

Sendo assim, poderíamos simplesmente adotar uma forma ‘híbrida’ entre o PHP 5 e o 7,  mantendo a maior compatibilidade possível entre as duas versões. O efeito colateral seria ignorar as algumas das novas funcionalidades disponíveis na versão 7.

Embora esse seja o caminho mais fácil, pode não ser o mais adequado. Afinal, se teremos o custo de implementar uma migração, porque não fazê-la completa? Outra questão válida é se as funcionalidades que teríamos que ignorar trariam algum bom benefício a ponto de não ser muito interessante ignorá-las.

No caso do php 7, há sim prejuízo em ignorar o que tem de novo. Mas pra entender isso, preciso listar quais as vantagens do novo php que consideramos válidas pra nós.

Vantagens do novo php

De fato há algumas novas funcionalidades do PHP 7 que já sentíamos falta a algum tempo. Citando:

Tipagem de retorno em métodos e funções

Uma das coisas que todo bom desenvolvedor PHP gosta é a tipagem dinâmica presente na linguagem. É ‘uma mão na roda’! Entretanto, uma das coisas que pelo menos nós aqui sempre sentimos falta era uma forma de identificar de maneira mais simples o retorno de um método ou função.

Há casos em que esse tipo de coisa não tem valor. Ex: se está lendo um número de um formulário, tanto faz se ele está como int/float ou string. Desde que a entrada esteja correta (seja um conjunto de dígitos referentes a número), irá processar a informação do mesmo jeito.

Porém, há situações em que você precisa de fato saber o tipo de um dado. Ex: está utilizando uma biblioteca de terceiros que realiza alguma operação e te retorna algo. Se o retorno não é informado na documentação a escolha é ler o código do método ou testar o retorno. Essa definitivamente não é a melhor solução pro problema.

Como nem tudo são rosas, há uma consequência para o uso desse tipo de funcionalidade. Se o método/função retorna mais de um tipo de valor, a funcionalidade irá complicar sua vida.

Para quem tem muito código já escrito e funcionando com múltiplos retorno, será complicado o uso da nova funcionalidade. Porém, nós não vemos essa questão como algo ruim. Afinal, em linguagens de tipagem forte (C, C++, C#, Java, etc) essa situação existe e achamos soluções pra elas lá. Então se existem soluções fora do PHP, podemos trazê-las para o PHP.

Essa foi a nossa escolha e por isso consideramos a nova funcionalidade uma vantagem necessária.

Na versão 7.2 do php essa tipagem do retorno ainda passou a reconhecer o retorno nulo.  Pelo menos pra nós, melhorou ainda mais o que já estava bom.

Novos operadores

Outra boa novidade foi a implementação de novos operadores que pelo menos tornam a codificação mais fluída.

O primeiro deles é o operador para teste de valor nulo. Antes esse teste era feito com a função is_null. Agora basta utilizar ?? em uma expressão de teste que resolve.

O outro operador que achamos legal é o “navinha”, o <=> que serve para comparar informações. Antes, isso era resolvido através do uso de if’s e else’s aninhados, o que fazia o código ficar um pouco longo.

Essa redução de tamanho de código permitida pelos novos operadores é muito útil. Pra quem escreve pouco código ou métodos pouco longos, isso talvez não faça muita diferença.  Porém,  em sistemas com milhares de linhas de código, cada linha conta. Por isso, gostamos e muito dessa novidade

Unificação entre erros e exceções

A última das boas novidades que encontramos é a unificação de erros e exceções. No php 5 erro e exceção eram coisam distintas, o que nos demandava tratá-los separadamente. O resultado era código ainda mais longo.

Com a unificação no php 7, agora podemos usar um try-catch pra resolver ambos os casos. Isso permite não só códigos menores, o que como escrevi acima é muito importante em projetos mais complexos, como também códigos mais elegantes.

Resumindo

O novo php melhorou, pra nós:

1 – o tratamento dos retornos das funções e métodos, nos desobrigando a testar o retorno ou ler o código fonte (quando disponível) em caso de dúvidas.

2 – a economia de código com novos operadores e a unificação no tratamento de erros e exceções

Pouco né? Nem tanto!

Em projetos pequenos é difícil perceber o valor dessas “pequenas” coisas. Porém quando precisa integrar seu software com o de terceiros ou mesmo dar manutenção em um código que escreveu tempos atrás, eu te garanto que irá gostar dessas mudanças “cosméticas”.

Como manutenibilidade de um projeto a longo prazo é sempre uma boa preocupação antes sequer de escrever a primeira linha de código, novidades que melhoram esse aspecto são sempre muito bem vindas.

Um pouco de maturidade no negócio

Embora a nova versão do PHP tenha as importantes vantagens que citei, não dá para simplesmente ‘reinventar a roda’ todo dia.  Os softwares dos nossos clientes estão desenvolvidos no padrão antigo (php 5). Alguns deles são extensos demais para mesmo considerarmos a atualização pro padrão novo sem implicar em custos pro cliente.

Isso nos gerou um impasse, porque decidimos usar o novo padrão, mas não podemos aplicá-lo em “tudo quanto é canto”.

A solução que encontramos foi aplicar o novo padrão apenas para os novos projetos e produtos. Assim precisaremos continuar mantendo código em padrão antigo ao mesmo tempo em que usamos o novo padrão nos novos projetos.

Um pouco confuso claro, mas a longo prazo traz muitos benefícios. Além de reduzir consideravelmente a geração de mais código no padrão antigo, podemos experimentar e amadurecer a nova tecnologia, através das novas implementações, para depois até tentar convencer os clientes a atualizar. As vezes, o próprio corte do suporte da tecnologia, como foi com o PHP 4, nos apresenta uma oportunidade para o upgrade.

Esse tipo de análise mostra maturidade. Eu não posso falar dos outros mas eu já fui muito xiita quanto a tecnologia. Sempre queria a melhor solução disponível e por melhor entenda, a melhor computacionalmente.

Acontece que no mercado as coisas não funcionam assim e trocar tecnologias para a última versão nem sempre é a melhor das opções. A maioria dos casos requer estudo e paciência para tal e isso, felizmente, já aprendemos.

Publicado em

Sql Server e suas peculiaridades

convert

Cast é uma operação consideravelmente comum na programação e em algumas situações também aparece no SQL. Neste artigo compartilhamos um pouco de nossa experiência ao implementar cast no sql server em combinação com outras operações.

 

APRESENTANDO O PROBLEMA

 

Ao utilizar SQL para armazenar e gerir os dados de um software, eventualmente será necessário realizar operações “esotéricas”, como converter uma string em um número, um número inteiro em um número real,  parte de uma string em data, etc.

Na programação chamamos de cast a essa operação de converter uma informação de uma determinada estrutura em outra estrutura e, dependendo da linguagem utilizada e dos tipos de dados envolvidos, é uma operação até bem tranquila de implementar. Mas é no SQL?

No SQL, a operação de cast depende do software de gestão de banco de dados utilizado, o famoso sgbd (ou dbms em inglês).  E esse é o tema dessa artigo.

Em um projeto em que utilizamos o framework .net e o sql server (sim, um projeto em que utilizamos ferramentas microsoft em tudo) precisamos fazer o cast de uma informação armazenada como string para outros tipos como data (date) e números reais (float).

Nós já tínhamos implementado cast antes no mysql, que fornece algumas funções de conversão de dados muito próximas das que existe na linguagem C. No sql server, não tem nada parecido e aí começaram as peculiaridades e um problema que nos tomou uma semana inteira para resolver. Isso mesmo, uma semana inteira para resolver um ‘simples’ cast.

O TAL DO CONVERT

 

Converter dados no sql server, a princípio nem é tão complexo. Ele possui duas funções internas que fazem isso pra você, de forma bem transparente: a CAST e a CONVERT.

Ambas funcionam de modo parecido porém em nosso projeto, identificamos que a CAST é mais adequada para a conversão de string para números (reais ou inteiros) enquanto que a CONVERT é mais adequada para casos mais genéricos já que permite identificar na função a formatação dos dados, exatamente o que precisávamos no projeto.

Você pode se perguntar, já que a CONVERT aparentemente resolvia o nosso problema, porque gastamos tanto tempo nessa solução? Bom, a questão é que a CONVERT resolvia parte do nosso problema, que era uma conversão genérica.

A outra parte do problema era identificar no ‘bolo’ dos dados qual conversão exatamente precisávamos implementar, ou seja, ao mesmo tempo que tínhamos que converter a string 9.5 para decimal (ou float se preferir), também estavam presente na mesma amostra informações como ‘alguma string qualquer’ que evidentemente não precisa de conversão alguma e ‘2018-01-01 00:01:53’ que deve ser convertida para DateTime e não decimal.

“E agora José?”

Agora, vamos procurar uma maneira de identificar quando e qual tipo de conversão é necessária.

Nosso primeiro teste incluiu o uso de regex, afinal, qual a melhor maneira de identificar padrões em string? Contudo, porém, todavia, havia uma pedra no meio do caminho chamada quantidade de dados da amostra.

A query em que a conversão devia ser utilizada (potencialmente, claro), buscava uma quantidade realmente grande de dados. Algo em torno de alguns milhares de registros. Daí você já consegue imaginar que regex não era a melhor solução, afinal, teríamos que rodar cada regex possível sobre toda a amostra antes de executar a conversão.

No melhor dos casos, acharíamos a conversão correta de imediato. No pior, precisaríamos rodar todos os regex até achar a conversão. Ou seja, solução ruim.

Pra tornar as coisas ainda piores, o sql server não gerava um erro ou mesmo uma exceção que pudesse ser capturada no C# listando qual conversão exatamente estava dando problema. Dessa forma, se na query tivesse algo em torno de 1000 conversões e a 501ª desse problema ele ignorava os 500 resultados corretos anteriores e simplesmente gerava um erro pouco ou nada explicativo (convertido em exceção no C#) falando que a conversão dava erro, mas não falava qual conversão.

Depois de horas e horas testando e debuggando com amostras menores, descobrimos que podíamos fazer um ‘divide and conquer à la sparta’, criando várias subquerys para converter o mesmo dado nas conversões possíveis ao mesmo tempo e depois unificando o resultado.

Utilizando esse método, escrevíamos uma query (Q) que fazia o OR de uma subquery que tentava converter o campo para int (QInt) com outra que tentava a conversão para decimal (QDec) com outra que tentava a conversão para datetime (QDat) com outra que simplesmente pegava o dado como ele estava (QDad) (Q = QInt OR QDec OR QDat OR QDad).

Por algum motivo que nunca descobrimos ao certo (mas supomos que seja por conta do uso do operador OR), o sql server não gerava exceção quando encontrava erro de conversão (ou se gerava isso não chegava no C#) e os resultados de cada conversão correta sempre apareciam.

Problema resolvido?

Ainda havia outra pedra no meio do caminho: a conversão para DateTime. Ao contrário do mysql no qual você simplesmente informa a formatação da string para o sgbd converter a stringo para datetime, no sql server tem uma complicação adicional: o style.

No sql server a formatação é um tanto fixa e pelo menos na conversão de string pra datetime é necessário informar a formatação interna em que a data deve estar (na de string pra decimal não precisamos disso).

Uma vez que encontramos o style correto, o problema do cast estava resolvido de uma vez por todas. Aí apareceu outro problema.

VAMOS COMPLICAR UM POUCO: ADICIONE UM GROUP BY

 

Além de realizar o cast de dados, também era necessário agrupar e ordenar o resultado da query.

Num primeiro momento isso pode parecer algo bobo, porém existe um pequeno detalhe no sql server que complicava a nossa vida: ele não faz ordenação de colunas virtuais.

Como em nosso primeiro estágio da solução, geramos colunas virtuais com os dados já formatados no padrão correto e o sgbd não ordenava esse tipo de coluna e precisávamos da ordenação, nos encontramos com outro problema para resolvermos, o que nos leva a próxima seção desse artigo.

Antes de já passarmos pra próxima seção, um pequeno adendo: o postgresql também não ordena colunas virtuais por padrão e o mysql após a versão 5.6 também não. É necessário alterar as configurações do sgbd para permitir esse tipo de operação.

A TAL DA CTE

 

A solução que o sql server provê para ordenar um campo virtual é utilizar uma tabela virtual, de forma que o sgbd veja o campo não mais como ‘inexistente’, mas sim parte de uma tabela (que pra todos os efeitos não existe de fato no banco). Isso é implementado com o uso de CTE’s, as common table expression.

Em nossa solução, colocamos a query que gera o resultado com os dados já convertidos em uma CTE e depois aplicamos a ordenação nessa CTE por uma query externa. Acabou ficando uma query dentro de outra query, dentro de outra query, mas isso o sql server dá conta sem problemas.

Com isso, finalmente demos fim a horas e horas de testes e mais testes, debugging e mais debugging, que nos renderam uma solução consideravelmente interessante e um tanto inesperada, já que nem em nossas mais loucas especulações imaginaríamos quem um ‘simples cast’ se tornaria algo tão complexo e trabalhoso de implementar.

A tempo, pra quem quiser aprender mais sobre as CTE’s, confiram esses links [1] [2]  [3]

 

Publicado em

Jogos, é mais fácil jogá-los do que fazê-los!

desenvolvimento de jogos

Criar jogos sempre foi uma fascinação, desde o primeiro contato com eles. Aquele negócio de criar um mundo/universo imaginário onde é possível fazer coisas que na realidade não é, fascina e leva muitos a se interessarem por TI.

Contudo, a maioria de nós, não tem a menor ideia de como realmente se faz um jogo. Queremos fazer um, mas não sabemos como fazê-lo. Minha ideia nesse post é elucidar um pouco de como é implementar um jogo, sob a ótica de quem trabalha na área de TI a algum tempo. Interessado? Então vamos nessa!

Etapa #1 – IdeiA

 

Todo software começa com uma ideia e jogos não são diferentes. Entretanto, assim como todo software, existe uma diferença bem estrita entre ideia implementável em nossa mente e ideia implementável em um computador.

Por ideia implementável em computador entenda ideia que pode ser codificada em algoritmo (ou conjunto de algoritmos) processável por nossa tecnologia de computação atual. Isso implica incluir além da possibilidade de processamento em tempo razoavelmente rápido, a possibilidade de uso dos métodos de input atuais (de nada adianta pensar num jogo que faz uso de interface neural quando não se tem esse tipo de tecnologia a disposição).

Além da limitação tecnológica, tem ainda a limitação de interesse. Esse jogo seria jogado por alguém mais além de você ou é um um jogo que provavelmente só você irá entender e gostar? Ou seja, haverá público para o seu jogo?

O último ponto a analisar na ideia é o ‘como eu pretendo jogar’? Será utilizando teclado e mouse? Terá níveis? Vai ter personagem? Vai ter luta?

Mas pera, isso não é a primeira coisa em que pensamos quando queremos um jogo?

Coloquei essa questão por último não foi atoa. Na etapa da concepção tendemos a pensar primeiro em como jogar, em imaginar as telas do jogo, em ver-nos ou ver outros jogando. Contudo, se fizer essa análise antes de considerar a limitação tecnológica e de público, a chance do seu jogo não dar certo cresce exponencialmente. Porque?

1 – Você pode pensar em utilizar uma tecnologia que ainda não existe ou não está disponível comercialmente ou não é comum e acessível para a maioria do seu público planejado.

2 – Você pode não ter público algum no final das contas. Embora não há problema em fazer um jogo para você mesmo, você pode!, se está querendo que outros joguem o seu jogo, precisará considerar a opinião alheia. Afinal, se depois de todo o trabalho para construir o jogo (o que mostremos a seguir) ninguém gostar dele, isso poderá ter um impacto muito negativo na sua estima ao ponto de lhe desestimular de tentar desenvolver outros jogos.

3 – Descobrir se a tecnologia suporta o que você quer pro seu jogo e se há pessoas interessadas, irá influenciar positivamente o planejamento do jogo e até te ajudar a pensar melhor em ‘como eu jogarei isto’.

Agora que já criticamos o bastante a ideia, é hora de passa pra próxima etapa.

Etapa #2 – Definição de Escopo

 

Quem nunca leu aquela frase “quem se define, se limita”? Pois bem, independente dela ser verdade ou não para uma pessoa, ela é bem verdadeira para softwares.

E a etapa de definição de escopo é exatamente isso: limitar o que terá e o que não terá no jogo.

Como é de se esperar, pra definir um escopo é necessário considerar a etapa anterior. Se a ideia é jogar num console, então a primeira limitação é a plataforma. Se a ideia é um jogo para o público infantil, então outra limitação é a complexidade do gameplay (não que crianças não possam jogar um frenético FPS, elas podem. Só não é comum para a maioria do público). Se a ideia é permitir lutas tridimensionais então um pré-requisito é uma engine que suporte objetos 3D e execute animações sobre esses objetos a um nível decente. E assim por diante.

Aqui vou eleger alguns dos elementos de escopo necessários a um jogo e que já usamos em projetos do tipo da Nibblelab:

1 – Ambiente

O local ou locais onde o jogo irá executar influencia e muito. Não só na disponibilidade de métodos de input e tamanhos de tela, como também no tamanho do público potencial, assim como na disponibilidade de software de suporte ao desenvolvimento como SDK’s decentes e engines. Definir o ambiente é de suma importância!

2 – Softwares de suporte

Em decorrência direta da escolha do ambiente vem os softwares de suporte ao desenvolvimento, afinal, a menos que você queira escreve tudo que irá precisar do zero, da engine aos drivers, irá precisar utilizar bibliotecas, SDK’s e outros softwares de terceiros. Alguns irão resolver seu problema. Outros não. Alguns serão acessíveis, outros não (sim, acessíveis. Tem software que é bom mas custa sozinho todo o budget do projeto. Aí não dá né!).

Em algumas situações, um software de suporte, tipo uma engine, pode até influenciar na escolha do ambiente. Eu já vi projetos que deixaram de suportar determinadas plataformas porque nelas não tinha suporte da engine utilizada no projeto. Não que isso seja um problema. Ao contrário, é uma escolha. Entretanto cabe ao você ou seu responsável técnico definir quando um software de suporte vale tanto ao ponto de influenciar outros pontos do seu jogo.

Outro ponto a analisar é continuidade do software. Isso é expresso pelo tamanho da comunidade em torno do software e a frequencia em que ele recebe atualizações. Uma vez eu trabalhei num projeto de jogos em que utilizamos uma engine que tinha tudo o que precisávamos, mas era mal documentada e a comunidade em torno dela era muito pequena. Resultado? Tivemos que trocar por outra inferior, porém mais bem documentada e com comunidade maior (de certa forma, isso vale para softwares comerciais também).

No geral a regra é muito simples: escolha os softwares que atendem ao jogo. Ou seja, os que cabem no orçamento, os que oferecem as funcionalidades que precisam (lembra o que falei de animações? Não adianta querer um jogo com animações e não usar uma engine que suporte esse tipo de coisa), os que tem bom suporte dos desenvolvedores ou da comunidade.

3 – Gameplay e Level Design

Isso aqui é traduzir o ‘como eu jogo isso?’ da etapa anterior em definições claras de projeto.

Ex: no meu jogo o jogador poderá criar personagens com características A, B e C. Então eu defino onde e como isso será feito e quais são características. O que elas representarão e como irão interagir com o resto do jogo.

Outro exemplo: no meu jogo o player precisa pilotar a nave escapando de uma série de obstáculos para passar de nível. Então eu defino como e quantos serão esses obstáculos, como eles serão exibidos e com qual frequencia e qual a relação deles com a nave. Também defino por quanto tempo o player precisa pilotar ou de quantos obstáculos ele precisa passar para terminar o level e após isso, o que será feito logo em seguida. Se irá abrir outro level ou se terá algum troféu.

4 – Serviços anexos

Pode não parecer mas há muito em jogo além do que o jogo propriamente dito. Você pode precisar de um site para fazer a divulgação. Pode precisar de uma API para registrar online os jogadores e seus scores. Pode precisar de outros serviços como processar pagamentos de micro-transações. Tudo isso precisa ser definido adequadamente antes de começar a desenvolver o jogo. Porque? Pra não ter surpresas depois com funcionalidades necessárias que simplesmente ‘surgiram do nada’ sqn, assim como para planejar melhor o uso do orçamento.

Etapa #3 – Produção/Definição do conteúdo áudio-visual

 

Agora que já tem ideia e escopo definidos, é hora de pensar numa das partes fundamentais de todo jogo: o áudio-visual.

“Ah mas tem jogo aí que usa gráficos pixelizados e fazem sucesso”. Você pode questionar isso (como já me questionaram uma vez). Contudo, pode não parecer mas aqueles gráficos pixelizados com aquela música ‘zuada’ foram definidos como parte do escopo daquele projeto e cuidadosamente implementados.

Uma coisa importante para lembramos sobre jogos é que eles são arte e arte nem sempre nos agrada. Porém, se agrada a outros, é arte (ignore a discussão filosófica do termo, please!).

E por ser arte, você precisa se dedicar nessa parte.  Mesmo que você já seja um excelente designer ou compositor, ou mesmo não saiba nada de música ou arte gráfica, não poderá deixar o conteúdo áudio visual sem a devida atenção.

Além deles comporem o seu jogo e serem por eles que o player verá e experimentará o jogo, eles estão diretamente ligados ao gameplay e level design. Lembra daqueles sons de suspense em jogos de survival horror ao abrir uma porta por exemplo? Então, eles estão lá para te induzir a um comportamento que compõe a imersibilidade do jogador no ambiente do jogo.

A imersibilidade é algo tão importante que você se lembra dos jogos por conta dela. E mais importante, jogos com boa imersibilidade mas pontos fracos em outros aspectos (como história) já conseguiram ficar entre os mais jogados por quase meia década (já sabe de quem estou falando né?). Então, cuide bem dessa parte.

Agora, como fazer isso depende dos recursos a sua disposição. Se você domina a arte gráfica ou música, faça você mesmo. Ou se tiver alguém em sua equipe com boas skills nessas áreas, a sua equipe pode fazer. Agora se esse não é o seu caso, há sempre repositórios de gráficos e sons disponíveis na internet, assim com bons profissionais a disposição para fazê-los.

De um jeito ou de outro, é possível conseguir gráficos e sons decentes para atender o seu jogo.

Quanto ao onde aplicar esses recursos, isso dependerá completamente do seu tipo de jogo e do que definiu no gameplay. Lembra do exemplo que citei do som de suspense em jogos de survival horror? Bom, esse é um bom exemplo de onde aplicar adequadamente recursos audio-visuais.

Etapa #4 – Ahhhh finalmente a programação

 

Com ideia, escopo e recursos audio-visuais definidos, a próxima etapa é aquela que engenheiros de software e geeks em geral se deleitam: a programação.

Da configuração (ou implementação) da engine até escrever os levels, tudo é muita festa e claro, muito trabalho. E embora eu não vou me alongar muito aqui (afinal, o post já está muito grande), farei apenas algumas observações às quais você precisa se atentar quando chegar nessa etapa

1 – Jogos são programas rápidos: do jogo mais simples de dress-up até os poderosos jogos que simulam ambientes 3D inteiros, a velocidade de execução é uma constante. Usuários em geral odeiam lags e em jogos, isso pode significar a morte de um

2 – Testes: a maioria dos softwares tem bugs embutidos. Mesmo aqueles construídos com base em heurísticas podem ter erros, afinal, são criaturas imperfeitas que constroem os softwares. Contudo, lançar um jogo (ou qualquer outros software) bugado por demais prejudicará a experiência do jogador e poderá fazer com que ele abandone o jogo permanentemente. Por isso considere o período de testes alpha e beta, open e closed antes de lançar.

3 – Entregue o que prometeu: todo mundo gosta de surpresas e presentes (os bons presentes, claro), porém antes de encher seu jogo de conteúdo adicional, de easter eggs, certifique-se que ele faz exatamente aquilo que se propõe a fazer, ou seja, se é um jogo para teste matemático, então ele deve permitir no gameplay a realização de testes matemáticos e isso deve funcionar muito bem, afinal, a maioria das pessoas compram jogos por causa do que eles propõe, não por conta de algum bônus.

Etapa #5 – Hora da jogatina!!!

 

Uma vez que tenha uma versão testável do jogo, é altamente recomendável realizar os testes alpha e beta.

Esse conceito vem da disciplina de engenharia de software, estudada nos cursos de ciências da computação entre outros nos universidades e se refere basicamente a testes realizados em estágios diferentes do desenvolvimento.

De maneira resumida, os testes alpha são realizados pela equipe de desenvolvimento em ambiente controlado, ou seja, no próprio equipamento de desenvolvimento disponível à equipe. Esses testes servem para corrigir bugs e melhorar funcionalidades de um software e geralmente vem após os testes automáticos realizados pela própria máquina (unit test, por exemplo).

Seguindo os testes alpha, vem os testes beta que podem ser fechados a um grupo específicos de testers (closed beta) ou abertos a qualquer um que desejar participar (open beta). Você já deve ter visto por exemplo jogos em estágio de early access no steam que você pode comprar para ajudar a equipe de desenvolvimento testanto o jogo pra eles. Esse é um tipo de teste beta.

Uma vez finalizados os testes, vem a parte final.

 

Etapa #6 – Publicação

 

Depois de tempo produzindo, definindo, programando, finalmente vem a parte da publicação, a parte em que lança o seu jogo para outras pessoas jogarem e se divertirem junto com você no seu jogo.

Embora essa etapa pareça simples, há também alguns pontos a considerar. Se está por exemplo lançando um jogo para plataformas mobile, como android e iOS, precisará enviar o jogo para a loja avaliar e às vezes, precisará alterar alguma coisa por conta de alguma política de uso que possa ter ignorado em alguma etapa anterior (isso já aconteceu em uma app que lançamos na Nibblelab).

Além disso, se fará alguma divulgação do jogo, todo o material publicitário deve estar pronto no momento do lançamento e se possível, já ter sido veiculado alguma parte dele, igual as grandes desenvolvedoras fazem na E3.

Outra coisa que precisará ficar atento é com os serviços anexos. Se seu jogo precisará de um servidor público online para funcionar, ele precisará estar pronto e funcionando até aqui.

Por último, lançar o jogo não é tudo. Precisará monitorar a vendas, se for um jogo pago, e recomendavelmente, monitorar o retorno da comunidade. Os comentários dos jogadores no blog do jogo, ou nas lojas de aplicativos ou no steam. Precisará ficar atento pois sempre há algo no qual os jogadores poderão acrescentar ao jogo ou a sua experiência nessa área.

 

Fazendo um jogo

 

Como escrevi no início do post, desenvolver jogos é uma arte que chama a atenção de muita gente. Se você não conhecia o processo de desenvolvimento, espero tê-lo ajudado a entender um pouco melhor como se cria um jogo e quem sabe, te estimular a desenvolver um.

Em meu tempo de graduação, participei de um projeto de desenvolvimento de jogos, com o qual aprendi muita coisa. Depois da graduação, trabalhei em alguns projetos  de jogos para alguns clientes e hoje temos na Nibblelab um projeto de desenvolvimento de jogos, o projeto R (aguardem mais notícias hehehehe).

Nesse projeto um dos nossos desenvolvedores, que também é um fã de jogos mas nunca tinha trabalhado com isso antes, fez um comentário que me motivou a criar esse post e nomeá-lo: “cara, jogar um jogo é muito mais fácil que criar um jogo”.

E o que ele falou é verdade. Usar é mais fácil do que desenvolver. Porém isso não significa que você não pode ter seu jogo só porque não tem habilidades de desenvolvimento de software ou design. Você pode contar conosco pra isso, então, se está procurando equipe para desenvolver seu jogo, fale conosco que vemos uma maneira de nos ajudarmos 😀

E esse post foi longo pessoal. Agora acabou.

Publicado em

Em casa de ferreiro, colher nem sempre é de pau …

de cara nova

E estamos de cara nova!

Depois de algum tempo desenvolvendo o novo site, incluindo os mais recentes avanços em tech que temos em nosso ‘arsenal’, finalmente publicamos o novo site da Nibblelab

Esse projeto em específico foi desafiador. Primeiro porque como reza o ditado popular, “em casa de ferreiro, a colher é de pau”. E isso é uma realidade.

Estamos sempre ocupados com algum projeto e geralmente não temos tanto tempo para nos dedicar ao nosso próprio site (ironia né!?). Não que a outra versão fosse ruim, mas a atual é muito mais bonita e traz vários avanços em tecnologias que desenvolvemos nos últimos meses, como:

  • melhora na responsividade
  • melhora no design gráfico
  • novos elementos de UI/UX

O fato é, a cada novo projeto, aprendemos algo novo. Agregamos algo novo. Conhecemos novas ideias e tecnologias.  Por isso o próximo projeto é sempre mais avançado e melhor do que o atual e isso é de se esperar em empresas de tecnologia (se ficar estagnado nesse mercado, seu negócio morre!). Então, seguindo essa regrinha básica, temos um novo site, bem mais cool do que o nosso anterior.

Agora, falando em tech, afinal, esse é um blog de tecnologia, de uma empresa de tecnologia (you’ld guess by now …), combinar o vídeo introdutório com aquela animação de máquina de escrever, foi bem mara de implementar. Só naquela parte foram praticamente dois dias, até ficar bom, até ficar do jeito certo.

A parte interessante é que tem um tick de sincronização ali, porque o vídeo é baixado do servidor, carregado e executado ao mesmo tempo que a animação e no caso, precisamos que a animação seja vista desde o começo pelo internauta, o que em caso normal não acontece. Então tivemos que colocar um timeout lá para só iniciar a animação depois de alguns segundos, assegurando que dessa forma tanto o vídeo já estaria carregado, quanto o usuário  estaria o vendo e vendo o início da animação (o equivalente de não comerem o bolo do seu aniversário antes que você chegue na festa).

Enfim, o site novo ficou legal, estamos de cara nova e se você ainda não checou o site, olha lá que ele está muito legal 😀

https://www.nibblelab.com/