Bom, agora que estamos mais ou menos encaminhados para começar a trabalhar na UGDK, acho que é bom estabelecermos nossas primeiras metas.
Dei uma olhada hoje antes da reunião e, juntando com uma conversa que tive com o @Henrique, imagino que podemos começar cortando algumas coisas:
Ogre3D
Sistemas de script
Até porque essas features já são opcionais.
Fora isso, vi que estamos usando a glm. @Henrique, a ideia era dropar nossas classes de geometria e ficar só com a glm? Não lembro mais.
Depois disso, não sei se seria melhor darmos uma revisada na organização das pastas, ou já começar a revisar a API das principais classes (Engine, Scene, Task, etc.).
Pode ser um plano bom esse, cortar classes nossas que são melhor satisfeitas por bibliotecas de terceiros.
Não sei dizer se realmente precisa organizar as classes: já ficou melhorzin quanto separou em 2d/3d.
Acho que tem 2 grandes pontos que é legal olhar, discutir e revisar o plano que a UGDK vai ter e expor.
Scenes/Tasks
Rendering Functions
O primeiro é se vale a pena forçar um modelo de “ter scenes”.
O segundo é como que um jogo que usa a UGDK renderiza coisas. Se é apenas literais do estilo da love, ou se tem alguma logica mais interessante.
Data-driven para mim para buzzwords tipo falar “usar cloud!”. O que é data driven? Objetos do jogo? Vamos forçar um modelo de gameobjects com componentes?
Fora tudo isso, vai ter algum editor para preparar esses dados do formato que a engine espera? E assim vai indo.
Vamos ter alguma linguagem de programação estilo a blueprints da unreal?
Resumindo, “data-driven” por si só é altamente genérico para pensar em implementar, e qualquer solução que eu penso me parece absurdamente fora do escopo, quase sendo um projeto inteiramente a parte.
Fora isso, me preocupo bastante com performance. Muito difícil ficar lento em desktops e/ou GPU dedicadas pq essas são rápidos d+, mas mobile é até difícil ter uma performance boa.
Esse tipo de coisa com certeza não. E a gente já tinha concordado que suporte a scripts seria algo à parte.
Será que não rola alguma solução intermediária? Quais foram as soluções que você pensou?
Concordo que foi uma proposta genérica da minha parte. O que eu queria era justamente levantar a discussão se vamos ter algum modelo de objetos/componentes/whatever na UGDK, principalmente porque isso afeta a discussão sobre como faríamos (ou deixaríamos de fazer) a API para cenas/tasks e afins.
Pelo que entendi, você prefere não ter nada disso, e fica por conta de cada jogo se virar caso queiram usar data-driven em alguma coisa (como fizemos nas fases do horus eye). Não tem nada que podemos usar para deixar isso um pouco mais fácil, e que seja possível fazermos dentro das nossas limitações? Tem várias coisas que são bem pentelhas de fazer por código, e que muitos jogos usam em comum:
GUI
Formatos de colisão
Mapas
Animação/Cutscenes
Diálogos
Parâmetros de partículas (=P)
Fora coisas que são específicas por jogo, mas que podiam ser representadas de uma maneira padrão (OK, aqui eu estou forçando um pouco a barra).
That said, off-topic stuff:
Sempre achei que “data-driven” fosse um termo bastante consolidado na indústria de jogos, vide o próprio livro do Jason Gregory (Game Engine Architecture). Ele até diz que ser “data-driven” é uma das características principais de uma engine:
Arguably a data-driven architecture is what differentiates a game engine
from a piece of software that is a game but not an engine.
Também tem um artigo bem antigo (de mais ou menos 2000) do Game Programming Gems (o primeiro capítulo do primeiro volume, se não me engano) que explica e defende o uso de data-driven design. Dado isso, eu não chamaria “data-driven” de buzzword, principalmente porque considero ela uma técnica bem objetiva e básica, ao invés de algo vago e simplesmente “parte da moda”.
O que imagino por data driven (e o que eu deveria ter deixado claro) é que o core–ou seja a engine–roda um jogo–que é um conjunto de dados com regras e assets e coisas, separado do core.
Tipo doom.
Mas realmente, isso parece bem óbvio para qualquer engine? Pq se não tem isso não é bem uma engine né?
Acho importante deixar a interface com o desenvolvedor bem abstraída do código, na minha opinião, o mínimo possível deveria ter que ser implementado em código por eles. Afinal, não bastasse o skillset necessário para o design de um jogo, agora vamos exigir proeficiência em C++?
para mim, acho que o quê vai mais fazer diferença para os desenvolvedores seria:
GUI
Mapas
Diálogo (Talvez venha como bonus da GUI, sei lá)
…
Serem Data-driven
O motivo disso é que são pontos onde a grande parte do processo criativo vai estar, deixar ela abstraída e simples seria um bonus grande para qualquer time que venha a usar a UGDK no futuro. Não ter que hard-code esse itens agilizaria muito o processo de fazer um jogo, acho.
Principalmente para o mapa, mas para o diálogo também: pensa toda vez que você for recompilar o jogo, ter que recompilar todos os mapas junto pois eles tão hard-coded no troço
…A ANGUSTIA que isso não causaria.
A não ser que você queira torturar o seu compilador por nunca compilar seus EPs…
Unity/Unreal usam, mas é o melhor modelo geral? A nossa engine vai ter alguma distinção ao usar isso? Se eu for fazer um RTS, como encaixa um modelo de Game Objects?
insira aqui tb a parte de game engine “data-driven”
Se estamos falando de da Engine de um jogo específico, como Uncharted, The Witcher 3 e tals, não faz o menor sentido não ser data driven. O jogo é dito pelo seu conteúdo, e quem produz esse conteúdo é artista (no sentido de não-programador: modelos, animações, etc).
Quanto mais genérica é a nossa engine, mais difícil é ter algo data driven relevante. O engine do Horus Eye consegue ser muito mais pq falamos que ele é isométrico com objetos andando em mapas sem planos. Aquela engine é bem robusta, e da para fazer muita coisa com aqueles scripts.
Isso sim é uma meta boa da UGDK providenciar. O máximo de componentes bem feitos, e fáceis de integrar e estender que funciona em qualquer tipo de jogo.
Definitivamente, tanto que a UGDK já tem uma tentativa disso. Precisa melhorar bastante, pq UI is hard.
Em particular da para fazer algo data-driven, de preferencia lendo algum formato de interface que algum editor use. (Só não tendo que integrar um webkit… haha)
Extender o que a pyramidworks faz? Parece legal na realidade. Precisa julgar se vale a pena implementação própria, se alguma engine de física mesmo é melhor. Suporte a instanciar objetos facilmente usando arquivos de configuração, criados com coisas tipo o PhysicsEditor (e/ou algo open source ae).
Mas tb que ver o propósito disso, e se não é alguma misfeature que simplesmente ter uma engine de física não seria melhor o/
Mapa de jogo? Suporte a zoom in/out, pan e scroll numa tela, com ícones em cima e tals? É legal, mas isso parece mais algo que um usuário nosso faria usando componentes de UI.
Se for outra coisa, explique-se xD
Animação temos o suporte da UGDK lá, inclusive com um arquivo de input e tudo mais. É bem completo, integra com a parte de render e UI e tals.
E as 2 vezes que eu usei, teve alguma limitação que quase o torna inutilizável. No maverick toda a parte de tempo de animação não funciona direito =/
Cutscene depende muito de como é o render da engine, e de como o jogo se renderiza.
Talvez algo de storyboarding, mas talvez seja algo que é melhor implementar com mais contexto do jogo.
Provavelmente não é o que vc estava pensando, mas eu acho que atacar isso na parte de I18n/voice acting/subtitles é bem promissor. I18n é algo crucial para um jogo de sucesso, e que precisa ser trabalho com desde o começo.
Haha. Precisaria de um sistema de partículas primeiro!
Que, por sua vez, é tão relevante dependendo de o quão bom é o seu editor.
Engine de um jogo específico, tipo Doom? Sim. Mas fica bem difícil fazer algo que não seja um FPS com a engine do Doom.
Se o jogo for programado em C++? Sim, vamos exigir sim.
Mas mesmo que não esteja no código essas coisas, que nunca é uma boa ideia, vc provavelmente vai ter que compilar os assets em si: eles nunca são gerados/armazenados num formato que o seu jogo interpreta diretamente.
Fora o fato que gerar uma build instalável do seu jogo envolve empacotar os assets do jogo e tals. Principalmente se vc for mobile.
Malditos jogos da tapps que demoram o triplo pq tem muitos assets…
Em outros assuntos, nosso próximo objetivo é conseguir rodar o Maverick do @Henrique. É um teste melhor que os exemplos porque os exemplos não usam a última versão da UGDK.
Dado que não teremos mais a parte 3D (OGRE), vamos ter só os módulos ugdk-core e ugdk-2d no repositório da UGDK, certo? Será que não rola separar aquilo que for específico de 2D em uma extensão à parte (como planejamos fazer para 3D e scripts)?
Compiler hell is a real place muahahaa