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)?
Não vejo problema em juntar a ugdk-2d e a ugdk-core.
No caso de separar em core/2d/pyramidworks, seria legal não separar em reps diferentes. Isso traz umas dores de cabeça meio desnecessárias no momento.
O @Omarillion disse que prefere manter separado, para manter um mínimo de compatibilidade com a ugdk-3d, que algum dia ele pretende continuar (separado mesmo). Mas ele também acha melhor deixar no mesmo repo de um jeito ou de outro.
A questão pra mim então é se a UGDK “canônica” vai ser uma engine “completa” por si só. Se sim, ela precisa ter a ugdk-2d inclusa. Se não, ela vai ser só uma base em cima da qual engines mais específicas podem ser implementadas. Por mim ambas opções parecem OK, e concordo que fazer em um repo só é bem menos treta.
Então, rapaziada,
Estava tentando fazer a ugdk aguentar fazer janelas dinamicamente, deu certo abrir e fechar manualmente (via código).
O negócio é que, se o usuário clicar no x de uma janela não-principal o mundo acaba.
Eu tava tentando fazer a ugdk levantar um evento do tipo SDL_QUIT mas não tô entendendo o sistema de eventos :l
O segfault que dá é pq o system::Run() chama um graphic::UseCanvas() num canvas que é inválido, pq ele pressupõe uma RenderScreen, que tem um smart pointer pra Window, que tem raw pointer pra uma sdl_window, que, em tese, morreu.
O problema, além de fazer soar o evento de “user requested termination” é:
na struct do SDL_QUIT não tem nem SDL_window_id, só tipo timestamp etc. Então se o usuário clicar no ‘x’, a única alternativa é matar a cena.