O cocos2d possui um scheduler que pode ser chamado a cada frame ou por um intervalo específico. Perdi algum tempo tentando realizar isso com o CCMoveBy, mas logo percebi que teria que controlar o movimento frame a frame.

Então tentei determinar uma forma de fazer com a que a bola se movesse. Dividi a tela em quadrantes e estabeleci os modificadores que deveria aplicar aos eixos X e Y que a bola se movesse. A figura abaixo mostra como funcionam esses modificadores.

Pensando no formato landscape, quando a bola vai se mover para o quadrante 1, os valores de X e Y devem ser incrementados, logo, ambos assumem o valor inteiro 1. Caso a bola tenha que se mover parao quadrante 4, ambos devem ser decrementados, assumindo o valor -1.

Então chegamos na seguinte fórmula:

Próxima Posição da Bola no Eixo X = posiçãoAtualX + incrementoPosiçãoX * modificadorX

O mesmo se aplica ao eixo Y.

Compilei e rodei. Resultado? Desastre total

Acontece que essa variável incrementoPosiçãoX teria que ser realacionada diretamente com a quantidade de frames por segundo. O movimento da bola ficou tosco e muito lento.

Voltamos ao método update do cocos2d. Ele recebe como parâmetro uma variável do tipo ccTime, chamada delta. Esse é exatamente o tempo final menos o tempo inicial da renderização de um frame. Voltamos ao segundo grau nível médio e aplicamos a fórmula do movimento retilíneo uniforme (MRU, a velha S = So + V.t):

Espaço = Espaço Inicial + Velocidade * Tempo

No nosso jogo:

Próxima Posição da Bola no Eixo X = posiçãoAtualX + (velocidade * delta) * modificadorX

Se eu quiser um movimento mais rápido, incremento a velocidade. Simples assim. Percebi que o valor 200 era ideal para a velocidade, tanto no simulador quanto no iPad.

Abaixo, screenshots desta última sessão que durou três horas. Eu apanhei pra caramba do CCMoveBy!

Abaixo, dois screenshots da sessão de hoje. Falta fazer a limitação para que o pad não exceda a largura do dispositivo. A velocidade do pad está na velocidade do toque, pensei em como deixar isso mais lento também.

Outro detalhe importante é que o dedo da pessoa fica bem em cima do pad. Testei isso no iPad no tamanho 320×480 e o tamanho 2X. Tô pensando em subir um pouco mais os pads, ou somente deixá-los maiores. Amanhã essa será a missão!

PS: Vou botar o fonte no GitHub também amanhã. 

Update:

Repositório no GitHub: https://github.com/leonardoeloy/VolcanoPong

Já tem uma alteração também. Expandi a área do toque para um retângulo acima do pad. Uma imagem abaixo explica isso:

Vida Longa e Próspera

E agora Henrique Gogó será a meu parceiro nesta empreitada! O cara é músico, designer, desenvolvedor e ainda por cima, futuro pai. Eu que sou um Zé Ninguém estou aqui com inveja de não conseguir fazer nem 10% do que ele faz, mas feliz porquê agora vamos fazer uns projetos de verdade.

Apesar dessa ideia do Volcano Pong ser somente uma forma de aprender melhor a API do cocos2D, já estamos mirando mais na frente, para o próximo título.

Agora tenho a certeza que teremos sprites e lógicas melhores!

Olhei pro iPhone, o iPhone olhou pra mim e já comprei o “Learn cocos2D Game Development with iOS 5“.

Meu background em Objective-C é ZERO. Em desenvolvimento de jogos é ZERO vezes dois. O máximo que fiz foi umas brincadeiras com OpenGL na faculdade, além de uma interface de zoom contínuo para um banco de dados para J2ME (do tempo do “bumba meu boi”).

Como já tenho uma bagagem de 15 unidades temporais de programação no bolso, começando com C e passando por muitos buzzes que vieram desde 1997, não estou encontrando muitas dificuldades em utilizar o Objective-C. Claro que estou aprendendo muito. Cada linguagem nova é sempre um bom momento para quebrar paradigmas.

Desenvolvimento de Jogos

Eis um assunto em que sou completamente leigo. Tenho ideias de como isso funciona, mas, como disse, são só ideias. O livro do cocos2d está me ajudando em entender como concretizar essas ideias.

Não estou muito preocupado em fazer da melhor forma, só quero tentar concretizar minhas ideias usando o pouco que aprendi no livro (no momento, ainda no capítulo 5).

A única coisa que sei sobre isso é que esta é uma indústria fraca no nosso Brazil. Bem, normal, não é? Não nos preocupando com isso, vamos ao nosso primeiro título.

Volcano Pong: Porquê Vulcões são Sensacionais

Pouco conhecimento + engine de jogos 2D = Pong

Essa fórmula é inevitável. Além disso, como sou um nada em design, essa ideia me pareceu ser executável de forma bem trivial, usando uns sprites do OpenGameArt. Sem mais delongas, a especificação preliminar do jogo:

Ideia: Jogo de Pong com tema de Vulcões
Inteligência Artificial: Não pensei muito sobre isso ainda. Com certeza o oponente será o computador.
Arte:

• Background: Volcano Lava Floor
• Bolinha: Fireball Spell (se não der certo, fazer uma bola tipo pegando fogo sem rastro, animada via sprites)
• Pad: Um retângulo de 32×8. Ainda procurando um sprite legal; caso não encontre, fazer um.
• Fontes: Ainda pendente.
• Som:
  • “Ping” e “Pong” alternado quando a bolinha bater no pad. Vou fazer com o MorphWiz ou SampleWiz.
  • Indicativo que o placar foi alterado, pensando em um som tipo uma roldana ou cortina abrindo.
  • “Woo hoo!” quando o jogador fizer ponto.
  • Um beep quando o oponente fizer ponto.

Jogabilidade:

• Jogo funcionará em modo landscape (tanto right como left). O pad do jogador ficará do lado esquerdo e o oponente no direito. Estou pensando se o movimento será via toque ou acelerômetro, acho que vou testar os dois e ver o que se adapta melhor.
• O jogo será dividido em 10 fases. O nível de dificuldade irá subir com uma melhor IA e com maior intesidade de efeitos como terremotos, chuvas e bolas de fogo.
• O jogador terá que fazer 12 pontos para passar de fase. O jogo irá salvar automaticamente a cada fase.
• O menu inicial irá sugerir um novo jogo ou continuar da última fase jogada e ligar/desligar som.
• Um toque na tela durante o jogo irá habilitar o menu de pause, com as opções de sair do jogo, retornar, reiniciar a fase e ligar/desligar o som.
• Quando a bola estiver no pad para iniciar uma nova rodada, um toque na tela libera a bola. Uma mensagem deve aparecer no meio da tela indicando isso.

Drafts das telas do jogo:

Carmack que me aguarde…

E deixo aqui minha óbvia homenagem aos chucrutes pela alegria tardia que nos ofereceram. #foobar

Deve haver um claro equilíbrio entre os metais e o piano. Ditando o ritmo, o contrabaixo sustenta a opereta. Deixa uma indiscutível leveza aos agudos melosos e crescentes empreendidos pelo trompete. O piano não deixa o ritmo morrer, soa ao fundo, sempre suave, sempre ativo. Sóbrio e fiel.

Por vezes, vemos a necessidade de um sax. Rouco, arrastado, complexo, porém, indubitavelmente eficiente e firme. E a bateria, que conduz pacientemente todas as mais ousadas “fugas do tema”. Não haveria jazz sem o incerto rufar de uma caixa.

No final das contas, após a apresentação formal de cada instrumento dentro do tema proposto, finda a obra. Mas não regride, aliás, acontece o contrário: acaba com uma certa imposição, sustentando a premissa de uma execução perfeita, exata, sempre única.

Já tentaram fazer software assim?

Kurose em Redes de Computadores e a Internet não trata do assunto, somente algo superficial sobre criptografia. Tanenbaum em Sistemas Operacionais Modernos (3a. Ed.) também só dá uma arranhada. Pra variar, nos salvamos com Stallings em Critografia e Segurança de Redes. Tanenbaum em Redes de Computadores faz sua confusão sobre o assunto, seguindo à risca aos princípios de Kerckhoffs.

Stallings é o mais detalhado, mas só divide a Criptoanálise em duas: Diferencial e Linear. Tanenbaum complementa com análise por consumo de energia elétrica e análise de sincronismo, mas em parágrafos limitados a informar sobre as ténicas.

Motivação

• O principal problema com o DES tem sido sua vunlerabilidade ao ataque de força bruta, em razão do seu tamanho de chave relativamente curto (56 bits). (Stallings, p. 56)
• Com a popularidade das crifras de bloco como o 3DES, os ataques por força bruta tornaram cada vez mais impraticáveis. (Stallings, p. 56, adaptado)

Criptoanálise Diferencial

• A criptoanálise diferencial é o primeiro ataque conhecido capaz de quebrar o DES em menos de 2^55 criptografias.
• Um outro esquema de criptoanálise diferencial pode quebrar o DES em 2^47 criptografias, exigindo a mesma ordem em textos claros escolhidos. Apesar de esforço menor (número de criptografias), este ataque é de interesse apenas teórico.
• A criptoanálise diferencial não funciona muito bem com o DES. Em 1974, quando projetado, esta falha fora identificada e devidamente tratada com as S-Boxes e a permutação P.
• O raciocínio por trás da criptoanálise diferencial é observar o comportamento de pares de blocos de texto evoluindo a cada rodada da cifra.
• Tanenbaum diz que a criptoanálise diferencial funciona a partir de um par de blocos de texto simples que diferem apenas por um pequeno número de bits e pela observação cuidadosa do que acontece em cada interação interna, à medida que a codificação prossegue. Isso leva a um atáque probabilístico (p. 799, adaptado).

Criptoanálise Linear

• Esse ataque baseia-se em encontrar aproximações lineares para descrever as transformações realizadas no DES.
• Esse método pode encontrar uma chave DES dados 2^43 textos claros conhecidos, o que torna a criptoanálise linear inviável com oum ataque ao DES.
• Tanenbaum aqui diz que este tipo de criptoanálise rompe o DES em 2^46 textos simples conhecidos.

Tomei o cuidado de verificar as referências e ambas apontam para o mesmo artigo de Matsui. Porém, Tanenbaum referencia (Matsui, 1994), enquanto Stallings cita (Matsui, 1993). De qualquer forma, o congresso ocorreu em 93, e pelo visto, a publicação dos anais em 94.

Como isso aqui é ponto grande, resolvi dar uma olhada no artigo original. Não sei se é o sono, mas a única informação que encontrei é que para DES de 16 rodadas (padrão), o valor é de 2^47. Outros locais, tipo Wikipedia, corroboram o valor de 2^43 de Stallings. A dica? Escolha dependendo de quem pergunta, no caso de concursos, a banca.

Análise do Consumo de Energia Elétrica (somente Tanenbaum)

• Computadores utilizam 3 volts para representar o bit 1 e 0 volt para representar um bit 0.
• O processamento de um bit 1 exige mais energia elétrica que o processmaneto de um 0.
• Dependendo do esforço empreendido pelo algoritmo e a redução do clock do computador para valores perto da escala de 100Hz, um atacante poderá analisar a voltagem e o nível de energia consumida.
• Tanenbaum classifica que desta forma é supreendemente fácil deduzir a chave.
• Esse tipo de algoritmo é anulado pela codificação cuidadosa do algoritmo em Assembly para ter certeza que o consumo de energia será independente da chave e das rodadas.

Análise de Sincronismo (somente Tanenbaum)

• Os algoritmos criptográficos estão repletos de instruções if que testam bits nas chaves rodadas.
• Se partes then e else demorarem períodos de tempo diferentes, tornando mais lento o clock e verificando quanto tempo demoram diversas etapas, talvez seja possível deduzir as chaves rodadas.
• Embora seja uma técnica exótica, Tanenbaum exalta que são técnicas eficientes e capaz de quebrar crifas que não planejadas para lidar com estes ataques.

Há umas 3 semanas fui convidado a palestrar sobre SOA. Trabalhei com “isso” de abril a dezembro do ano passado, num projeto de integração entre diversos sistemas com o Oracle EBS. Fomos o segundo projeto (de EBS) no país a utilizar tal arquitetura.

Antes disso, SOA era a tecnologia do futuro (desde 2005). Ao entrar em contato próximo com ela, o que vi me deixou muito preocupado com o que vender por aí como SOA.

A Oracle, gigante do nosso mercado, disponibiliza uma suite que possibilita o desenvolvimento de soluções usando todas as sopas de letras que você possa imaginar. O problema é nos detalhes, os produtos são bastante falhos. Fluxos gigantes derrubam servidores de aplicação, problemas de comunicação com banco de dados, fluxos assíncronos são uma dor de cabeça constante, e N outros problemas.

Resumo da ópera: o projeto ficou bastante comprometido, pois integrações foram subestimadas e a tecnologia ainda não estava madura o suficiente para embarcarmos em tal aventura, numa empresa que fatura R$ 700 milhões por ano. Mas tudo bem, foi entregue graças a madrugadas à fio!

Voltando ao primeiro parágrafo, quando fui convidado a palestrar sobre o assunto, pensei em meter o pau no que representa o SOA. Porém, pensei bem, aquilo foi a visão de um único fabricante que tive, e confesso aqui, eu não havia estudado o suficiente para compor o que considero uma arquitetura orientada a serviços hoje em dia.

Com isso em mente, compus uma palestra com o pé firme na teoria, mostrando os contra-sensos das visões teórica e prática.

Não incentivo aqui a submissão dos nossos pares às nossas crenças, sim o exercício pleno daquilo que tomamos como verdade no nosso íntimo. Dispomos de máscaras diversas – do político, vaidade, orgulho -, através delas nos apresentamos ao mundo. Queime a máscara do medo da reprovação. Uma a menos e já estaremos no caminho para melhorar.

Chega de alisar cactos