Difference between r1.1 and the current
@@ -1,7 +1,37 @@
[[TableOfContents]]
== 진행 ==
* 2015년 12월 31일 10시, 겨울 코미케 3일차에 게임 판매를 시작하였습니다.* 총 52장 中 48장이 팔렸고, 1장은 코미케에 샘플로 제출, 1장은 다른 서클과 교환, 2장이 남았습니다.
* 트위터에서 #Project_AI 라는 해시태그를 통해 버그 리포팅을 받고 있습니다.
* 즉 버그 리포팅을 계속해서 하고, 업데이트를 합니다.
* 후기
== 후기 ==
* 이렇게 정상적으로 끝난 게 지금 생각해보면 참 신기합니다. 시간에 쫓겨서 매일 밤을 새던 게 엊그제 같네요.
* 아래는 프로젝트 진행하면서 느꼈던 점입니다. 앞으로 게임 프로젝트를 하실 분들이 있다면 간단하게 참고해보시는 것도 좋을 것 같습니다.
* ~~사실 OMS 자료에도 있습니다.~~
* 당연한 얘기지만, Unity 사용 시 가급적 서로의 Unity 버전은 통일하시길 바랍니다. 버전마다 미묘한 기능 차이가 있기 때문에, 충돌할 여지가 있습니다.
* 역시, Unity 스크립트 작성 시에는 C#과 JavaScript 중 하나로 통일하시길 추천드립니다. 특히 JavaScript에서 C# 코드를 가져다 쓸 수 있다는 점 때문에, 자칫 혼란을 야기할 수가 있으니 꽤나 중요한 사항입니다.
* [http://docs.unity3d.com/ScriptReference/] Scripting Reference입니다.
* C# 사용 시에는 항상 지원되는 C# 버전을 고려하시길 바랍니다. 지금은 (2016년 기준) C# 6.0까지 나와있는 상태지만, Unity에서는 Mono 2.6을 사용하는 관계로 C# 3.0과 아주 일부분의 C# 4.0 까지만 지원됩니다. async/await 키워드나 Task/Factory, dynamic 타입 등에 대해서는 작동하지 않으니 유의하시길 바랍니다.
* 항상 게임 오브젝트의 생명 주기를 잘 파악하시길 바랍니다.
* OnEnable → Start → Update → LateUpdate 등등으로 이어지는 구조에서 각 함수가 언제 호출되는 지 꼭 알고 계셔야 합니다.
* Scene간 이동이 자유로울 때 이 함수는 불릴까? 특정 함수에서 이 함수를 사용하면 제대로 된 값이 나올까? 라는 질문을 끊임없이 던지시길 바랍니다.
* 멀티 스레딩이 필요할 때가 있습니다. 다만 Unity 라이브러리에는 멀티 스레딩이 지원되지 않는 것들이 굉장히 많습니다.
* 예를 들어, Resource 로드나 gameObject 프로퍼티 사용, Component 가져오기 등에서도 멀티 스레딩이 지원되지 않으며, 심지어는 Random.range도 멀티 스레딩이 지원되지 않습니다.
* 객체를 직렬화하여 세이브를 하고자 할 때는 특히 주의하세요. 예를 들어 Sprite와 같은 객체는 Serializable하지 않습니다.
* 어쩔 수 없지만 Unity 자체에도 버그가 있습니다.
* 가끔 예기치 않은 종료를 하게 되면, 반드시 있어야 할 라이브러리를 인식하지 못하는 상황이 발생합니다. 이 때는 Reimport all을 해주세요.
* Application.Quit()은 어플리케이션을 종료시키는 아주 단순하고 사용하기 좋은 메서드이지만, 불행하게도 버그가 있습니다. 그것은 바로 불특정 상황에 종료는 되지만 크래쉬가 나면서 종료가 나는 것인데요, 이 때는 이 메서드 대신 프로세스를 종료하는 다른 메서드를 사용해보시는 것을 추천드립니다.
* 개발 중, 기획은 항상 변할 수 있다는 것을 명심합시다. 이를 위해, 스크립트는 항상 기능의 확장에 대해서 항상 열려있어야 합니다.
* 실제 빌드 후의 테스트에 대해 항상 조심하세요. Unity Editor에서 실행 시에는 Unity에서 (윈도우의 경우) 레지스트리에 설정값을 집어넣어주는 관계로, Editor에서 발생하지 않았던 버그가 빌드 후에 갑자기 나타나는 경우도 있습니다.
* 사용자는 왠만해서 개발자의 의도를 따라가지 않습니다. 최대한 사용자의 편의를 제공하는 쪽으로 GUI를 구성하시길 바랍니다.
* 이것도 당연하지만 게임을 하는 것과 만드는 것은 다릅니다. 조심!
* 개인적인 의견이지만, 인터넷 상으로의 회의보다는 직접적인 면대면 회의가 확실히 효율이 좋습니다. 더 좋은 커뮤니케이션을 위해 항상 노력해주세요.
* Unity Project는 git과는 그렇게 상성이 좋지 않습니다.
* 단점으로써 scene의 내부에 있는 gameobject를 약간이라도 수정하게 된다면 scene 파일 자체가 바뀐 것으로 인식됩니다. 즉, 여러 사람이 한 번에 수정하면 안되는 atomic한 단위는 gameobject가 아닌 scene입니다.
* metadata파일을 항상 주의합시다.
* 2D 게임을 개발 할 시, 3D 프로젝트에서 축 하나를 없는 셈 치고 개발하는 방법과 2D 프로젝트로써 개발하는 방법이 있습니다.
* 3D 프로젝트로써 2D 게임 개발을 한다면, 사용하지 않는 축의 좌표나 마찰력 등의 힘, object sorting 등을 잘 파악해야 합니다.
------------------------------------------------------------
[Project_AI]
1. 진행 ¶
- 2015년 12월 31일 10시, 겨울 코미케 3일차에 게임 판매를 시작하였습니다.
- 총 52장 中 48장이 팔렸고, 1장은 코미케에 샘플로 제출, 1장은 다른 서클과 교환, 2장이 남았습니다.
- 트위터에서 #Project_AI 라는 해시태그를 통해 버그 리포팅을 받고 있습니다.
- 즉 버그 리포팅을 계속해서 하고, 업데이트를 합니다.
- 즉 버그 리포팅을 계속해서 하고, 업데이트를 합니다.
2. 후기 ¶
- 이렇게 정상적으로 끝난 게 지금 생각해보면 참 신기합니다. 시간에 쫓겨서 매일 밤을 새던 게 엊그제 같네요.
- 아래는 프로젝트 진행하면서 느꼈던 점입니다. 앞으로 게임 프로젝트를 하실 분들이 있다면 간단하게 참고해보시는 것도 좋을 것 같습니다.
사실 OMS 자료에도 있습니다.
- 당연한 얘기지만, Unity 사용 시 가급적 서로의 Unity 버전은 통일하시길 바랍니다. 버전마다 미묘한 기능 차이가 있기 때문에, 충돌할 여지가 있습니다.
- 역시, Unity 스크립트 작성 시에는 C#과 JavaScript 중 하나로 통일하시길 추천드립니다. 특히 JavaScript에서 C# 코드를 가져다 쓸 수 있다는 점 때문에, 자칫 혼란을 야기할 수가 있으니 꽤나 중요한 사항입니다.
- http://docs.unity3d.com/ScriptReference/ Scripting Reference입니다.
- http://docs.unity3d.com/ScriptReference/ Scripting Reference입니다.
- C# 사용 시에는 항상 지원되는 C# 버전을 고려하시길 바랍니다. 지금은 (2016년 기준) C# 6.0까지 나와있는 상태지만, Unity에서는 Mono 2.6을 사용하는 관계로 C# 3.0과 아주 일부분의 C# 4.0 까지만 지원됩니다. async/await 키워드나 Task/Factory, dynamic 타입 등에 대해서는 작동하지 않으니 유의하시길 바랍니다.
- 항상 게임 오브젝트의 생명 주기를 잘 파악하시길 바랍니다.
- 멀티 스레딩이 필요할 때가 있습니다. 다만 Unity 라이브러리에는 멀티 스레딩이 지원되지 않는 것들이 굉장히 많습니다.
- 예를 들어, Resource 로드나 gameObject 프로퍼티 사용, Component 가져오기 등에서도 멀티 스레딩이 지원되지 않으며, 심지어는 Random.range도 멀티 스레딩이 지원되지 않습니다.
- 예를 들어, Resource 로드나 gameObject 프로퍼티 사용, Component 가져오기 등에서도 멀티 스레딩이 지원되지 않으며, 심지어는 Random.range도 멀티 스레딩이 지원되지 않습니다.
- 객체를 직렬화하여 세이브를 하고자 할 때는 특히 주의하세요. 예를 들어 Sprite와 같은 객체는 Serializable하지 않습니다.
- 어쩔 수 없지만 Unity 자체에도 버그가 있습니다.
- 가끔 예기치 않은 종료를 하게 되면, 반드시 있어야 할 라이브러리를 인식하지 못하는 상황이 발생합니다. 이 때는 Reimport all을 해주세요.
- Application.Quit()은 어플리케이션을 종료시키는 아주 단순하고 사용하기 좋은 메서드이지만, 불행하게도 버그가 있습니다. 그것은 바로 불특정 상황에 종료는 되지만 크래쉬가 나면서 종료가 나는 것인데요, 이 때는 이 메서드 대신 프로세스를 종료하는 다른 메서드를 사용해보시는 것을 추천드립니다.
- 가끔 예기치 않은 종료를 하게 되면, 반드시 있어야 할 라이브러리를 인식하지 못하는 상황이 발생합니다. 이 때는 Reimport all을 해주세요.
- 개발 중, 기획은 항상 변할 수 있다는 것을 명심합시다. 이를 위해, 스크립트는 항상 기능의 확장에 대해서 항상 열려있어야 합니다.
- 실제 빌드 후의 테스트에 대해 항상 조심하세요. Unity Editor에서 실행 시에는 Unity에서 (윈도우의 경우) 레지스트리에 설정값을 집어넣어주는 관계로, Editor에서 발생하지 않았던 버그가 빌드 후에 갑자기 나타나는 경우도 있습니다.
- 사용자는 왠만해서 개발자의 의도를 따라가지 않습니다. 최대한 사용자의 편의를 제공하는 쪽으로 GUI를 구성하시길 바랍니다.
- 이것도 당연하지만 게임을 하는 것과 만드는 것은 다릅니다. 조심!
- 개인적인 의견이지만, 인터넷 상으로의 회의보다는 직접적인 면대면 회의가 확실히 효율이 좋습니다. 더 좋은 커뮤니케이션을 위해 항상 노력해주세요.
- Unity Project는 git과는 그렇게 상성이 좋지 않습니다.
- 단점으로써 scene의 내부에 있는 gameobject를 약간이라도 수정하게 된다면 scene 파일 자체가 바뀐 것으로 인식됩니다. 즉, 여러 사람이 한 번에 수정하면 안되는 atomic한 단위는 gameobject가 아닌 scene입니다.
- metadata파일을 항상 주의합시다.
- 단점으로써 scene의 내부에 있는 gameobject를 약간이라도 수정하게 된다면 scene 파일 자체가 바뀐 것으로 인식됩니다. 즉, 여러 사람이 한 번에 수정하면 안되는 atomic한 단위는 gameobject가 아닌 scene입니다.
- 2D 게임을 개발 할 시, 3D 프로젝트에서 축 하나를 없는 셈 치고 개발하는 방법과 2D 프로젝트로써 개발하는 방법이 있습니다.
- 3D 프로젝트로써 2D 게임 개발을 한다면, 사용하지 않는 축의 좌표나 마찰력 등의 힘, object sorting 등을 잘 파악해야 합니다.
- 3D 프로젝트로써 2D 게임 개발을 한다면, 사용하지 않는 축의 좌표나 마찰력 등의 힘, object sorting 등을 잘 파악해야 합니다.
