VId. Eu sou um Programador! (Antecipando problemas)

Não tão rápido, Jack. Um programador... um bom programador... tem que pensar no futuro. Ou seja, antecipar o que os jogadores irão fazer. Jogadores são sórdidos e atenciosos nas coisas, e se tiver algum problema com o seu jogo, eles eventualmente irão achá-lo.

Você pode identificar algum problema no código que já escrevemos?

Sim?Não? Se lembre de que os jogadores não vêem o jogo do mesmo jeito que você. Você sabe como as coisas devem agir; eles não.

Você está no caminho reto e apertado do “deveria fazer...” mas os jogadores não enxergam esse caminho tão claro quanto você. Eles andam por aí e entram em loops infinitos e bugs. Ou eles deliberadamente procuram por eles. Coisas que você nem imaginava que havia ali.

Acho que deveríamos ver nosso bug em ação. Primeiro precisamos de algo para atacar. Faça um novo arquivo icon e nomeie de “bug” (isto é simbólico). Clique na palheta e desenhe algum tipo de bug. Agora dentro de mob e entre as linhas icon e Login(),

coloque isso:

+bug //Novo protótipo
++icon = ‘bug.dmi’ //Define o novo icon, que era o ‘pessoa.dmi’

Nós quebramos a ordem alfabética em nosso código. Mas desse jeito temos os protótipos, mob e mob/bug, perto um do outro. Agora compile.

Para colocar nosso bug(inseto) no mapa, nós temos que abrir o arquivo Testworld.dmp. No painel à esquerda você verá o que é chamado de “Arvore”, que é um arranjo de galhos.

Clique no pequeno sinal ao lado de “mob” e a arvore vai abrir mostrando nosso bug.

Clique no bug e então coloque um ou dois ou dez em qualquer lugar que você quiser no mapa.

Compile de novo e rode. Experimente usar o verb Atacar. Mate um bug... então continue atacando. Muito irritante, né? Já teve jogos produzidos e vendidos com bugs bobos como esse (bater,bater,bater e nunca matar). Nós somos melhores que isso.

Olhando seu jogo, uma pessoa que não tem muito conhecimento iria ver um tipo de design de jogo de estratégia, algo raro em um tutorial de iniciante. Mas o design de um game é muito importante para mim. E deveria ser muito importante para você. Que tal se colocarmos quando o mob morrer o jogador ganhar 100 de ouro?

VIe. Buntime Rugs(Runtime bugs)

O que nós temos é um Runtime Bug. Nosso código parece ótimo... mas não faz o que agente quer que ele faça. Isto pode ser muito frustrante, e não tenha duvidas que você ainda vá bater muito sua cabeça no teclado durante sua carreira como programador. É por isso que eu tenho POIUYTREWQ marcado em minha testa.

Quando encaramos um problemas, nós (1) pensamos em todas as soluções e (2) escolhemos a mais eficiente. Este “pensar em todas as soluções” é provavelmente um pouco confuso para os iniciantes em DM. Então eu quero que você esqueça do código, pense na lógica do mundo real. Isto pode ser uma questão que você se pergunta todo dia em sua vida: “Como posso fazer as pessoas pararem de matar coisas que já estão mortas?”.

Desse jeito, nossas soluções caem para duas categorias básicas: Bloquear o assassino de matar o defunto, ou simplesmente remover o cadáver, então não teremos que bloquear.

Vou mostrar como fazer os dois.

VIf.Matendo o assassino sem atacar de novo(A declaração de else)

Aqui está o nosso jeito de bloquear o assassino.

++Atacar(mob/M as mob in oview(1))
+++if(M.HP<=0) //Se o HP de de M for igual ou menor que 0
++++usr<<”[M] já esta morto!”
+++else //Se não
++++usr<< “Você atacou [M]!”
++++oview()<<”[usr] atacou [M]!”
++++var/dano = rand(1,10)
++++world << “[dano] dano!”
++++M.HP -= dano

if e else trabalham juntas. Você pode ter um if sem um else, mas você não pode ter um else sem um if. Eles fazem do mesmo jeito que soam. Apesar de que else, poderia ser “otherwise”(de outra maneira) (if, else = Se, de outra maneira).

Créditos:
Blake pelo tutorial
-KiRa por postar aqui na ARM