Deep Blue VS Garry Kasparov

Inesquecível o dia em que o grande campeão mundial de xadrez perdeu pra o Deep Blue, programa de computador criado pela IBM para essa finalidade.

[wikipedia]
Deep Blue (em português, azul profundo) foi um supercomputador e um software criados pela IBM especialmente para jogar xadrez com 256 co-processadores, capazes de analisar aproximadamente 200 milhões de posições por segundo.
[/wikipedia]

Abaixo temos a notação da partida:

[Event "Match"]
[Site "Philadelphia (USA)"]
[Date "1996.??.??"]
[EventDate "?"]
[Round "1"]
[Result "1-0"]
[White "Deep Blue (Computer)"]
[Black "Garry Kasparov"]
[ECO "B22"]
[WhiteElo "?"]
[BlackElo "?"]
[PlyCount "73"]

1.e4 c5 2.c3 d5 3.exd5 Qxd5 4.d4 Nf6 5.Nf3 Bg4 6.Be2 e6 7.h3
Bh5 8.O-O Nc6 9.Be3 cxd4 10.cxd4 Bb4 11.a3 Ba5 12.Nc3 Qd6
13.Nb5 Qe7 14.Ne5 Bxe2 15.Qxe2 O-O 16.Rac1 Rac8 17.Bg5 Bb6
18.Bxf6 gxf6 19.Nc4 Rfd8 20.Nxb6 axb6 21.Rfd1 f5 22.Qe3 Qf6
23.d5 Rxd5 24.Rxd5 exd5 25.b3 Kh8 26.Qxb6 Rg8 27.Qc5 d4 28.Nd6
f4 29.Nxb7 Ne5 30.Qd5 f3 31.g3 Nd3 32.Rc7 Re8 33.Nd6 Re1+
34.Kh2 Nxf2 35.Nxf7+ Kg7 36.Ng5+ Kh6 37.Rxh7+ 1-0


Como eu sei que nem todo mundo que lê esse blog sabe interpretar uma notação desse tipo, deixo aqui um link que mostra a simulação da partida vista em cima de um tabuleiro (precisa-se do Java):

http://www.chessgames.com/perl/chessgame?gid=1070874

A derrota de Kasparov no "match" é uma das maiores polêmicas do mundo do xadrez. Naquela ocasião, o grande mestre acusou a IBM de ter trapaceado dizendo que jogadores humanos intervieram durante a segunda partida.

A IBM se defendeu dizendo que os ajustes no programa e intervenções ocorriam somente entre uma partida e outra. Kasparov pediu os arquivos (printouts dos log files), porém a IBM se recusou a fornecê-los. Na base de dados do computador havia mais de 700 mil partidas de Mestres e Grandes Mestres, porém quando Kasparov pediu à IBM algumas partidas jogadas pelo Deep Blue para que entendesse melhor seu oponente, o pedido foi negado. Kasparov pediu ainda um novo match, porém a IBM não teve interesse e aposentou o computador. Há um documentário de 2003 (Game Over: Kasparov and the Machine) que conclui que esta vitória foi armada para elevar o valor das ações da companhia.

Vai saber.

VLC, o Chuck Norris dos media players

Citar a lista de recursos do pequeno e leve tocador de arquivos multimídia VLC faz lembrar daqueles engraçados e-mails com os Chuck Norris Facts. Dúvida? Então veja algumas das qualidades desse excelente player:

• A comunidade do VLC criou sua própria Wikipedia para listar as funções e recursos do programa. Já são 423 verbetes.
  
• O VLC roda em todos os sistemas operacionais conhecidos. Não estamos falando só de Windows, Mac e Linux. O player tem versões para BeOS, FreeBSD, Syllabe, Solaris...
  
• Mesmo não tendo nenhuma empresa gigante o apoiando (como o Windows Media Player e o iTunes), o VLC é baixado, em média, uma vez a cada cinco segundos.
  
• Sem a ajuda de nenhum codec adicional, o VLC suporta todos os formatos de áudio e de vídeo que você imaginar, como AVI, MPG, MOV, WMV, Real, SVCD... E toca sem problemas aqueles que você nem imagina como Matroska, 3GP, FLV, Cinepak, FLAC, Ogg. O VLC abre até arquivos de ASCII Art
  
• Não tem problema se o arquivo de vídeo em AVI está corrompido ou incompleto, o VLC toca na marra.
  
• O VLC é capaz de tocar DVDs que estão no formato de imagem (ISO) sem precisar descompactar os dados ou criar drive virtual.
  
• O VLC tem uma interface muito simples. Mais simples que a do MS Paint. Mesmo assim oferece compatibilidade com todos os formatos de legendas possíveis e ainda permite sincronizar a exibição dos textos com o filme usando o próprio programinha.
  
• Com meia-dúzia de cliques, o VLC pode ser configurado para transmitir e receber transmissões multimídia via streaming nos padrões Unicast, Multicast, VOD, IPv4 e IPv6.
  
• O VLC pode usar Skins para ficar com a mesma aparência do iTunes, do Winamp, do Windows Media Player e até com o desenho de um Home Theater.
  
• Pessoas de 20 países diferentes trabalham no desenvolvimento do VLC. Há versões em catalão, finlandês, hebreu, pashto, nepalês e punjabi –entre outras.

Para baixar o VLC 0.9, vá ao Download INFO.

criando um MMORPG

Um guia para iniciantes de como criar um MMORPG
por Radu Privantu
Traduzido por Sérgio Oliveira

Esse artigo irá focar nos primeiros passos da construção dos seus próprios RPGs On-line massivos (do inglês, MMORPG - Massive On-line Role Playing Games). ele é voltado para o desenvolvedor de jogos iniciante, com recursos e experiência limitados. Depois de ler esse artigo, você deverá saber o que é necessário para começar, e alguns conselhos sobre o que fazer e o que não fazer. O primeiro passo é avaliar suas habilidades, e os seus recursos. Você precisa ser honesto consigo mesmo, porque pode ser frustrante perder o seu tempo tentando construir algo que você não consegue.

Primeiro passo: Avaliando suas habilidades

Habilidades necessárias:

1. Conhecer pelo menos uma linguagem de programação. Até aqui, o C++ é a escolha mais popular entre os desenvolvedores devido as suas vantagens de eficiência e performance. O Visual Basic, Java ou C# também devem dar conta.

2. Familiarize-se com uma biblioteca gráfica. Escolhas mais populares são o SDL, OpenGL, ou DX/D3D... Escolha a biblioteca que você irá utilizar. Você pode escolher entre a WinSock, SDL net, ou DirectPlay.

4. Adquira uma experiência geral em programação de jogos. Por exemplo, o laço dos eventos, multithreading, design de GUI, etc.

Habilidades altamente recomendadas:

1. Comunicação Cliente/Servidor e arquitetura.

2. Programação multiplataforma. Você provavelmente vai querer projetar o seu MMORPG, e especialmente o servidor como um que possa rodar em múltiplos SOs. Para esse propósito, eu recomendo usar SDL, OpenGL e SDL net.

3. Desenvolvimento Web. Isso será necessário se você quiser permitir às pessoas verem as estatísticas do jogador, as informações do servidor, e outras informações em um website.

4. Segurança & Administração. Você não vai querer que alguém hackeie o seu servidor e bagunce tudo!

5. Habilidades do time. Você vai precisar de um time que possa liderar e gerenciar com sucesso.

Segundo passo: Faça um projeto preliminar.

Eu notei muitas pessoas postando em vários fóruns a procura de times para fazer MMORPGs. A maioria deles começa com algo assim: "Nós somos uma empresa/estúdio de jogos iniciante e estamos precisando de 3 artistas, 2 programadores, 1 músico, etc. para um inovador, nunca visto antes, MMORPG onde você terá total liberdade para fazer o que você quisesse e remodelar o mundo, etc. Nós iremos pagar você quando o jogo estiver pronto e nós tivermos feito algum dinheiro." Infelizmente, com a tecnologia atual e largura de banda limitada, você não consegue ter um mundo dinâmico. Visar algo impossível irá inevitavelmente levar à falha. Ao invés disso, tente começar com um projeto e uma arquitetura pequenos, funcionais, e expansíveis.

Arquitetura de Software Básica

Primeiro, tente focar em fazer um modelo cliente/servidor simples, onde você poderá:

1. Criar um novo personagem
2. Salvar o personagem (no servidor)
3. Loguar com o personagem
4. Permitir conversar com os outros
5. Permitir navegar pelo cenário em 3D

Salvar os personagens pode parecer simples, mas de fato, não é. Por exemplo, há duas maneiras de salvar os personagens: usando um servidor de banco de dados ou usando arquivos. Há vantagens e desvantagens para ambas:

http://img83.imageshack.us/img83/8196/iyung5.jpg


Terceiro passo: Escolhendo um protocolo interno para transmissão de dados

Isso pode parecer simples, mas, novamente, não é. Você não pode simplesmente mandar strings com, '\0' para encerrar. Isso porque você irá precisar de um protocolo consistente, que poderá enviar ambas a string e os dados binários. Não é aconselhável usar 0 (ou qualquer outra seqüência) para encerrar, porque o encerramento pode ser parte do fluxo de dados que você quer enviar. Além do que, se você enviar 20 bytes, e depois outros 20 bytes, é muito provável que o servidor não irá receber um pacote de 20 bytes, e depois outro pacote de 20 bytes. Ao invés disso, ele irá receber 40 bytes de uma vez, para evitar ficar desperdiçando banda com cabeçalhos desnecessários. Alternativamente, você pode mandar um pacote de 1K, mas o servidor irá recebe-lo em dois pacotes menores. Então você precisará saber onde um pacote começa, e onde ele termina.
No Eternal Lands, nós usamos o seguinte método:

* Offset 0: 1 byte denotando o comando transmitido.
* Offset 1: 2 bytes, o comprimento do dado transmitido.
* Offset 3: comprimento variável, o corpo da mensagem.

Esse método tem a vantagem de ser consistente: todos os dados transmitidos seguem o mesmo padrão.
A desvantagem é que alguns comandos têm a um comprimento conhecido, fixo, então a largura de banda é desperdiçada. Nós iremos eventualmente alternar para um aproximação híbrida, num código mais adiante.
A próxima coisa a se decidir é o modelo do servidor: "sem sockets de bloqueio, sem threading", ou "com sockets de bloqueio, com threading". Ambos métodos (com threading X sem threading) têm suas vantagens e desvantagens.

Com Threading:

1. Uma resposta um tanto quanto reprimida do servidor, desde que um jogador precise de muito tempo (como ler dados do banco de dados) isso é feito no seu próprio thread, não afetando outros.
2. Muito difícil de depurar e implementar propriamente: Você vai precisar de muita sincronização, e um pequeno descuido pode ter efeitos desastrosos (queda do servidor, duplicação de item, etc.)
3. Faça uso dos sistemas multiprocessadores.

Sem threading:

1. Muito mais fácil de implementar e depurar.
2. Tempo de resposta menor.

Na minha companhia, nós optamos pelo caminho sem threading, porque eu simplesmente não tenho recursos e disposição para lidar com o threading.

Quarto passo: O Cliente

Você planeja fazer um jogo 2D ou 3D? Alguns iriam argumentar que é mais fácil fazer um jogo 2D. Eu fiz ambos, e eu acredito que o 3D seja mais fácil. Deixe-me explicar.

Em 2D, você normalmente tem o buffer de frames, que é um grande array de pixels. O formato desses pixels podem diferir, de placa de vídeo para placa de vídeo. Algumas têm modos RGB, outras têm modos BGR, etc. O número de bits para cada cor podem variar também. Isso acontece só para modos de vídeo de 16bpp. Modos de vídeo 8-bit e 24-bit são mais fáceis, mas com seus problemas (8-bits te dão algumas cores (256), enquanto modos de 24-bit são mais lentos). Você também irá precisar fazer as suas próprias rotinas de tratamento de sprites, e você tem de selecionar os seus objetos sozinho, então eles serão desenhados na ordem certa. Claro, você pode usar OpenGL ou D3D para jogos 2D, mas normalmente não se usa. Nem todo mundo tem uma placa aceleradora 3D, então usar uma biblioteca 3D para um jogo 2D normalmente traz as desvantagens dos dois mundos: Nem todo mundo vai poder jogar o seu jogo, e você não poderá rodar a câmera, ter sombras melhores, e várias outras coisas específicas de aplicações 3D.

O modo 3D, como eu já disse, é mais fácil, mas requer algum conhecimento básico de matemática (especificamente trigonometria). Hoje em dia as bibliotecas gráficas são muito poderosas, e irão oferecer a você as operações básicas de graça (você não precisa selecionar os seus objetos para a frente de novo, mudando a cor e/ou a textura de um objeto é muito fácil, os objetos serão iluminados de acordo com a luz e com a sua posição (conforme você calcula os vetores normais para eles), e mais. Assim sendo, 3D dá a você muito mais liberdade de criação e movimento. As desvantagens são que nem todo mundo poderá jogar o seu jogo (você ficaria surpreso com a quantidade de pessoas que não tem placas aceleradoras 3D), e gráficos pré-renderizados sempre irão parecer melhor que seus equivalentes renderizados em tempo real.

Quinto passo: Segurança

Obviamente, não dá pra se confiar nos usuários. Em nenhuma circunstâncias você pode assumir que os usuários não poderão derrotar os seu super bem projetado esquema de criptografia (se você usar um), ou seus protocolos. Tudo que o usuário mandar para o servidor tem de ser validado. Muito provavelmente, no seu servidor você terá buffers fixos. Por exemplo, é comum ter um pequeno buffer (talvez de 4K) para os dados que chegam (dos sockets). Um usuário malicioso pode mandar uma seqüência de dados realmente grande. Se não for verificado, isso irá sobrecarregar o buffer, resultando em queda do servidor, ou, pior, o usuário poderá conseguir hackear o seu servidor, executando códigos arbitrários. Toda mensagem sozinha tem de ser verificada: quer ocorra a sobrecarga do buffer, quer dados inválidos sejam enviados (como uma mensagem do usuário "entre nessa porta" ainda que a porta esteja no outro lado do mapa, ou "use a poção de cura" ainda que o usuário não tenha tal poção, etc.)

Eu vou repetir: É extremamente importante validar todos os dados. Sempre que houver uma violação, registre o nome do usuário, o IP, o horário e a data, e a natureza da violação. A cada intervalo de tempo, verifique o registro. Se você achar violações de muitos usuários, isso é normalmente um bug no cliente, ou um problema de rede. Entretanto, se você achar muitas violações do mesmo usuário ou IP, esse é um bom indicador de que alguém está brincando com o servidor, tentando hackear ele, ou rodando um macro/script. Também, nunca armazene dados no cliente. O cliente deve receber seus dados do servidor. Em outras palavras, Ele não deve mandar coisas como: "OK, essa é minha lista de itens" ou "minha força é 10, minha mana é 200, e minha vida é 2000 de 2000". Também, o cliente não deve receber mais dados do que os necessário. Por exemplo, o cliente não deve saber onde os outros jogadores estão, exceto se eles estiverem próximos. Isso é senso comum, já que mandar todos os jogadores pra todo mundo irá consumir muita banda, e alguns jogadores podem hackear o cliente para a eles vantagens desonestas (como pegar a posição de certo jogador mostrado no mapa). Tudo isso é de senso comum, mas, novamente, você ficaria surpreso em descobrir quantas pessoas não possuem o que chamamos de senso comum.

Outras coisas a se considerar, quando falamos de segurança: A velocidade que um jogador anda deveria ser forçada para o servidor, não para o cliente. O servidor deve manter a contagem do tempo (em milisegundos) de quando um cliente se moveu pela última vez, e se uma requisição de movimento chegar mais rápido do que o limiar normal, essa requisição deveria ser descartada. Não responda a essas falsas requisições, por que elas podem resultar em latência na rede (ex: lags do jogador, e todos os dados que ele mandou nos últimos 10 segundos voltam mais uma vez).

Verifique a distância. Se um jogador tentar trocar com outro jogador que está a 10 bilhões de quilômetros de distância (ou mesmo em outro mapa) registre isso. Se um jogador tentar visualizar, ou usar um objeto do mapa que está distante, registre. Seja cuidadoso com IDs falsos. Por exemplo, é normal assinar um ID para todos jogadores (o ID pode assinado quando eles logam, ou pode ser permanente (ID único)). Se o ID é dado quando o jogador faz login (ou quando um monstro é criado), faz sentido usar a posição (índice) na array dos jogadores (onde o jogador está) como o ID.

Então o primeiro jogador que logar terá o ID 0, o segundo terá o ID 1, e assim por diante. Agora, muito provavelmente você terá um limite de, digamos, 2000 índices na lista do jogador. Então se um jogador mandar um comando como: "veja o ator com o ID 200000" isso irá derrubar o servidor se ele estiver desprotegido e tentar acessar uma memória inválida. Então uma verificação como:"
se ator id<0>max de jogadores então registre a violação e desconecte o jogador". Se o seu programa estiver em C ou C++, então tome o cuidado de definir o índice como 'unsigned int' e verifique cadeias maiores, ou se por alguma razão você definiu o índice como int (int, é colocado como padrão), lembre-se de verificar se o ator é <0>max. Uma falha nisso irá resultar em muita frustração tanto para você quanto para os outros usuários. Similarmente, verifique coordenadas fora do mapa. Se você tem alguma forma busca de trajetória no seu servidor, e os cliente se movem clicando na posição no chão, certifique-se de que eles não irão clicar fora do mapa.

Sexto passo: Montando um time

Montar um time dá muito trabalho (a não ser para Pong ou Tetris). Isso é especialmente verdade para MMORPG. Você não pode simplesmente fazer tudo sozinho. O ideal é que um time seja composto de:

* Ao menos 3 programadores: 1 para o servidor, e 2 para o cliente (ou 1 para o cliente, um para as ferramentas, mais de 6 deve ser muito. Isso realmente depende das suas habilidades de liderança. No mínimo 1 artista, mas preferencialmente 2 ou 3. Se for um jogo 3D você vai precisar de um artista 3D, de um artista 2D (para texturas, interface, etc.), um animador, e um líder para o departamento de arte. A menos que você seja um bom artista, o departamento precisa se manter junto e coordenado por um artista experiente.

* Alguns construtores de mundos: construir todos os seus mapas é um longo processo, e é critico para o sucesso do jogo. Novamente, se você irá precisar de um líder para o departamento de construção do mundo, Você não pode simplesmente ter qualquer um fazendo o que diabos ele quiser já que o design do mundo deve ser consistente.

* Um webmaster é excelente, a não ser que você seja realmente bom com web design, e esteja disposto a gastar o seu tempo fazendo um website. Ter um músico não é necessário, mas um jogo com som e música pode ser mais enjoativo do que um sem.

* Um designer para economia do jogo. Você pode pensar que isso é fácil, e você pode fazer tudo sozinho, mas de fato é uma das coisas mais complicadas. Se sua economia for mas projetada (ex os itens não estiverem propriamente balanceados, recursos são colocados aleatoriamente nos mapas, etc.) os jogadores vão ficar enjoados/frustrados e irão sair. Nós tivemos um grande problema em um dos nossos estágios iniciais, especialmente porque a economia foi feita principalmente por mim (um programador), e não foi planejada de maneira apropriada. Então levamos cerca de 2 meses para repensar e reimplementar um novo sistema de economia. Isso também exigiu uma eliminação total dos itens. Felizmente, a maioria dos nossos jogadores concordaram com a idéia, mas ainda foi frustrante gastar tantas horas argumentando, comprometendo, explicando, e em geral, perdendo tempo. Mas veremos mais da economia mais tarde.

Como mencionei antes, você irá precisar de 10 a 15 pessoas para o time, não incluindo os moderadores e administradores. Essas de 10 a 15 pessoas deveriam ter experiência prévia nos seus campos. Se todas elas forem iniciantes normalmente fica mais difícil, já que você irá precisar gastar muito tempo explicando a eles o que fazer, como fazer, porque o jeito que eles estão fazendo é ruim, etc.

Conseguir de 10 a 15 pessoas desde o início é quase impossível. Não importa o quanto você irá postar nos fóruns, você não vai conseguir membros do time de qualidade. Além do que, se alguém tiver muita habilidade em seu campo, porque ele iria se juntar ao seu time, se você não tem nada para mostrar? Muitas pessoas têm grandes idéias, mas implementa-las exige muito tempo e esforço, então elas preferem trabalhar em seus próprios projetos do que no seu. Então se você precisa de 10 a 1 pessoas, mas não consegue fazê-las se juntar ao seu time, como você conseguirá fazer um MMORPG? Bem, na realidade, você não irá precisar de todas elas desde o começo. O que você realmente irá precisar é de 1 programador e 1 artista. Se você é um programador, arrume um artista. Pegue um amigo com habilidades gráficas, pague um amigo de escola para fazer a parte artística ou outra coisa para você.

Agora que você tem um artista, e pelo menos uma idéia de como o jogo deveria ficar, é hora de começar a implementar a idéia. Uma vez que você tiver um projeto funcionando de um semi cliente/servidor, e alguns screenshots para mostrar (ou ainda melhor, a habilidade para os jogadores realmente logarem nos seu mundo, andar por ele, e conversarem um com o outro), mais pessoas irão querer se juntar ao seu time.
Preferencialmente, a menos que você tenha uma incrível tecnologia que ninguém mais tem, você deve deixar o código fonte do seu cliente aberto. Muitos programadores iriam se juntar (como voluntários) a um projeto de código aberto, ao invés de um projeto de código fonte fechado. O servidor, por outro lado, deve ser um código fonte fechado (a menos que você planeje desde o início fazer um código de MMORPG totalmente abeto).

Alguns outros conselhos: Não fique se gabando do seu jogo até que você tenha algo pra mostrar. Uma das coisas mais alarmantes é quando um novo usuário posta um pedido de ajuda, pedindo para um grande time se juntar ao jogo dele, explicando o quanto é legal o jogo dele. Uma vez que você tenha ido para os anúncios do website (normalmente em um serviço de host gratuito) você verá um impressionante menu de navegação, contendo seções como: "Download", "Screen Shots", "conceitos de arte", "Fóruns". Você clica no link de download, e você obtém um página muito legal de "Em construção". Então você clica clica no screenshot da página de Screenshots, e você terá o mesmo resultado. Se você não tiver nada para baixar, não coloque um link de um screenshot. Ainda melhor, nunca perca o seu tempo com um website até que você tenha pelo menos 10% dentro do projeto (programação e arte).

Sétimo passo: Desfazendo alguns mitos

1. Você não pode fazer um MMORPG, só dá pra uma companhia grande construir um.

Eu discordo disso. Enquanto produzir um jogo como um World of Warcraft, Ever Quest 2, Asheron's Call 2, Lineage 2, e outros é impossível para times pequenos, de desenvolvimentos independentes, fazer um jogo decente é possível, desde que você tenha experiência, motivação e tempo. Você irá precisar de pelo menos 1000 horas de programação para ter um demo muito simples, e talvez mais de 10-15K horas de programação para um cliente/servidor quase completo. Mas como o líder do time terá de fazer muito mais do que simplesmente programar, ele terá de manter o time junto, resolver conflitos, fazer relações públicas (RP), suporte de tecnologia, configurar servidores, banir criadores de problemas, brainstorming, etc. Serão suas atribuições. Então você também será sobrecarregado com tarefas que não são de programação. Então você provavelmente irá precisar ir para o trabalho/escola, o que diminui o tempo que você terá para se dedicar para o seu projeto. Nós tivemos sorte de nenhum membro ter deixado o time, mas se isso acontecer pode realmente ser um problema. Apenas imagine seu artista saindo na metade do caminho do projeto. E ainda pior, ele não te da permissão para usar mais a sua arte. Claro, isso pode ser resolvido assinando um contrato, mas seria muito penoso coseguir outro artista. Ter dois estilos de arte diferentes no mesmo projeto pode ser um problema.

2. Grandes quantias de dinheiro (normalmente com 4-6 dígitos) são necessárias para manter um servidor.

MMORPG. Bem, isso simplesmente não é verdade. Eu tenho visto servidores dedicados, como 1000GB/mês para aproximadamente 100 USD/mês (e uma configuração 2-300 USD livre). A menos que o seu protocolo de transferência de dados seja muito mal projetado, 100 GB/mês deveria ser suficiente para um servidor manter o seu website o os downloads dos seus clientes (o download do cliente pode gerar muito tráfego, uma vez que ele se torne popular). Nosso cliente tem cerca de 22MB, e algumas vezes nós temos uma transferência de 400 GB/mês. E nós não somos tão populares (ainda). Outra coisa é, você não irá precisar de um servidor dedicado para começar esse projeto. Um cabo DLS pode fazer esse trabalho muito bem, até que você atinja 20-30 pessoas online ao mesmo tempo. Aí é melhor encontrar companhia de hospedagem mais amigável para hospeda-lo de graça, em troca de alguma publicidade, ou pague do seu próprio bolso.

3. Fazer um MMORPG é divertido.

Isso não é verdade. Você pode achar que todo mundo irá gostar de você, que os jogadores serão suportáveis, que você pode fazer aventuras inovadoras, e, claro, ter muitos jogadores jogando o seu jogo. Jogadores podem ser irritantes. Como esse é um jogo totalmente livre, eles irão achar razões para reclamar. O que é pior é que as pessoas irão geralmente reclamar de coisas contraditórias. Os guerreiros não irão gostar do fato de ser muito difícil subir os níveis, enquanto os mercadores ficarão muito desapontados pelos guerreiros fazerem muito dinheiro com saques. Se você aumentar a dificuldade dos monstros, algumas pessoas ameaçarão deixar o jogo. Se você aumenta-la, as mesmas pessoas não irão gostar do fato de agora até os iniciantes poderem fazer dinheiro facilmente. Deixar como está, não é uma boa idéia. Tem de haver inovações e melhoramentos. Se você decidir mudar alguma coisa, por exemplo adicionar alguns desafios novos para aqueles que manufaturam itens, alguns irão dizer que é muito difícil. Se você não fizer, eles irão dizer que é muito fácil ou que jogar é enjoativo. Você deve ter notado que os jogadores satisfeitos geralmente não irão dizer nada e estarão satisfeitos, enquanto as pessoas problemáticas irão reclamar na maioria das vezes.

A economia é em um MMORPG é mais difícil de ser balanceada que o seu equivalente em singleplayer. Num jogo single player, você pode ter armas melhoradas gradualmente, então conforme o jogador avança ele pode conseguir um equipamento melhor, e abandonar (vender) o velho. Em um jogo multiplayer, por outro lado, esse é um conceito falho desde que todos podem pegar as melhores armas, pulando as armas de baixo nível. A maioria dos jogadores prefeririam não usar nenhuma arma e só ir salvando até que eles pudessem adquirir as melhor arma possível. O projeto da economia merece o seu próprio artigo.

Todas as coisas que eu enumerei até agora, adicionadas com o trabalho extra e com os desafios deveriam fazer você pensar pelo menos duas vezes antes de decidir se engajar em um projeto tão imponente. Você precisa entender as implicações da sua decisão.


Conclusão

Espero que esse artigo tenha dado a você a idéia que você precisava. Meu próximo artigo será sobre como configurar uma economia (mais especificamente, quais erros evitar), e alguma informação sobre como debugar um cliente e um servidor.

Sobre o autor

Esse artigo foi escrito por Radu Privantu, líder de programação e projeto pela Eternal Lands (www.eternal-lands.com), um MMORPG gratuito e com código fonte aberto.

Bug no protocolo TCP permite ataques DoS

Nova falha num software de base da internet põe todos os sites em risco.

Especialistas em segurança dizem ter descoberto um bug no protocolo da internet que pode ser explorado para tirar do ar qualquer dispositivo numa conexão de banda larga. Isso permitiria a execução de gigantescos ataques de negação de serviço (DoS).

A vulnerabilidade, segundo os pesquisadores, localiza-se no protocolo TCP, sigla de Transmission Control Protocol. A descoberta foi feita por dois pesquisadores suecos, que não pretendem revelar o problema. Não se trata da existência de bugs num sistema operacional ou plataforma, mas na maneira em que os roteadores, PCs e outros sistemas conectados se comunicam com máquinas remotas.

Assim como ocorreu no caso do bug recentemente encontrado no DNS – Domain Name System, outra estrutura básica da internet --, o ataque a esse bug no protocolo TCP exige a coordenação de muitos fornecedores não só para desenvolver a correção, mas também para distribuí-la e aplicá-la no mesmo momento.

A descoberta foi feita na Suécia por dois pesquisadores, Robert E. Lee e Jack C. Louis, que não pretendem revelar detalhes da vulnerabilidade. No momento, eles tentam convencer empresas sobre a importância do problema.

--
Fonte: Info online

Calculadora do amor

Gente, fuçando a internet por aí acabei encontrando uma coisa muito interessante: a calculadora do amor.

O algoritmo que fizeram é, de fato, inovador; diferente daquelas idiotices que a gente costuma ver por aí. É, no mínimo, uma forma inteligente de se calcular.

Vocês podem ver a obra já em uso clicando no link abaixo:

http://www.lovecalculator.com.br/quiz/pt/4049120/free

Vale a pena dar uma olhadinha.

Baixar vídeos do Youtube

Código:

javascript:location=fullscreenUrl.replace ('watch_fullscreen','get_video')

Para baixar é simples:

Esteja na página do seu vídeo, coloque o código na barra de endereços (onde fica o www) e aperte ENTER. Salve o arquivo que vai aparecer e, depois de baixá-lo, renomei-o para nomequalquer.flv (o .flv é importante). Pronto, vídeo baixado sem a necessidade de nenhum programa.

Observação: .flv é o formato flash vídeo. Pra poder visualizar esse tipo de formato, você precisará do K-LITE codec's. Você também pode converter o formato .flv pra .mpeg ou .avi, usando o programa WinAVI Video Converter.

Dica: Adicione esse código aos seus favoritos. Dessa forma basta "clicar" no código lá nos favoritos e este já será executado. Ter que colar esse código na barra de endereços toda vez que quiser baixar algum vídeo pode se tornar uma tarefa chata. =)

Espero que gostem.

Algoritmo solucionador de problemas!

Agora criado o algoritmo, vejamos a sua implementação:

http://br.geocities.com/squallmdm2/LOL.html

Sobre XSS...

Vendo meu último post, pensei: por que não uma explicação mais "completa" sobre XSS? Dessa forma mais pessoas poderão explorar esse tipo de falha da próxima vez, o que resultará num maior comprometimento com a segurança do site por parte de seus estagiários funcionários.

Primeiro vejamos um exemplo:

http://busca.igbusca.com.br/app/busca.ig?q=%3Cscript%3Ealert(%22XSS%22)%3B%3C%2Fscript%3E&x=0&y=0&pagina=1&navegadorQuery=&start=0&related=true&site=&o=&t=&view=&idCanal=&nomeCanal=&totalRegistrosFast=&navegadorName=&navegadorDataIni=&navegadorDataFin=&totalResultadosGoogle=32




Caso você tenha clicado nesse link pouco depois do dia 4/10/08, vai ver uma janelinha com o nome XSS (como na imagem). Essa janelinha nada mais é do que a confirmação: o site está vulnerável. Perceba, no link, a parte alert("XSS") . Isso é um código JavaScript, que é executado normalmente, como se fosse parte do código fonte da página.

Tente colocar no campo de busca "%3C%73%63%72%69%70%74%3E%77%68%69%6C%65%28%31%29%61%6C%65%72%74%28%22%58%53%53%22%29%3B%3C%2F%73%63%72%69%70%74%3E" e aperte ENTER. Vai ver um grande incoveniente, não colocado pelos criadores do site, obviamente.

Então. XSS pode ser, numa maneira mais clara, uma forma de transformar "sites confiáveis" em "sites não-confiáveis".

Para saber explorar essa falha da maneira mais coveniente, um bom entendimento de HTML+JavaScript é imprescindível. (e não é difícil aprender tais linguagens)

Temos aqui, nesse link, alguns códigos que podem ser inseridos nos campos de textos dos sites-alvos, a fim de saber se os mesmos são vulneráveis ou não:

http://ha.ckers.org/xss.html

Portanto, fica a dica: sempre observe a URL do site que está clicando e procure saber se a pessoa que está te enviando o link é realmente de confiança. E sempre que ficar desconfiado, desabilite o JavaScript no seu navegador.

Espero que gostem da informação.

Falha no Orkut 10: A revolução.

Olá.

Setembro, dia 30, 2008: mais uma falha encontrada no orkut.com. Dessa vez a falha era na página do álbum, mais especificamente nos comentários.

Falarei um pouco sobre essa falha.

A falha dessa vez (na maioria das vezes, por sinal) foi um XSS, cuja definição pode ser "Script de site cruzado". Em resumo: Coloca-se um script malicioso como um comentário em alguma foto e este é interpretado normalmente (como se fosse colocado pelos programadores da página) pelo browser do usuário. Com isso, existe a possibilidade de roubo de cookies (logam-se no seu perfil sem nem saber sua senha), entrada involuntária em comunidades, recados e postagens em comunidades também involutariamente, phishing, além de, é claro, infecções de vírus (ufa!). Isso tudo apenas clicando em um link do próprio Orkut.com.

A falha durou pouco mais de dois dias, e foi muito bem aproveitada pelos "hackers" do orkut.



Eu, esperto como sou (XD~), também tirei um proveito dessa falha. Fiz com que uma boa quantida de usuários me deixasse o seguinte recado: "Joaozin, vc eh o cara! :D"
A falha era no "m.orkut.com.br", e infelizmente já foi corrigida. Mas não demora muito pra aparecer uma outra.

Enfim, depois de tantas mancadas, não fica tão difícil de entender o porquê do Orkut ainda não ter saído da fase beta... :)

E, a propósito, essa é a primeira postagem do meu blog!