Novo RPG Maker MZ! [Novidades e discussões]

[DadoCWB]

Peço perdão se a forma como me posicionei parece desmerecer sua opinião ou coisa do tipo, mas vale lembrar que aqui é um fórum, não seu blog pessoal. Você é bem-vindo a dar sua opinião e expressar o que você gostaria na engine; da mesma forma, eu posso muito bem discordar e discutir em cima disso, que no fim das contas sou só eu dando minha opinião também.



Então, o problema de adicionar coisas demais por padrão na engine é justamente que ela vai ficando mais complexa (estou assumindo que por "default na ferramenta" você quer dizer não só ter o código pra fazer funcionar como também incluir partes no editor que permitam configurar de forma nativa). Quanto mais complexidade, mais trabalho de manutenção pros desenvolvedores, mais coisas pros usuários aprenderem e mais complexidade pros desenvolvedores de plugins lidarem por causa do código adicional. Principalmente pra coisas muito complexas como multiplayer, sistemas de batalha ativa (vi muita gente pedindo ABS por padrão na engine ,_,) e etc.

Além disso, a tendência é que essas coisas sofram o "efeito RTP": se todo jogo tem essas features, a galera vai buscar outras coisas pra se diferenciar, e se continuar o ciclo de ir juntando essas coisas como padrão na engine você acaba lotando ela de coisas que nem eram essenciais e boa parte das pessoas vai acabar nem usando. O RPG Maker só é tão acessível como é porque ele tem só o básico mesmo pra você criar um jogo de RPG.

Por isso meu ponto de que eles só precisam dar condições pros desenvolvedores de plugin fazerem o trabalho deles: ao invés de adicionar um monte de coisa por padrão, é só adicionar "pontos de encaixe" que permitam personalizar as coisas se preciso, por exemplo, trocando aquele campo de notas por um campo de "meta tags", que acaba sendo a finalidade dele.

Nem tudo que você falou se encaixa nessa categoria mesmo, e inclusive a parte das layers já foi confirmada. Aumentar o editor de eventos seria ótimo mesmo, mas pelas screenshots que postaram parece que ele se mantém mais ou menos do mesmo tamanho das versões anteriores (provavelmente é preguiça deles fazerem uma interface que se ajuste a tamanhos diferentes, pra ser sincero uashuhas).

Sendo ou não meu blog pessoal, minha opinião não carece de aprovação ou desaprovação sua ou de quem quer que seja. E no mais Você tem todo o direito de estar errado.

Os apontamentos que fiz parte de uma visão subjetiva e ideal. Não disse que é possível ou viável. Aliás nem faria isso sem remuneração já que esse tipo de consultoria é um serviço caro.

 

[Brandt]

Sendo ou não meu blog pessoal, minha opinião não carece de aprovação ou desaprovação sua ou de quem quer que seja.

Blog, chat e fórum – como ferramentas tecnológicas de transmissão/interação.

Perceba o uso frequente da expressão "discussão", em contraponto a simplesmente "exposição", na descrição do que é um fórum.
Bem vindo à internet.

Os apontamentos que fiz parte de uma visão subjetiva e ideal. Não disse que é possível ou viável. Aliás nem faria isso sem remuneração já que esse tipo de consultoria é um serviço caro.

Toda visão aqui é subjetiva, nem por isso está imune a críticas. Você disse o que esperava, eu disse que não era possível/viável porque tenho mais experiência no assunto. É uma troca perfeitamente válida, não?

Não precisa ficar ofendido porque eu disso que não dá pra fazer o que você quer ou que é melhor fazer de outro jeito, é muito mais produtivo pra todo mundo só tentar entender uma visão diferente e tentar debater se você tiver algum contraponto.

---

Pra não falar que fugi totalmente do assunto do tópico, segue uma previsão do tamanho dos chars na engine nova (créditos Creative Ed na RMWeb):

​

Será o fim dos chibi?
Aguardemos...

 

[Jorge_Maker]

Bem, o fim do chibi não vai ser. Seguindo a definição do que é chibi no âmbito de mangá japonês, se trata de um personagem com corpo pequeno e cabeça grande; olhá só, o RTP do Maker segue esse padrão desde... o primeiro? uhashuae'

No máximo vai ficar menos cabeçudo mesmo. Mas nem sei se dá pra tirar essa conclusão por uma secção em baixa qualidade de um dos chars do RTP. Pessoalmente, creio que vão manter o mesmo padrão de chars que vem sendo trabalhado desde o VX: chars que possuem as mesmas dimensões de um tile.

Há um motivo técnico para que todos os chars (ou pelo menos, a maioria), desde o VX, tenham, literalmente, proporções de um quadrado; chars maiores que isso tem um grande potencial de causar problemas em interação com o tilemap, isso se deve à perda das prioridades dos tiles (aquelas que tinham no Xp). Segue o exemplo:

Eu dúvido que irão voltar com as milagrosas prioridades, então sigo com a minha proposição. Do contrário, eu já estaria vendido para este novo Maker, sem dúvidas. xD

 

[DadoCWB]

Blog, chat e fórum – como ferramentas tecnológicas de transmissão/interação.

Perceba o uso frequente da expressão "discussão", em contraponto a simplesmente "exposição", na descrição do que é um fórum.
Bem vindo à internet.



Toda visão aqui é subjetiva, nem por isso está imune a críticas. Você disse o que esperava, eu disse que não era possível/viável porque tenho mais experiência no assunto. É uma troca perfeitamente válida, não?

Não precisa ficar ofendido porque eu disso que não dá pra fazer o que você quer ou que é melhor fazer de outro jeito, é muito mais produtivo pra todo mundo só tentar entender uma visão diferente e tentar debater se você tiver algum contraponto.

---

Pra não falar que fugi totalmente do assunto do tópico, segue uma previsão do tamanho dos chars na engine nova (créditos Creative Ed na RMWeb):

​

Será o fim dos chibi?
Aguardemos...

Tá perdeu seu tempo meu caro. E realmente não estou interessado no que vc pensa sobre o que eu penso. Ao invés disso, foque sua expertise em apresentar suas ideias a quem estiver nelas interessados. Eu não estou. Não estou ofendido, Só que sua opinião pra mim honestamente não faz diferença alguma. Postei coisas que eu realmente gostaria de ver numa nova versão da ferramenta. Não estou preocupado seriam ou possíveis caso contrário eu teria entrado em contato direto com a desenvolvedora.

 

[Brandt]

Tá perdeu seu tempo meu caro. E realmente não estou interessado no que vc pensa sobre o que eu penso. Ao invés disso, foque sua expertise em apresentar suas ideias a quem estiver nelas interessados. Eu não estou. Não estou ofendido, Só que sua opinião pra mim honestamente não faz diferença alguma. Postei coisas que eu realmente gostaria de ver numa nova versão da ferramenta. Não estou preocupado seriam ou possíveis caso contrário eu teria entrado em contato direto com a desenvolvedora.

Entendo. Já pensou em usar twitter ao invés de um fórum? Lá te segue só quem quer saber sua opinião, e se você tiver medo de discutir pode bloquear quem achar conveniente.

 

[Raizen]

Bom vou deixar minha opinião igual a que deixei na rmweb já que o assunto foi levantado, eu acho besteira imbutirem coisas que são fáceis de implementar na engine apenas para facilitar quem for usar.
Tipo, eu mesmo achei besteira até o sideview no MV, ele começa a restringir os jogos e empurram em uma direção única, quanto mais features "padronizadas" que são colocadas na engine, mais ela separa o completo amador de quem quer fazer algo legal.
Tipo adicionar coisas que são 30 minutos para escrever um plugin acho que faz mais mal a engine do que bem, então coisas como adicionar "coisas que o plugin do yanfly fazia", acho total besteira.

Existem algumas coisas que elevariam o nível da engine sem tirar a facilidade dela, por exemplo integrar melhor os plugins no editor, o MV já deu um passo grande para isso, mas imagina se no MZ os plugins possam adicionar funcionalidades nos eventos comuns/eventos/batalha tudo no editor, isso traria mais facilidade para quem não tem tanto conhecimento e maleabilidade para a engine também. Isso resolveria 90% dos pedidos novos para a engine, como falaram integração com mouse na página de eventos etc... Com isso eu simplesmente posso fazer um plugin que adicione essa função na page dos eventos.

Outras coisas que são mais da arquitetura e não features pré-montadas para dar menos trabalho pros iniciantes, não restringir os tiles 48x48, melhor controle nas configurações dos tiles (Isso foi parcialmente revelado que foi feito), melhorar e bastante a exportação para apk, web, exe o que for, porque o do MV é BEM PORCO. Atualizar as libs (Isso é meio óbvio, mas vai que...)

Na verdade é mais do mesmo e o óbvio, com a excessão de nos darem a possibilidade de adicionar novas funcionalidades para quem for editar, isso pra mim era a chave para o MZ ser uma engine de sucesso sem perder a facilidade do RPG Maker e atrair o pessoal amador, caso contrário vai ser só um MV melhorado com umas funçõezinhas a mais imbutidas. Eu vou acreditar nisso até lançarem, porque o MV andou meio caminho com os plugins para isso, mas parou no meio sei lá porque.

 

[DadoCWB]

Entendo. Já pensou em usar twitter ao invés de um fórum? Lá te segue só quem quer saber sua opinião, e se você tiver medo de discutir pode bloquear quem achar conveniente.

Trabalho e lido com público há bastante tempo. Trabalho e lido com criação de produto a bastante tempo. Não tenho medo de expor meu ponto de vista sobre o que quer que seja. Mas pra deixar bem claro: não estou interessado em sua opinião a respeito da minha opinião. Gaste sua energia ara expressar a sua própria Eu realmente esperava que pudesse discernir o que é uma visão particular de um laudo técnico. Mas acho realmente inútil continuar com isso. Peço desculpas por poluir o fórum com uma conversão inoportuna como essa.

 

[Hudell]

Bem, o fim do chibi não vai ser. Seguindo a definição do que é chibi no âmbito de mangá japonês, se trata de um personagem com corpo pequeno e cabeça grande; olhá só, o RTP do Maker segue esse padrão desde... o primeiro? uhashuae'

No máximo vai ficar menos cabeçudo mesmo. Mas nem sei se dá pra tirar essa conclusão por uma secção em baixa qualidade de um dos chars do RTP. Pessoalmente, creio que vão manter o mesmo padrão de chars que vem sendo trabalhado desde o VX: chars que possuem as mesmas dimensões de um tile.

Há um motivo técnico para que todos os chars (ou pelo menos, a maioria), desde o VX, tenham, literalmente, proporções de um quadrado; chars maiores que isso tem um grande potencial de causar problemas em interação com o tilemap, isso se deve à perda das prioridades dos tiles (aquelas que tinham no Xp). Segue o exemplo:

Eu dúvido que irão voltar com as milagrosas prioridades, então sigo com a minha proposição. Do contrário, eu já estaria vendido para este novo Maker, sem dúvidas. xD

Aí também é problema de configuração do tile. A passabilidade estrela como o próprio ícone indica, é pra ser usado para coisas que ficam no céu, como efeitos de nuvens, telhado, etc. Objetos no chão que tenham um tamanho maior do que um tile deveriam ser adicionados via eventos.

 

[Jorge_Maker]

Aí também é problema de configuração do tile. A passabilidade estrela como o próprio ícone indica, é pra ser usado para coisas que ficam no céu, como efeitos de nuvens, telhado, etc. Objetos no chão que tenham um tamanho maior do que um tile deveriam ser adicionados via eventos.

O problema é esse, se não for algo que sempre ficará acima de tudo, você não tem opções a não ser usar a estrela. O próprio Tileset é configurado dessa forma por padrão. É 8 ou 80.

Eu sei que você usa essa "técnica" no seu jogo; eu também, inclusive, é o que temos. Mas honestamente, me diga: Mil árvores no tilemap e mil eventos de árvores, os dois a 80 Km, qual irá desempenhar maior impacto na performance do jogo?

Não quero dar uma de viúva do XP, mas eu gostava quando eu podia simplesmente colocar uma árvore diretamente no tilemap sem a necessidade de seccionar um Sprite para usá-lo como um objeto dinâmico do mapa (i.e., que altera sua posição conforme as coordenadas de exibição da câmera).

 

[Alex Rockmaker]

Vi as screenshots e como um usuário que não usa muito plugins e scripts externos vai aqui minha opinião.

A uns meses atrás eu comentei sobre como o RPG Maker vinha perdendo espaço, não só pelo debande da comunidade de desenvolvedores como também pelo alcance que tem nas plataformas e mídias sociais. Um dos problemas, que foi dito acho que pelo Corvo, é que o RPG Maker é uma ferramenta transitória para engines "de verdade", e por isso tem sua estrutura adequada à essa função. É triste pensar nisso, mas no fundo a gente sabe que é a realidade.

Pra que usa o programa levando os recursos nativos ao limite, ou no meu caso fazendo gambiarras, uma melhora mínima e adição de coisas novas só vai ter um impacto positivo, pois talvez simplifique alguns processos que por eventos são um pesadelo de manter, como menus por evento e interfaces personalizadas de todo tipo. Mas sendo bem sincero...a vontade de mudar de engine vai virando cada vez mais uma urgência, e acredito que não estou sozinho nesse pensamento.

A minha frustração ao ver as screenshots é simplesmente que vamos continuar a ver jogos com esses mesmos gráficos desde o VX, e por conta disso os milhares de conteúdos sobre jogos ruins de rpg maker que usam desses gráficos ainda vão trabalhar a favor dessa estigmatização da engine como uma engine ruim. Pra mim é menos um problema técnico, até porque nem uso o RTP nos meus projetos, e sim um problema de construção da imagem da engine, que tá a mais de uma década acumulando essa fama infame por jogos mal feitos por aí. Uma mudança gráfica seria bem vinda pra desvincular esses jogos (que grande parte foram feitos entre o Vx e o MV) da engine.

Vou aguardar as novidades, pois talvez de fato sejamos "Wowiados" pelas novidades, mas sendo muito sincero...Tô bastante desanimado com o que vi.

 

[Douglas12ds]

Peço perdão se a forma como me posicionei parece desmerecer sua opinião ou coisa do tipo, mas vale lembrar que aqui é um fórum, não seu blog pessoal. Você é bem-vindo a dar sua opinião e expressar o que você gostaria na engine; da mesma forma, eu posso muito bem discordar e discutir em cima disso, que no fim das contas sou só eu dando minha opinião também.



Então, o problema de adicionar coisas demais por padrão na engine é justamente que ela vai ficando mais complexa (estou assumindo que por "default na ferramenta" você quer dizer não só ter o código pra fazer funcionar como também incluir partes no editor que permitam configurar de forma nativa). Quanto mais complexidade, mais trabalho de manutenção pros desenvolvedores, mais coisas pros usuários aprenderem e mais complexidade pros desenvolvedores de plugins lidarem por causa do código adicional. Principalmente pra coisas muito complexas como multiplayer, sistemas de batalha ativa (vi muita gente pedindo ABS por padrão na engine ,_,) e etc.

Além disso, a tendência é que essas coisas sofram o "efeito RTP": se todo jogo tem essas features, a galera vai buscar outras coisas pra se diferenciar, e se continuar o ciclo de ir juntando essas coisas como padrão na engine você acaba lotando ela de coisas que nem eram essenciais e boa parte das pessoas vai acabar nem usando. O RPG Maker só é tão acessível como é porque ele tem só o básico mesmo pra você criar um jogo de RPG.

Por isso meu ponto de que eles só precisam dar condições pros desenvolvedores de plugin fazerem o trabalho deles: ao invés de adicionar um monte de coisa por padrão, é só adicionar "pontos de encaixe" que permitam personalizar as coisas se preciso, por exemplo, trocando aquele campo de notas por um campo de "meta tags", que acaba sendo a finalidade dele.

Nem tudo que você falou se encaixa nessa categoria mesmo, e inclusive a parte das layers já foi confirmada. Aumentar o editor de eventos seria ótimo mesmo, mas pelas screenshots que postaram parece que ele se mantém mais ou menos do mesmo tamanho das versões anteriores (provavelmente é preguiça deles fazerem uma interface que se ajuste a tamanhos diferentes, pra ser sincero uashuhas).

Depois que o Mask... Quer dizer, o Brandt citou esses pontos, agora eu percebo como ele tem razão. Claro que seria bem legal ter todas essas funcionalidades mais complexas ou até mesmo mais convenientes para os veteranos buscando um pouco mais de aventura em seus desenvolvimentos, mas isso iria acabar tirando o RPG Maker daquilo que ele nasceu para ser: uma engine que busca tornar acessível a produção de JRPGs.

 

[Hudell]

O problema é esse, se não for algo que sempre ficará acima de tudo, você não tem opções a não ser usar a estrela. O próprio Tileset é configurado dessa forma por padrão. É 8 ou 80.

Eu sei que você usa essa "técnica" no seu jogo; eu também, inclusive, é o que temos. Mas honestamente, me diga: Mil árvores no tilemap e mil eventos de árvores, os dois a 80 Km, qual irá desempenhar maior impacto na performance do jogo?

Não quero dar uma de viúva do XP, mas eu gostava quando eu podia simplesmente colocar uma árvore diretamente no tilemap sem a necessidade de seccionar um Sprite para usá-lo como um objeto dinâmico do mapa (i.e., que altera sua posição conforme as coordenadas de exibição da câmera).

Como que era no XP? Eu nem consigo imaginar um jeito melhor de fazer.
Adicionar várias árvores por evento no mapa não seria pesado se o maker fosse bem implementado.

 

[Jorge_Maker]

Como que era no XP? Eu nem consigo imaginar um jeito melhor de fazer.
Adicionar várias árvores por evento no mapa não seria pesado se o maker fosse bem implementado.

No XP nós temos 6 tipos de prioridades, de 0 a 5. Um tile de prioridade 0 seria aquele que fica abaixo de tudo, já um com prioridade máxima, não estaria necessariamente acima de tudo, mas funciona com tal. Ao menos eu nunca tive problemas quanto a isso.

O usuário pode usar essa ferramente de forma arbitrária, claro, mas como estamos falando de árvores, usarei uma como exemplo: A prioridade de um tile é igual a distancia vertical absoluta entre este e o tile que representa a sua base. Segue o exemplo:

 

[Hudell]

No XP nós temos 6 tipos de prioridades, de 0 a 5. Um tile de prioridade 0 seria aquele que fica abaixo de tudo, já um com prioridade máxima, não estaria necessariamente acima de tudo, mas funciona com tal. Ao menos eu nunca tive problemas quanto a isso.

O usuário pode usar essa ferramente de forma arbitrária, claro, mas como estamos falando de árvores, usarei uma como exemplo: A prioridade de um tile é igual a distancia vertical absoluta entre este e o tile que representa a sua base. Segue o exemplo:

É, isso é bem mais pesado do que adicionar um sprite, ou pelo menos se implementassem isso no MV seria bem pesado.
Pra isso aí funcionar, os tiles precisam ser movidos de um layer pra outro o tempo inteiro, re-gerando todos os layers do mapa a cada frame.

Na versão original do MV, os sprites também tinham um problema sério em que eles não tinham uma "posição Z", ao invés disso era um array gigante com todos os sprites que eram renderizados na ordem em que estivessem. Pra mover um sprite pra cima ou pra baixo esse array era reordenado em cada frame também. Essa era de longe a maior causa de lag no MV. Eu acho que eles resolveram isso em alguma atualização (ou talvez não), mas no meu jogo eu uso um plugin do pixi que adiciona uma posição Z e melhora isso bastante, aí nessa situação o uso de um evento pra árvore com certeza é mais efetivo.

No caso do XP, já que a feature existe os layers já são re-gerados em todos os frames então realmente não faz sentido adicionar a árvore por sprite, mas numa engine decente, ter uma forma simples de adicionar a árvore como um sprite seria bem mais efetivo (sem precisar adicionar um evento inteiro, com gatilhos, condições, páginas, etc - essas coisas deixam mais pesado mesmo que não estejam sendo usadas).

 

[Jorge_Maker]

Não sei como isso funcionaria no MV, tbh, você certamente tem mais autoridade para falar sobre. xD

De fato que essa implementação de tilemap é bem mais complexa que a convencional (admito que nunca vi algo similar fora do XP), mas vale lembrar que o tilemap só renderiza aquilo que está em exibição na tela (com margem de erro de 1 tile), enquanto que os eventos, em especial os respectivos sprites destes, atualizam a cada frame independente de sua posição na tela, sem falar das outras operações realizadas por estes que sequer estariam em uso nessa situação, como você mesmo apontou.

Nesse caso, convém criar objetos mais simples do que os eventos, que sirvam apenas como referência para posição de seus respectivos Sprites. Mas não é todo mundo que teria esse entendimento, e convenhamos que não é tão conveniente quanto um editor específico para tal.

No MV, o Sr. Yanfly trabalhou em um plugin interessante sobre isso, o Grid-Free Doodads. É bem simples, mas a cereja do bolo desse plugin é o editor. Não usaria, mas foi inspirador para mim.

---

https://imgur.com/a/TttjSM4

Novas imagens do MZ. )o)
Não há confirmação da veracidade delas -pelo contrário, no fórum oficial não estão permitindo que sejam postadas, o que é compreensível.

Sendo ou não reais, é legal ter novo material para debate, mesmo que moldado em expectativas.

 

[Hudell]

As screenshots acima batem com algumas coisas que eu já sei sobre o MZ, então devem ser reais.

Edit:
Eu tô feliz com o MZ já. Como eu só uso pra editar mapas mesmo, as coisas que eu mais queria ele tem. Vou migrar o orange pra ele.

 

[Hudell]

(Depois de 3 dias ainda conta como double-post?)

Novo trailer:

https://twitter.com/x/status/1273511331086438400

Confirmaram agora que o leak é real.
Pessoal da rmweb anunciou que a partir de quinta que vem começam a falar sobre as novas features.

Screenshots em inglês:


Features confirmadas pelo trailer:
- Campo pra digitar um nome no comando "Show Text"
- Um novo sistema de animação? (o leak falava em um sistema de partículas)
- O gerador de faces na screenshot acima acho que é novo também.

 

[Rafael_Sol_MAKER]

Rapaz, agora precisamos de gente que manje dos japonês para poder garimpar mais informação desse vídeo. Vou ficar de olho na gringa e ver o que eu descubro.

 

[DadoCWB]

Isso me interessa...

 

[Lord Wallace]

Rapaz, agora precisamos de gente que manje dos japonês para poder garimpar mais informação desse vídeo.

@Aika-chan Vem socorrer o pessoal aqui! Hhahahah