Gameobject내의 inspector의 속성들을 데이터화 하기.

문제점 : 게임내의 오브젝트의 속성을 변경할수 있도록 인스펙터의 정보들을 데이터화 하는것.

 

예: 모덴군 (칼, 총, 바주카, 등등으로 리소스가 제작되어 하나의 프리팹에서 데이터에 따라 변화 해야 했다.

 

해결방법 모색: ScriptableObject로 사용하려했으나 레벨링 단계에서 데이터화 된 문서를 필요로 했기때문에 외부 파일을 이용하기로 하였다. 또한 ScriptableObject : 5KB에 비해 xml데이터의 용량은 1KB였다. 무려 5배나 차이가 난다.

 

Google검색어 : unity3d inspector xml

https://www.google.co.kr/?gws_rd=cr&ei=cAHeUt_4I-a5iQeBwIGQDA#newwindow=1&q=unity3d+inspector+xml

 

XML 저장 불러오기 의키 라이브러리

http://wiki.unity3d.com/index.php?title=Save_and_Load_from_XML

 

ScriptableObject 예제

http://wiki.unity3d.com/index.php?title=CreateScriptableObjectAsset

 

유니티 메뉴얼 TextAsset

http://docs.unity3d.com/Documentation/Components/class-TextAsset.html

 

xml 온라인 파서

http://xmlvalidator.new-studio.org/

 

유니티 개발 50가지 팁

http://makegamessa.com/discussion/67/50-tips-for-working-in-unity/p1

 

On private vs public, vars should traditionally only be public if you specifically want them to be accessible outside your class. Unity complicates this by making public the way to expose stuff in the editor as well, but at least you can add [HideInInspector] to fields that should be publicly accessible in code, but designers shouldn't touch in the inspector. Otherwise default property setups are useful but potentially expensive:
public bool Foo { get; set; }

On storing large amounts of data, such as text and levels, XML is good (and a traditional way to do things) but we've found JSON actually works out better in some regards. It's less verbose, so less wasted space (eg in savegames) and because the structure maps objects pretty much exactly it's easier for everyone to understand. It also plays well with web services (more easily than XML) which helps in some things. There are some excellent json serialization/deserialization libs freely available for Unity that work just fine.

On naming, I'm also a fan of Pascal case, and always have been. I also tend to despise underscores. One thing is causing me to lean towards all lowercase with underscores as separators though: Mac vs Windows and their handling of case. In theory sticking to Pascal case is ideal, but there are so many fringe cases where people use different capitalization for things, like Background vs BackGround and things get muddled, and this has led to issues. I dunno, still trying to decide where I fall on this.

On referencing prefabs and never using strings for anything, for the most part I agree, but we found an interesting Unity bug that has led to us to using named prefab paths (aaaargh) instead of prefab references. Unity takes significantly longer to instantiate objects from a prefab reference compared to instantiating it from the prefab path on Android. As in almost an order of magnitude longer. We had epic loading time issues, switched to using named over references, and gained back minutes of load time!