하이어라키 창에서 t를 이용한 검색방법
- 꽤나 자세하게 검색해야 나온다.
- 컴포넌트를 검색할 수 있다.
인스펙터 창 복붙하기
- Cube 1의 값을 Cube2로 옮기고 싶다!
- inspector창을 2개로 늘리고 갈라준다. 인스펙터 창의 lock을 걸어서 다른 오브젝트를 선택해서 인스펙터창이 바뀌지않도록만든다.
- 인스펙터 창에서 private변수를 보고싶다면 우클릭 후 디버그모드로 동작
커스텀에디터만들기
게임뷰에서 디바이스 시뮬레이터를 사용
- 다양한 디바이스 환경에서 테스팅이 가능하다. 세이프존을 사용하여 UI배치가 되면 안될 곳을 미리 설정가능
로그를 Collapse를 통해 같은종류메시지끼리 모을 수 있다.
프로젝트 세팅에서 Reload Domain and Scene을 Do not으로 바꾸면 게임플레이 모드가 빠르다.
다양한 Static변수나 초기화값을 매번 Reload하지 않는 것.
싱글톤의 경우 문제가 생길 수 있는데, Awake에서 초기화해주는 코드가 있다면 해결가능.
프리퍼런스에서 Colors의 Playmode 색상을 바꿀 수 있다.
라이더
-
IDE?? 게임개발에 맞춰져있음. 무료화되었다!
-
코드리팩토링기능
-
에셋 참조기능
-
이벤트함수확인
-
기여자 확인
-
직렬화 가능여부 표기
-
호출 빈도 높은 함수 확인
-
다이어그램그리기
-
키맵설정을 가져오면 비주얼스튜디오 단축키를 그대로 사용가능
-
템플릿 생성
-
선넘은조언 Ctr + . 을 하면 검사중요도를 낮출수있다.
-
라이더 단축키
- F12 구현찾기
- Shift + F12 모든 참조 찾기
- Ctrl + - 돌아오기
- Ctrl + M + M 코드 블록 접기
- Ctrl + . 하면 제안을 받을 수 있다. => 빠른 수정 기능
- 알트 후 드래그시 커서를 증식시킬 수 있다.
- Ctr+K+C => 주석처리 => Ctr + K + U => 주석해제
- Ctr + BackSpace 빠르게 지울 수 있다.
LogViewer
- 디버그정보확인가능
라이더 중단점 + 디버깅 시연
- 메모리탭에서 insert를 눌러서 새 watch를 추가하고 여기에 내가 보길 원하는 데이터값을 입력하여 값을 확인 가능
유니티 - 프로젝트이름 - Temp - Backupscenes -> 씬 백업정보 저장됨.
디자인 패턴
-
디자인 패턴은 무엇인가
객체지향 코드 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 설계 패턴
문제
객체지향 프로그래밍을 설계할 때 -> 다른 사람이 작성한 기존 코드를 파악, 수정, 기능 추가
성능하락, 버그발생 등이 발생할 수 있다. 복잡할 수 록 더더욱
-> 디자인 패턴이 강력한 해결 도구가 될 수 있다. -> 효율적인 커뮤니케이션 수단이다.
ex ) 싱글톤, 옵저버, 팩토리 등으로 만들자! << 직관적, 효율적
개발 중 마주치는 대부분의 문제는 이미 수많은 개발자들이 경험한 문제이므로, 이를 해결책으로 만들어낸
설계 전략이 바로 디자인 패턴이다
-
아무리 좋은 디자인 패턴이라도 무조건적인 적용은 해가 될 수 있다.
중요한 것은 "패턴을 사용하는 것" 이 아니라 "왜 이 구조(패턴)가 효과적인가" 를 이해하여야한다.
절대적인 해결책이 아닌 반복적으로 나타나는 문제에대한 효과적인 설계관점을 제공하는 방법론이다.패턴을 도입할때는 "정말 필요한가? 효과적인가?" 를 먼저 고민하고, 코드의 간결성과 명확성을 우선하여야 한다.
1. 싱글톤
프로그램 전체에서 단 하나의 인스턴스만 존재하도록 보장하는 디자인 패턴
=> 무분별하게 쓰면 유지보수성을 해친다. 오디오매니저, 데이터매니저, 풀매니저, UI매니저 등등 객체하나로 유지되어야 할 오브젝트들에 적용
특징 )
전역 접근성, 유일한 인스턴스 보장, 생성자 접근 제한 ( 외부에서 싱글톤객체 생성을 막는다. )
ex )
GameManager, AudioManager, SceneLoader, UserDataManager, PoolManager
조건 )
여러 시스템에서 공통적으로 사용, 상태를 유지, 게임 전체 수명주기동안 살아있음, 유일하게 존재.
2. 팩토리
인스턴스를 생성할 때, 객체 초기화나 해줘야 할 동작들을 팩토리 라는 클래스에서 전담.
코드가 비대해지는 것을 방지하고 초기 생성의 문제를 팩토리에서만 관리하므로 유지보수 용이
3. 오브젝트 풀
객체를 반복적으로 재사용하고 파괴하는 비용을 줄이기 위해서, 미리 생성해둔 객체를 재사용
오브젝트를 비활성화 두었다가, 필요할때 재활성화 해서 쓰는 구조
기본 구조 )
ObjectPool 풀에서 비활성화 된 오브젝트를 가지고 있다가 필요하면 사용 / 사용 후 반납
반납 은 Queue나 list화 해서 반납
- 팩토리와 오브젝트 풀의 합체도 가능 ( 팩토리는 생성과 관련되어있으므로 )
4. 옵저버
어떤 객체의 상태변화가 생기면 그 객체에 등록된 여러 다른 객체들에게 자동으로 알림을 보내는 설계패턴
플레이어 체력이 깎일 때 -> UI에서 이를 항상 업데이트하기 매우 번거로움.
UI가 플레이어를 항상 감시?? 하는 패턴
5. 중재자
객체들 간의 직접적인 상호작용을 막고, 대신 중간에서 조정하는 객체를 두는 구조.
- 중재자와 옵저버를 합친 이벤트버스, 이벤트 채널 클래스를 만들어서 사용
Enum -> 이벤트이름
Dictionary로 이벤트 이름을 키값, Value로 Action
Subscribe로 구독 UnSubscribe로 구독해제 , Publish로 액션을 실행
6. 스테이트
각 상태를 클래스로 캡슐화 => 상태전이 fsm을 만들어낼 수 있다.
7. 전략패턴
상속을 통해 같은 메서드를 사용하여 다른 동작
8. 커맨드 패턴
명령을 객체로 캡슐화하여, 요청을 나중에 실행하거나 취소하거나 로그에 기록
