아빠곰의 세상나들이

간단히 조직이 큰 그림을 볼 수 없는 형태 또는 마인드를 갖고 있지 못한 조직들이 종종 있다.

준비 안된 조직의 특징은 근시안적 발상을 갖고 있거나 게임 개발을 로또 복권 처럼 대박을 기대한다.

다른 특징 하나는 조직내 이슈나 사람에 대한 비난을 많이 하는 반면,
문제에 대한 해결 방안을 내놓지 못하거나 잘한다는 표현이나 긍정적인 표현은 없다.
또한 의견이나 이슈에 대한 토론이라는 형태는 없다.
아니 있으면 그것은 마치 노는 것이나 잡담으로 치부하며
컴퓨터 앞에 앉아서 일만 하라고 하고 무언가의 결과물을 기대한다.

회의가 많아진다.
문제점은 있지만 결과가 없다.
아니 도리뱅뱅같은 개념의 회의만 될 뿐!
시간이 지나도 문제의 해결은 없이 폭탄 돌리기 하다가
어느새 누군가가 독박 쓰고 멘붕을 당하고 있을 것이다.

게임 개발은 창작물이다.
혼자의 생각이나 의견으로 나올수도 있겠지만
대부분 이런 경우는 천재 한명이 회사를 좌지우지하는 경우일 것이고
보편적인 회사나 조직의 경우는 많은 사람들의 의견이 나오고
옳바른 방향의 토론이나 많은 대화를 통해 의견을 모으고 합의의 결론에 도달해
새로운 창작물에 대한 심도 있는 결과물이 나온다고 본다.

개발은 그냥 연장 몇개 들고 조립해 나오는 식으로 화자되어
누구나가 보편적인 생각이라는 식으로
개발자들이나 조직에 있는 사람들에게 세뇌시키는 발언을 하는 경우가 종종 있다.

이런 스타일의 조직은 과감한 결정이 뒤따라야 하지 않나 싶다.

어쩌다 준비안된 조직이 성공하는 경우도 있다.

문제는 오래가지 못하거나, 성공할때 벌어둔 돈에 비례해서 시간이 걸리겠지만, 망해가는 절차를 밟았다.

1990년대~2000년 그 많던 게임 개발사들이 성공하고 망하고 하는 과정들을 지켜보면서 몇자 적어봤다.

출처 - http://docs.unity3d.com/Documentation/ScriptReference/index.Script_compilation_28Advanced29.html-

스크립트 컴파일 최적화 (Advanced)

유니티는 모든 스크립트를 .Net dll로 컴파일 합니다. 이 .dll 파일들은 런타임에서 jit 방식으로 컴파일 됩니다.

이 방법은 빠른 속도의 스크립트 실행이 가능하도록 해줍니다. 이 방법은 기존 javaScript 대비 20배 정도 빠르고 native c++ 코드보다는 50%정도 느린 속도를 나타냅니다. 스크립트를 수정하고 저장하게 되면 유니티가 모든 스크립트를 컴파일 하는데 일정 시간이 걸리게 됩니다. 유니티가 컴파일을 진행하고 있는 경우, 유니티 메인 윈도우 오른쪽 아래 부분에서 작은 spinning progress icon을 확인하실 수 있습니다.

스크립트 컴파일은 다음의 4단계를 거쳐서 진행됩니다.

1. “Standard Assets”, “Pro Standard Assets” 또는 “Plugins”폴더 내에 있는 스크립트들이 가장 먼저 컴파일 됩니다.

위의 나열된 폴더 내의 스크립트들은 이 폴더 외부의 스크립트에 직접 접근할 수 없습니다.

해당 클래스나 변수에 직접 접근할 수는 없지만, GameObject.SendMessage 메소드를 통해서 통신을 할 수 있습니다.

2. “Starndard Assets/Editor”, “Pro Standard Assets/Editor” 또는 “Plugins/Editor”내의 스크립트들이 그 다음 순서로 컴파일 됩니다.

UnityEditor 네임스페이스를 사용하려는 경우에는 해당 스크립트를 반드시 위와 같이 “Editor”폴더 내부에 위치 시켜야 합니다. 예를 들어, menu item을 추가하거나 custom wizard를 작성하는 경우에는 위에 나열된 폴더 중 한 곳에 위치시켜야 합니다. 이 스크립트들은 1번의 그룹에 있는 스크립트에 접근이 가능합니다.

3. “Editor”폴더 외부의 스크립트들이 그 다음 순서로 컴파일 됩니다.

위의 단계에서 언급된 폴더 또는 “Editor”폴더 외부의 스크립트들이 그 다음 순서로 컴파일 됩니다.

이 단계에서 컴파일되는 스크립트들은 첫 번째 단계의 스크립트에 접근이 가능합니다 (“Standard Assets”, “Pro Standard Assets” 또는 “Plugins”). 이는 다른 스크립트 언어와 상호 운용이 가능하게 해줍니다. 예를 들어, C#스크립트를 참조하는 JavaScript를 작성하려는 경우, C# 스크립트를 “Standard Assets”폴더에 넣고 JavaScript는 “Standard Assets” 폴더 외부에 놓습니다.

이렇게 하면, JavaScript에서 C# 스크립트에 바로 접근이 가능합니다.

첫 번째 그룹에 속한 스크립트들은 컴파일 하는 데 시간이 더 많이 걸리게 됩니다. 첫 번째 그룹의 스크립트들이 컴파일 될 때, 세 번째 그룹의 스크립트들도 재 컴파일 되어야 하기 때문입니다. 따라서 컴파일 시간을 줄이고 싶은 경우, 변경이 거의 없는 스크립트는 첫 번째 그룹에 두고, 변경을 많이 해야 하는 스크립트는 세 번째 그룹에 둡니다.

4. “Editor”폴더 내부의 스크립트들이 그 다음 순서로 컴파일 됩니다.

UnityEditor 네임 스페이스를 사용하려는 경우, “Editor”폴더 내부에 해당 스크립트들을 넣어 두어야 합니다. 예를 들어, menu item을 추가하거나 custom wizard를 작성하는 경우에는 “Editor” 폴더에 위치시켜야 합니다.

여기에 위치한 스크립트들은 이전 그룹에 속한 모든 스크립트에 접근이 가능합니다.

게다가 WebPlayerTemplates 라는 이름의 폴더 내부에 위치한 스크립트들은 더 이상 컴파일 되지 않습니다.

유니티 버전에 따른 조건부 컴파일

유니티 2.6 버전부터 C# 전처리 define 구문이 추가되었습니다. 이 define 구문들은 사용 중인 유니티 버전을 구별하고 이를 이용하면 버전에 따라 특정 기능에 조건부 접근이 가능합니다.

이 코드는 특정 유니티 버전에만 게임의 특정 기능이 동작하도록 할 때 사용할 수 있습니다. 이 Define 구문이 유니티 2.6 버전부터 적용이 된다는 점을 주의해야 합니다. 스크립트에서 사용할 수 있도록 이 후의 유니티 버전에 해당하는 Define 구문이 적절하게 추가될 예정입니다.

플랫폼 별 조건부 컴파일에 대한 자세한 사항은 아래 링크를 참고하시기 바랍니다.

http://docs.unity3d.com/Documentation/Manual/PlatformDependentCompilation.html