게임 엔진에서 필요한 애셋로드 시스템을 만들었습니다.
유니티나 언리얼 같이 대규모 범용 엔진의 경우에는 모든 애셋에 GUID를 묶어서 참조나 애셋위치가 바뀌었을 경우 추적등에 활용합니다.
유니티는 각 애셋파일마다 meta파일을 만들어서 guid등 여러 값을 이용해서 애셋의 완벽한 유니크함을 확보해서 여러 관리를 하고 언리얼의 경우 커더란 애셋DB에서 애셋을 관리 합니다.
그러나 제 엔진은 대규모 범용 엔진이 아니라.. 저혼자 게임을 만들기 위한 '작고 빠른' 게임엔진이 목표이기에 이러한 시스템은 만들기도 힘들고 1인 개발이라 관리도 빡쎕니다. 일단은 단일 관리 API로 고전 방식대로 사용합니다.
지정한 상대 경로를 통한 파일로드.. 없으면 '에러'로 고전방식대로 개발합니다.
사실 GUID 방식으로 관리하는것은 여러 개발자가 프로젝트를 진행할때 리소스의 위치변경, 또는 삭제 등 편집의 복잡성을 일관되게 관리 하기 위해서는 반드시 필요하나 .. 공통적으로 런타임시 메모리를 '왕창' 처먹는다는 단점이 있습니다. 일례로 유니티의 경우에는 빌드해서 안드로이드나 iOS와 같은 메모리가 중요한 모바일에서 로드하면 애셋 DB만 수십 수백메가를 혼자 처먹고 있습니다.
직렬화라는 편리함을 얻는 대신 성능을 많이 깍아먹고있죠.. (요즘 시대가 이렇습니다..)
====================================================================
보통 엔진을 사용하면 LoadAsset("./Asset/Texture/Face.png") 이런식으로 많이 쓰는데.. dll을 주로 사용하는 현재 엔진에서는 보다 고전적이고 원초적인 방식으로 모든 애셋에 동기/비동기 API만 따로 둡니다.
현 프로젝트에서는 dll에 템플릿을 API로는 왠만하면 빼지말자.. 라고 정했기도 했고.. 또 추후 AI Agent개발시 분명한 API사용법을 Agent에 전달하려고 합니다. 그리고 dll 동적 라이브러리에서 템플릿을 외부로 노출하는 것은 사실 좋은 구조가 아니긴 합니다. dll을 사용하는 쪽에서.. 예를 들어 (GameLib)같은 클라이언트 게임 개발을 위한 미들웨어 같은것을 둔다면 그곳에 정적 라이브러리로 유저 편의성을 위해서 템플릿 API를 노출하는 것이 맞습니다.
모든 API가 작동하는 것을 테스트 하였고 Json과 XML은 추후 필요시 그때 넣으려고 합니다.
json은 yyjson 라이브러리를 xml은 libexpat이나 yxml 파서를 사용할것 같습니다. 둘다 C로 작성되었고.. 적은 메모리 할당량과 매우 빠른 성능을 보여줍니다. yyjson은 뭐 말이 필요 없는 최고의 C언어로 작성된 json 파서입니다.
이제 Model과 Material을 제작해서 렌더링하고 화면 Scene 정보를 저장/로드하는 과정이 필요 합니다. 사실상 본격적인 3D엔진 개발이라고 볼수 있죠.. 문제는 유니티나 언리얼, 고도엔진에서 사용하는 계층형 씬노드를 관리하는 방식을 그대로 사용할지.. 고민입니다.
계층형 씬노드의 장점은 만들기 편하고, 사용하기도 직관적이고 좋습니다. 다만 객체지향형 프로그래밍의 최대 단점인 CPU캐시 효율성이 완전 꽝이라.. 이걸 이대로 써야 하나? 라는 고민이 듭니다.
범용적인 월드 계층 노드의 구성을 했을경우. CPU 내부에서 작동 대부분이 1개 노드 관련 작업할때마다 메모리 점프하느라 메인 메모리 - 캐시딴(L1, L2, L3)의 수많은 Read Access로 시간을 다 보냅니다.
그래서 DOD나 ECS프로그래밍 같은 방법론이 나오고 실제로 효과도 엄청나지만.. 둘의 단점은 프로그래밍하기 직관적이지 못하고 쓰기도 더럽게 힘들다는 데 있습니다.
그래서 예전에 자체엔진 만들때는 지형 관련 데이터는 TerrainSceneManager, 캐릭터는 CharacterSceneManager 식으로 그룹, 기능별로 썼는데.. 이번에도 이렇게 만들까? 라는 생각이 들기도 합니다.
다만 이럴경우 다양한 게임을 AI에게 맡겨서 만들기 힘들것 같다는 생각이 들고.. 그래서 고민입니다..
