STAGE VK - Laying the Foundation

Welcome to my first post about STAGE VK. STAGE stands for Simple Tridimensional Animation Game Engine, and VK refers to Vulkan.

Why?

The motivation that led me to start this personal project comes from the master’s degree I am currently studying at UPC in Barcelona, Advanced Programming for AAA Games. At the same time, a group video game project called Bound by Death is also being developed, for which another Game Engine is being built using the DirectX 12 API.

It is a fascinating project in which the tasks are shared among all the members of the team. Together with some of my classmates, I decided to focus more on the development of the Game Engine, which is both a challenge and a great learning stimulus. Meanwhile, the design of the video game is being developed in parallel by another group of classmates.

As far as the development of the Engine is concerned, the main drawback is that, because the work is divided up, there are parts I do not implement and whose inner workings I do not fully understand. Because of that, I sometimes feel that I am not making the most of the learning opportunity. Even so, this is inevitable, as we only have until October 2026 to create the Game Engine and develop the video game from scratch.

For that very reason, after several months of learning about Game Engine development and gaining a more mature perspective on the subject, I wanted to begin this personal project: my own Game Engine. Not only as an exercise to consolidate what I have learned during the master’s degree, but also as a way of going one step further and learning something extra along the way. And that is where Vulkan comes into play.

First Steps

• The first step was to download and install the Vulkan SDK.

• Then GLFW, in order to create the application window.

• And finally, the GLM library to handle what we all love most: mathematics.

Once the project had been created and linked in Visual Studio, I tried to build a clear foundation before moving on to more complex systems.

The current architecture is organised around an Application class, which acts as the core of the engine and coordinates its overall lifecycle: initialisation, per-frame update, and final cleanup.

Application owns the startup configuration (AppConfig), the main window (Window), and the collection of engine modules, while also keeping basic frame information such as deltaTime, fps, and the pause state.

The design is based on a simple modular architecture, where each subsystem inherits from a base Module class with a shared lifecycle: Init, Update, PreRender, Render, PostRender, OnResize, and CleanUp.

The structure is very readable, with a stable execution order and a natural way of continuing to expand the engine without mixing responsibilities too early.

In the UML, this can be clearly seen in the relationship between Application, which owns multiple modules, and Module, which defines the system’s common interface.

At platform level, Window encapsulates GLFW and represents the operating system window. Its responsibility is not to render, but to manage the window, process events, report the framebuffer size, and detect resize events.

This separation allows the rest of the engine to work with a clean window abstraction, without depending directly on GLFW everywhere. In the UML, Application appears as the owner of Window, while other systems only depend on it when they need access to the native handle.

The current graphics module is BackendVKModule, which represents the first real layer of the Vulkan backend. At the moment, it creates the VkInstance and the VkSurfaceKHR, and exposes those handles to the rest of the engine. The architectural reasoning here is important: this module does not exist to decide what is drawn, but to establish the technical foundation that will later allow the creation of the logical device, queues, swapchain, synchronisation, and frame cycle. In the UML, this is reflected as a specialised module that inherits from Module, depends on Window to create the surface, and is cached by Application for convenient access.

Result

For now, the visible result is very simple: the only thing that compiles is a blank window. However, that is precisely the point of this first phase. Rather than aiming for an immediate visual result, the objective has been to establish a solid initial foundation on which the rest of the project can be built with order and architectural purpose. This blank window is not the end of anything, but the starting point of STAGE VK.