Why does XVE look so basic?

I've literally been inundated by a message about my XVE project, specifically calling out why I have the temerity to describe it as an "Engine when it looks do basic?"

My over simplification in reply being that an engine can be anything you please, the engine is simply the framework within which the content can execute.

 

This applies to Unreal, Unity, Godot all of them, if you have something which will load your models, compile/apply your shaders and render to the screen you have a graphics engine.  If you have a threading model, memory or allocation handling, logging, input, user interface... All these module pieces form an engine.

The reason I am investing time working in my own such project is to explore those modules in which I find my experience or knowledge needing expanding, where I wish to trial alternative approaches, keep up with emergent new techniques or processes.

And of course for the content itself to explore the content creation tools; for instance I am very much a Blender beginner, and learning fast.  I could not say this just three months ago.

 

The major advantage to me in performing this kind of exploratory work at home in my own time is of course that I take a confidence and an assuring confidence back to my real work, as a leader of a small team I feel I am equipped to jump into pair program and just help.  I feel equipped going over a diverse or new code base; for instance recently I explored the Dagor engine used by WarThunder and the Little Vulkan Engine by Brendan Gaela.

 

Chronologically XVE has gone over many internal milestones, long before I began posting anything to YouTube or this blog about it, including:

• CMake & Project Structure
• Coding Standards
• Git & Commit Hook integration for Jenkins Continuous Integration Builds
• Test Framework
• Module Design
• Base
• Renderer
• Data loading
• XML
• CSV
• Wavefront Obj
• Generated type definitions (a whole generator suite written in python
• Entity Component System
• Threading Model
• Thread pool
• Anonymous Async Dispatch
• Promise/Future Standard Exploration
• Memory/Allocator Models
• Slab Allocators
• Dynamic Allocators
• RPMalloc
• Standard Allocator API (Custom)
• Input Framework
• XInput/DirectInput
• SDL2 Input
• SDL3 Input
• GLFW Input
• Custom personal exploration

And only after all this did I begin exploring actual game content and systems and component and entity relationships to represent the game design concepts.

 

The engine becomes a tool, a tool to achieve the delivery of the experience we want our players to experience and enjoy, so they return time & again to our game.

 

The game is key, and if done right the player should never know what engine or framework is being used to deliver that experience to them.