목차
리팩토링
토요일이라 그런가 딴짓 폭발 중~
접속하고 한시간 정도 유튜브 순회 돌고.. 다른 팀원들 접속한 걸 보고 정신 차리고 리팩토링에 시작했다.
코드로만 작성하면 조금 헷갈리고, 어느부분 했는지 안했는지 헷갈려서
다이어그램 또한 손보면서 병행하고 있다.


이런식으로 리팩토링 진행 전(즉, 검토 전)인 부분은 회색처리해두고 완성되면 하얗게 변경하는 방식으로 진행하고 있다.
일단 오류 안뜨고, 뭔가 굴러는 가고.. 하는 방식으로 완료된것 같음.
[RequireComponent()]
위 속성을 사용하면 필수 구성 요소를 종속성으로 자동 추가한다.
예를 들어 Rigidbody가 필요한 객체인데, 개발자가 깜빡하고 해당 컴포넌트를 추가하지 않을 수 있다.
이러한 휴먼에러를 방지하기 위해 사용될 수 있는 것이다.
또한 종속된 컴포넌트를 삭제하려하면 다음과 같이 삭제할 수 없다는 경고 메시지를 출력한다.

[RequireComponent(typeof(BossMonster))]
public class BossMonsterAI : MonsterAIBase
{
private void Start()
{
monster = GetComponent<BossMonster>();
InitializeBehaviorTree();
}
위와 같이 코딩함으로써 monster의 null 체크를 하지 않아도, RequireComponent attribute 덕분에 null 에러가 뜰 일이 없다!
주의사항
첫째로,
이미 부착된 스크립트에는 RequireComponent가 다시 작동하지 않는다.
즉, 해당 스크립트가 컴포넌트로 추가되어있었을 경우,
추후에 RequireComponent 속성을 추가하더라도 종속성 체크 및 필요한 컴포넌트를 자동으로 추가해주진 않는다.
따라서, 스크립트가 게임 오브젝트에 부착되는 순간에, 혹은 AddComponent를 호출할때 그 효과가 나타나는 것이다.
둘째로,
추상클래스의 경우 컴포넌트로 추가될 수 없기 때문에, 이를 잘 생각해서 진행해야한다.
셋째로,
상호 참조는 할 수 없다. MonsterCondition과 MonsterAI는 둘 다 함께 존재해야하는 상황이라도,
한 스크립트에만 RequireComponent 속성을 부여하는 것이 좋다.
상호 참조의 경우, 무한 순환이 발생할 수 있기 때문에 본래의 목적한 결과를 얻지 못할 수도 있기 때문이다.
결론
일단 배우게 된 거라 정리를 해봤는데, 당분간은 사용하지 않을 것 같다!
사용하더라도 rigidbody나 trigger용 boxcollider같은, 유니티 제공 클래스만 하는 것이 안전할 것 같음.
느낀점
리팩토링을 끝냈는데도 찝찝하다.
왜지...? 뭔가 빠뜨린 기분.
더 보면 볼수록 세세한 조정이 계속 들어갈 것 같아서 여기서 그만두기로 했다.
내일 학습 할 것은 무엇인지
일단 에디터에서 플레이를 눌렀을 때, 순간 버벅이는 것처럼 보이는데 내 유니티 문제인지, 내 코드의 문제인지 파악해야할 것 같다.
이제 리팩토링이 끝났으므로 본격적으로 BT의 Behaviour Node들을 생성할 수 있게 되었다.
일단은 대각선이든 뭐든 상관없이 전진할 수 있도록만 만들어서, 이동하는 듯한 기분 정도만 냈다.
이거라도 성취감 느껴야 잘 잘것 같았다...
내일은 상하 이동을 제한하고 좌우 이동만 가능하게 구현하고,
공격 스킬들을 제외한 노드들을 구현할 예정이다.
그 후, 공격 셀렉터, 시퀀스까지만 구현하고 하위 노드들을... 몬스터팀 다른 분들과 나누지 않을까 싶다!
'부트캠프 > 본캠프' 카테고리의 다른 글
| [내일배움캠프_2025SEP15] 스킬 구현 시작, 레이어비트마스크 (0) | 2025.09.15 |
|---|---|
| [내일배움캠프_2025SEP14] BT 구현 시작, 코드 리뷰 가능할까...? (0) | 2025.09.14 |
| [내일배움캠프_2025SEP12] DataHandler, 상속 설계의 중요성 (0) | 2025.09.12 |
| [내일배움캠프_2025SEP11] Behavior Tree (0) | 2025.09.11 |
| [내일배움캠프_2025SEP10] 프레임워크 몹 프로그래밍, 최적화 학습 (0) | 2025.09.10 |