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:
- 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”.