Review – Rocket Fist (Switch/PC)

rocketfist_capa

Jogo #7 da limpeza de backlog.

Se eu tivesse que descrever Rocket Fist em uma só sentença, diria que é um jogo de queimada entre robôs para até quatro jogadores.

Este título me chamou a atenção quando foi lançado para o Switch, em agosto de 2017. O eShop do Switch ainda não tinha muita coisa e este foi o primeiro jogo brasileiro a aparecer nele. Somando isso ao fato de que estava em promoção por volta de 5 doletas, foi uma aquisição fácil.

Com apenas dois botões e mecânicas bem simples, Rocket Fist é muito fácil de entender, mas difícil de dominar, à medida que os adversários (IA ou outros jogadores) vão ficando bons. Você controla um pequeno robô em uma arena fechada, que é capaz de disparar um punho mecânico para destruir os adversários. Ao disparar o punho, é preciso recolhê-lo novamente, ou correr o risco de perdê-lo para um adversário.

rocketfist_01

Utilizando ricochete do punho nas paredes de diferentes ângulos, a distância do projétil e uma impulso (à la dash de Towerfall), é possível neutralizar os ataques inimigos, desde que executado no tempo certo, e também roubar o punho deles. Ainda é possível deixar os adversários tontos, atingindo-os com um impulso ou após morrer e aparecer no “Revenge Rail”, uma espécie de trilho por onde seu fantasma pode percorrer as bordas da arena, atrapalhando os robôs vivos.

Isso é tudo que há para fazer em Rocket Fist. Embora pareça pouco, é uma experiência multiplayer bastante divertida, muito rápida e com grande potencial de replay.

Há também um modo campanha/single-player, com algo em torno de 20 fases. Mas Rocket Fist é obviamente um jogo pensado e balanceado para o modo de múltiplos jogadores. Isso fica evidente pela simplicidade da história e da IA dos adversários, tudo feito por um só desenvolvedor, Daniel Snd.

O outro único desenvolvedor do jogo, Thiago Adamo, foi responsável por todos os efeitos sonoros e músicas. E é aí que o jogo tem destaque. A trilha é bastante agradável e os efeitos são muito bem escolhidos. Em um jogo onde tanta coisa acontece ao mesmo tempo, é muito fácil ter efeitos demais, barulho demais e não se entender nada do que está acontecendo. Isto não acontece em Rocket Fist.

rocketfist_012jpg

Fica a recomendação para quem quer um jogo simples de aprender e com profundidade suficiente para entreter quatro jogadores por algumas horas. Se pegar o jogo para o PC perde a portabilidade/facilidade de levar para os lugares e jogar com os amigues, mas a versão para computadores é compatível com SteamWorks e possui um editor de fases.

Para começar este review como começou e deixar a recomendação em uma só sentença, diria que Rocket Fist é o jogo ideal para partidas competitivas rápidas no seu switch com até 3 amigos, para quando enjoar do coop de Overcooked e enquanto não sair TowerFall para o console.

Rocket Fist

Lançamento: Maio de 2016
Gênero: Ação, Arcade
Plataformas: Nintendo Switch, Windows, MacOS e Linux

Me adiciona aí nos joguinhos:

Steam ID: luizcavalcanti
Switch Friend Code: 4378-5362-3706

Visualizando a atividade de seu repositório git com gource

Já pensou em preparar uma animação/visualização do repositório de um projeto? Já fiz isso algumas vezes, em especial no final de um projeto. Acho que isso ajuda a colocar em perspectiva todo o trabalho feito nos últimos meses ou anos. É muito comum perdermos a noção do todo após os momentos finais de ajustes, implantação (quem ainda faz isso?), etc.

Gource é uma ferramenta de código livre que é capaz de gerar animações do histórico de um repositório de controle de versão (Git, SVN, Mercurial e Bazaar). A primeira vez que usei Gource foi pelos idos de 2010 e desde lá muita coisa mudou.

A ideia deste post é fazer um breve tutorial de como usar Gource (+ ffmpeg) para gerar (e gravar em vídeo) uma visualização da evolução de um repositório com o passar do tempo.

Gerando a animação

Uma vez instalado corretamente*, basta executar o Gource e seus parâmetros na raiz do repositório (a sua cópia local, claro):

gource

Pronto, é isso, você já deve ver uma janela com o timelapse do seu projeto. Mas convenhamos que essa versão default é bem simples. Vamos incrementar:

gource -s 0.5 --start-date '2017-08-25' -f --key --highlight-users --user-image-dir avatars -a 1 -logo logo.png -1920x1080

Este monte de parâmetros não chega a ser metade dos possíveis, mas já é um bom começo. Uma curta explicação de cada um deles:

-s {tempo} Tempo de vídeo por dia de projeto(em segundos)
-a {tempo} Tempo máximo (em segundos) sem atividade no projeto (achata os dias inativos)
-f Exibe em modo tela-cheia
-o {arquivo/stream} Saída para arquivo/stream (formato ppm)
-logo {logo.png} Logo do projeto
-{w}x{h} Largura (w) e altura (h) do video em pixels
--Title {‘titulo’} Título do projeto
--start-date {‘yyyy-mm-dd’} Data de início da visualização
--user-image-dir {dir} Pasta com imagens dos usuários (“Nome Sobrenome.png/jpg”)
--key Exibe legenda de extensão de arquivos
--highlight-users Nome de usuários sempre visível

A saída deve ficar parecida com esta que fiz do Tretas Lendárias, um joguinho de código livre que fizemos para o Jogabilijam 2:

Para aproveitar que mostrei este vídeo, vou deixar um tutorial bônus de como utilizar o ffmpeg** para gravar tais vídeos.

Gravando saída usando ffmpeg

Para gravar em vídeo a visualização gerada pelo Gource, é preciso primeiro direcionar a saída do comando para o output padrão, utilizando o parâmetro -o. Utilizando esta saída como entrada para o comando ffmpeg (utilizando o recurso de pipeline do shell), é possível gravar tudo em um arquivo de vídeo:

gource -s 0.5 --start-date '2017-08-25' -f --key --highlight-users --user-image-dir avatars -a 1 -logo logo.png -1920x1080 -o - | ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -crf 1 -threads 0 -bf 0 saida.mp4

Não vou entrar no mérito dos parâmetros do ffmpeg neste post, basta dizer que ele irá gravar a saída em FullHD com 60 quadros por segundo. Se sua máquina não for rápida, deve demorar um pouco, mas o resultado é de excelente qualidade.

Acho que é isso, bom proveito :)

* Procure por instruções na sua distribuição, para quem usa mac/homebrew, dá para instalar com brew install gource.
** Mais uma vez, procure por instruções de como instalar o ffmpeg com os codecs de sua escolha.

 

SOAP vs REST?

Este post surgiu como uma resposta em uma discussão bastante interessante no grupo de telegram PyBR e a versão mais rudimentar dele foi escrita em um gist. Um membro pediu indicação de uma biblioteca Python para lidar com Web Services que utilizavam SOAP como protocolo, outros membros questionaram a razão dos serviços não estarem implementados em RESTful, e por fim alguém falou que SOAP era um jeito ultrapassado de implementar Web Services. Como faz algum tempo que eu não lido com SOAP, logo imaginei que algo havia surgido neste meio-tempo para substituí-lo.

Mas não, ele se referia à RESTful Web Services como um substituto do SOAP. A verdade é que sequer faz muito sentido fazer uma comparação entre REST e SOAP, visto que o primeiro é um padrão arquitetural, o segundo um protocolo. Acho que faz mais sentido fazermos uma comparação entre HTTP (seguindo REST ao pé da letra ou não) e SOAP.

Para a maioria dos casos que encontro hoje em dia, implementar uma API pública utilizando HTTP faz muito mais sentido, tanto pela flexibilidade de poder usar XML ou JSON, quanto pela simplicidade da operação. Mas quando eu acho que SOAP vale a pena ou é a escolha “certa”?

Modelagem de negócio

A maioria das APIs têm foco em entidades e operações básicas nessas entidades (ex.: entidade Cliente e operações de inserir (PUT), alterar (POST), buscar (GET), etc…). Você começa a ter problemas em manter sua modelagem (endpoints, coerência interna, etc) de forma consistente quando suas operações não tem uma entidade clara, ou fogem muito do padrão CRUD que os métodos HTTP “impõem”. Tenho certeza que todos podemos imaginar exemplos disso, aplicados à nossa realidade. Eu já tive, por exemplo, que fazer um serviço/endpoint para migração opcional de dados de um sistema antigo para um novo, sob demanda de certos usuários. Como eu represento isso bem apontando para uma entidade e uma única operação/método HTTP?

Protocolo de transporte

Você sempre pode usar HTTP/HTTPS? Quando não, SOAP é independente de protocolo de transporte e resolve essa para você.

Tratamento de erro

SOAP possui tratamento de erro embutido. É possível que algumas libs ou frameworks para RESTful web services hoje em dia também possuam, se não for o caso e você não quiser/tiver tempo de implementar sua própria camada de confiabilidade, SOAP é uma boa escolha. Há também garantia de transporte/entrega, independente do protocolo de transporte.

Operações com estado

O título da seção já é bem descritivo. SOAP preconiza e suporta interações stateful, simular/garantir algo parecido com APIs RESTful utilizando HTTP/S não é simples, e filosoficamente, nem deve ser feito, para ser direto.

Autenticação

Embora não seja difícil implementar autenticação em serviços RESTful, não há o conceito de sessão, portanto, é muito complicado implementar autenticações consistentes que fujam do padrão token/passcode ou que usem aquele OAuth by google/facebook. É muito comum, por exemplo, precisarmos aproveitar o Enterprise Single Sign-On (SSO) que uma empresa já use internamente, para autenticar o uso de web services.

Conclusão

Amo RESTful APIs + HTTP/S e vou protegê-los. Odeio SOAP e ter que lidar com XML. Adoraria que todos esses problemas sumissem, mas é pouco realista. A verdade é que um não surgiu para substituir o outro, mas sim para simplificar a implementação e consumo de Web Services em determinados casos. O prêmio de consolação? Implementar estes serviços com SOAP, hoje, é muito mais simples que nas épocas das primeiras versões do JAX-WS e frameworks similares. Não dói tanto quanto parece.

Minha primeira semana na Nokia Store

Há algumas semanas, eu me perguntava como se diferenciavam as lojas de aplicativos das mais diversas plataformas móveis. Alguns dados como quantidade, qualidade e preço médio de aplicativos são bastante conhecidos do público consumidor, bem como dos desenvolvedores. Mas e quanto ao processo de publicar um novo app? Controle de qualidade? Tempo gasto? Custo de associação? E o acompanhamento do desempenho da aplicação lançada?

Com um novo projeto J2ME no horizonte, precisava encontrar um jeito de conhecer a tecnologia (que nunca tinha trabalhado antes) e aproveitei para responder minhas dúvidas sobre o processo de publicação de mais uma loja, a Nokia Store para S40 e Symbian.

Numa bela sexta-feira, fim do expediente, vi uma notícia no Hacker News sobre um certo site que havia liberado (quase) todas as bandeiras do mundo em formato PNG sob licença Creative Commons. Essa foi a oportunidade. Em 1 hora (sem contar melhorias e correções nas semanas posteriores) junto com um colega de trabalho, uma aplicação foi produzida. Trata-se de um simples quiz sobre bandeiras de países, utilizando Canvas e tratamentos de eventos um pouco menos básicos do J2ME. Embora simples, a aplicação ficou razoavelmente divertida, rola até hoje uma competição pelo maior placar aqui no trabalho. Também aproveitei para testar uma nova plataforma de Ads lançada pela Nokia (http://nax.nokia.com)

Não há muito o que comentar sobre o processo de publicação, já que ela não difere muito dos outros. Algumas vantagens são o preço (1 euro para associação) e o controle de qualidade, que chegou ao cúmulo de reportar que o About/Help não estava adequado para publicação, mostrando que além dos processos automatizados de teste, uma pessoa realmente abriu o aplicativo e testou. Mas não estou aqui exatamente para fazer um comparativo entre lojas ou convencer ninguém a publicar na Nokia Store (embora você realmente deveria, os 60 milhões de Ashas espalhados por aí estão esperando :D). Gostaria, na verdade, de mostrar algumas estatísticas que colhi na primeira semana de disponibilidade do aplicativo na loja:

Total de downloads: 6245
Total de países: 117

Ranking dos países (5 primeiros):

Número de downloads

País Downloads
Índia 927
Tailândia 570
Rússia 493
Brasil 444
Filipinas 348

Impressões de Anúncios

País Impressões
Índia 803
Rússia 578
Tailândia 396
Brasil 393
Paquistão 289

Anúncios clicados

País Clicks
Índia 17
Tailândia 17
Rússia 15
Indonésia 13
Brasil 8

CTR (http://en.wikipedia.org/wiki/Click-through_rate)

País Clicks Percentual
Bielorrúsia 2 50%
Líbia 2 28.57%
Quênia 1 25%
Iraque 3 20%
Kuwait 1 20%

CTR dos mais impressos

País Percentual
Tailândia 4.3%
Rússia 2.6%
Índia 2.1%
Brasil 2%
Paquistão 1.4%

Anúncios mais lucrativos por CTR

País Montante
África do Sul US$ 0.43
Tailândia US$ 0.39
Brasil US$ 0.30
Rússia US$ 0.15
Paquistão US$ 0.12

Algo que salta os olhos é como a plataforma é especialmente forte no BRIC. Lançar o aplicativo em inglês foi muito importante para ter visibilidade no mercado indiano, que lidera quase todos os rankings do aplicativo. A liderança da Índia, na verdade, só tem se acentuado a cada semana que passou depois da primeira, sendo responsável hoje por mais da metade do total de downloads do aplicativo. Quem sabe a próxima brincadeira com o S40 já saia com suporte a Hindi desde a primeira versão ;)

Torne-se um fazedor. Não pergunte-me como…

Nos últimos tempos tenho refletido com mais frequência sobre minha profissão. Eu, como muitos de minha geração, resolvi estudar computação por gostar de jogos, e sonhava um dia poder fazê-los. Essa ideia/lembrança é ponto chave na conclusão que tenho chegado nos últimos tempos.

Um jogo é um produto, um fim, uma solução. Fazê-lo era o que importava, não os meios para isso. Mas algo se perdeu no meio do caminho… eu aprendi a programar.

É um mundo fascinante, com uma quantidade brutal de detalhes, onde horas de esforço oriundo de meses ou anos de estudos produz resultados encantadores. Quase tão encantador quanto o produto desse ofício, é o ofício em si.

Visite qualquer cafezinho de uma empresa com programadores e verá. Eles estarão debatendo sobre linguagens, paradigmas, gerenciamento de memória, boas práticas, bla, bla, bla. Entra um rapaz do departamento jurídico, faz um comentário sobre “festa x” ou “jogo do Flamengo” e o assunto se mantém por 10 segundos, antes de voltar para “linguagens funcionais são mais adequadas que as imperativas para projetos do tipo y” ou “garbage colletors são uma porcaria”, e o pobre rapaz volta para sua sala. É quase como a vingança dos nerds, se não fosse patético.

Não, não acho que é mais legal falar sobre o show do Exaltasamba ou sobre a goleada do Real sobre o Barça, nem acho que aspectos técnicos são assunto proibido ou desagradáveis. Só acho que passo tempo demais discutindo problemas que não vou resolver, pois eles não são… bem… problemas. São nunances, características das FERRAMENTAS que utilizamos para resolver problemas de verdade. Ferramentas são coisas que usamos para fazer as coisas que importam. Ou você imagina um pedreiro filosofando sobre o cinzel?

“Mas se ninguém se preocupasse com essas coisas, não teríamos as ferramentas que temos hoje para trabalhar!”

Certamente. A diferença é que para as pessoas que constróem essas ferramentas, elas são o problema, não a ferramenta. Se você constrói as ferramentas, esse texto não é para você. A moral da história é: Foco no problema.

Argumentar por que Java agora é mais rápido que C++ para cálculos de transformadas de Fourier, ou vice-versa, tem a mesma utilidade para você quanto para os criadores das respectivas linguagens: Nenhuma. O problema é outro.

As gotas d’água

Hoje conversando com meu amigo Zanoni, comecei um monólogo idiota sobre como Design Patterns são inúteis no meu trabalho atual, mas como são importantes para certos tipos de projeto. Devo ter falado por 30 minutos, antes de perceber que um build que deveria resolver meu real problema já deveria estar me esperando.

Ao chegar em casa, me deparei com um comentário da Anna no Google+, e resolvi prolongar o tema nos comentários, emitindo a minha toda-poderosa opinião. Devo ter perdido pouco mais de 1 hora entre escrever e revisar o texto que postei. Sabe o que é mais engraçado? Não tem a mínima importância para ela nem para mim. Sequer vai melhorar nossa quarta-feira, quando ela ler.

Depois de longa e conturbada reflexão, decidi mudar esse aspecto de minha vida. O processo vai ser longo, mas pretendo focar mais nos resultados concretos das coisas que eu resolva fazer. Tornar isso público no blog aumenta a pressão, e é isso que preciso agora. O primeiro passo vai ser reverter os vícios que a educação de nível superior me presenteou.

Afinal, como diz uma certa empresa de telefonia, “It’s not the technology, it’s what you do with it”.

Também quer se tornar um fazedor? Não pergunte-me como, acabei de tomar essa decisão!