A löve não tem nada de data-driven, por exemplo.
Mas dá para entrar na discussão da diferença entre engine e framework. Da última vez que fiz isso o Nakamura quase me defenestrou.
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… 
Compiler hell is a real place muahahaa
https://www.youtube.com/watch?v=FnuA-M-aq8w
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.
Não poderei ir hoje na reunião, mas irei na quarta. Enquanto isso tento rodar o Maverick
Imprevisto: estou longe da usp no momento e só consigo chegar aí depois da reunião, pq eu vou ficar preso aqui até tarde.
Eu venho quarta e, bensadeus, meu laptop chega até semana que vem. Daí eu começo a ser mais útil
Valeu e desculpa, não achei q eu ia me demorar aqui
Beleza, então hoje a reunião fica cancelada mesmo.
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)?
Bem, já tem a pyramidworks. Ela atualmente possui coisas de tratamento de colisão 2d.
Então a gente joga lá as coisas que forem específicas de 2D?
Acho que a parte mais complicada é que a classe Window tá no módulo ugdk-2d.
Tem uma implementação da Window na ugdk-2d, deveria ter uma classe base no core. Eu lembro que a ugdk-3d tinha uma Window própria.
O problema é que todas as coisas de opengl acabam dependendo da ugdk-2d eu acho, e disso tira que as coisas de UI tb.
Ah, entendi agora.
A situação atual é a seguinte. A UGDK tem:
- ugdk-core (que inclui a pyramidworkds)
- ugdk-2d
- ugdk-3d
- ugdk-script
Os módulos ugdk-3d e ugdk-script vão sair. Aí, para ser consistente, vejo duas opções.
- Mover a pyramid works pra fora da ugdk-core e ficar com:
- ugdk-core
- ugdk-2d
- ugdk-pyramidworks
E nesse caso, acho que seria razoável considerar mover a ugdk-2d e a ugdk-pyramidworks para outros repos
- Mover a ugdk-2d para dentro da ugdk-core e ficar tudo junto.
Faz sentido?
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.
Queria deixar marcado o ponto a partir do qual estamos fazendo nosso trabalho atual. Pensei em fazer um tag “legacy”. Ou é melhor deixar um branch?
Enquanto compilava o Maverick, tive o seguinte erro:
Error LNK2019 unresolved external symbol _uncompress referenced in function “public: __thiscall tiled::Layer::Layer(class JSONNode const &)” (??0Layer@tiled@@QAE@ABVJSONNode@@@Z) maverick ~\maverick\build\src\tiled-reader.lib(layer.obj) 1
O tiled-reader.lib ta na pasta, tho.
~desculpa ressuscitar a thread~
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.
Ideias? Sugestões? Tô ficando bem perdido.
Na engine.cc é definido um SDLEventHandler que lida com o SDL_QUIT, mas apenas quando só tem apenas Uma (a principal) janela.
Dá segfault antes de chegar ao handler se tiver mais que uma.
SOOO folks…
Continuamos ou Hiatus? Por mim continuamos, o que vocês acham?
mas vamos ver se a gente atrai outros membros também :v