gamedev

Meu jogo foi para capa da Google, YEAH! 2018 Lindo lindo :).

Standard

Bom, é com motivo de muita alegria que o game no qual fiz parte do desenvolvimento foi parar na capa da Google.
SIMMMMMM, está lá estampadasso.

O jogo que desenvolvi (fiz parte do core de desenvolvimento) é o Magic Master -> https://play.google.com/store/apps/details?id=air.com.mopixgames.magicmaster&hl=en

Mas como cheguei lá e como é o resultado disto?
Você pode estar se perguntando:

Como faço para meu jogo ir para capa da Google Play?

Antes de mais nada quero agradecer a Deus por ter feito parte desse  projeto chamado Magic Master.
Eu não comecei a desenvolver ele do zero, muito pelo contrário, eu entrei no projeto quando o mesmo estava em andamento e teve uma baixa no core de desenvolvimento, me levando a ser o main dev do game. A empresa na qual presto serviço até a data deste post é a MOPIX (Mopix Games) de Belo Horizonte (MG). (http://www.mopix.com.br/)

O jogo é um tower defense que foi desenvolvido por 3 anos. É um jogo que tem um design diferenciado (Raoni Dorim é o artista) + uma equipe forte de animação e etc. O jogo foi para o CoreLabs (aceleradora de nível mundial) e recebeu bastante investimento.

Vamos aos pontos do que é estar na capa do Google? Ok, vamos lá!

1 – Downloads

Parece que não é tão importante estar na capa do Google, mas é, é sim, é MUITO :).
Os downloads do game que eram algo em torno de (no máximo) 50/100 por dia passaram para 2000 ao dia. É um ganho de 1000%, isso atrai mais players e consequentemente coloca mais in-app purchases em crescimento.

ATUALIZADO O POST!!!
Neste exato momento (horas após a publicação deste post) estamos em 4000 downloads / dia e subindo! YEAHH!

2 – Portifólio

Não é simples chegar lá, a jornada é forte, mas a compensação de ser destaque ali denota o quão refinado é o processo para chegar até ali. Em Minas Gerais apenas 2 empresas conseguiram tal feito, a Mopix e outra empresa. Sem dúvidas é uma coroação que recebi sem precedentes (e jamais esperei por isso mesmo sendo formado em gamedev).

3 – O processo (como chegar lá)

Bom, estar ali é extremamente sofrido, parece que não, mas é!
Para estar ali o seu game precisa de:

  • Feedback de touch (em tudo que tem button effect),
  • Pause funcionando redondamente (e não só o pause, como o pause sob HOME/Back/Lock buttons do android [botões físicos do android]),
  • No Retorno ao game pós HOME button, Back button, Lock Button o jogo deve exibir o menu de pause (hard hein???),
  • Design de certa forma atraente,
  • Gameplay de certa forma atraente,
  • Adequar seu código ao sdk da Google mais recente possível (mínimo hoje é o 26, que corresponde ao android 8),
  • Se ele realmente precisa de sleep, deve usar Dozen da Google na API level 26,
  • Não deixe bugs no game, parece claro isso, mas lá é obrigação, bugs são requests para ontem,
  • O feedback de touch é bastante estressante de se lidar :(,
  • O sdk 26 exige muito mais dos programadores, principalmente por causa das permissions (que se dividem em permissões perigosas e permissões normais). <— cuidado!

Não é uma tarefa simples e fácil, se observar a documentação da Google é extremamente pesado.
Adequando todo seu game aos pontos acima você pode entrar em contato com o representante BR ou da América Latina da Googleplay solicitando a feature do seu jogo.

Não vou detalhar tanto os procedimentos e etc porque um post seria pequeno demais para isto.

Obrigado a todos envolvidos.

Unity 5.6+ and 2017.1.1f1+ Build Problemas (Android): AAPT failed or Android SDK paths problems (JDK Included)

Standard

Hello Guys, chegou a hora de dar algumas dicas de como sanar esse problema chato que está rolando na Unity nos últimos tempos. Deixo claro que vou postar alguns links para salvação do clan, ok? Então vamos lá:

1 – Problemas com SDK da Google na Unity 5.6+ ou 2017+ (JDK mais novo também apresenta problemas)

Recentemente tentei subir minha engine para as versões mais recentes e na hora de buildar para a Google tive diversos problemas. Visando deixar claro cada problema e solução resolvi dissecar através de links por problemas para que você fique bastante em paz na hora de compilar o bicho. No caso de SDK temos diversos problemas que vão desde a Google Tools que não está 100% compatível com a Unity, isto foi oficialmente divulgado, como no link abaixo:

https://unity3d.com/pt/unity/whats-new/unity-5.6.1#section-fixes

A solução que a Unity manda utilizar-se é uma bem conhecida (eu fiz um how to recente sobre: http://www.littleoak.com.br/2018/01/03/how-to-install-support-to-android-sdk-unity-2017-java-development-kit-jdk-dica-simples-e-funcional-jdk-1-9-problems/)

No mesmo link acima eu ensino como lidar com o JDK mais recente (1.9) que também apresenta alguma incompatibilidade misteriosa com a Google.
Outro link bom (e bem WINDOWS no assunto) trata do mesmo assunto, pode ser visto em:

http://devlog.markhlavac.com/2017/06/30/installing-android-sdk-for-unity3d-using-sdk-tools-and-cli/

Isso sana erros como

unable to list target platform

Acima matamos o problema de SDK da Google (e JDK da Oracle).

2 – Problemas na Hora de Buildar para Android

A mensagem mais comum e genérica que você pode receber na hora de buildar para android é:

Unity build problem – AAPT failed ALGUMACOISA ALGUMA COISA ALGUMA COISA

OUUUU

“There is a problem parsing the package”

 

Bom, existem vários caminhos que podem apresentar este problema (VÁRIOS MESMO), mas normalmente a solução que vou deixar vale para quase todos (senão todos) MESMO. Parse é o que mais recebe correção no tweak abaixo, no caso do AAPT pode ser o JDK cagado, nesse caso siga o passo que já falei no link -> http://www.littleoak.com.br/2018/01/03/how-to-install-support-to-android-sdk-unity-2017-java-development-kit-jdk-dica-simples-e-funcional-jdk-1-9-problems/

Na tela de Build Settings precisamos clicar em player settings que fica lá embaixo na tela:


Clicando em PLAYER SETTINGS temos de ajustar várias coisas, não vou entrar nos detalhes, mas há 1 ponto que deve ser BASTANTE observado, OTHER SETTINGS, nele temos o “range” de qual Android mínimo deve rodar o game e qual a API para qual o android foi projetado, se você colocar um range aceitável vai dar certo. Se o mínimo for alto seu Android não vai rodar, se a API for alta demais provavelmente sua Unity não vai compilar corretamente, então fiz assim:


No MINIMUM API LEVEL coloquei o 4.1 e no TARGET deixei o 7.1 (que é level 25, a que temos garantido na TOOLS e NO SDK DA GOOGLE 🙂

Abração guys, vamos que vamos.

How to Install Support to Android SDK (UNITY 2017+) & Java Development Kit (JDK) – Dica simples e funcional (JDK 1.9 problems)

Standard

Bom, serei o mais objetivo possível, ok?

Meu setup será descrito logo abaixo e o tweak para resolver também.

My Desk:

Mac OSX HighSierra 10.13.2,
8 GB ram,
Core2duo,
SSD 120gb Vertex 3 OCZ,
Unity 2017.1.1f1 personal 64bt.

Passo 1 (step 1):

Baixe o Android Studio (sim, o sdk vem nele, essa conversa de gamb de SDK não existe, precisa baixar e o bicho é grande, 700mb+, baixe aqui:

https://developer.android.com/studio/index.html

Depois de baixar e instalar (instalei default) você deve abrir ele e dizer que não tem instalação anterior, apenas um novo WORKSTATION. (nova instalação, sem importação de NADA).

Passo 2 (step 2):

No mesmo link de download do studio existe uma parte de ferramentas de CLI, você deve baixar a CLI do seu SO (pode ser windows, não tem problema, se seguir a lógica desse artigo você vai conseguir fazer rodar em seu windows numa boa):

Baixe em https://dl.google.com/android/repository/sdk-tools-darwin-3859397.zip a versão que eu usei.

EXTRAIA o arquivo que vai gerar uma pasta chamada tools. Pegue esta pasta, copie-a, entre na pasta /Users/SEU_USUARIO/Library/Android/sdk, DELETE OU renomeie a pasta tools que existia e coloque a pasta tools nova (a que você baixou e extraiu do google).

Feito isto temos o básico do Android SDK, mas precisamos arrumar o java (e esse é pegadinha do malandro viu?).

Antes de passarmos para o java precisamos entrar na pasta

/Users/little_oak/Library/Android/sdk/tools/bin pelo terminal, sim, abra o TERMINAL DO MAC (shell) e vamos ter que digitar comandos, lets go?

cd /Users/little_oak/Library/Android/sdk/tools/bin

./sdkmanager “platform-tools

./sdkmanager “platforms;android-25”

./sdkmanager “build-tools;25.0.3”

Entenda que ali é ./ MESMO, estamos mandando rodar o binário que não faz parte de um path global do sistema (para poder rodar comandos se estar no caminho completo dele).

 

Passo 3 (step 3):

Resolvido o problema do SDK da GOOGLE, agora precisamos resolver o sdk da Oracle. De alguma maneira estranha a Unity em suas versões anteriores apresentava uma inconsistência com a TOOLS da google mais recente (isso está descrito no link abaixo):

https://unity3d.com/pt/unity/whats-new/unity-5.6.1#section-fixes

A Unity 2017+ por sua vez já suporta a tools nova, porém apresenta alguma inconsistência pra lá de estranha com o JDK mais recente, o que me fez usar um JDK mais velho. Para dar certo usei o JDK jdk1.8.0_151.jdk (pode baixar aqui: http://download.oracle.com/otn-pub/java/jdk/8u151-b12/e758a0de34e24606bca991d704f6dcbf/jdk-8u151-macosx-x64.dmg).

Assim que baixar instale normalmente. Terminada a instalação teremos alguns problemas para sanar, descrevo nos passos abaixo.

Passo 4 (step 4):

No OSX, o sistema bloqueia por padrão a leitura da pasta Library do usuário, sendo necessário dar permissões a esta pasta. Como segurança não é o quesito principal deste postei achei por bem mandar um 777 nela, logo precisamos rodar o comando abaixo:

sudo chmod 777 /Users/MEU_USUARIO/Library/

Feito isto agora podemos brincar na Unity.

Abra a Unity 2017+ e vá em UNITY -> PREFERENCES (imagem abaixo):
External TOOLS -> PROCURA PELA PARTE DE SDK E JDK.

EM SDK coloque: /Users/little_oak/Library/Android/sdk
EM JDK coloque: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home

No Windows os paths mudam, mas é bem mais fácil que no MAC.

Depois é só compilar :).

 

Unity 5+ Cuidado ao Comparar Pontos Flutuantes :(

Standard

Spoilers: comparar 2 pontos flutuantes diretamente com ==, >, <, etc. não é legal!

Por questões de hardware, o computador sempre carrega algum erro em operações de ponto flutuante (que é mais notado quanto mais vc vai fazendo operações em cima do valor de ponto flutuante). Isso é chamado de erro de mantissa, que vocês podem procurar mais em livros de calculo numérico, ou em links como esse:
http://producao.virtual.ufpb.br/…/livro.chunked/ch03s07.html

Por isso é uma boa prática de programação quando comparar valores de ponto flutuante usar um patamar de erro (ou threshold) que a gente chama normalmente de epsilon. Esse valor vai ser a precisão que você quer na operação, e vai variar de acordo com a necessidade do seu código. Por isso que eu e mais alguns sugerimos usar:
|A-B| > epsilon, ou A-B > epsilon

Pode parecer óbvio que A > B funcionaria, mas para alguns casos não, e daria errado. Esse link que o Fernand Rossa divulgou fala de um jeito mais resumido:
https://msdn.microsoft.com/en-us/library/c151dt3s.aspx
Mas vcs podem ver um exemplo nesse link, também da documentação do C#, do porque pode dar errado:
https://msdn.microsoft.com/…/library/ya2zha7s(v=vs.110).aspx

É um problema muito importante para computação que necessita de precisão muito grande de resultados, como problemas de engenharia. Mas geralmente na área de jogos ele acaba não sendo tão relevante, e por isso muita gente acaba não sabendo disso.

Informativo de Leonardo Pereira: https://www.facebook.com/ltorpereira?hc_ref=ARS69EpNMLAV9EGZCS35pTwcmLiYwNg2Xou5_U06NEfek6oEchdWO94nHbQYJffYMzc
No post: https://www.facebook.com/groups/unity3dbr/permalink/1780010805351473/
No fórum da Unity Brasil: https://www.facebook.com/groups/unity3dbr/?hc_ref=ARS69EpNMLAV9EGZCS35pTwcmLiYwNg2Xou5_U06NEfek6oEchdWO94nHbQYJffYMzc

Moirai, um exemplo de jogo que mostra o quão podre é a comunidade que consome jogos (não generalizando)

Standard

Quando falamos de jogos Indie estamos falando de uma parte da indústria que se vira nos 30, sim, estamos falando de Studios com pequeno porte que normalmente possuem pessoas que trabalham durante o dia e desenvolvem seus games durante a noite (ou em uma fração de tempo maior durante o dia, depende de cada caso/studio).
Nesse cenário podemos destacar o esforço e o empenho de várias grandes produções e de produtos muito bem polidos.
Uma das coisas que me chama mais a atenção é o quão podre é uma fração da comunidade que “consome” jogos.
Se observamos com parcimônia uma grande fatia dos que consomem games são pessoas “normais”, àquelas que acreditamos serem players ou desenvolvedores que estão apreciando um determinado produto, mas há outra parte da comunidade que causa muito estrago ao ser humano por trás de uma produção de jogo: A fatia que consome pirataria e a que usa de cracking para obter algum benefício com isto (sabe-se lá qual benefício se tem em ser imbecil).

1 – Pirataria é crime, crime pesado!

Por muito tempo consumi pirataria, ao ponto que tudo que posso estou aplicando licenciamento sobre. Se você consome pirataria, por que diabos se sentiria bem se eu usasse um “serial” e te desse um salário fake? É assim que fazemos com o desenvolvedor de software por trás de uma solução que usamos quando utilizamos de pirataria!
Pirataria é roubo, é crime, se usou você é ladrão!

2 – Cracking e os usuários deste meio (ou os que comem fezes e as introduz na cabeça)!

Estes me espantam mais que os pirateiros, pois a maior parte que consome pirataria REALMENTE não tem condições de pagar por um Photoshop da vida e acaba pirateando (costuma-se pagar caro com isso, cracking com exploit/trojan em esteganografia é punk!), estes são vermes que usam de meios para obterem vantagens sobre os outros, ou pior, para ganhar alguma notoriedade em uma comunidade semelhante a um esgoto (causar danos a outrem sem motivos e ganhar destaque por isso? ISIS, é você?).
Há inúmeros exemplos antigos e novos de pessoas com bastante tênia na cabeça, sim, cito alguns:

– hacking no Counter Strike,
– hacking no PUBG (aimbot, fastmove ou hackspeed e etc),
– ddos (esse é o que vou falar), flood e etc. <— é aqui que esse artigo se baseia.

De forma dolorosa temos pessoas que possuem mentalidade medíocre no mundo (alô ISIS, é você?). Não ganham nada com isto, literalmente nada (apenas a famosa notoriedade entre lammers) e causam danos muita das vezes irreversíveis à comunidade mais séria que consome jogos.
Houve há um tempo atrás um determinado ataque contra um servidor de um jogo chamado Moirai (o caso é mais detalhado no link http://meiobit.com/368427/moirai-o-interessante-jogo-indie-destruido-por-hackers/), onde a base de dados recebia um flood intenso, parecia ser algo como um sql injection ou mesmo um ddos em cima do banco de dados, o que tornou o jogo inviável de manter (desde monitoramento a patching), o que fez com que os mantenedores do jogo desistissem do projeto. Uma perda séria (mesmo parecendo que não), pois o jogo tinha um contexto de Experimento Social, algo que enriqueceria a comunidade consumidora de jogos de alguma forma, e para lamento temos a resposta dos próprios desenvolvedores do produto:

“Desde o lançamento no Steam o nosso banco de dados recebeu diversos ataques. Trabalhamos duro (e as vezes com o suporte de membros da comunidade) para atualizar nosso sistema para um estado mais gerenciável e minimizar a probabilidade de ataques. Contudo, recentemente nosso banco de dados esteve sob seguidos ataques que arruinaram a experiência para alguns jogadores, resultando em termos que tirá-lo do ar. É importante que saibam que nenhum dado de emails foi comprometido nesse ataque. No entanto, essa vulnerabilidade significa que estamos sujeitos a futuros ataques. Não somos um estúdio grande e não temos recursos para prevenir corretamente esses ataques, então removeremos o jogo da loja”

Me pergunto o que houve com às pessoas deste século:

1 – Passaram a consumir fezes?
2 – Passaram a introduzir fezes na cabeça?
3 – As duas alternativas acima estão corretas?