최라마 1인 게임 개발자 모임 후기
- 출시한 사람과 안한 사람의 인력이 다름을 느꼈음
- 생각보다 더 소울라이크 개발자가 없음을 느꼈다
- 아마 개발하기 어렵다고 느껴서 도전하지 않는 듯 함
- 언리얼 개발은 재직자 한 명만 있었고 나머진 다 유니티 고도 엔진이었음
- 게임 음악 개발에 진심인 분을 만나서 놀라웠다
- 나중에 프로토타입 만들면 제안해보면 좋을 듯
- 생각보다 업계에서 AI 사용에 관한 확실한 프레임워크는 확립되지 않아보인다
- 게임개발은 웹개발보다 AI 활용이 더디다는 생각이 들었음
6. 캐릭터 공격 판정
레거시 네이밍 컨벤션
AnimInstance->Montage_Play(DeadMontage);이런 코드가 있어 언리얼 코딩 표준 문서를 찾아봤는데도 메소드 네이밍에 언더스코어 써도 된다는 이야기가 없어서 강사님과 AI한테 물어봄
- 대부분 이런 경우는 아주 오래된 레거시 호환성 목적으로 남아있는 것
클로저
FTimerDelegate::CreateLambda([]() { Destroy(); })[&]는 **"모든 외부 변수를 참조로 캡처"**를 의미- 여기서는
this포인터를 암묵적으로 캡처 Destroy()는this->Destroy()와 동일- AI의 경고: 위 람다 함수에선 타이머가 실행될 때 이미 객체가 파괴되었을 수 있다며, &는 참조로 캡처하므로 댕글링 포인터의 위험이 있다고 지적함
- →
FTimerDelegate::CreateWeakLambda(this, [this]() { Destroy(); })사용을 권장함
- →
7. 캐릭터 스탯과 위젯
- 스탯 컴포넌트: 액터에 부착할 수 있는 컴포넌트 중 Transform이 없는 컴포넌트
- 액터 기능 확장할 때 컴포넌트로 모듈화하면 좋음
- 스탯 데이터 담당 컴포넌트와 UI 위젯 담당 컴포넌트로 분리
- 액터는 두 컴포넌트가 서로 연결되도록 중개하는 역할
- 두 컴포넌트가 소통을 하기 위해 필수불가결하게 어디선가는 무조건 한 번 연결해주는 다리를 놓아줘야 함. 어쩔 수 없음.
- 명시적 연결부가 없이 서로 소통한다면 그건 상온초전도체같은 마법임
IEEE 754 부동소수점
https://devocean.sk.com/blog/techBoardDetail.do?ID=165270
- 부표처럼 떠다닌다 해서 부동 소수점(뜰 부(浮)에 움직일 동(動))
- 123.45를 부동소수점으로 표현할 때
부호 x 가수 x 밑수(지수)로 표현 - 밑수와 지수가 바뀜에 따라 가수가 변하기 때문에 floating한다고 부름
- 이걸 정규화(가수가 밑수보다 작은 한 자리 자연수 1로 고정)하면 정수부는 표현하지 않고 가수부와 지수부만으로 표현할 수 있기 때문에 정규화를 함
UE_KINDA_SMALL_NUMBER:(1.e-4f)
액터의 라이프 사이클
위젯 컴포넌트와 위젯
- '위젯 컴포넌트'는 액터 위에 UI 위젯을 띄우는 동작을 관리하는 컴포넌트
- '위젯'은 UI를 그리는 역할
위젯 컴포넌트의 초기화 과정
- 발행-구독 모델 구현을 위해 위젯 컴포넌트의 초기화 단계를 파악할 필요가 있음
- UI 관련 컴포넌트는 액터의
BeginPlay()이후에 호출됨 - 생성 시
InitWidget함수와NativeConstruct함수를 호출NativeContstruct를 사용하면 액터와 위젯의 초기화 이후 시점이므로 두 객체의 존재를 보장받을 수 있음
- 위젯 컴포넌트는 설계상 반드시 액터 하위에서 호출된다는 보장이 없으므로 소유 액터에 대한 정보를 지원하지 않음. 따라서 우리의 경우에 소유 액터 정보를 보관할 수 있도록 확장해야 함