I created an asset loading system needed for a game engine.
For large-scale general-purpose engines like Unity or Unreal, they assign GUIDs to all assets for reference and tracking when asset locations change.
Unity creates a meta file for each asset file and uses multiple values like GUIDs to ensure complete uniqueness of assets for management, while Unreal manages assets in its asset database.
However, my engine is not a large-scale general-purpose engine... my goal is a 'small and fast' game engine for solo game development, so it's difficult to build such a system, and as a solo developer, management is also tough. For now, I'll use a single management API in the classical way.
Loading files through a specified relative path... if not found, it returns an 'error' and I develop in the classical way.
In fact, GUID-based management is essential for consistently managing the complexity of edits such as resource location changes or deletions when multiple developers work on a project... however, the common disadvantage is that it consumes a lot of memory at runtime. For example, in Unity's case, when you build and load on memory-critical mobile platforms like Android or iOS, the asset database alone consumes tens to hundreds of megabytes.
In exchange for the convenience of serialization, performance is significantly compromised... (that's how things are these days..)
====================================================================
Usually, engines are used like LoadAsset("./Asset/Texture/Face.png")... but in the current engine which primarily uses DLLs, I provide separate synchronous/asynchronous APIs for all assets in a more classical and primitive way.
In the current project, I decided to avoid exposing templates as APIs in the DLL as much as possible... and later, when developing AI Agents, I want to provide clear API usage examples to the Agent. And exposing templates externally from a dynamic library DLL is actually not good architecture. On the side that uses the DLL... if you place middleware like (GameLib) for client game development, it's correct to expose template APIs as static libraries there for user convenience.
I have tested that all APIs work, and I plan to add JSON and XML support later when needed.
I plan to use the yyjson library for JSON and either libexpat or yxml parser for XML. Both are written in C... and show low memory allocation and very fast performance. yyjson is the best JSON parser written in C language, no explanation needed.
Now I need to create Models and Materials for rendering and implement the process of saving/loading Scene information. This can essentially be considered the beginning of serious 3D engine development... The problem is whether to use the hierarchical scene node management approach used in Unity, Unreal, or Godot engines... I'm uncertain.
The advantages of hierarchical scene nodes are that they're easy to create, intuitive to use, and convenient. However, the biggest drawback of object-oriented programming is that CPU cache efficiency is completely terrible... so I'm wondering if I should really use it as is?
When using a generic world hierarchy node structure, most operations inside the CPU require memory jumps for each node-related task, spending most of the time on numerous Read Access between main memory and cache layers (L1, L2, L3).
That's why methodologies like DOD or ECS programming have emerged and are actually very effective... but their downside is that they're not intuitive to program and are terribly difficult to use.
So when I created a custom engine before, I used terrain-related data with TerrainSceneManager, characters with CharacterSceneManager, organized by group and function... I'm wondering if I should do the same this time?
However, if I do this, it seems like it would be difficult to have AI create diverse games... so I'm worried about it..
