그리고 GameController가 가상의 위치에 건물 오브젝트가 필요하다고 할 때(실제 상황이라면 게임 로딩이나, 캐릭터가 멀리 나가거나 등 이겠죠), LoadBlock 스크립트를 부릅니다.
그 다음 LoadBlock은 이 위치는 어떤 크기와 종류의 건물이 들어서는지 정하지만, 지금은 일단 가상의 저장된 파일을 부르게 합니다.
그렇게 층으로 데이터를 고친 뒤, LoadFloor로 데이터를 넘깁니다(이 작업은 층 수만큼 반복). LoadFloor에서는 건물에 묶여있는 대부분의 것들을 불러옵니다. 벽, 창문, 계단, 엘리베이터, 뭐 그런 것들요.
그리고 LoadFloor는 층에 벽을 집어넣기 위해 LoadWall을 부르죠. LoadWall에서는 이때까지 위에서 내려온 데이터들을 실제 Unity에서 쓸 수 있게 바꾸고, Mesh로 만들어 올립니다.
문제는 이 모든 과정에서 GameObject가 엄청나게 많이 생겨요.
(지금은 이 코드에서 생기는 수 천 개의 일회성 변수는 생각하지 맙시다.)
일단 플레이할 때, 주위에 건물이, 적게 잡아, 50개 정도는 있어야겠죠.
그런데 이 건물 50개가 20층짜리라 치면, 층 마다 GameObject가 따로 있어서 벌써 GameObject가 1000개입니다.
여기에 각 층마다 벽을 포함한 각종 잡동사니가 200개쯤 있다면, GameObject 200000개.
이 모든 물건에 MeshCollider가 들어갈 걸 생각하면 벌써부터 암에 걸리죠.
그리고 앞으로 많은 계산이 필요할 걸 생각하면, GameObject 수가 최대 2000개 안을 유지해야 합니다.
20,000 GameObjects(Static) = 15 fps
원래는 최적화같은 건 적어도 2년간은 신경 안 쓰고 하려고 했습니다만, 실행이 안 되는 수준이 되면 이야기가 달라집니다.
일단 건물들을 몇 개 복사해서 쓰는 건 게임 컨셉과 거꾸로 가기 때문에 기각. (모든 건물이 다 유일무이하게 되는게 목표 중 하나라)
...사실 줄일 수 있는 부분은 Floor 내의 정적인 카테고리들(벽들, 바닥들)을 한 오브젝트로 처리하는 것 뿐입니다.
네, 벽들이 다른 텍스쳐들을 가질 걸 생각하면 이것도 불가능한 부분이죠.
-이래서 다른 게임들이 건물울 미리 만들어놓는 겁니다, 여러분.
더 디테일 있고, 더 효율적이잖아요.
20,000 GameObjects(ActiveX) = Stable
그런데 글을 쓰면서 검색해봤습니다.
보이지만 않는다면, GameObject 수 자체는 문제가 안 되는 것 같네요.
그렇다면 일단 벽이나 제대로 만들어볼까요.
건물 생성 부분만 6개월 잡았는데, 부족한 건 아닌가 모르겠네요.
벽 하나만 붙잡고 1달이잖아요.
GameObject Anti-Optimization
Now I know how to make Walls with scripts, next thing I should do will be loading these Walls from saved files.
So I seperated the scripts file to several pieces. (I've done this last week)
When GameController found out the Block(Building) GameObject is needed in a certain position(e.g. Loading the Game, or PC moved far away), it calls LoadBlock script.
LoadBlock script should figure out what kind of building should be in that position, but for now it just calls a virtual save file for test.
And LoadBlock decrypts the file and send them to LoadFloor(LoadFloor will be called multiple times, of course). And LoadFloor scripts makes what the floor need to have by calling scripts, such as LoadWall.
LoadWall makes Mesh from the data all the way from LoadBlock, and send them to LoadFloor.
The Problem is this kind of process makes a ton of GameObjects.
(Let's not think about thousands of one-off variables)
When you playing it, there should be at least 50 buildings around you loaded, shouldn't it?
If all those have 20 floors, since each floor are their own GameObject, already there are 1,000 GameObjects.
And if those floors has some stuff like walls about 200, this means 200,000 GameObjects.
And all of these has MeshCollider. Thinking about this is a great way to have a cancer. :(
20,000 GameObjects(Static) = 15 fps
I didn't want to think about optimization at least for 2 years, but things become different if the game is unplayable.
Copying buildings goes opposite direction from the concept, so no-no. (One of the goal is make every buildings as unique as possible)
...Only thing I can think of is treat static stuff(walls, floors) as one GameObject.
As Walls will have different textures, this isn't possible, neither.
-This is why the other games make buildings beforehand, everyone.
It's way more detailed, and more optimized way.
20,000 GameObjects(ActiveX) = Stable
But I've been googled while writing this.
If they are not visible, the number of GameObject isn't that much problem to play-ability.
Then I should do the Wall thing again.
Walking down the opposite direction of 'optimization.'
I thought making building would take 6 months, but this may be not enough.
