Teste de Jogo

[hategum rpg]

Novidade

[Corvo]

Diria que está mais para um teste de sistemas. Para um início, estão indo bem, continue refinando. E, por garantia, faça backup do backup também.

[hategum rpg]

Sim, foi um teste de sistemas, tenho que ter certeza de que funcionem quando forem exigidos. Percebi que ocorre uma sobrecarga em eventos pesados, ou eventos com muitas chamadas de eventos comuns.

A ideia é criar um pacote que sirva de base para o jogo todo e até como molde para futuros jogos.

São sistemas dependentes, é como uma ramificação em um jogo de escolhas, alguns funcionam em paralelo outros através de interruptores.

A ordem em que são executados também influenciam nas mecânicas do jogo, desse modo tenho que verificar antes de sair criando novos mapas.

Até o momento tem uns 74 eventos comuns e 1600 variáveis, tenho focado na progressão dos personagens, que são quatro.

Também não criei muitos itens só aqueles no menu, falta melhoras o sistema dos inimigos e ou várias outras coisas.

Estou gostando de criar desse modo, tenho liberdade para escolher no que posso mexer, mas fica bagunçado, não é um pacote pré definido está tomando forma aos poucos.

Qualquer dia posto outro vídeo dos sistemas.

[hategum rpg]

Atualizações

Este protótipo de sistemas tem:

Dados relevantes;

Eventos comuns: 112
Switches: 203
Variáveis: 1924
Pictures: 77
Characters: 155
Plugins: Community_Basic e MadeWithMv.

Tipo de sistemas

sistema de movimento diagonal.
Sistema de Botões.
Sistema de Menu.
Sistema de batalha.

[Brandt]

Antes de mais nada, maneiro que você tenha desenvolvido tudo isso aí. É bastante coisa, o resultado ficou interessante também.

Dito isso, queria comentar em cima disso aqui:

Ainda não uso nenhum plug-ins adicionais.

e disso:

Eventos comuns: 112
Switches: 203
Variáveis: 1924
Pictures: 77
Characters: 155

Não vou negar o mérito de fazer as coisas sozinho (em contraste a pegar pronto da internet e usar), de fato é o melhor jeito de aprender, e se seu objetivo não é de fato construir um jogo completo (o da maioria dos usuários da engine não é), é o melhor que o RPG Maker tem a te oferecer. Por outro lado, fazer esses sistemas aí dessa forma dificilmente é o melhor jeito de aprender com a engine (e certamente não é, se o objetivo for ter um produto final usável e bem acabado).

Pra começar, tem algumas coisas fundamentais de programação que qualquer um que queira programar alguma coisa (e aqui não importa se é com código, eventos no RPG Maker, planilhas de excel, apresentações de Power Point ou água caindo) deveria entender antes de começar a desenvolver qualquer coisa. Talvez o mais essencial é saber diferenciar um programa "bom" (e bota aspas nisso) de um programa ruim (e esse é ruim mesmo).

Por exemplo, vamos supor que queremos um programa que diz se um número dado é par ou ímpar. É um requisito bem simples, certo?
Um exemplo de programa bom seria o seguinte:



Esse programa é bom porque não faz nenhum passo desnecessário (daria até pra enxugar e tirar o resto da divisão direto da variável 1, mas não importa muito), é relativamente curto (embora a sintaxe dos comandos dos eventos não ajude muito) e, mais importante, não depende diretamente do valor do número digitado de nenhuma forma. Eu não preciso saber qual número foi digitado na hora de escrever o programa, nem se ele tem 8 ou 20 ou um googol dígitos; o programa funciona pra qualquer caso.

Esse é mais um exemplo de programa "bom", embora bem menos eficiente e mais complexo:



O ciclo ali basicamente simula o resto da divisão, e no fim da repetição o valor da variável 1 é 0 se o número era divisível por 2 e -1 caso contrario (se quiser, teste com alguns valores). Esse programa ainda é "bom" em um certo sentido, porque assim como o exemplo anterior não depende do valor do número em si, e funciona pra todos os valores, além de ser (relativamente) pequeno; só é objetivamente pior que o exemplo anterior porque ele demora um tempo absurdo para valores grandes.

Agora um exemplo de programa ruim:



Esse aqui não tem salvação. Ele demora tanto quanto o exemplo anterior (precisa checar a condição pra cada valor possível do número), é gigantesco (no print só coube até o 4; se quisesse fazer funcionar pra números de 8 dígitos, como os dois exemplos anteriores, precisaria de +/- 25 milhões de prints). Outro problema bem grande aqui é que as mensagens ficam repetidas pra cada número, então se porventura eu quiser mudar essa mensagem pra alguma coisa diferente no futuro (ex. "o seu número é par/ímpar") vou ter que mudar centenas de comandos no programa.

Recomendo dar uma passada no https://www.reddit.com/r/badcode/ pra ver mais exemplos; mesmo que você não entenda o código em si, é fácil de perceber esse mesmo tipo de estrutura em todos os programas que a galera posta lá (o sub tem exatamente a proposta de expor código ruim).

Enfim, por quê eu disse tudo isso: pra ser sucinto, o motivo de a maioria dos sistemas complexos pra engine serem feitos com plugins e não com eventos é porque, em geral, programas feitos com eventos são ruins. Isso não é só porque quem programa com eventos sabe menos de programação como um todo (embora, geralmente, seja o caso), mas porque os eventos não são feitos pra construir sistemas complexos, e portanto não têm muitas das ferramentas que você usaria para construir programas "bons" para esses sistemas; se não tem como fazer programas bons, os programas necessariamente ficam ruins mesmo.

O número exorbitante de variáveis, switches e eventos que você usou aí pra sistemas que não deveriam ser tão complexos são sintomáticos de programas ruins: o tamanho do programa (que é aproximadamente proporcional ao número de variáveis/switches e "unidades", no caso os eventos) está proporcional ao tamanho do problema; isso é a mesma coisa que escrever um programa de 10000 linhas pra ver se cada número de 0 a 10000 é par ou ímpar, ao invés de escrever um de 10 linhas que faz a mesma coisa.

Pra você ter uma ideia, esses são alguns plugins que têm menos de 1924 linhas (das quais boa parte nem é código, inclusive, e certamente o número de variáveis aí é pelo menos uma ordem de magnitude menor que 1k pra todos eles):

• FPLE: https://centrorpg.com/index.php?topic=14140.0 - 1199 linhas
• Akea Animated Battle System: https://centrorpg.com/index.php?topic=24730.0 - 1683 linhas
• OcRam - Lights plugin: https://forums.rpgmakerweb.com/index.php?threads/ocram-lights-plugin-for-mv.108614/ - 1811 linhas
• SomeFire - Skill Trees System: https://forums.rpgmakerweb.com/index.php?threads/skill-trees-system.100429/ - 1861 linhas
• Todos esses 13 plugins de menu, a maioria nem chega a 1000 linhas: https://forums.rpgmakerweb.com/index.php?threads/13-alt-menu-screens.61323/

E esses são todos plugins bastante complexos, que oferecem sistemas complexos; fora que a aproximação pelo número de variáveis é beeeem ruim, quase certeza que seus sistemas por eventos aí têm mais comandos que o número de linhas de todos esses plugins aí somados (se fosse só um comando pra criar e um pra ler cada variável, já cobriria pelo menos quaisquer dois).

Enfim, meu ponto é: eu entendo querer evitar código, código assusta (principalmente javascript); mas você não está se fazendo nenhum favor com isso. Você está programando de qualquer forma, só está se forçando a usar um meio inadequado pra isso.
O esforço que você coloca em fazer esses sistemas absurdos por eventos provavelmente seria muito melhor investido em estudar um pouco de código e começar a fazer seus próprios sistemas da forma adequada, usando uma ferramenta adequada. Temos um board de Programação aqui no fórum com vários tutoriais pra isso, e o que não falta na internet é tutorial de programação (ainda mais JS; e se bobear tem até alguns especificamente focados no RPG Maker MV).

[hategum rpg]

Então, as variáveis são números, que variam, eu poderia usar menos, mas é algo para o jogo completo.
é como se eu tivesse um d6 rolando números de 1 a 6, em paralelo e em determinado momento eu quero
saber que numero esta o dado.

O fps funciona em 60, gravando um video cai...

Eu uso uns códigos ruins, tipo esse.

Spoiler

[close]

Algo mais simples seria como a imagem abaixo. Eu pessoalmente enjoou fácil nesse sistema de batalha. Mas tenho vários gráficos nesse estilo.

Spoiler

[close]

Eu uso uns comandos de plugin, as vezes são ate melhores. Obrigado pelas dicas!

[hategum rpg]

Continuando com meus sistemas, desta vez um sistema de luta.
No estilo do jogos retro. Os gráficos estão desleixados pois fiz com pressa,
é só pra causar impacto visual : )
A data frame dos golpes esta em 10, a gravidade está em 2 frames,
e a troca de gráficos está sem pré-load, vou tentar inserir mais golpes e magias,
ou quem sabe fazer um sistema para um jogo de corrida.

[hategum rpg]

Uma imagem do projeto, eu já adicionei alguns elementos de meu jogo nesse sistema, ainda falta muita coisa.

Mais uma imagem?

Spoiler

[close]

Sinto que estou evoluindo com a ultima otimização do sistema 

[hategum rpg]

Testando iluminação


Quero esse efeito...

Spoiler

[close]

ou esse como a referência.

Spoiler

[close]

como está indo...

Spoiler

[close]

Pretendo colocar algumas cores assim, não sei se um plugin de iluminação vale a pena...

[paulojunior55]

Testando iluminação

Quero esse efeito...

Spoiler

[close]

ou esse como a referência.

Spoiler

[close]

como está indo...

Spoiler

[close]

Pretendo colocar algumas cores assim, não sei se um plugin de iluminação vale a pena...

Deve ter diversos plugins de iluminação por aí, conheço por imagens e vídeos um do Khas que parece interessante, é um plugin pago. Nunca usei nenhum e nem conheço outros.

Se fosse tentar esse efeito, usaria a maneira que estou fazendo as sombras no projeto.

Tiro uma imagem do mapa com o plugin do Hudell, OrangeMapshot.

E uso essa imagem em um editor gráfico, como camada de base para ver as modificações, faço uma camada acima dela de mesmo tamanho com as sombras, e depois salvo as sombras em um png com transparência.

E uso o plugin do mog hunter, Weather_EX para usar essa imagem no mapa em overlay.

Para fazer esse efeito, o que mudaria é a maneira de editar a imagem, fazer várias camadas, uma para sombras e várias outras, uma para cada cor diferente de luz, diferentes porcentagens de transparência para chegar no aspecto adequado, e só desmarcar a imagem de base que é a imagem do OrangeMapshot e salvar como uma png com todas as modificações.

Esses plugins são para o mv e são livre para uso comercial, o do Mog encontra no site dele e o do Hudell encontrei no fórum internacional de rpg maker, feito pela empresa da engine.

[hategum rpg]

Achei um jeito de colocar iluminações através de tilesets, ate que fica legal, quando for um poste ou uma luz de cima eu colocarei por pictures.
Andei testando esse projeto, já estou mudando algumas coisas. 

O que demora bastante pra fazer são os sprites, o banco de dados é meio maçante é control C e control V, tem uma coisa que dá um trabalho gigante para reorganizar que são as configurações de controle, são vaias combinações possíveis, acho que vou deixar algumas predeterminada em benefício do gameplay.

Afinal estou me focando no gameplay e deixando a história como um background. Tem vários sistemas incompletos que não dá pra mostrar no vídeo e eu tenho que trocar o software que grava, é só 10 minutos cortou a parte do personagem pulando os obstáculos do mapa.

 
 

[hategum rpg]

Atualizações -

Playlist no Youtube.
Menu de partículas.
Sistema de núcleo de desenvolvimento adicionado.

Removido o sistema de checagem de swithc, estava causando
complicações no desenvolvimento.

Trabalho atual
- Montagem de peças para o gerador.
- Montagens de ícones para habilidades.
- Configuração de hud slot.

Condições definidas

Não usar palavras em imagens.

Este projeto é uma obra de ficção baseada no livro eternidade 1 - fatos 2020 e 2021.

[hategum rpg]

Tem esse tutorial que utilizo para não ficar perdido.

Spoiler

Classes e Habilidades


PASSO A PASSO PARA ADICIONAR AS HABILIDADES


No sistema 3.0 na seção Huds de tela

esolher modo skill bar 1, e inserir antes da
ramificação. Dentro da execução dessa switch.

a habilidade deve ter uma swithc para cada slot
de tela, exemplo Ataque no slot 1 até Ataque no slot8.

Adicionar a condição se é ligada, dentro desta
execução, adicionar a condição do nivel da habilidade.

Cada habilidade tem um nivel de 0 a 10, para cada
variação numerica inserir a exibição de imagem,
cada imagem tem seu numero especifico por posição
no slot.

Por exemplo imagem numero 90 é correspondente a posição
do slot 7, cada mudança de imagem mantem a numeração e
as coordenadas. Veja as posições e coordenadas abaixo
do modo skill bar 1.

Assim em cada variavel de nivel existe uma variavel de imagem,
que é a hud que surgirá na tela.

Completando a grade de habilidade o proximo passo é na
seção "verificação de modo de combate" este é divido
nas oito partes da execucução do controle de comando.

Cada acionamento de botão exibe a verificação associada
ao slot especifico. Logo se ataque no slot 1 foi adicionado
este deve estar dentro da verificação de combate Slot 1.

A verificação é semelhante ao sistema de hud na tela com
a diferença do acionamento da swithc de ABS.
Cada variavel de nivel aciona uma switch de Abs que tambem é
definida por nivel de habilidade. Por exemplo Abs ataque 0 ate
o Abs ataque 10. Lembrar de criar a ramificação para desligar caso
esta habilidade não esteja equipada.

Configurando o Abs no mapa e o evento de equipar,ambos
são semelhantes a diferença é que o evento de equipar utiliza as
variaveis para trocar de abas e o evento abs utiliza switch para
trocar de aba.

Cada nova aba contem uma variação de nivel da habilidade sendo assim
o uso se torna especifico,tanto para equipar a habilidade no cinturão
como para o uso.

Restriçoes e limites.
São cerca de 1600 habilidades, derivado de 144 habilidades de núcleo
Assim é 144x11(0 a 10) = 1584 + o posicionameto que é multiplicado pelo
nucleo 144x8 (slots)= 1152 totalizando 2736, para ligação de Abs e hud.

[close]

[hategum rpg]

Novas mudanças nos controles e 50% das habilidades já introduzidas mas não configuradas.

[hategum rpg]

Um tempo sem tocar o projeto me fez refazer os sistemas.