1. 다른 스크립트 (컴포넌트)의 내부 프로퍼티를 참고할때는 Start()에서 해라. Awake()에서 참조하려고 하면 참조대상이 초기화되기전에 코드가 먼저 실행될 수도 있어서 NullReferecne 에러가 난다
그래도 무조건 Awake에서 불러와야겠다 하면 Project settings에서 스크립트 실행 순서를 수정할 수 있는데, 이렇게 임의로 실행순서를 건드리는 것은 예상치 못한 사이드 이펙트를 초래할 수 있기 때문에 가급적이면 하지 말자
(GameManger가 무조건 spawner 보다 먼저 실행되게 해서 spawner가 GameManager를 참조할 수 있도록 함)
(스크립트 실행 순서를 조절 하니 Spawner가 GameManger의 level 프로퍼티를 잘 불러온다)
2. Prefab을 로드하는 방법은 Inspector에서 드래그 드랍 하는 방법 외에도 Resources 폴더에서 코드로 불러 올 수 있다.
-> 유니티에서 Resources 폴더는 프레임워크 매직의 영향을 받는 폴더이다. 루트/Resources에 위치한 파일들은 ResourcesLoad 메서드를 사용해서 로드 가능하다.
- 프리펩 이외의 다른 파일들도 가능할 것으로 판단된다.
결국 프리팹 같은 리소스를 메모리에 올릴때, 인스펙터 GUI에서 할당하는 방법과 코드로 할당하는 방법 2가지가 되는데, 두 방법을 혼용하지 않도록 멘탈 모델을 제대로 가져가야할 필요가 있겠다는 생각을 다시 한번 했다.
오브젝트의 내부 프로퍼티를 초기화 할 때도 비슷한 생각을 몇번 했는데, 분명 코드에서 transform을 줬음에도 불구하고, game scene에서는 이상한 값이 들어가있길래 확인해보니 Inspector에서 뚱딴지 같은 값이 들어가 있어서 존재하지 않는 버그와 섀도우 복싱을 뒤지게 했기 때문이다
(뜬금없이 Transform의 Z축이 음수로 되어있어서 생성되는 하위 Object가 바닥에 가려서 안보였다)
* 스크립트와 인스펙터 번갈아가면서 잘 보자. 아니면 앗싸리 둘 중 하나로만 밀고 가던가
3. Instantiate를 해줘야지 게임월드에서 상호작용이 가능하다.
Prefab 로드를 한다는건. 그냥 메모리에 올렸다!!! 이 뜻이다. 실제 게임에서 상호작용하려면 Instantiate 메서드를 사용해 실제 게임 월드에 올려야한다 <<< 매우 중요
4. LinQ Extension Method
분명 같은 리스트인데, using System.Linq 라고 특정 네임스페이스의 사용 유무에 따라서 자료형이 사용할 수 있는 메서드가 달라진다고??
좀 더 알아보니, 이런 확장 메서드는 사용자가 직접 만들어서 기본 자료형에 삽입할 수도 있다는데, 이건 너무 프로그래머들을 믿어주는게 아닌가...하는 생각이 든다.
C# 전문가한테 물어보니, 이런 모르면 쳐맞는 패턴들이 왕왕 있기에 자바나 dotnet에서 무거운 IDE를 선호하는 경향이 있다고 한다.
매우 흥미롭네요.....
(OrderBy 메서드는 Linq 를 using하지 않으면 쓸수 없다~)
5. Collider가 스프라이트와 일치하지 않을때는 Reset을 누르면 알잘딱센 맞춰준다
이건 개꿀팁이 맞네요....
오늘 유니티 좀 하려고 휴가까지 쓰면서 방방 뛰면서 해봤는데, 뭔가 얻어가는 정보들은 많은데, 머리에 한번에 정렬이 되지 않네
항상 그렇듯 계속 반복하고 대가리도 박아보면서 머슬 메모리로 만드는 수 밖에 없겠다
스크립트엑서큐션오더 건드리는것도 나쁜 방법은 아닌데, 메니저가 늘어나고 서로 참조하는 정보가 많아지면 매번 저기서 바꿔주고, 실행순서 고민하고 그럴때가 있거든
그래서 메니저를 관리하는 슈퍼메니저?를 만들어주고, 각 매니저의 로드가 끝났을 때 를 확인하기 위해서 public static event System.Action OnLoaded; OnLoaded?.Invoke(); 이런식으로 주고, 슈퍼메니저에서 Manager.OnLoaded += ManagerLoaded; 이렇게 확인해주면, 모든 메니저가 로드됐을 때, 각 메니저에 최초로 실행되어야 할 함수 ( 본문에서 스포너에 해당하는 부분 ) 을 작동시키게 해주면, 이후 유지보수 할 때도, 신경쓸거 없어서 좋아
아 오히려 매니저가 늘어나면 저거 컨트롤 하는게 좋을 때도 있구나, 나는 저게 ms 단위로 컨트롤 하길래, 사용자에게 공개되어있지 않은 랜더링 시퀀스를 침해할까봐 안 건들었거든. 예를 들면 1000ms 뒤에 게임매니저를 로드했는데 400ms에 전체 인스턴스가 로드 되었는지 확인하는 유니티 내부 로직이 있다면 게임유니티가 게임매니저를 제대로 홀드 못할테니까.
말한것처럼 매니저가 많아진다면 저렇게 타이밍 기반으로 컨트롤 하는 방법도 생각해볼께 고마웡
아니 반대야!! 나중에 메니저가 더 많이 추가되면, 그때마다 스크립트엑서큐션오더를 수정할 순 없으니깐, 저 부분은 건드리지 말고, 상위 메니저인 슈퍼메니저? 를 하나 더 파서, 얘가 모든 하위 메니저의 로드 상태를 관리하고, 모든 메니저가 로드 되었을 때, 각 메니저에 행동을 할당 해주는게 좋다는 말이였어!!
싱글톤을 꼭 모노 상속 받아야 하는 건 아니라 레벨 처럼 원시타입이고 json 같이 따로 직렬화 저장 할 거면 퓨어한 c# 싱글톤으로 데이터 매니저 같은놈 만들어서 쓰면 됨 어떤 유니티 객체도 초기화 블록 보다 빠를 순 없음
모노 상속이라는게 monobehavior 클래스로 만들어진 객체를 참조한다는 의미인거지??
resoueces폴더 안쓰는게 좋다곤 하는데 나는 걍 씀 - dc App