본문 바로가기

레퍼런스/고도엔진

고도엔진 튜토리얼 #11 파일 시스템(File system)

도입


파일시스템은 아직 엔진 개발에서 뜨거운 주제입니다. 파일 시스템은 어떻게 에셋이 저장되고 접근되는 지 관리합니다. 잘 설계된 파일시스템은 다수의 개발자에게 협업할 때 같은 소스 파일과 에셋을 편집할 수 있게 해줍니다.


고도엔진의 초기 버전은 (그리고 고도라고 이름 붙이기도 전의 것들도) 데이터베이스를 사용햇습니다. 에셋은 데이터베이스 안에 저장되고 ID를 할당받았습니다. 로컬 데이터베이스, 메타 데이터 파일 등 다른 방식도 시도했습니다. 결국 간단한 접근이 채택되어 지금의 고도는 모든 에셋을 파일로 파일 시스템에 저장합니다.



이행


파일시스템은 자원을 디스크에 저장합니다. 스크립트, 씬 또는 PNG 이미지 등 어떤 것도 엔진의 자원입니다. 만약 자원이 디스크에 있는 다른 자원을 참조하는 속성을 포함하면 자원들의 경로가 포함되어있습니다. 만약 자원이 내장된 하위 자원을 가지면, 자원이 모든 하위 자원과 함께 단일 파일에 저장됩니다. 예를들어 폰트 자원은 폰트 텍스쳐와 대부분 함께 묶여있습니다.


일반적으로 고도 파일 시스템은 메타 데이터 파일 사용을 피합니다. 이유는 간단합니다. 존제하는 에셋 매니저와 VCS는 우리가 구현할 수 있는 어떤 것보다 낫기 때문에 고도는 SVN, Git, Mercurial, Perforce 등과 함께 하는 데에 최선을 다하고 있습니다.


파일시스템의 예는 다음과 같습니다 :


/engine.cfg
/enemy/enemy.scn
/enemy/enemy.gd
/enemy/enemysprite.png
/player/player.gd



엔진.cfg(engine.cfg)


엔진.cfg 파일은 프로젝트 설명 파일입니다. 그리고 언제나 프로젝트의 루트에서 찾을 수 있죠. 사실 이 파일의 위치가 루트가 어디인지를 정의합니다. 이 파일이 고도가 프로젝트를 열때 가장 먼저 찾는 파일입니다.


이 파일은 win.ini 포맷의 파일을 이용해 프로젝트의 배열을 텍스트 형태로 포함하고 있다. 심지어 빈 엔진.cfg 파일도 빈 프로젝트의 기본적인 정의를 하는 기능을 한다.



경로 구분 기호


고도는 / 만을 경로 구분 기호로 사용한다. 이는 휴대성 때문이다. 심지어 윈도우를 포함한 모든 운영체제는 c:\project\engine.cfg가 아닌 c:/project/engine.cfg로 쳐야한다.



자원 경로


자원에 접근할 때, 호스트 OS 파일시스템 레이아웃을 사용하는 것이 번거롭고 가져올 수 없습니다. 이를 해결하기 위해, 특수 경로 res://가 만들어졌습니다.

경로 res://는 언제나 프로젝트 루트를 가리키고 있습니다(engine.cfg가 위치된 곳, 그래서 res://engine.cfg는 언제나 유효합니다).

이 파일 시스템은 에디터에서 지역적으로 프로젝트를 실행할 때 읽기-쓰기 전용입니다(This file system is read-write only when running the project locally from the editor). 출력될 때 또는 다른 장치에서 실행될 때 (핸드폰이나 콘솔, 또는 DVD에서 실행될 때), 파일 시스템은 읽기 전용이 되고 쓰기는 더 이상 수행되지 않습니다.


유저 경로


디스크에 쓰는 것은 아직도 자주 게임 상태를 저장하거나 콘텐츠 팩을 다운로드 하는 등의 다양한 작업을 필요로 합니다. 이 목적을 위해서는, 엔진이 user://라는 특별 경로가 항상 쓸 수 있게 보장해야 합니다.



호스트 파일시스템


대안으로 호스트 파일시스템 경로도 사용될 수 있습니다. 하지만 릴리즈된 제품들이 모든 플랫폼의 그런 경로에서 작동한다고 보장할 수 없기 때문이다. 하지만, 호스트 파일시스템 경로를 사용하는 것은 고도에서 개발 툴을 쓰는데 매우 유용할 수 있습니다.



단점


이 간단한 파일 시스템 설계에 몇몇 단점이 있습니다. 첫번째 문제는 에셋을 움직일 때(재명명을 한다거나 프로젝트의 다른 경로로 움직인다거나) 에셋들에 존재하는 참조가 깨진다는 것입니다. 이 참조들은 새로운 에셋 경로를 가리키도록 다시 정의해야 합니다.


두번째는 윈도우와 OSX 파일과 경로 이름은 대소문자를 구분하지 않는다는 겁니다. 만약 개발자가 대소문자를 구분하지 않는 호스트 파일 시스템에서 작업하다가 "myfile.PNG"라는 에셋을 저장하고 "myfile.png"라고 참조하는 경우, 이는 안드로이드, 리눅스 등의 다른 플랫폼에서는 제대로 작동하지 않을겁니다. 이는 압축 패키지를 이용하여 모든 파일을 내보내는 실행 파일에도 적용될 수 있습니다.


고도를 다룰 때는 여러분이 팀의 파일 명명 규칙을 명확하게 정의하는 것이 좋습니다. 단순한 바보같은 관례는 소문자 파일과 경로 이름만 허용하는 것입니다.