Instalando Quake
Agora, voltarei a jogar. =)
Ao ler um dos blogs do Bennett, vi ele mencionar um site para produção automática de tirinhas – sem precisar desenhar, só ser roteirista. O site? WittyComics. Fiz umas 3 tirinhas até agora, que ilustram este post.
Jokes
Dynamic
Finally!
Recentemente saiu a notícia no BR-Linux: estava disponível para jogar Quake Live com a pequena instalação de um plugin no Firefox. Entro no site do quakelive e tento instalar no meu Firefox ou no Safari do Mac OS X. O resultado foi o mesmo, a tela abaixo.
Incompatibilidade de plugin
Instalando o plugin
Plugin instalado
Prossigo com o processo de instalação, ele demora um pouquinho baixando atualizações (ok, minha banda de conexão não é muito larga), mas finalmente consigo começar o jogo. Como estou jogando na VM, com recursos escassos para vídeo e conexão lenta, o jogo ficou bastante lento, porém mesmo assim dá pra sentir que o jogo está bom e é empolgante ter essa portabilidade para GNU/Linux através do Firefox. Resta agora conseguir isso para o Mac OS. =)
Carregando jogo
Tela de boas vindas
Começando a jogar
Jogando em tela inteira
Enquanto estava estudando a linguagem de programação Lua, em um capítulo sobre elementos funcionais da linguagem, me deparei com uma explicação interessante para tail recursion. Nela, o autor do livro (Programming in Lua, 1ª Edição) falava como a linguagem implementa completamente tail recursion(que acho que fica bem traduzido como recursão de cauda). Até aí tudo legal, mas melhora.
Bem, pra demonstrar que implementa e também explicar o conceito, o autor se utiliza de um jogo-exemplo: um labirinto. O jogo constrói o labirinto através de funções que chamam umas às outras, porém utilizando-se de recursão de cauda para manter sempre o uso de memória como se só houvesse uma função. Explicação e o exemplo utilizado podem ser encontrados aqui.
Explicando melhor recursão de cauda: o princípio é que não precisamos que uma função fique esperando o retorno de um resultado de outra para terminar sua execução, como acontece normalmente. Se você faz uma função em C, ou um método em Java, que termina com um comando return outraFuncao;, a função original ficaria esperando o termino da chamada para poder terminar sua execução. Só que outraFuncao pode fazer chamadas a outras funções, e essas a mais outras, e assim por diante. Tal carga será deixada para a memória, que acabará por estourar(um stack overflow, ou estouro de pilha). Mas perceba que, no caso de uma instrução final de uma função, não há motivo para a espera de retorno da chamada. Pode-se simplesmente indicar que o retorno será o da função agora chamada, e limpar a memória utilizada pela execução da original. É isto que linguagens funcionais como Haskell e Scheme e linguagens com fortes influências, como Lua, implementam.
A novidade que gostaria de compartilhar aqui é uma implementação do mesmo código feito em Lua, para Haskell. O código pode dar origem a um jogo bastante complexo e infinitamente escalável, já que ao chamar uma nova função (entrar em um novo quarto) nenhuma informação é mantida da que chama, e sua execução é encerrada por completo. Código em Haskell abaixo:
import IO
main = do
room1
room1 = do
putStrLn "You're in room #1"
text <- getLine
if text=="south" then
room3 -- movendo-se pro quarto 3
else
if text=="east" then
room2 --movendo-se pro quarto 2
else
putStrLn "Invalid move" >>
room1 --permanece no mesmo quarto
room2 = do
putStrLn "You're in room #2"
text <- getLine
if text=="south" then
room4
else
if text=="west" then
room1
else
putStrLn "Invalid move" >>
room2
room3 = do
putStrLn "You're in room #3"
text <- getLine
if text=="north" then
room1
else
if text=="east" then
room4
else
putStrLn "Invalid move" >>
room3
room4 = do
putStrLn "You're in room #4! You won!"
O código é simples, elegante, e correto. É este mesmo comportamento que torna a recursão um ponto tão forte em Haskell: iteração não é necessária à linguagem pois recursividade não apresenta peso adicional algum ao código. Isto nos permite escrever funções recursivas muito mais poderosas do que podemos encontrar em uma linguagem como C ou Java, onde a pilha de execução não suporta tantas chamadas quanto uma tarefa mais complexa possa precisar(ex.: inserção em uma árvore AVL com 100 mil nós). Isso nos permite executar códigos como o clássico exemplo do fatorial:
fact x = if x < 0 then error"Fatoriais sao de numeros positivos!"
else fact2 x 1 where
fact2 0 acumulador = acumulador
fact2 x acumulador = fact2 (x-1) (acumulador*x)
Pode-se rodar este exemplo e calcular o fatorial de 100 mil, o que não é possível com recursão em C. Apesar do peso do alto nível de abstração, vemos aí parte do poder do paradigma funcional e da linguagem Haskell!
PS: Erro corrigido no quanto à recursividade do fatorial. Ah, e o exemplo do fatorial pode não dar Stack Overflow, mas dependendo da entrada você pode atingir picos de uso de CPU. =)
Charge encontrada em tutorial sobre Alloy, que nos faz lembrar da importância de especificação bem feita. Ou acabamos encontrando problemas assim na análise:
Prova Formal
Cuidado!!! =)
Este post é dedicado aos lendários jogos de Adventure de outrora, jogos que fizeram minha infância e adolescência muito mais interessantes. =)
Os jogos deste gênero produzidos no começo dos anos 90 pela Lucas Arts tinham tudo: humor, sarcasmo, inteligência, ação e até romance – a p**ra toda. Foi uma boa era. Jogos muito bem feitos, nos quais você não tinha como perder: parte da filosofia da empresa era que “jogos são feitos para divertir, não para frustrar o jogador” – havia realmente declarações da filosofia nos manuais dos jogos! É, muita coisa mudou desde então. Por isso, volta e meia recorro a eles.
Full Throttle
“An ambush? Really?”
, por Miranda, amiga de Maureen, pouco antes de ela lhe sacanear não lhe dando uma carona.
Hit the Road
Day of the Tentacle
The Day of The Tentacle é um jogo ousado. É bem provável que ele seja um dos motivos de eu gostar de história, já que sua paródia da história americana junto com a idéia de causalidade de fatos e apelo científico tornam o jogo bastante complexo. Paradoxos de viagem no tempo são deixados de lado quando você precisa salvar o mundo!
Um pouco do enredo: Não menciono o Maniac Mansion original aqui por alguns motivos: sua dinâmica era um tanto mais confusa que o 2º, nunca cheguei a jogá-lo por completo, e ele não possuía a filosofia de que o jogador não pode perder – não necessariamente nesta ordem. Mesmo assim, sua história tem continuidade no segundo jogo da série, onde 3 estudantes voltam a Mansão para salvar o mundo, quando um tentáculo – criação do Dr. Fred, gênio lunático do primeiro jogo – pede socorro com ajuda de um hamster. Ao salvarem o tentáculo bom, eles também libertam um tentáculo terrivelmente maligno, que parte então para dominar o mundo. A única solução então é viajar no tempo de forma a impedir que o tentáculo maligno ganhe poderes, e venha a precisar ser impedido. Quando os três personagens tentam fazê-lo, acabam se separando entre o passado, presente e o futuro, e AÍ começa a diversão de verdade. =)
Um último jogo sobre o qual eu comentaria seria a série da Ilha dos Macacos (Maldição, fuga, etc). Formam uma série muito bem sucedida e tal, MAS eu nunca os joguei. Houve milhares de comentários entre amigos, porém nunca tive a oportunidade. Uma pena. Quando jogar, colocarei algo aqui.
Com meu tempo atribulado, hoje tive uma iluminação:
Preciso de algo para gerenciar melhor meu tempo durante o dia… já sei, vou fazer um temporizador!
Isso, e pelo fato da água da chaleira ferver demais e eu ter que re-enxê-la para fazer café. Muito chato isso – mesmo. Fui até o Eclipse, e comecei a digitar.
Quero algo em formato de pop-ups, que aparecem na tela e me diga: “Ei, hora disso.”
Pop-ups.. hum… Poderiam ser Dialogs? Surgiu uma idéia simples:
Começando com uma classe simples, chamemo-a Main.
public class Main{
}
Para podermos chamar fácil Dialogs de opções a partir dela, podemos acrescentar algo: herdando de JFrame, fica fácil de usá-la como componente pai de um Dialog de JOptionPane. Começamos a fazer sua classe principal também:
public class Main extends JFrame{
public static void main(String[] args){
Main m = new Main();
m.setVisible(false);
}
}
Ok, agora já temos um JFrame invisível. A partir deles vamos abrir pop-ups. Podemos ter um para saber quantos minutos você quer esperar, e outro para saber que mensagem ele deve retornar para lhe lembrar do que era para ser feito. Finalmente teremos um que indicará que passou o tempo.
public class Main extends JFrame{
public static void main(String[] args){
Main m = new Main();
m.setVisible(false);
String tempo = JOptionPane.showInputDialog(m,"Digite o tempo de espera");
if(tempo==null){
//caso da janela ser cancelada ou fechada.
System.exit(0);
}
tempo=tempo.trim();
int minutos = Integer.parseInt(tempo);
String mensagem = JOptionPane.showInputDialog(m,
"Digite a mensagem de alerta!");
Thread.sleep(minutos*60*1000);
JOptionPane.showMessageDialog(m,mensagem);
m.dispose();
System.exit(0);
}
}
}
O programa todo é mais ou menos isso. Na chamada de Thread.sleep, a multiplicação é feita para passar de minutos para milissegundos, medida de tempo que ele usa. Claro, algumas exceções devem ser verificadas: NumberFormatException e InterruptedException, para o parseInt e o sleep, respectivamente. Podemos florear também o retorno um pouco. O código final fica assim:
public class Main extends JFrame{
public static void main(String[] args){
Main m = new Main();
m.setVisible(false);
try{
String tempo = JOptionPane.showInputDialog(m,"Digite o tempo de espera");
if(tempo==null){
//caso da janela ser cancelada ou fechada.
System.exit(0);
}
tempo=tempo.trim();
int minutos = Integer.parseInt(tempo);
String mensagem = JOptionPane.showInputDialog(m,
"Digite a mensagem de alerta!");
Thread.sleep(minutos*60*1000);
JOptionPane.showMessageDialog(m,mensagem,"Passados "+tempo+" minutos!!!",
JOptionPane.WARNING_MESSAGE);
} catch(NumberFormatException e){
JOptionPane.showMessageDialog(m, "Use somente "+
" números inteiros para o tempo!!!");
} catch(InterruptedException e){
JOptionPane.showMessageDialog(m, e.getMessage());
} finally{
m.dispose();
System.exit(0);
}
}
}
}
Quanto à dependências dos pacotes, só precisa do JFrame e do JOptionPane – nada que um Ctrl+Shift+O não resolva.
Isso, em uma classe só, é um aplicativo trivial e funcional o suficiente para eu ter me viciado nele. Já virei escravo dele para tudo que preciso. E não me preocupo mais que a água da chaleira evapore toda.
