Você sabe que seu jogo está em perigo quando...

Um pouquinho de humor pra descontrair. Espero que gostem.

Você sabe que seu jogo está em perigo quando...

...quando um dos seus engenheiros pergunta, “Isso é uma explosão ou uma árvore?”
...quando seus engenheiros começam a plantar mensagens subliminares nas texturas dizendo “Esse jogo não é um lixo.”
...quando a licença de direitos autorais ocupa mais espaço em disco do que o código do jogo.
...quando você ouve o level designer exclamar, “O editor de mapas faz isso!? Nossa, isso teria nos poupado meses!”
...quando você aprende sobre os recursos do seu jogo lendo entrevistas do seu publisher num site de jogos uma semana antes do lançamento do beta.
…quando você percebe que enviou acidentalmente a versão completa do jogo para todos os sites de demonstração e revistas de jogos.
...quando você pergunta sobre Inteligência Artificial ao seu produtor e ele responde, “Aqueles geradores de números aleatórios podem fazer qualquer coisa.”
...quando o produtor diz “minha mulher não gosta disso, então nós teremos que mudar”.
...quando você navega na internet e encontra um jogo freeware similar ao seu, mas melhor.
…quando você pega seu programador-chefe numa loja comprando uma cópia de “Começando com o Visual C++ 6.0”.
...quando a tela de título do jogo requer mais código que o jogo em si.
...quando o site que faz propaganda do jogo tem 95% do orçamento.
...quando o GIF promovendo seu site é mais legal que a tela de título do jogo.
...quando você começa a pensar em uma maneira de otimizar seu contador de quadros por segundos para ganhar alguns quadros por segundo.
...e você dobra os quadros por segundo ao fazer isso.
...quando alguém lhe pergunta as horas e você responde “oh, 0000 e 1001”.
...quando você decide desistir e escrever o jogo como um único arquivo em batch bem grande.
...quando você pede ao artista para usar o mínimo de cores possível e ele entrega seu trabalho em preto e branco.
...quando seu chefe diz, “Eu encontrei uma forma de reduzir nosso tempo de desenvolvimento”, enquanto segura uma cópia de Klil and Play.
....quando seu time de desenvolvimento se diverte mais jogando paciência do que seu jogo.
....quando você tem que implorar por patrocínio de uma empresa para *alugar* um scanner por uma semana.
...quando você acha que seu jogo pode ser mais commercial se for vendido como um protetor de tela.
...quando você constantemente checa as livrarias procurando pelo novo livro de programação “Como programar (nome do seu jogo)”, com o código-fonte completo incluso.
…quando o computador dá pau e destrói todos os vestígios do jogo e de seu desenvolvimento.
...e todos ficam aliviados com isso.
…quando uma companhia rival envia uma cópia do código deles por pena.
…quando nem mesmo a IA do jogo quer joga-lo – ela simplesmente se apaga.
...quando seus artistas estão discutindo o uso correto de listas encadeadas.
...quando seu programador-chefe diz “É trivial”, e é mesmo, menos pra ele.
...quando você gasta mais tempo sonhando em estrangular o produtor do que programando.
…quando misteriosas caixas de diálogo “Você deseja registrar agora ou mais tarde?” começam a surgir no seu servidor.
...quando a versão alfa cheia de bugs feita há um ano é melhor que a versão final.
...quando você vai mostrar a versão final ao cliente e aparece a mensagem “Seu período de registro expirou”.
...quando executar seu jogo é uma maneira mais rápida de reiniciar o computador.
…quando um amigo diz que os gráficos estão perfeitos... para o rádio.
...quando, após nove meses de desenvolvimento o produtor diz “Vocês sabem aqueles royalties que nós prometemos... primeiro de abril!”.
...quando você pergunta ao seu chefe sobre o pagamento e ele responde “Pense na glória!”.
...quando o produtor diz “ache um site de pirataria” sempre que você pede por algum programa de desenvolvimento.
...quando você dá uma olhada no seu algoritmo de pathfinding e vê algo do tipo “direção = random(4)”.
...quando seu site diz, “Nós não fornecemos patches, já que não fazemos código com bug”.
...quando seu produtor diz, “Nós simplesmente não temos tempo pra planejar as coisas”.
...quando o programador-chefe vem até você e pergunta, “Então, o que é essa tal ‘classe’ de que eu tenho ouvido falar tanto?”.
...quando a descrição do designer de sua nova idéia quente para um jogo começa com “Bem, é muito parecido com Quake...”.
...quando o programador-chefe vê “Aprenda C++ em 10 Minutos” como uma referência completa.
...qunado você tem que colocar uma almofadinha no botão de reset.
...quando seus computadores não cumprem os requisitos mínimos do jogo.
…quando o código de uma das bibliotecas que você está usando diz “#ifdef 19_DE_SETEMBRO”.
…quando você ouve o produtor dizer ao seu chefe “Sombras em tempo real num 386? Sem problemas.”
…quando seus programadores acham que estão sendo espertos ao nomear uma variável int como “eger”.


Seleção, tradução e adaptação por: Eu mesmo ^^ (Diego).
Essas frases fazem parte de uma coleção (bem mais extensa) que pode ser encontrada em http://www.gameai.com/youknow.html.

Macros de Debug

Aí vai um pequeno código pra ajudar no debug dos seus programas. O código foi originalmente postado na Allegro wiki por James Lawder Andrews. O que eu fiz foi dar uma editada no código e inserir comentários em português pra que todo mundo entenda.

Espero que seja útil. Comentem.

/* ======= debug.h =======
Conjunto de macros que permitem escrever informações de debug em um arquivo se DEBUG estiver definido */


#ifndef _DEBUG_H_
#define _DEBUG_H_

/* Caso a macro DEBUG esteja definida, será definida a macro DEBUGOUT que permite gravar no arquivo informações de debug. Caso contrário, será definida uma macro vazia que não irá entrar no código no processo de compilação. */
#define DEBUG

#ifdef DEBUG
#include <fstream>

/* Esta macro é usada para gravar no arquivo de debug.
'message' pode ser uma string (entre aspas) ou uma variável.
As macros __FILE__ e __LINE__ são pré-definidas pelo compilador e representam, respectivamente, o nome do arquivo e a linha. */
#define DEBUGOUT(message) debug << "(" << __FILE__ << ":" << __LINE__ << ") " << message << std::endl << std::flush;
#else
/* Se chegar até aqui, significa que DEBUG não foi definida, portanto define-se uma macro vazia DEBUGOUT que não faz nada. */
#define DEBUGOUT(message)
#endif


#ifdef DEBUG
/* Aqui é indicado para o compilador que o objeto debug vai ser declarado em outro arquivo.*/
extern std::ofstream debug;
#endif

#endif


/* ======= teste.cpp =======
Aqui testamos nossa macro pra ver se ela realmente funciona. */

#include <iostream>
#include <debug.h>

using namespace std;

int main(){
#ifdef DEBUG
/* Se DEBUG estiver definido, precisamos declarar o objeto debug que foi declarado através de um extern no arquivo debug.h.
O argumento neste caso é o nome do arquivo que queremos gravar.
Este é o único teste que deve ser feito de maneira explícita. Todas as outras chamadas relativas ao DEBUG só serão incluídas na compilação se a macro estiver definida. Caso se deseje compilar sem o debug, pode-se comentar a linha #define DEBUG (em debug.h). */
ofstream debug("debug.txt");
#endif
int x = 10;

DEBUGOUT("ERRO"); // Gravando uma string no arquivo
DEBUGOUT(x); // Gravando o conteúdo de uma variável no arquivo.
}