idisposable

Unity C# – IDisposable 알아보기

unity_logo

이번에는 IDisposable 인터페이스에 대해서 알아보겠습니다. C#은 가비지콜랙터(Garbage Collector)를 가지고 있습니다. 이 GC는 기본적으로 관리되는 모든 객체들의 참조 링크를 관리하며 더이상 참조되지 않는 객체들을 자동으로 메모리에서 소거하는 작업을 수행합니다. 하지만 GC는 창 핸들, 열린 파일, 스트림과 같이 관리되지 않는 리소스들을 인식하지 못합니다.

다음은 문제가 발생할 가능성이 있는 StreamReader의 사용 예 입니다.

하지만 위의 코드는 ReadToEnd() 메소드를 수행하는 과정에서 오류가 발생할 가능성이 있습니다. 이때에 Close()가 호출되지 않고 반환될 가능성이 있습니다. 이러한 문제를 대응하기 위해 흔히들 try-catch-finally 구문을 사용해 볼 수 있습니다.

위의 코드는 ReadToEnd() 메소드를 수행중에 예외가 발생되면 발생한 예외의 내용을 로그에 출력하게 됩니다. 그리고 예외가 발생하거나 성공하거나 상관없이 Close() 메소드를 정상적으로 수행하게 됩니다. 하지만 이러한 복잡한 과정 없이 Close() 호출을 알아서 호출해주는 구문이 있습니다. 위와 같은 방법이 아닌 using 블록을 사용하여 다음과 같이 처리할 수 있습니다.

위의 코드에서 우선 눈에 띄는 것은 using 키워드를 사용했다는 점과 Close() 를 명시적으로 호출하지 않고 있다는 부분입니다. 이제 IDisposable에 대해 이야기를 해볼 때인 것 같습니다.

스크린샷 2016-08-11 오후 6.22.38

SteamReader는 TextReader의 자식 클래스입니다. 그리고 이 TextReader는 IDisposable 인터페이스를 구현하고 있습니다. 스크린샷 2016-08-11 오후 6.25.08

이 IDisposable 인터페이스는 Dispose() 메소드 하나만을 가지고 있네요. 이 IDisposable 인터페이스를 구현한 클래스는 Dispose() 클래스를 구현해야 하며 여기서 자신의 메모리 할당 내역을 정리해야 합니다. 위에서 보여준 예제에서 보여지는 StreamReader 역시 Dispose() 클래스를 구현하고 있으며 여기서 리소스를 정리하는 적절한 처리가 되어있을 것입니다.

이제 위의 코드는 IDisposable 인터페이스를 구현하고 있는 클래스를 인스턴스화 하여 사용하며 using 블록을 나가는순간 (심지어 오류가 발생하더라도) Dispose() 가 호출되어 사용한 리소스가 자동으로 정리됩니다.

그렇다면 using 블록 내부에서 발생한 예외는 어떻게 처리할 수 있을까요? 다음과 같은 방법으로 처리할 수 있습니다.

using 바깥쪽에 try-catch 문을 사용해도 using 블록을 빠져나갈 때 Dispose() 가 호출됩니다.

참고 : https://msdn.microsoft.com/ko-kr/library/system.idisposable(v=vs.110).aspx

Navier-Stokes 방정식

유체방정식인 Navier-Stokes 방정식을 푸는 것이 게임에 구현된 것은 거의 못 본것 같습니다. 아직까지는 단순한 노이즈 기반의 식을 쓰는 것 정도로 충분한것 같고요. 저는 지금까지는 이런 물리식을 게임에 쓰는일은 전혀 안해봤네요. 논문상으로는 파티클을 생성시켜서 물결을 일으키는 수준까지는 있습니다만 대부분 이펙트로 처리하는 것 같습니다.

참고로 Navier-Stokes방정식을 영화 CG쪽에서는 Newtonian 방법이나 Lagrangian 방법으로 나뉘는데 Newtonian은 물의 공간을 표현하는데 좋고 (일반적인 프로그램에서 지원하는 것 같더군요) Lagrangian은 물뿌리는 것에 좋습니다. 점성도 표현 가능하죠. (Realflow라는 프로그램이 많이 쓰입니다.) 다만 실시간이 절대 아니고요 시간이 아주 오래오래 걸려요.

게임쪽에 물리가 들어오기엔 좀 어려워보이는게 아무래도 해외 진출을 해야하는 형편이다보니 저사양을 고려하지 않을수 없어서 물리를 넣기에는 좀 어려울것 같아요.

결국 서버에서 물리를 자세히 하는 것은 오버라고 보고요 잘못된 위치를 보정해주는 정도만 해도 될것 같네요. 이런 일은 클라이언트 프로그래머가 가능한 업무 범위가 아닌가 생각됩니다.

Graveyard Keeper: How the graphics effects are made

Hello! I’m a lead programmer of the game “Graveyard Keeper”. I’d like to share with you some techniques and tricks that we used to make our game look as you see it from the GIF below.

We are very passionate about graphics in our games. That’s why we put so much time and effort into different effects and other stuff that makes our pixel art as attractive as possible. Maybe you will find here something helpful for your work.

First I want to say some words about big parts that compose the visual part of our game:

  • Dynamic ambient light is just change of illumination depending on the time of the day.
  • LUT color-correction is responsible for the change of color shades depending (again) on the time of the day (or world zone).
  • Dynamic light sources — torches, ovens, lamps.
  • Normal maps — make objects look like they have a real volume, especially when light sources move.
  • The math of light 3D distribution — a light source centered on the screen should illuminate a higher object properly and should not illuminate an object below (turned to the camera with its dark side).
  • Shadows are made with sprites, they turn and react to light source positions.
  • Object altitude simulation — for the fog to be displayed correctly.
  • Other stuff: rain, wind, animations (including shader animation of leaves and grass) and so on.

Let’s talk about those in more details now.

Dynamic ambient light

Nothing special here. Darker at night, lighter in the daytime. The light’s color set with a gradient. By nightfall a light source not only becomes darker but gets blue tint.

It looks like this:

LUT color correction


LUT (Look-up table) is a table of color change. Roughly speaking it’s a three-dimensional  RGB array where each element (a) corresponds to a color with its coordinates as RGB values; (b) contains the color value that the color associated with the element should be changed to. So if there is a red point at coordinates  (1, 1, 1), it means that all the white color from the picture will be replaced with red. But if there is white color at the same coordinates (R=1, G=1, B=1), the change doesn’t happen. So LUT by default has coordinates associated with a particular color. I mean that point with coordinates (0.4, 0.5, 0.8) is associated with color (R=0.4, G=0.5, B=0.8).

It should also be pointed here that for convenience that 3D texture is represented as two-dimensional. That’s how for example default LUT (that doesn’t change color) looks:

Easy to make. Easy to use. Works really fast.

It is very easy to set up — you give an artist a picture from your game and say: “Make it look like it’s evening”. Then you apply all color layers plus the default LUT. Congratulations! You get an Evening LUT.

Our artist was actually very passionate about it. He created 10 different LUTs for different time of day (night, twilight, evening and so on…) That’s how the final set of LUTs looks:

As a result one location may look different at different time of day:

The picture also shows how the intensity of the light sprites changes depending on the time of day.

Dynamic light sources and normal maps

We use regular light sources, the default Unity ones. Also, every sprite has its own normal map. This helps to feel the volume.

These normals are pretty easy to draw. An artist roughly paints light on 4 sides with a brush:

And then we merge them with a script in a normal map:

If you are looking for a shader (or software) that can do that, pay attention to Sprite Lamp.

3D light simulation

This is where things start to be a bit more complicated. You can’t just light the sprites. It’s very important whether a sprite is “behind” a light source or “in front of” it.

Take a look at this picture.

These two trees are at the same distance from the light source but the back one is illuminated while the front one is not (because the camera faces its dark side).

I solved this problem very easily. There is a shader that calculates the distance between a light source and a sprite on the vertical axis. If it’s positive (the light source is in front of the sprite), we illuminate the sprite like we always do, but if it’s negative (the sprite is blocking the light source), then the intensity of lighting is fading depending on the distance at a very quick rate. There is a rate, not just “not to illuminate”. So if the light source behind the sprite is moving, the sprite is blackening gradually, not at once. Yet it’s still very fast.

Shadows

Shadows are made with sprites rotating around a point. I tried to add a skew there, but it turned out to be unnecessary.

Every object may have a maximum of 4 shadows. The shade from the sun and the additional three from dynamic light sources. So the image below shows this concept:

The problem “how to find the closest 3 light sources and to calculate the distance and an angle was solved with a script running in the Update() loop.

Yes, it’s not the quickest way considering how much math is involved. If I programmed it today, I would use that modern Unity Jobs System. But when I did it there was no such thing so I had to optimize regular scripts we had.

The most important thing here is that I did the sprite rotation not modifying the transform but inside a vertex shader. So the rotation isn’t involved here. You just put a parameter to a sprite (I used the color channel for that, all the shadows are black anyway), while the shader is responsible for sprite rotations. It turns out to be quicker — you don’t have to use Unity geometry.

There is a minus to this approach. The shadows are to be adjusted (and sometimes drawn) separately for each object. Yet actually, we used about ten different more or less universal sprites (thin, thick, oval etc.)

The next disadvantage is that it’s difficult to make a shadow for an object that is stretched along one axis. For instance, look at the fence shadow:

Not ideal. That’s how it looks if you make a fence sprite translucent:

It should be noted here, by the way, that the sprite is highly distorted vertically (the shadow sprite original looks like a circle). That’s why its rotation looks like not just a simple rotation but also like a distortion.

The fog and the altitude simulation


There is also fog in the game. It looks like this (the regular version above and and an extreme 100% fog to demonstrate the effect).

As you see, the tops of houses and trees are seen from the fog. In fact, this effect is really easy to make. The fog consists of a great deal of horizontal clouds spread across all the picture. As a result the upper part of all the sprites is covered with a fewer amount of fog sprites:

The wind

The wind in a pixel art game is a completely different story. There are not many options here. To animate manually (it’s not possible considering how much art we have) or to make a deforming shader, but then you’ll have to deal with some ugly distortions. You can also don’t do any animation, but then the picture will look static and lifeless.

We chose the deforming shader. It looks like that:

It’s pretty obvious what’s happening here if we apply the shader to the chequered texture:

It should also be pointed here that we do not animate the whole crown of a tree but some particular leaves:

There are also an animation of a wheat field shake and things are pretty simple here too. The vertex shader changes the shape of the x-coordinates taking y-coordinate into account. The highest point will be shaken the most intensely. The intention here is that the top should move while the root shouldn’t. Plus the phase of shaking varies according to the x/y coordinates to make different sprites move separately.

This shader is also used to create a swinging effect when a player goes through wheat or grass.

I think that’s all for now. I haven’t spoken about scene construction and about its geometry, because there is a lot to speak about in a new entry. Beyond that I’ve spoken about all the main solutions that we applied developing our game.

유니티에서 가비지 컬렉션 최적화 하기 – 번역글 공유

안녕하세요. 유니티에서 가비지 컬렉션에 대한 글을 번역한 것 공유합니다. 
원문 링크 – https://unity3d.com/kr/learn/tutorials/topics/performance-optimization/optimizing-garbage-collection-unity-games?playlist=44069 –

전체 원문 내용이 많아서 6개의 글로 나눠서 포스팅했습니다.
유니티에서 메모리를 관리하는 방법과 가비지 컬렉터(Garbage Colletor)의 동작 방식 및 주의할 내용을 정리하기 좋은글이니 참고하세요~

가비지 컬렉션 개요 – http://bit.ly/optimizinggc1
가비지 컬렉션과 동반되는 문제 – http://bit.ly/optimizinggc2
가비지 컬렉션에 의한 피해 줄이기 – http://bit.ly/optimizinggc3
불필요한 힙 할당을 발생시키는 주요 원인1 – http://bit.ly/optimizinggc4
불필요한 힙 할당을 발생시키는 주요 원인2 – http://bit.ly/optimizinggc5
가비지 컬렉션의 영향을 최소화하기 위한 코드의 구조화 – http://bit.ly/optimizinggc6

블로그 방문 많이 해주시고, 배너도 많이 눌러주세요 🙂
감사합니다.

서버 프로그래밍 공부에 대한 생각

어떤 분께서 클라이언트신데 서버를 어떻게 배워야 할지 모르겠다고 쓰신 글을 보고 작성해 봅니다.C++ 윈도우 서버를 처음부터 만든다면 다음과 같은 내용을 공부해야 할것으로 생각됩니다.지극히 주관적인 생각이니까 참고만 부탁드려요.

1. 준비학습
1-1. win socket (tcp/udp)
1-2. iocp
1-3. overlapped io
1-4. 멀티스레드
1-5. 메모리/오브젝트 풀
1-6. 3,5를 활용한 브로드캐스팅
1-0. 별도로 간단히 SQL의 사용법
이 밖에도 TCP의 전송 및 혼잡제어 부분은 udp를 만들때 응용되기도 하고, 전송 중 예외처리를 위해 중요하다고 생각합니다.보통 이쯤 될때까지 혼자 만들다보면 어쩐지 udp를 슬슬 버리게 됩니다. 이핑계 저핑계 대면서요 ㅎ중국에서 udp를 쓰면 다 털린다던가…암호화 알고리즘에 대해 나와야 할것같은데? 라고 생각하시는 분도 계시겠지만 공부하며 혼자 하다보면 저것도 벅차요 ㅋ디비는 살짝 논외로 쳤는데 결국은 필요해집니다. 레디스라거나 하는걸 추가로 학습하면 좋을듯!

공부가 끝난 뒤 개발해야 할 내용은
2. 모듈 개발
2-1. 로깅시스템
2-2. 메모리/오브젝트 풀
2-3. 스레드 풀 (TLS랑 전역적인거 둘 다 되는걸로)
2-4. iocp 모듈 (프로엑터 패턴. tcp, udp)
2-5. 패킷 프로세싱 (전송 및 혼잡제어)
2-6. 테스트로 사용할 서버/클라
2-7. 우아한 접속/종료 및 예외처리
2-8. 스트레스 테스트 툴
이렇게 만들어보면 조금 감이 올 것이고 그 다음에 해야 할 일은 모듈화 해서 라이브러리로 만드는 것이겠죠.그런데 라이브러리화가 끝나면 ‘자 이제 시작이야~(내꿈을) 내꿈을 위한여행~(피카츄)’ 가 시작됩니다.바로 서버 구조란 무엇인가… 에 대해 고민해야 할 차례거든요.

3. 서버 구조 설계
3-1. 한대의 서버가 클라이언트들을 받아들이는 가장 단순한 구조 (유저가 많아지면 서버를 나눔)
3-2. 서버가 많아짐에 따라 접속/인증만 처리하는 로비서버 + 여러대의 게임서버 구조
3-3. 인증을 만들다보면 필요한 페킷 암호화 및 인증키 처리 (여기서 이걸 우겨넣다가 라이브러리를 재설계 하는 일도;;)
3-4. 그런데 요즘 유저들은 서버 자체가 나뉘면 싫어하지 않을까요? 체널링에 대한 고민
3-5. 체널링에 따른 인증 이동기능
3-6. 서버간 통신 및 브로드캐스팅 (ex 메이플의 메가폰. 운영자공지 등)
뭐 이정도 공부하고 이정도 만들면 되지 않을까… 그렇게 생각하고 있습니다.그런데 과연… 자신이 서버 프로그래머로 취직할게 아니거나, 컨텐츠 서버 프로그래머로 취직하려고 해도 이런 내용들이 전부 필요할까요? 저는 그것에 대해서는 상당히 회의적입니다. 간단히 클라이언트만 봐도 요즘 DirectX12 배우시는 학생분들 있으신가요? 여기서 만약 부스트 asio가 등장한다고 해도 대분류 1번 준비학습 정도만 생략되는 수준입니다.뿐만 아니라 아무리 asio나 부스트가 좋다고 해도 사실 1번에서 누군가 이끌어주지 않으면 많은 시행착오를 겪게됩니다.어떻게 만들어야 쓰기 편하고 표준적인지 알기 어렵기 때문이죠.DirectX 처음 배울때 3D MAX 파싱해서 물체 띄우는 수준으로 게임엔진을 만들 수 없는것과 같습니다.

4. 권장 사항이때 제가 권할 수 있는 방법은 일단 오픈소스나 상용엔진을 학습해보는 것입니다.여기서 서버엔진이란 무엇이며, 어떻게 쓰는것이 표준적이고 효율적인 설계인지를 엿볼 수 있습니다.그 뒤에 자신이 무엇을 하고싶은지 고민해보세요.컨텐츠를 만드시고 싶다면 서버엔진을 배우시고 잘 활용하는 쪽으로 학습하시는걸 추천합니다.그러나 나는 ‘서버 엔진 프로그래머가 되겠어!’라고 결심하셨다면 위의 것들을 하나씩 정복해 나가시면 될 것 같습니다 ㅎ

5. 핵심?프로그래머로 일하는데 있어서 서버를 지향하시는 분들께서는 이정도면 되지 않을까.. 그렇게 생각합니다.라우터라던가 L4스위치 등 하드웨어에 대한 지식이 풍부하면 도움은 되겠지만 프로그래밍 이외의 범위임으로 일단 생략…우리 마음대로 만들겠다! 라며 상용 엔진을 사용하지 않는 회사들도 재야의 고수들이 기본기 있고 범용적인 라이브러리드ㄹ을 자체적으로 개발해서 사용하고 있기 때문에 무료/상용 엔진으로 기본기와 구조를 익혀도 좋습니다.넷트워크에서 중요한 신뢰성등은 사실 지식도 필요하지만 많은 노하우가 중요한 만큼 상용엔진을쓰는것이 안정적이고 편안하고 안락한 퇴근을 보장하죠… ㅇ<-<세롭게 공부하면서 개발해 보는것도 중요하지만 상용 엔진을 권하는 이유는 이밖에도 많습니다.요즘 트렌드는 엔진을 처음부터 개발하기 보다는 그간 만들어진 바퀴들도 얼마나 멋진것을 만들어내느냐에 있으니까요!

두서없고 주관적인 글 읽어주셔서 감사합니다. 위에 살짝 요약해뒀고요. 질문이나 부드러운 의견은 언제나 환영합니다!

Pixel Perfect sprites in Unity

유니티 4.3에서, 유니티에서 제공하는 2D 툴로 작업을 한적이 있다면 다음과 같은 현상을 보았을 것이다.

위 그림은 1024×768 크기의 물결 스프라이트를 씬에 올려 놓은 경우다. 하지만 왼쪽 상단에 위치한 게임 해상도는 1024×768임에도 불구하고 게임화면과 물결 스프라이트이미지가 딱 맞지 않는 현상이 발생한다.
이를 해결하기 위해서는 Camera 옵션중 orthographic의 Size를 변경해주면 된다.
Camera Size는 다음과 같이 계산하면 된다 : Camera Size = (GameTargetHeight / 2) / PixelsToUnitys
Pixels To Unity은 Default로 100으로 되어있다.
위와 같은 경우는, 게임 해상도가 1024×768이기 때문에, CameraSize는 3.84가 될 것이다 :(768 / 2) / 100 = 3.84

Camera Size를 수정하면 다음과 같이 물결 스프라이트가 게임화면에 딱 들어맞게 된다.

C# Extensions Method

C# 3.0부터 추가된 기능이다. 이 기능을 사용하게 되면 기존 형식을 확장, 수정하지 않고도 메소드를 추가할 수 있다. Microsoft .NET 문서 에선 확장메서드를 호출하나 Extensions Method 나 차이가 없다고 서술하고 있다.

확장명 메서드를 호출하는 것과 형식에 실제로 정의된 메서드를 호출하는 데는 명백한 차이가 없습니다.

사용용도

이 기능은 어느 클래스에나 사용할 수 있기 때문에 특정한 범위에서 사용하는 것이 좋다. 일반적으로 봉인된(sealed) 클래스에 필요한 기능을 추가할 수 없을 때가 가장 적합한 사용용도 인 거 같다.

사용방법

사용방법은 생각보다 간단하다. String 클래스를 예로 들어보겠다.

namespace ExtensionMethods
{
    public static class MyExtensions
    {
        public static int WordCount(this String str)
        {
            return str.Split(new char[] { ' ', '.', '?' }, 
                             StringSplitOptions.RemoveEmptyEntries).Length;
        }
    }   
}

Extensions Method의 생성 조건이 몇 가지 있다.

  • 클래스는 static으로 선언해준다. ( 자동으로 함수도 static )
  • 매개변수의 첫 번째는 this와 해당 메소드가 들어갈 타입을 적어준다.

예제에 맞게 적고 string 변수를 확인해보면 WorldCount 라는 함수가 보일 것이다.

기타 설명

더 자세한건 Microsoft .NET 문서 를 참고하길 바란다.


Unity + Extensions Method

이 기능을 유니티에 가져와 적용해본다면 기존에 불필요하게 했던 작업을 함수 하나로 보기 좋게 정리할 수 있게 된다.

기존에 유니티 기능으로만 사용했을 때 불편한 작업이 있었다.

  • transform.position의 x값만 바꾸고 싶을 때
  • Sprite의 Color중 Alpha 값만 바꾸고 싶을 때
  • 배열에서 랜덤을 뽑고 싶을 때 ( 물론 이건 C#이지만..ㅋ )

등등 상황에 따라 더 있겠지만 저런 상황에 Extensions Method 기능을 사용하면 매우 편리하다.

첫 번째 경우를 가지고 설명하자면 Unity의 Transform 클래스에 Extensions Method를 추가하면 좀 더 코드가 깔끔해지고 보기 편해진다.

TransformExtensions.cs

using UnityEngine;

public static class TransformExtensions
{
    public static void SetPositionX(this Transform transform, float x)
    {
        var newPosition = new Vector3(x, transform.position.y, transform.position.z);
        transform.position = newPosition;
    }
}

Test.cs

using UnityEngine;

public class Test : MonoBehaviour
{
    private void Start()
    {
        // 이전의 X값 변경 방법
        transform.position = Vector3.zero;
        Debug.Log("[Basic] Prev: " + transform.position);
        transform.position = new Vector3(20, transform.position.y, transform.position.z);
        Debug.Log("[Basic] Curr: " + transform.position);

        // Extensions Method
        transform.position = Vector3.zero;
        Debug.Log("[Extensions] Prev: " + transform.position);
        transform.SetPositionX(20);
        Debug.Log("[Extensions] Curr: " + transform.position);
    }
}

마무리

Extensions Method는 클래스의 수정이 불가능한 부분들에 의한 반복적인 일들을 줄여줄 수 있는 좋은 기능인 것 같다. 유니티로 개발을 하면서 어쩔 수 없이 반복적이고 불필요한 코드들이 늘어난다면 이 기능을 이용해 리팩토링하는 것도 좋을 것 같다.

유니티 작업에 대한 50 팁 (모범 사례) 50 Tips for Working with Unity (Best Practices)

출처: http://seungngil.tistory.com/entry/유니티-작업에-대한-50-팁-모범-사례-50-Tips-for-Working-with-Unity-Best-Practices [To be a programmer…]

팁들에 대해서

이 팁들은 모든 프로젝트에 적용 가능하지는 않습니다.
  • 이것들은 3~20명의 인원으로 구성된 작은팀의 프로젝트 경험을 기반으로 합니다.
  • 구조, 재사용성, 명확성, 기타 등등 의 비용은 팀 크기와 프로젝트의 크기에 따라 비용 지불 여부가 결정 됩니다.
  • 많은 팁들은 취향의 문제 입니다.
    (하지만 여기에 나온 여러 팁들은 우열을 가리기 어려울 정도로 좋은 기술들 입니다.)
  • 몇개의 팁은 공식 Unity 개발에 위배 되는 것들입니다. 예를 들면, 몇개의 특수한 인스턴스를 위한 프리팹의 사용은 매우 Unity 에서 싫어하는 방식으로, 비용 또한 상당히 높습니다(이렇게 라도 prefab 들을 사용하는게 나을 때도 있습니다).  그러나 나는 이런 팁들이 미친 짓 같아 보여도 가끔 좋은 결과를 가지고 오는 경우도 보곤 합니다.

Process

1. 자산을 여러 버전으로 나누지 말라. 항상 모든 자산은 오직 한 버전으로 있어야 한다. 만약 절대경로로 프리팹, 씬, 또는 메쉬 등을 분기 하여 만드는 경우 옳은 버전이다. “잘못된” 분기는 임시적 이름으로, 예를들면 밑줄 두개를 접두로 붙이는 경우다. __MainScene_Backup. 프리팹을 분기 하는 경우 분명하게 이름을 명시하는게 안전하게 생성하는 방법이다. (Prefabs 섹션을 참고)
원문
2. 버전 컨트롤을 사용할 경우 각 팀 구성원들은 테스트를 위해 체크 아웃한 프로젝트의 두번째 복사본이 있어야 한다. 변경 후, 두번째 복사본은 clean copy 및 update 를 하고 test 를 해야 한다. 모든 사람들은 clean copy 상태에서 변경을 해야 합니다.
원문
3. 레벨 수정을 위한 외부 레벨 툴을 사용하는걸 고려하라. Unity 는 완벽한 레벨 에디터가 아니다. 예로, 우리는 3D tile 기반의 게임을 위해 레벨 빌드를 TuDee 를 사용하여 만들었으며, 우리는 tile 친화적인 툴을 통해 도움을 받았다 (그리드 가 붙는, 그리고 90 도 로 여러번 회전, 2d 뷰, 빠른 선택). XML 파일을 통한 prefab 초기화는 간단합니다. Guerrilla Tool Development 에 자세한 아이디어가 있습니다.
원문
4. 레벨 저장을 scene 대신 XML 으로 하는걸 고려하라. 이건 훌륭한 기술이다:
  • 이렇게 만들면 각각의 scene 을 다시 만드는게 불필요해 집니다.
  • 이렇게 만들면 보다 빠르게 로딩 합니다(대부분의 객체가 scene 에서 공유되는 경우)
  • 이렇게 만들면 scene 을 합치는게 쉬워집니다.(Unity 의 새로운 text 기반 scene 은 너무 많은 데이터를 포함하고 있어 합치는게 비현실적으로 보입니다)
  • 이렇게 만들면 데이터 레벨 수준에서 관리를 할 수 있습니다.
당신은 여전히 Unity 를 레벨 에디터 로 사용 할 수 있습니다(필요성을 못 느낄경우). 네가 데이터 , 에디터와 레벨 로드 를 실시간으로 처리, 에디터로 부터 레벨 저장을 해야 할 경우 몇몇의 코드는 직렬화 와 역직렬화를 필요로 하게 된다. 너는 아마 또한 객체간 참조를 유지하기 위해 Unity 의 id system 을 모방 해야 할 것입니다.
원문
5. 일반적인 커스텀 inspector 코드를 작성하는 걸 고려하라. 커스텀 inspector 를 작성하는건 매우 간단하나, Unity 의 시스템은 많은 단점을 가지고 있다.
  • 상속을 활용한 방식을 지원하지 않습니다.
  • 당신이 정의 하는 inspector 컴포넌트는 필드 타입 수준에서 구성이 안되며, 오로지 클래스 타입 레벨만 지원합니다. 예 로, 만약 모든 게임 오브젝트가 SomeCoolType 필드타입 이고, inspector 에서 다르게 렌더링 하려 할 경우,당신은 모든 클래스들에 대해서 inspector 를 작성해야 합니다.

당신은 기본적으로 inspector 시스템을 다시 구현함으로써 이러한 문제를 해결 할 수 있습니다. reflection의 몇가지 기술을 사용하여 해결할 수 있으며, 자세한 방법은 문서의 끝에 나와 있습니다.

원문

Scene Organisation

6. scene 폴더를 빈 게임 오브젝트 의 이름으로 사용하라. 당신의 scene 에서 찾고자 하는 오브젝트를 쉽게 찾을수 있도록 구성 할 수 있습니다.
원문
7. 관리하는 prefab 과 폴더 (빈 게임 오브젝트) 를 0 0 0 에 넣습니다. 만약 위치를 명시하지 않은 채 오브젝트의 위치를 사용 하면, 아마 원점에 있을겁니다. 그 방법은, 실행 중 로컬과 월드 공간간의 문제를 줄여줄 수 있으며, 코드는 일반적으로 간단합니다.
원본
8. GUI 컴포넌트의 offset 사용을 최소화 하라. Offset 은 항상 자신의 부모 Component 에서 레이아웃 Component 를 사용해야 합니다. 그들은 조부모(부모의부모)의 위치에 의존해서는 안됩니다. Offset 을 올바르게 표시하기 위해서는 서로를 취소 할 수 없습니다 . 이런 일을 방지하기 위해 기본적으로:
부모 컨테이너가 임의의 위치로  (100, -50) 이고, 자식의 위치가  (10, 10) 이기를 희망 할 경우, 위치 정의를 (90, 60) [relative to parent] 으로 하면 된다.
이 에러는 컨테이너가 invisible 상태일때 공통으로 발생하며, 또는 시각적 표현이 없는 경우에 해당합니다.
원문
9. 당신의 월드 바닥을 y = 0 으로 하라. 이와 같이 하면 오브젝트를 바닥에 생성하는게 쉬워지며, 게임 로직, AI, 물리 등을 2D 공간(이게 적절할 경우)으로 월드에 적용할 수 있습니다.
원문
10. 모든 scene 을 게임 실행 가능하게 만듭니다. 이건 대폭적으로 테스트 시간을 줄일 수 있습니다. 모든 scene 을 실행 가능하게 만들려면 두가지 고려사항이 있습니다:
첫번째로, 이전에 로드해야 하는 scene 의 데이터가 필요로 하는데 사용 할 수 없는 경우, 임시 데이터 를 제공 할 수 있도록 해야 합니다.
두번째로, 생성한 오브젝트는 다음의 scene 과 scene 을 불러오는 사이에 계속 되어야 한다.
myObject = FindMyObjectInScene();
 
if (myObjet == null)
{
   myObject = SpawnMyObject();
}
원문

Art

11. 케릭터와 서있는 오브젝트는 pivot 기반이여 하며, center 중심이어선 안된다 . 이런식 으로 만들면 보다 쉽게 케릭터와 오브젝트를 바닥에 올려놓을 수 있습니다 . 이것은 또한 게임 로직, AI 와 물리 등이 필요로 하는 경우에 3D 환경에서 2D 같이 제작 할 경우 쉽게 만들 수 있습니다.
원문
12. 제작하는 모든 메시의 바라보는 방향을 일치 합니다(+Z 또는 -Z). 케릭터와 다른 오브젝트들의 메시는 바라보는 방향이 다르게 적용이 됩니다. 바라보는 방향을 통일 시키면 많은 알고리즘들을 쉽게 적용 할 수 있습니다.
원문
13. 시작시 스케일의 규모를 정하도록 한다. 만든 작업물을 임포트 할때 스케일 크기를 1로 하게 되면 그것의 트랜스폼 스케일은 1 1 1 이 된다. 스케일의 비교를 쉽게 하기 위해서 참조 오브젝트(Unity 상자)를 사용 합니다. 게임에 적합한 Unity 단위 비율을 선택하고, 정한것에 충실하도록 합니다.
원문
14. GUI 컴포넌트와 파티클을 수동으로 생성 해야 할 경우 2개의 삼각형으로 된 평면을 사용 합니다. 평면을 Z+ 방향으로 하는게 빌보드와 GUI 를 만드는데 쉽게 합니다.
원문
15. 테스트 작업물 만들기 및 사용
  • 스카이 박스들을 위한 사각형 표기.
  • 그리드(격자).
  • shader 테스트를 위한 다양한 평면 색상: 흰색, 검은색, 50% 회색, 적색, 녹색, 청색, 마젠타, 노랑, 청록색.
  • shader 테스트를 위한 그라데이션: 검은색 에서 흰색, 적색에서 녹색, 적색에서 청색, 녹색에서 청색.
  • 검은색과 흰색으로 된 체커보드(체커판).
  • 부드럽고 거친 노멀맵.
  • 빠른 테스트 scene 설정을 위한 라이팅 을 갖춤(프리팹).
원문

Prefabs

16. 모든 것에 프리팹을 사용하도록 한다.   당신의 scene 에 게임 오브젝트만 있는 경우에는 프리팹이 폴더에 있을 필요는 없습니다. 심지어 한번만 사용 하더라도 고유 객체를 프리팹으로 해야합니다. scene 을 바꾸지 않는 경우 만든것을 수정하는걸 편하게 작업할 수 있습니다. (또 다른 장점은 EZGUI 를 사용하는 경우 신뢰 할만한 스프라이트 아틀라스 를 구축할 수 있습니다.).
원문
17. 특수화된 프리팹은 사용해도 좋지만; 특수화 된 인스턴스는 사용하지 말라. 만약 다신이 두개의 적 타입을 가지고 있는 경우, 그리고 그것들이 프로퍼티만 다른 경우, 속성에 대해 별도의 프리팹을 만들고, 그것을 링크 합니다. 이렇게 하는게 가능한 경우는
  • 한 곳에서 각각의 타입을 변경 할 경우
  • scene 을 변경하지 않고 변경 할 경우
당신이 너무 많은 적 타입을 가지고 있을지라도, 특수화는 여전히 에디터의 인스턴스를 만들어서는 안됩니다. 한가지 대안책은 절차를 따르거나 또는 모든 적들을 기준의 파일 / 프리팹을 사용하는 겁니다. 적들을 구분하는걸 사용하여 하나의 적을 쓰러트리거나, 적의 위치 또는 플레이어 진행 기반의 알고리즘을 사용합니다.
원문
18. 프리팹과 프리팹의 링크는 되나; 인스턴스와 인스턴스 간의 링크는 안된다. scene 에 프리팹을 끌어놓을 때 프리팹의 연결이 유지 됩니다; 인스턴스에는 링크가 없습니다. 프리팹을 연결할 때마다 scene 의 설정을 줄여 주는게 가능해지며, scene 을 변경할 경우도 줄여줄 수 있습니다.
원문
19. 가능하다면, 인스턴스간의 연결 설정은 자동으로 하라. 만약 당신이 인스턴스간의 링크를 필요로 한다면, 프로그래밍적으로 링크를 설정 합니다. 예를 들어, Player 프리팹 자체를GameManager 을 시작함과 동시에 등록 할 수 있으며, 또는 GameManager 가 시작 할때 Player 프리팹 인스턴스를 찾을 수 있습니다.
만약 당신이 프리팹에 다른 스크립트를 추가 하길 원한다면 루트에 다른 메시를 넣어선 안됩니다. 당신이 메시로 부터 프리팹을 만들려고 한다면, 첫번째 메시의 부모는 비어있는 게임 오브젝트 이어야 하며, 그것은 루트 이어야 합니다. 스크립트를 루트에 넣게 되면, 메시 노드가 아니게 됩니다. 그 방법은 당신이 inspector 에서 설정한 모든 값을 잃어버릴일 없이 다른 메쉬와 메시를 대체하기 훨씬 쉬울 것 입니다.
하위 프리팹의 대안으로 연결된 프리팹을 사용합니다. Unity 는 하위 프리팹을 허용하지 않으며, 하위 프리팹 간의 관계가 명확하지 않기 때문에 팀에서 작업 할 때 기존의 타사 솔루션은 위험 할 수 있습니다.
원문
20. 분기 프리팹에 대해서 안전한 절차를 사용하도록 하라. 설명은 Player 프리팹 예제를 통해서 합니다.
프리팹을 바꾸는거에 대해 많은 문제에 대한 절차는:
  1. 복제된 Player 프리팹이 있습니다.
  2. 복제된 거에 대한 이름을 __Player_Backup 로 변경합니다.
  3. Player prefab 으로 생성한걸 바꿉니다.
  4. 작업이 진행 될 경우 __Player_Backup 를 지웁니다
복제후 Player_New 으로 이름을 바꺼선 안되며, 생성된걸 바꺼선 안됩니다!
일부는 상황이 더 복잡합니다. 예를 들어, 특정 변화는 두 사람을 포함 할 수 있으며, 두사람이 위의 과정을 따라하면서 작업을 완료하면 작업한 scene 을 망가질 수 있습니다. If it is quick enough, still follow the process above 그래도 여전히 필요로 하는경우, 위의 절차를 따르십시오. 바꾸는데 시간이 오래 걸릴경우, 다음의 절차를 따라야 할 수 있습니다:
  1. 사람 1:
    1. Player 프리팹을 복제 합니다.
    2. 이름을 __Player_WithNewFeature 나 __Player_ForPerson2 로 바꿉니다.
    3. 복제된 걸로 변경을 하고, 커밋을 하여 [사람 2] 에게 제공합니다.
  2. 사람 2:
    1. 새로운 프리팹으로 변경 생성 합니다.
    2. Player 프리팹을 복제하고, __Player_Backup 이라고 부릅니다.
    3. __Player_WithNewFeature 인스턴스를 scene 으로 드래그 합니다.
    4. 오리지날 Player 프리팹을 인스턴스에 드래그 합니다.
    5. 작업이 진행 될 경우 __Player_Backup 와 __Player_WithNewFeature 를 지웁니다.
원문

Extensions and MonoBehaviourBase

21. 기본 mono behaviour 을 확장하고, 당신의 컴포넌트를 그것으로부터 모두 파생하라. 
이렇게 하면 몇가지 일반적인 기능을 구현 할 수 있으며, 이러한 유형의 호출에 안전하고 복잡한 호출이 가능해 집니다.(예로 무작위 호출)
원문
22. Invoke 를 위해 안전한 메서드를 정의 하며, StartCoroutine 과 Instantiate 가 있다.
Task delegate 를 정의하고, 문자열 이름에 의존하지 않는 방법을 정의 하는데 사용합니다.
예를 들면:
public void Invoke(Task task, float time)
{
   Invoke(task.Method.Name, time);
}
원문
23. 공유 인터페이스를 사용하여 컴포넌트를 함께 작동하도록 확장을 사용 합니다. 가끔 특정 인터페이스의 구현된 컴포넌트를 얻어오는데 편리하거나, 앞의 언급한 컴포넌트를 가지고 오브젝트를 찾는데 편합니다.
아래에 구현된 내용은 typeof 대신에 generic 버전의 함수들로 사용되고 있습니다. generic 버전은 인터페이스와 함께 작동하지 않지만, typeof 는 가능합니다. 아래의 방법은 generic 메소드를 이용하여 래핑합니다.
//Defined in the common base class for all mono behaviours
public I GetInterfaceComponent<I>() where I : class
{
   return GetComponent(typeof(I)) as I;
}
 
public static List<I> FindObjectsOfInterface<I>() where I : class
{
   MonoBehaviour[] monoBehaviours = FindObjectsOfType<MonoBehaviour>();
   List<I> list = new List<I>();
 
   foreach(MonoBehaviour behaviour in monoBehaviours)
   {
      I component = behaviour.GetComponent(typeof(I)) as I;
 
      if(component != null)
      {
         list.Add(component);
      }
   }
 
   return list;
}
원문
24. 구문보다 편리하게 사용하기 위해 확장을 사용합니다. 예를 들면:
public static class CSTransform 
{
   public static void SetX(this Transform transform, float x)
   {
      Vector3 newPosition = 
         new Vector3(x, transform.position.y, transform.position.z);
 
      transform.position = newPosition;
   }
   ...
}
원문
25. 방어적인 GetComponent 를 대안으로 사용 하라. Sometimes forcing component dependencies (through RequiredComponent) can be a pain. 때때로 강제적인 컴포넌트 의존(RequiredComponent 유발)은 고통이 될 수 있습니다. 예를들어, it makes it difficult to change components in the inspector 그것은 어려운 inspector 의 구성요소를 변경 할 수 있습니다(base type 이 같은 경우). As an alternative, the following extension of GameObject can be used when a component is required to print out an error message when it is not found. 대안으로, 확장된 GameObject 를 찾을때 컴포넌트가 발견되지 않은 경우 오류 메세지를 출력 하면 된다.
public static T GetSafeComponent<T>(this GameObject obj) where T : MonoBehaviour
{
   T component = obj.GetComponent<T>();
 
   if(component == null)
   {
      Debug.LogError("Expected to find component of type " 
         + typeof(T) + " but found none", obj);
   }
 
   return component;
}
원문

Idioms

26. 비슷한 일에 다른 해결책을 사용하지 마십시오. 대부분의 경우 일을 할때마다 하나 이상의 해결책이 있습니다. 이러한 경우, 프로젝트에 한가지 방법을 선택하고 진행 할 수 있습니다. 여기에 이유가 있습니다:
  • 몇가지 해결책이 함께 잘 작동하지 않습니다. 한가지 해결챌을 사용하면 다른 해결책에 적합하지 않으며 한 방향으로 디자인을 강요 합니다.
  • 몇가지 해결책을 사용하는게 어디로 가야 하는지 팀 멤버를 이해 시킵니다. 이것은 구조와 코드를 이해하기 쉽게 합니다. 실수를 하기 더 쉽도록 유도가 됩니다.
해결책 그룹들의 예시:
  • Coroutines vs. state machines.
  • 하위 프리팹들 vs. 연결된(링크) 프리팹들 vs. 전지 전능한 프리팹들.
  • 데이터 분리 전략.
  • 2D 게임에서 상태를 위해 스프라이트를 사용 하는 방법.
  • 프리팹 구조화.
  • Spawn 전략.
  • 개체를 찾을 수 있는 방법: 타입 vs. 이름 vs. 태그 vs. 레이어 vs. 레퍼런스(링크).
  • 그룹 개체들을 찾는 방법: 타입 vs. 이름 vs. 태그 vs. 레이어 vs. 레퍼런스(링크) 배열
  • 오브젝트의 그룹들 찾기 vs 자체 등록 (싱글톤 객체?)
  • 실행 순서 제어 (Unity 를 이용하여 실행 순서 제어 vs. yield 로직 vs. Awake / Start 와 Update / Late Update 의존 vs. 수동 메소드 vs. 모든 주문 아키텍쳐)
  • 개체 / 위치 / 타겟 의 선택과 인 게임의 마우스: 선택 관리자 vs 로컬 자체 관리
  • scene 변화와 데이터 간의 유지: PlayerPrefs 를 통해, 또는 새로운 scene 이 로드 될때 지워지지 않은 객체.
  • 애니메이션 결합 방법 (블렌딩, 더하거나 레이어링(계층관리)).
원문

Time

27. 쉽게 일시 중지 하기 위해 당신만의 Time class 를 유지 하라. Wrap Time.DeltaTime 와 Time.TimeSinceLevelLoad 은 계정 별 일시 중지와 시간 scale 이 가능합니다. 이것을 사용하는데는 훈련이 필요로 하지만, 많은 부분에 대해 쉽게 제작 가능하며, 특히 다른 Time 의 일을 실행 하기 편합니다. (예로 interface 애니메이션과 게임 애니메이션 등)
원문

Spawning Objects

28. 게임이 실행 될 때 생성되는 개체가 계층 구조를 더럽히게 하지 말라. Set their parents to a scene object to make it easier to find stuff when the game is running.
게임이 실행 중 일때 개체를 쉽게 찾을 수 있도록 scene 개체에 부모를 설정 합니다. 비어있는 게임 오브젝트를 사용하거나 behaviour 가 없는 싱글톤을 이용하여 만들면 코드에 접근하기 쉽습니다. 이 오브젝트를  DynamicObjects 라고 부릅니다.
원문

Class Design

29. 편의를 위해 싱글톤 을 사용하라. 다음 클래스는 자동으로 싱글톤 을 상속하는 클래스를 만들 것 입니다:
public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
   protected static T instance;
 
   /**
      Returns the instance of this singleton.
   */
   public static T Instance
   {
      get
      {
         if(instance == null)
         {
            instance = (T) FindObjectOfType(typeof(T));
 
            if (instance == null)
            {
               Debug.LogError("An instance of " + typeof(T) + 
                  " is needed in the scene, but there is none.");
            }
         }
 
         return instance;
      }
   }
}
싱글톤은 관리자에 유용하며, ParticleManager 또는 AudioManager 또는  GUIManager 등이 있습니다.
  • 고유한 프리팹의 인스턴스를 위한 싱글톤은 사용하는걸 피하는고 관리하지 않는게 좋습니다(Player 같은). 이 원칙을 준수하지 않으면 상속 계층 구조를 복잡하게 하며, 그리고 특정 유형의 변경을 힘들게 합니다. 오히려 GameManager 에서 참조를 유지하는게 좋습니다.(또는 다른 전지 전능한 클래스 ;-))
  • 종종 클래스 외부에서 사용되는 public 변수 와 메소드 에 대한 static 속성과 메서드를 사용합니다. GameManager.Instance.player 대신에  GameManager.Player 으로 작성이 가능합니다.
원문
30. component 들을 들어, inspector 에 변화를 주지 말아야 할 변수는 공개 하지 않습니다. 그렇지 않으면 그것은 무엇을 하는지 알수 없게 되여 디자이너가 변경을 해버리게 됩니다. 이런 경우 두줄 이나 네줄의 언더스코어를 접두로 변수 이름에 붙이면 수정을 꺼리게 될 것이다.
(역자 : 이런 경우 [HideInspector] 를 변수 상위에 붙이면 아예 노출이 일어나지 않습니다)
public float __aVariable;
원문
31. 게임 로직에서 인터페이스를 분리하여 제공합니다. 이것은 기본적으로 MVC 패턴 입니다.
모든 입력 컨트롤러는 호출되여 알려 해당 컴포넌트에 명령을 제공해야 합니다. 컨트롤러 로직을 예로, 컨트롤러는 플레이어의 상태에 따라 제공할 명령을 결정 할 수 있습니다. 그러나 이것은 안좋습니다 (예로 컨트롤러를 더 추가하는 경우 중복된 로직으로 불릴 가능성이 있습니다). 대신에, 플레이어 객체는 앞으로 이동을 할 경우에 통지 해야만 하며,  현재 상태(예를 들어 느려졌거나 아니면 기절)에 따라 속도를 설정하고 Player 의 방향을 업데이트 합니다. 컨트롤러는 자신의 상태에 관한 일을 해야 합니다(컨트롤러는 플레이어가 상태를 바꾸려고 할때 상태가 바뀐 상태인지 알수가 없습니다; 따라서, 컨트롤러는 전혀 플레이어의 상태를 알수 없습니다). 또 다른 예는 무기의 변화 입니다. 할 수 있는 옳은 방법은 GUI 가 플레이어의 SwitchWeapon 을 호출 하는 방법입니다. GUI 는 transform 과 부모와 모든 요소에 대해서 조작해선 안됩니다.
모든 인터페이스 컴포넌트는 데이터를 유지해야하고 자신의 상태에 관한 처리를 합니다. 예로, 맵을 표시하거나, GUI 는 플레이어의 움직임에 따라 표시 할수 있도록 계산을 합니다. 그러나, 이것이 게임 상태 데이터 이면, GUI 에 속해서는 안됩니다. GUI 는 단지 게임 상태 데이터를 표시해야 하며, 데이터는 다른곳에 유지해야 합니다. map 데이터는 다른곳에서 유지해야 합니다(예를 들어, GameManager 에서).
게임플레이 오브젝트는 GUI 에 대해서 아는게 거의 없습니다. 한가지 예외는 일시 정지 행동으로, Time.timeScale 을 통해 전체적으로 제어 합니다(물론 이는 좋은 생각은 아닙니다.. 보기에는). 게임플레이 오브젝트는 게임이 멈춘 상태일 때 알아야 합니다. 하지만 그게 전부 입니다. 따라서 게임 플레이 오브젝트로 부터 GUI 컴포넌트를 연결할 필요는 없습니다.
일반적으로, 당신이 GUI 클래스들을 모두 지울 경우에도, 게임은 여전히 컴파일 되야 합니다.
당신은 또한 GUI 와 input 을 재 구현시 새로운 게임 로직을 작성할 필요가 없어야 합니다.
원문
32. 별도의 상태와 Bookkeeping. Bookkeeping 변수는 빠르게 또는 편리하게 사용하기 위함이며, 그리고 현재 상태로부터 복구하는걸 가능하게 해준다. 이렇게 분리하면, 당신은 더 쉽게 적용 가능하다.
  • 게임 상태 저장, 그리고
  • 게임 상태 디버그
한가지 방법은 각각의 게임 로직 클래스를 위해 SaveData 클래스를 정의 하는 것이다.
[Serializable]
PlayerSaveData
{
   public float health; //public for serialisation, not exposed in inspector
} 
 
Player
{
   //... bookkeeping variables
 
   //Don’t expose state in inspector. State is not tweakable.
   private PlayerSaveData playerSaveData; 
}
원문
33. 별도의 특성화 구성.
동일한 메시들로 두개의 적을 고려 하는데, 벨런스 값이 다르다.(예를 들어 다른 힘과 다른 스피드를 가지고 있는경우). 별도의 데이터에 대해 여러가지 방법이 있습니다. 이중에 하나는 내가 원하는 것일거라 생각하며, 오브젝트가 생성될 때나, 게임이 저장될 때 입니다.
(Tweakable 들은 상태 데이터가 아니나 구성 데이터로, 그래서 저장할 필요가 없습니다. 개체가 로드 되거나 생성되는경우, tweakable 들은 별도로 자동으로 로드 됩니다.)
  • 각각의 게임 클래스에 템플릿 클래스를 정의합니다. 예로, 적인 경우 우리는 또한 EnemyTemplate 라고 정의 합니다. 모든 차별화된 tweakable 들은 EnemyTemplate 에 저장합니다.
  • 게임 로직 클래스 에는, 변수나 템플릿 타입을 정의 합니다.
  • 적 프리팹을 만들고, 두개의 템플릿 프리팹 WeakEnemyTemplate, andStrongEnemyTemplate 을 만듭니다.
  • 로딩하거나 오브젝트를 생성하면, 정식 템플릿에 템플릿 변수를 설정 합니다.
이 방법은 매우 정교한 방법이 될 수 있습니다. (그리고 때로는 불필요하게 복잡하므로 주의!)
예를 들어, generic 다형성을 사용하기 위해, 우리는 아마 이런식으로 정의 하는게 좋을겁니다:
public class BaseTemplate
{
   ...
}
 
public class ActorTemplate : BaseTemplate
{
   ...
}
 
public class Entity<EntityTemplateType> where EntityTemplateType : BaseTemplate
{
   EntityTemplateType template;
   ...
}
 
public class Actor : Entity <ActorTemplate>
{
   ...
}
원문
34. 표시 텍스트 이외에 다른 용도로 문자열을 사용하지 마시오. 특히, 개체 나 프리팹의 식별을 위해서 문자열을 사용하지 않습니다. 한가지 어쩔수 없는 예외는 애니메이션 으로, 일반적으로 자신의 문자열 이름으로 접근 할수 있습니다.
원문
35. Avoid using public index-coupled arrays 공개된 인덱스 결합 배열을 사용하지 마시오. 예로 무기 배열, 총알 배열, 파티클 배열 을 정의 하지 않는 것으로, 이런 경우에 대해서 좋은 방법은 아래와 같습니다:
(역자 : 배열의 인덱스를 직접적으로 사용하는걸 줄이라는 의미 인거 같습니다)
public void SelectWeapon(int index)
{ 
   currentWeaponIndex = index;
   Player.SwitchWeapon(weapons[currentWeapon]);
}
 
public void Shoot()
{
   Fire(bullets[currentWeapon]);
   FireParticles(particles[currentWeapon]);   
}
이런 코드를 많이 사용 하지 않는 문제는, inspector 에 설정 할 때 실수를 할 가능성이 있기 때문 입니다.
오히려, 세 변수를 캡슐화 하는 클래스를 정의하고 그 배열을 확인 하십시오.
[Serializable]
public class Weapon
{
   public GameObject prefab;
   public ParticleSystem particles;
   public Bullet bullet;
}
이 코드는 보기에 단정해 보이나, 매우 중요하며, inspector 에 데이터를 셋팅할 때 실수하기 어렵습니다.
원문
36. 시퀀스 이외의 다른 구조에 대한 배열을 사용하지 마시오. 예로, 플레이어가 세개의 공격 타입을 가지고 있다고 칩시다. 각각 현재 무기를 사용하지만 서로 다른 포탄과 다른 동작을 생성합니다.
당신은 아마 배열을 사용해 세개의 총알을 발사 하려하며, 이러한 로직을 사용할 것입니다:
public void FireAttack()
{
   /// behaviour
   Fire(bullets[0]);
}
 
public void IceAttack()
{
   /// behaviour
   Fire(bullets[1]);
}
 
public void WindAttack()
{
   /// behaviour
   Fire(bullets[2]);
}
Enums 을 사용하면 좀 더 나은 코드가 될 수 있습니다…
public void WindAttack()
{
   /// behaviour
   Fire(bullets[WeaponType.Wind]);
}
그러나 inspector 에서는 안됩니다.
그것은 별도의 변수를 사용하는 것이 좋기 때문에 어떤 콘텐츠를 넣어도 이름으로 도움말이 될 수 있습니다. 타입이 단정 지어질때 클래스를 만듭니다.
[Serializable]
public class Bullets
{
   public Bullet FireBullet;
   public Bullet IceBullet;
   public Bullet WindBullet;
}
Fire 를 설정하면 Ice 와 Wind 데이터는 없다고 가정합니다.
원문
37. serializable 클래스의 그룹 데이터는 가까운거 끼리 모아 inspector 로 만들어야 한다 . 어떤 엔티티는 수십개의 조절할게 있을수 있습니다.  이 경우 inspector 에 연결될 변수를 찾는게 악몽이 될 수 있습니다. 더 쉽게 만들기 위해, 다음의 단계를 따르십시오:
  • 변수의 그룹에 대한 별도의 클래스를 정의 합니다.
    그것들을 public 및 serializable 합니다.
  • 기본 클래스에서, 위와 같이 정의된 각각의 유형의 public 변수를 정의 합니다.
  • 변수를 Awake 나 Start 에서 초기화 하면 안되며; 그것들은 serializable 이기 때문에, Unity 에서 잘 처리 해줄 것입니다.
  • 당신은 정의된 변수가 연결되기 전에 초기화를 지정하는게 가능하다
inspector 의 접을 수 있는 공간의 그룹 변수들은, 관리를 쉽게 합니다.
[Serializable]
public class MovementProperties //Not a MonoBehaviour!
{
   public float movementSpeed;
   public float turnSpeed = 1; //default provided
}
 
public class HealthProperties //Not a MonoBehaviour!
{
   public float maxHealth;
   public float regenerationRate;
}
 
public class Player : MonoBehaviour
{
   public MovementProperties movementProeprties;
   public HealthPorperties healthProeprties;
}
원문

Text

38. 스토리 텍스트가 많은 경우, 파일에 넣도록 합니다. inspector 의 에디팅 할수 있는 영역으로 두지 마십시오. 이것은 Unity 에디터를 열지 않고도 변경을 쉽게 해줄 것이며, 특히 scene 을 저장하지 않고도 가능할 것입니다.
원문
39. 당신이 로컬라이징을 할 계획이 있다면, 하나의 지역에 모든 문자열을 분리합니다. 
이 작업을 수행하는 방법에는 여러가지가 있습니다. 한가지 방법은 예를 들어, 기본값을 영어로 설정하고, 각 문자열에 대한 공개 문자열 필드에 텍스트 클래스를 정의 하는 것입니다. 다른 언어는 하위 클래스를 두고 언어에 맞추어 다시 초기화 하는 것입니다.
더 정교한 기법은 (텍스트의 길이가 길고 / 길거나 언어의 갯수가 많은 경우 적절합니다)sheet 로부터 읽어오고 선택된 언어로부터 기본이 되는 문자열을 선택해서 로직에 제공 하는 것입니다.
원문

Testing and Debugging

40. 물리, 애니메이션, 그리고 AI 를 디버깅하기 위해 그래픽 logger를 구현 합니다. 이건 상당히 빠르게 디버깅 할 수 있게 합니다. 여기에 자세한 정보가 있습니다 here.
원문
41. HTML logger를 정의 합니다.  몇가지 경우에 대해서, logging 은 매우 유용 합니다.
구문 분석(컬러 코드, 멀티 뷰, 스크린샷 기록)을 하게 되면 로그를 디버깅 하는게 훨씬 쾌적 할 수 있습니다. 여기에 자세한 정보가 있습니다 here.
원문
42. 당신의 FPS counter 를 구현합니다. 예. Unity 의 FBS counter 가 정말 제대로 측정할지도 모르나, 그것은 프레임 레이트가 아닙니다. 직관과 육안 검사와 일치 할 수 있도록 자신의 것을 구현 합니다.
원문
43. Implement shortcuts for taking screen shots 스크린샷을 이용해 바로가기를 구현 합니다.  많은 버그는 비쥬얼이며, 그리고 당신은 사진을 찍어두면 보고가 좀 더 쉬워집니다. 이상적인 시스템은 스크린샷을 덮어씌우지 않도록 PlayerPrefs 의 카운터를 유지 해야 합니다. 스크린샷은 실수로 사람들이 저장소에 커밋하는걸 방지하기 위해 프로젝트 폴더 외부에 저장해야 합니다.
원문
44. 플레이어의 월드 위치를 출력하기 위한 바로가기를 구현 합니다. 이것은 월드의 특정 장소에서 발생하는 버그의 위치를 리포트를 하기 쉬워질 것이며, 이는 번갈아 가면서도 쉽게 디버깅 할 수 있습니다.
원문
45. 테스트를 쉽게 만들기 위한 디버그 옵션을 구현합니다. 몇가지 예를 들면:
  • 모든 아이템 언락
  • 적 제거
  • GUI 끄기
  • 플레이어 무적
  • 모든 게임 플레이 불가.
원문
46. 충분히 작은 팀의 경우, 디버그 옵션을 사용하여 각 팀의 구성원을 위한 prefab 을 만듭니다. 파일에 사용자 ID 를 넣고: 게임이 실행 될 때 읽어집니다. 이 이유는:
  • 팀 구성원은 사고로 자신의 디버그 옵션을 커밋 하고 모두에게 영향을 미치기 않기 위함입니다.
  • 디버그 옵션을 바꾸는 것은 scene 을 바꾸는게 아니기 때문입니다.
원문
47. 모든 게임 플레이 요소와 scene 을 유지 합니다. 예로, 모든 적이 있는 scene, 당신이 상호 작용 할수 있는 모든 개체, 그외 등등. 너무 오래 게임을 하지 않고 기능을 테스트 할 수 있도록 합니다.
원문
48. 디버그 바로 가기 키를 위한 상수를 정의하고, 한 곳에서 보관 합니다. 디버그 키는 일반적으로 (또는 편리한) 게임 입력이 처리 되는 위치에서 같이 처리 되지는 않습니다. 바로 가기 키의 충돌을 방지 하기 위해 중앙 위치에 상수를 정의 합니다. 대안으로 디버그 함수인지 아닌지 상관없이 한 곳에 모든 키를 처리 하는 겁니다. (단점은 이 클래스는 이 개체에 대해서 참조를 추가로 해야 할 수도 있습니다)
원문

Documentation

49. 설치를 문서화 합니다. 대부분의 코드는 문서에 있어야 하며, 하지만 이러한 것은 코드 외부에서 문서화 해야합니다. 디자이너가 설정하기 위한 코드를 선별하여 만드는것은 시간 낭비 입니다. 문서 설정이 효율이 극대화 됩니다 (만약 문서가 최신이라면).
다음 사항을 문서화 합니다:
  • 레이어 사용 (충돌, 컬링, raycasting – essentially, 어떤 항목에 어떤걸 해야)
  • 태그 사용.
  • 레이어를 위한 GUI 깊이 (무엇을 통해서 표시해야)
  • scene 설치
  • Idiom 설정
  • 프리팹 구조
  • 애니메이션 레이어
원문

Naming Standard and Folder Structure

50. 문서화 규칙 및 폴더 구조를 따르시오. 일관성 규칙 및 폴더 구조는 쉽게 찾고자 하는걸 찾을 수 있으며, 일이 무엇인지 파악 할 수 있습니다.
당신은 아마도 자신의 규칙 및 폴더 구조를 생성 할 수 있습니다. 다음의 예는 한가지 입니다.
원문

Naming General Principles

  1. 무언가를 호출 합니다. bird 는 Bird 를 호출 합니다.
  2. 이름을 선택 할 때는 확연하고 기억될 수 있는 이름으로 선택합니다. 만약 당신이 마야 게임을 만든다고 해서, 레벨 이름을 QuetzalcoatisReturn 로 해서는 안됩니다.
  3. 일관성을 유지 하십시오. 이름을 선택할때, 기준에 충실해야 합니다.
  4. Use Pascal case, like this: ComplicatedVerySpecificObject. Do not use spaces, underscores, or hyphens, with one exception (see Naming Different Aspects of the Same Thing).
    이와같이 파스칼 케이스를 사용합니다: ComplicatedVerySpecificObject. 공간( ), 언더바(_), 또는 하이푼(-), 한가지 예외와 함께 (같은 일에 다른 이름을 보게 될 경우)
  5. 버전 번호를 사용하지 말고, 또는 단어로 진행 상태를 표시 하지 마십시오 (WIP, final).
  6. Do not use abbreviations: DVamp@W should be DarkVampire@Walk.
    약어를 사용하지 마십시오: DVamp@W 는 DarkVampire@Walk .으로 표기 합니다
  7. 디자인 문서의 용어를 사용합니다: 사망 을 문서상 호출 하려면 Die 애니메이션을 부릅니다. DarkVampire@Die, 를 부르며 DarkVampire@Death 는 안됩니다.
  8. 구체적인 설명은 왼쪽에 표기 합니다: DarkVampire 는 좋은 방법이며 VampireDark 는 안좋은 방법입니다. PauseButton는 좋은 방법이며 ButtonPaused는 안좋은 방법입니다. 이것을 예로 들면, 모든 버튼이 단어 버튼으로 시작하면 inspector 에서 일시 정지 버튼을 찾기 쉬워집니다. [많은 사람들이 다른 방법을 더 선호하며, 때문에 시각적으로 보다 더 확실히 그룹화를 하여 생성합니다. 이름이 있지만 그룹화를 위한게 아니며, 폴더를 위한것 입니다. 이름이 안정적으로 빠르게 자리 잡고 할 수 있도록 동일한 유형의 객체를 구분하는 것 입니다.]
  9. 일부 이름은 순서를 형성합니다. 이름에 숫자를 사용하며, 예로 PathNode0,PathNode1 가 있습니다. 항상 시작은 1이 아닌 0으로 시작합니다.
  10. 순서를 필요로 하지 않는 일에 번호를 사용하지 마십시오. 예로 Bird0, Bird1,Bird2 는 Flamingo, Eagle, Swallow 라고 표기합니다.
  11. 임시 객체는 이중으로 접두사에 언더바를 넣습니다 __Player_Backup.
원문

Naming Different Aspects of the Same Thing

언더바와 핵심 이름을 사용하여, 해당 상태에 “세부” 내용 설명합니다. 예로 들면:
  • GUI 버튼 상태는 EnterButton_Active, EnterButton_Inactive
  • 텍스쳐는 DarkVampire_Diffuse, DarkVampire_Normalmap
  • 스카이 박스는 JungleSky_Top, JungleSky_North
  • LOD 그룹은 DarkVampire_LOD0, DarkVampire_LOD1
단지 다른 유형의 항목 구분이 규칙을 사용하면 안되며, 예로  Rock_Small, Rock_Large 를 SmallRock, LargeRock 으로 사용 하는 경우 입니다.
원문

Structure

당신의 scene 의 구성, 프로젝트 폴더, 그리고 스크립트 폴더는 유사한 패턴을 가져야 합니다.
원문

Folder Structure

Materials
GUI
Effects
Meshes
   Actors
      DarkVampire
      LightVampire
      ...
   Structures
      Buildings
      ...
   Props
      Plants
      ...
   ...
Plugins
Prefabs
   Actors
   Items
   ...
Resources
   Actors
   Items
   ...
Scenes
   GUI
   Levels
   TestScenes
Scripts
Textures
GUI
Effects
...

Scene Structure

Cameras
Dynamic Objects
Gameplay
   Actors
   Items
   ...
GUI
   HUD
   PauseMenu
   ...
Management
Lights
World
   Ground
   Props
   Structure
   ...

Scripts Folder Structure

ThirdParty
   ...
MyGenericScripts
   Debug
   Extensions
   Framework
   Graphics
   IO
   Math
   ...
MyGameScripts
   Debug
   Gameplay
      Actors
      Items
      ...
   Framework
   Graphics
   GUI
   ...

How to Re-implement Inspector Drawing

1. 당신의 모든 에디터를 위한 기본 클래스를 정의

BaseEditor<T> : Editor 
where T : MonoBehaviour
{
   override public void OnInspectorGUI()
   {
      T data = (T) target;
 
      GUIContent label = new GUIContent();
      label.text = "Properties"; //
 
      DrawDefaultInspectors(label, data);
 
      if(GUI.changed)
      {         
         EditorUtility.SetDirty(target);
      }
   }
}

2. reflection 과 recursion 를 사용하여 draw 컴포넌트에 reflection 을 사용

public static void DrawDefaultInspectors<T>(GUIContent label, T target)
   where T : new()
{
   EditorGUILayout.Separator();
   Type type = typeof(T);      
   FieldInfo[] fields = type.GetFields();
   EditorGUI.indentLevel++;
 
   foreach(FieldInfo field in fields)
   {
      if(field.IsPublic)
      {
         if(field.FieldType == typeof(int))
         {
            field.SetValue(target, EditorGUILayout.IntField(
            MakeLabel(field), (int) field.GetValue(target)));
         }   
         else if(field.FieldType == typeof(float))
         {
            field.SetValue(target, EditorGUILayout.FloatField(
            MakeLabel(field), (float) field.GetValue(target)));
         }
 
         ///etc. for other primitive types
 
         else if(field.FieldType.IsClass)
         {
            Type[] parmTypes = new Type[]{ field.FieldType};
 
            string methodName = "DrawDefaultInspectors";
 
            MethodInfo drawMethod = 
               typeof(CSEditorGUILayout).GetMethod(methodName);
 
            if(drawMethod == null)
            {
               Debug.LogError("No method found: " + methodName);
            }
 
            bool foldOut = true;
 
            drawMethod.MakeGenericMethod(parmTypes).Invoke(null, 
               new object[]
               {
                  MakeLabel(field),
                  field.GetValue(target)
               });
         }      
         else
         {
            Debug.LogError(
               "DrawDefaultInspectors does not support fields of type " +
               field.FieldType);
         }
      }         
   }
 
   EditorGUI.indentLevel--;
}
위 method 는다음과 같은 헬퍼를 사용한다:
private static GUIContent MakeLabel(FieldInfo field)
{
   GUIContent guiContent = new GUIContent();      
   guiContent.text = field.Name.SplitCamelCase();      
   object[] descriptions = 
      field.GetCustomAttributes(typeof(DescriptionAttribute), true);
 
   if(descriptions.Length > 0)
   {
      //just use the first one.
      guiContent.tooltip = 
         (descriptions[0] as DescriptionAttribute).Description;
   }
 
   return guiContent;
}
이 inspector 에 툴팁을 생성하기 위해 클래스 코드에 주석을 사용합니다.

3. Define new Custom Editors

불행하게도, 당신은 여전히 각각의 MonoBehaviour 를 위한 클래스를 정의 해야 합니다. 다행히도, 이러한 정의는 비어 있을것이며; 모든 실제 작업은 기본 클래스에 의해 이루어 집니다.
[CustomEditor(typeof(MyClass))]
public class MyClassEditor : BaseEditor<MyClass>
{}

이론적으로 이 단계는 자동일 수 있지만, 난 아직 시도 해보지 않았습니다.

[출처] 유니티3D 50가지 팁|작성자 일리

출처 원문

출처: http://seungngil.tistory.com/entry/유니티-작업에-대한-50-팁-모범-사례-50-Tips-for-Working-with-Unity-Best-Practices [To be a programmer…]