Eu gosto muito dos desafios de programação do Daniel Shiffman, do canal The
Coding Train, porque me obriga a desenvolver algoritmos para resolver certos
problemas. Mas às vezes é roubada! Porque ele deixa o programa todo basicão e
eu quero chegar num produto mais finalizado. O desafio que estou falando é o
#142 - programar um Cubo de Rubik. Eu achei interessante porque um dos meus objetivos de vida é resolver esse
cubo, sem olhar tutorias na internet! Eu sempre tive cubos chineses que
travavam na hora de girar e as peças acabavam pulando. Mas, imaginem, o Daniel
precisou postar 3 vídeos apenas pra chegar num cubo que faz um certo número de
movimentos e depois desfaz!
Mas eu queria que o jogo tivesse:
- Diferentes tamanhos (de 2 a 7);
- Um sistema para selecionar o cubinho com o mouse;
- Um sistema para movimentar com as teclas WASD;
- Um menu para embaralhar e reiniciar.
Ou seja, levei o quádruplo do tempo. Como diria Pedro, é cilada Bino! Meu jogo
semi-finalizado ficou assim:
Quem quiser, pode ver meu código aqui:
Nesse desafio, foi usado o Processing, que conheci faz pouco tempo mas não dei muita importância. Pra quem não conhece, ele tem a mesma proposta do Arduino de facilitar o aprendizado de programação e eletrônica para leigos e crianças. Só que no Processing, você escreve programas em Java para rodar em computadores. Aliás, ele usa o mesmo editor de texto do Arduino. Se existissem quando eu era criança, eu seria outra pessoa! Teria feito jogos do caralho! Mas pelo contrário, não existia nada assim pra facilitar, e BASIC era muito limitado. Nenhum conhecimento de graça, nem internet!
Tanto no Processing como no Arduino, existem várias bibliotecas que podem ser baixadas dentro do programa. Elas são escritas pelo povo da internet que já pensaram no problema que você está possivelmente tentando resolver agora. São como módulos plug-and-play pro seu programa. Mas se como eu, você quiser fazer algo um pouquinho mais complicado, lascou-se! Aliás, não acho Java nem de perto acessível para leigos. O povo da internet provavelmente pensou a mesma coisa e adicionou um modo Python.
Então, Processing é bonito e tudo mais só que...
-
Quando eu tentei escrever uma classe de Menu pro meu jogo, descobri que o
Java não aceita membros estáticos dentro de classes públicas! Você precisa
definir classes estáticas e criar uma instância delas! Em c++, a
funcionalidade fica auto-contida, por exemplo:
class Menu { Menu(); // Construtor escondido public: static Menu& CreateMenu(const std::string& name); } // Em alguma outra parte do código: Menu::CreateMenu("File");
-
Java não passa ponteiros, então você não pode passar uma função de
callback como em c++, o que é ótimo, pois ponteiros geram todo tipo
de problemas! Só que versões anteriores à 8 não aceitam as
funções lambda, que funcionam como callback. Então, o jeito é
criar uma interface que deve ser derivada para cada função de
callback:
Menu_New("SHUFFLE", new MenuAction(){ public void run(Menu m) { println("We are shuffling the Rubik!"); shuffling = true; }});
Okay, não é tão ruim assim, copiar e colar a linha 2 não vai matar ninguém.
- O Daniel usou uma biblioteca pra movimentar a câmera num cenário 3D, PeasyCam, perfeito! Agora eu procurei alguma para sabe sobre qual face o ponteiro do mouse estava, achei! É a Picking do Nicolas Clavaud. Estava funcionando bem mas sempre mostrava um erro endDraw() no terminal. Então resolvi escrever minha própria biblioteca com ajuda das documentações obscuras geradas em javadoc nos recantos da internet. Funcionou mas ficou com pouca precisão, às vezes oscila entre duas faces.😞
- O jogo ficou lerdo no meu Core i5 com RX470 mas ficou fluido no meu notebook com MX150!? 😨
- No fim das contas, é legal que o Processing gere um .exe para rodar em qualquer computador, mas eu acharia melhor se fosse um .jar para embutir em uma página da web. Já pensou como seria bacana inserir o jogo aqui mesmo no blog?
Comentários
Postar um comentário