Este post documenta los hitos principales y puntos de inflexión en la historia de MasbitsEngine.
Orígenes — Motor 3D
El proyecto comenzó como un motor de juegos 3D. El desarrollo inicial se centró en la inicialización de Vulkan, una librería matemática propia, un grafo de escena y la carga de modelos 3D con Assimp.
El problema con los assets
El primer gran obstáculo fue la carga de assets 3D:
- Animaciones: Las animaciones esqueléticas requerían pesos de piel, transformaciones de huesos y mezcla de animaciones — cada capa añadía complejidad significativa
- Compatibilidad de formatos: FBX, glTF y OBJ tenían distintos niveles de soporte en Assimp
- Pipelines de texturas: Los pipelines PBR (albedo, normal, roughness, metallic, AO) requerían convenciones muy cuidadosas
El pivote hacia 2D
- Complejidad de las animaciones: La animación 2D es mucho más manejable y sigue ofreciendo capacidades visuales ricas
- Alcance práctico: El renderizado basado en tiles seguía requiriendo ingeniería significativa
- Foco de aprendizaje: Un motor 2D permite centrarse en la arquitectura central sin la complejidad del 3D
Vulkan y SDL3
Vulkan fue elegido sobre OpenGL y DirectX 12 por su control explícito y soporte multiplataforma. SDL3 reemplazó a SDL2 por su API más limpia y soporte nativo de Wayland en Linux.
Arquitectura ECS
El sistema de entidades y componentes fue adoptado para lógica de juego orientada a datos. Los sistemas operan sobre tipos de componentes de forma independiente:
// Sistema que procesa componentes Transform + Renderable
void RenderSystem::update(EntityManager& em, Camera& cam) {
for (auto& [t, r] : em.view<Transform, Renderable>()) {
VulkanRenderer::draw(r.mesh, t.getMatrix(), cam.getVP());
}
}Estado actual (2026)
Un motor 2D basado en tiles con renderizado Vulkan, arquitectura ECS, editor ImGui (tilesets, triggers, herramientas de cámara) y física Box2D — funcionando en Windows y Linux.