Projeto: USP's Game Development Kit (UGDK)


#1

A UGDK é a engine com a qual desenvolvemos nosso primeiro jogo, o Horus Eye. Desde então, separamos ela como uma ferramenta independente, voltada para jogos 2D (embora já tenhamos conseguido injetar a Ogre3D nela). Ela é escrita em C++14 e usa SDL, OpenGL, CMake e googletest. A licença dela é a zlib.

Por hora, queremos saber quem tem interesse em participar

Desenvolver a UGDK é trabalhoso, mas não é nem de perto algo do outro mundo. Você vai poder pôr em prática diversas habilidades desenvolvidas durante sua graduação e tranquilamente ir além. A experiência adquirida em um projeto desse tipo faz uma diferança enorme no seu currículo também.

Assim que tivermos uma quantidade mínima de pessoas, marcaremos as primeiras reuniões.

Objetivo

Queremos, no momento, focar em revitalizar a UGDK, tornando a compilação e instalação dela mais acessível e sua API mais consistente e estável. Isso provavelmente envolverá o abandono de diversas features (como 3D e scripting), mas eventualmente iremos as re-adicionando na engine (ou como plugins à parte).

De maneira geral, se você quer saber como certa parte da UGDK funciona, você pode perguntar aqui no fórum ou procurar especifamente por mim, o @Henrique, o @Omarillion, ou quem sabe até o @brocoli.

LabXP

Estamos tentanto incluir a UGDK como um projeto de MAC0472/MAC5716/MAC5717 (Laboratório de Métodos Ágeis/Programação Extrema). Assim que tivermos notícias, avisaremos aqui.

Links importantes

Página oficial
Descrição na wiki
Referência (dev)
Repositório no GitHub
Padrão de código


#2

#3

Estou interessado em participar.


#4

Também gostaria de participar.


#5

Grandiosa UGDK hahahaha

A parte de 3D que o @Kazuo mencionou usa o core da UGDK, mas usa a Ogre3D como engine gráfica e a BulletPhysics como biblioteca de física/colisão. Ambas são muito boas e conhecidas em seus respectivos campos. Quando fizemos esse módulo 3D da UGDK usamos essas bibliotecas prontas pois julgamos que até fazermos algo similar nós mesmos ia dar muito trabalho, e por serem open-source poderiamos usar elas e aprender sobre a programação 3D tanto de engine como do jogo em si de forma mais simples. No entanto acho que só um projeto nosso usa, o Ships Battle, que está parado no momento pois não tenho tempo de trabalhar nele agora…

De qualquer jeito, essa parte 3D já estava meio que separada num módulo separado dentro do mesmo repositório se não me engano, o que deve facilitar desabilitar ele para não atrapalhar builds novas.

E reitero o que o @Kazuo falou: enquanto trabalhar na UGDK pode ser um tanto quanto complicado e sem resultados imediatos (afinal, estarão mexendo na engine e não num jogo), é uma ótima forma de aprendizado sobre os algoritmos, processos e padrões de código por trás dos jogos.
O sistema de scripting que o Wil mencionou, acabou se tornando uma ferramenta poderosa que eu e ele transformamos numa biblioteca separada (independente da UGDK) chamada Ouroboros. Esse projeto se tornou nosso TCC =D Como parte da UGDK, esse módulo de scripting foi usado (entre outras coisas) para fazer o nosso jogo Asteroid Wars inteiro em Python, usando a UGDK.

Finalmente, (de novo) como o Wil mencionou, estou ai para qualquer dúvida sobre a UGDK. Já faz um tempo desde que mexi nela, mas ajudarei como puder.

até!


#6

Tb tenho interesse em participar


#7

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:

  1. Ogre3D
  2. 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.).


#8

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.


#9

Eu estava mais preocupado com a nossa separação em src/include. Não lembro qual era nossa moticação original pra isso XD.

Sim! Ótimas questões!

Por hora, só consigo pensar no esquema de Activities e Render Steps que fiz pro UFO project. Deve ter coisa melhor.


#10

@Henrique
Nós vamos colocar alguma coisa de support a data-driven design? Ou a ideia é que usar a ugdk precisa ser só programando?


#11

Data-driven é amor, mas eu imagino que vai ser um parto pra implementar :slight_smile:


#12

Acho que o esforço vale a pena. Se queremos que a engine seja High Quality™, data driven is a must.


#13

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.


#14

Eu que pergunto, não vamos? Nadinha de nada? =)

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:

  1. GUI
  2. Formatos de colisão
  3. Mapas
  4. Animação/Cutscenes
  5. Diálogos
  6. 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”.


#15

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é?


#16

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.


#17

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++? :laughing:

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… :smiling_imp:

:robot::fire: Compiler hell is a real place muahahaa
https://www.youtube.com/watch?v=FnuA-M-aq8w


#18

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! :stuck_out_tongue:
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…

#19

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.


#20

Não poderei ir hoje na reunião, mas irei na quarta. Enquanto isso tento rodar o Maverick