🤔 Para Refletir :
""Se a vida lhe der variáveis crie um evento dela.""
- riquecamarg0

[GUI THE MAKER SEMANAL] - ORGANIZANDO A BAGUNÇA: NOTAÇÃO HÚNGARA NO RPG MAKER

Gui Masculino

Cidadão
Membro
Membro
Juntou-se
09 de Julho de 2022
Postagens
169
Bravecoins
384
Motor de jogo
RPG Maker MV
Saudações, corações valentes!
Me diz uma coisa: como você nomeia suas variáveis e switches no RPG Maker? E depois de meses ou até anos mexendo no mesmo projeto, você ainda lembra o que cada uma faz? Ou fica perdido, sem saber se aquela variável que você criou dois anos atrás serve para controlar o ouro do jogador ou a vida de um inimigo qualquer? Pois hoje quero falar sobre uma forma simples de organização que pode salvar muito tempo e dor de cabeça: a notação húngara.
Talvez eu não seja a melhor pessoa para dar essa aula, acredito que meu amigo @Dr.XGB teria uma didática e conhecimentos sobre o assunto ainda melhor do que eu, mas quero compartilhar como tenho usado isso no meu próprio desenvolvimento.

1186090.png

"Eu tenho que deixar minhas mães orgulhosas! Vou me tornar a melhor garota-cavalo de todo o Japão!"
- Special Week (Uma Musume: Pretty Derby)

ORGANIZANDO A BAGUNÇA: NOTAÇÃO HÚNGARA NO RPG MAKER
A notação húngara nada mais é do que uma convenção de nomes usada em programação. Em vez de chamar a sua variável apenas de “PlayerMoney” ou “MensagemFinal”, você adiciona uma letra no começo que indica o tipo daquela informação. Assim, fica muito mais fácil bater o olho e entender para que aquilo serve. A lógica é simples: usar “n” quando for um número, “s” quando for uma string (um texto), “b” quando for booleano (verdadeiro ou falso, como os switches do Maker), e “id” quando a variável estiver guardando um identificador, como o número de um item, arma ou evento.

Na prática, isso funciona mais ou menos assim: se você tem uma variável que armazena a quantia de dinheiro do jogador, em vez de chamar apenas de “PlayerMoney”, você escreve “nPlayerMoney”. O “n” deixa claro que se trata de um número, e “PlayerMoney” explica o que exatamente aquele número representa. Outro exemplo seria uma string com a mensagem de fim de batalha, que poderia se chamar “sEndMessage”. Já um switch que marca se uma porta foi aberta ou não poderia ser chamado de “bDoorOpen”. E se você precisa guardar o ID de um item recebido, a variável poderia se chamar “idItemReceived”.

Outra escolha que eu faço é escrever o nome das variáveis e switches em inglês. Isso não é obrigatório, claro, mas tem algumas vantagens. Primeiro, porque a maior parte dos recursos, tutoriais, scripts e plugins do RPG Maker (e da programação em geral) está em inglês, então usar a mesma linguagem facilita a integração e evita misturar termos diferentes para a mesma coisa. Segundo, porque se em algum momento outra pessoa, especialmente alguém que programa, for ler seu projeto, ela já vai entender imediatamente o que significa "nPlayerMoney" ou "bDoorOpen". E terceiro, porque o inglês é mais “enxuto” para nomes curtos: "bDoorOpen" é mais simples que "bPortaAberta". No fim, isso é uma questão de gosto pessoal, mas é uma prática comum entre desenvolvedores e pode ajudar muito em projetos maiores.

Esse tipo de organização parece bobeira no começo, mas faz uma diferença enorme em projetos grandes. Ao invés de depender só do número da variável ou switch dentro do editor, você cria uma referência que se explica sozinha. Isso evita confusão quando você volta ao projeto depois de muito tempo e também ajuda caso outra pessoa vá mexer no seu jogo no futuro.

No fim das contas, a notação húngara não é uma regra rígida nem obrigatória. Você pode adaptar do jeito que fizer mais sentido para o seu fluxo de trabalho. O importante é ter um padrão, porque o que costuma matar projetos em RPG Maker não é o boss final nem o puzzle complicado, mas sim a bagunça de variáveis e switches que ninguém lembra para que servem. Organização é metade da batalha, e acredite: esse pequeno cuidado pode ser o que vai garantir que o seu jogo chegue até o fim.
 
Muito bom você ter abordado esse tópico aqui ao fórum.
Eu realmente fiz um vídeo explicando sobre a Notação Húngara.

Muitos programadorzinhos de apartamento de hoje em dia torcem o nariz quando falamos sobre isso por ser muito antigo. Então eles preferem ignorar ou, até mesmo, ridicularizar quem fala sobre ele. Hoje como já temos linguagens de programação tipada não há necessidade de usar essa convenção de fato.

No entanto quando levamos isso para o RPG Maker, enfrentamos aquele problema que existia nas linguagens mais antigas como a B, por exemplo, onde tudo eram inteiros. Então a solução para evitar uma futura zona no nosso código era utilizar prefixos nos quais representam o tipo daquela variável como você disse muito bem aqui no tópico.

Alguns prefixos que utilizo em meus projetos:

bSwitches
Embora eu não use o prefixo para os switches pelo fato dele serem somente booleanos (lá eu adoto a convenção chamada PascalCase), pode ser que em alguma ocasião específica eu queira usar uma variável do tipo booleana, principalmente para verificar condições através de cálculo ao invés de blocos if.

Exemplo:
Código:
<> Var [0002: nDistance] Set, 10
<> Var [0002: nDistance] Mul, V[0001: bActive]
Se V[0001] == 1, logo V[0002] será 10. Caso contrário, 0.
nValores numéricos inteiros
pPonteiros
Nos RPG Makers antigos a gente conseguia usar variáveis para apontar para as outras variáveis. Hoje somente via script.
str ou lpchStrings
Esse eu uso mais quando eu uso o RPG Maker 2000 com Destiny Patch.
lpch pode significar Long pointer character (ou pch que significa apenas Pointer character). É uma convenção muito comum quando usamos a API do Windows para desenvolver programas para Desktop. Basicamente serve para distinguir que essa variável é um ponteiro para uma cadeia de caracteres.
evID do Evento
Usamos para indicar que essa variável é o ID de um evento no mapa. Seja para movê-lo, aplicar um efeito nele ou chamar uma página de script nele (outro recurso removido nas versões modernas).
fnFunção
No RPG Maker 2000 com Destiny Patch, a gente consegue chamar eventos comuns através de variáveis. Como eventos comuns são nada mais que funções, a grosso modo, podemos usar uma variável para apontar para uma função, ou seja, um evento comum, para que possa ser chamado. Também chamamos essa prática de callback.
 
Voltar
Topo Inferior