2026/06/01

1.코드카타

2.AI퀴즈

3.언리얼 기초 다지기

4.기획 수업

---

코드카타(하루 3문제씩)

-두 수의 곱

-몫 구하기

-나이 출력

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>

int solution(int age) 
{
    int answer = 0;

    if(0<age && age<=120)
    {
        answer = 2023 - age;
    }
    return answer;
}

---

AI퀴즈

-애니메이션 개념 학습 필요

 

문제1:다음 코드는 Tick 함수를 사용하여 액터를 회전시키는 코드입니다. 빈칸에 들어갈 올바른 코드는 무엇인가요?

void AMyActor::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);
    
    FRotator NewRotation = GetActorRotation();
    NewRotation.Yaw += 90.0f * DeltaTime;
    ____________________;
}

정답: A - SetActorRotation(NewRotation);

내가 고른답: AddActorRotation(NewRotation);

오답노트: SetActorRotation() vs AddActorRotation()

SetActorRotation()

• 액터의 회전을 내가 지정한 회전값으로 설정

AddActorRotation()

• 액터의 현재 회전에 내가 준 회전량을 추가

• SetActorRotation() = 시계 바늘을 3시 방향으로 맞추기
• AddActorRotation() = 현재 시계 바늘에서 30도 더 돌리기

---

언리얼 기초 다지기

1-2강 강의 완

 

학습하면서 궁금했던 부분

의문1:왜 채팅UI를 플레이어 컨트롤러에 연결할까?
1.생명주기: 캐릭터가 죽을때 월드에서 사라지는 게임이라면 캐릭터가 죽어도 
채팅은 유지되어야 하기 때문.
캐릭터 리스폰 중에도 채팅창이 닫히거나 기존 대화 기록이 날아가지 않게 하기 위함.
2.입력처리: 언리얼에서 키보드나 마우스의 입력을 가장 먼저 받는 곳이
플레이어 컨트롤러다. 
채팅중에는 캐릭터 조작을 막고 채팅을 끄면 다시 마우스 커서
를 숨기는 등 입력상태 제어가 용이함.
3.네트워크:채팅을 칠 때 구조 (내 플레이어 컨트롤러->서버->다른 플레이어의 컨트롤러)
이런 순서이기 때문에 서버와 통신할 수 있어야 함.
플레이어 컨트롤러 클래스는 서버와 통신할 수 있는 대표적인 클래스.

의문2:왜 채팅UI를 플레이어 컨트롤러에 연결할 때 헤더에 변수가 2개필요할까? (Class, Instance)
어떤 UI를 만들지 고르는 용도:ChatInputWidgetClass
메모리에 생성된 진짜 UI:ChatInputWidgetInstance
Class가 있어야 Instance를 찍어낼 수 있음.

의문3.왜 OwingCXPlayerController->SetChatMessageString(Text.ToString()); 에서 Text.ToString() 이렇게 쓸까?
일단SetChatMessageString()함수에서 파라미터가 FString이고
FText와 FString은 용도가 다르기 때문인데.
FText:화면에 보여주기 위한 글자상자(UI용)
FString:컴퓨터로 조작하기 좋은 글자상자(기능용)

의문4.채팅을 화면에 띄우는 PrintString함수의 파라미터 중 맨 앞에 붙는 WorldContextObject이게 뭐지?
WorldContextObject: "이 함수를 실행하는 기준 공간이 어디인지 알려달라"는 뜻
this를 넣는이유:코드 작성장소가 ACXPlayerController인데 이 오브젝트가 있는 월드에 생성해 달라는 의미.

 

이해 잘 안되는 부분

void UCXChatInput::NativeConstruct()
{
	Super::NativeConstruct();

	if (EditableTextBox_ChatInput->OnTextCommitted.IsAlreadyBound(this, &ThisClass::OnChatInputTextCommitted) == false)
	{
		EditableTextBox_ChatInput->OnTextCommitted.AddDynamic(this, &ThisClass::OnChatInputTextCommitted);
	}
}

void U현재클래스이름::NativeConstruct()
{
	Super::NativeConstruct();

	// 1. 연결하기 (방어막 버전)
	if (내컴포넌트이름->이벤트이름.IsAlreadyBound(this, &ThisClass::내함수이름) == false)
	{
		내컴포넌트이름->이벤트이름.AddDynamic(this, &ThisClass::내함수이름);		
	}	
}

void UCXChatInput::OnChatInputTextCommitted(const FText& Text, ETextCommit::Type CommitMethod)
{
	if (CommitMethod == ETextCommit::OnEnter)
	{
		APlayerController* OwingPlayerController = GetOwningPlayer();
		if (IsValid(OwingPlayerController) == true)
		{
			ACXPlayerController* OwingCXPlayerController = Cast<ACXPlayerController>(OwingPlayerController);
			if (IsValid(OwingCXPlayerController) == true)
			{
				OwingCXPlayerController->SetChatMessageString(Text.ToString());

				EditableTextBox_ChatInput->SetText(FText());
			}
		}
	}
}
// 1."유저가 그냥 마우스를 딴 데 클릭한 게 아니라, 진짜로 'Enter' 키를 눌러서 글을 보낸 게 맞나?" 확인하는 조건문
// 2.이 UI를 소유하고 있는 진짜 유저(플레이어 컨트롤러)를 찾아옵니다. (기본형 리모컨)
// 3.중요(Cast): "가져온 리모컨이 우리가 만든 커스텀 리모컨(ACXPlayerController)이 맞는지" 확인하고 형변환합니다.
// 4.유저 리모컨에게 "방금 입력받은 글자(Text)를 문자열로 바꿔서 전송해줘!" 라고 명령을 내립니다.
// 5.전송이 끝났으니 내가 타이핑했던 입력창의 글자들을 다시 깨끗하게 빈 칸(FText())으로 비워줍니다.

 

 

 

---

기획수업- 전투 시스템 설계 이론

기획자가 타인과 소통할 때 태도를 참고하기 좋은 책 3권
1.언어의 온도
2.자존감 수업
3.말그릇

 

R&R 나누기 (책임과 역할을 밸런스있게)

 

다음 팀플 때 시도해보기
[ ] 회의 규칙 정하기 — "의견을 낼 땐 근거도 같이 / 지금은 결정할 시간인가 수렴할 시간인가 구분하기"를 회의 첫머리에 합의
[ ] 읽히는 기획서 쓰기 — 핵심을 맨 앞에, 한 장 요약을 먼저. 팀원이 안 읽는다는 전제로 작성
[ ] 기획 동결(freeze) 시점 정하기 — "이 시점 이후엔 핵심 기획을 바꾸지 않는다"를 킥오프에서 합의해, 선기획 후개발을 강제
[ ] 역할·스코프 합의 양식 쓰기 — 누가 무엇을 언제까지, 구현 가능 여부를 확답으로 적어두기
[ ] AI 활용의 내 기준 정하기 — 어디까지 AI에 맡기고 어디부터 내가 할지 스스로 선 긋기
[ ] 온라인 협업 방식 설계하기 — Zep 외 비동기 협업 툴과 문서 동기화 방법을 팀 차원에서 미리 정하기
[ ] 잘 만든 게임의 기획 뜯어보기 — 좋아하는 게임을 역기획해보며 기획 안목과 자신감 기르기

 

수업 목표

• 재미있는 전투의 3가지 조건(판단의 여지/성장감/즉각적 반응)을 설명할 수 있다.
• 히트박스, 허트박스, 공격 3단계(스타트업/활성/후딜레이)의 의미를 이해한다.
• 텔레그래프의 중요성과 올바른 설계 방법을 이해하고 기획서에 적용할 수 있다.
• 보스전의 페이즈 구조와 패턴 설계 원칙을 이해하고 직접 설계할 수 있다.
• 클래스, 빌드 다양성, 카운터 구조가 전투에 깊이를 주는 방식을 설명할 수 있다.
• 속성 상성 시스템의 기획 의도와 원소 반응 설계 원칙을 이해한다.
• 콤보 시스템의 3가지 구조(버튼 시퀀스/자동 이어지기/스킬 연계)와 설계 원칙(캔슬·감쇠)을 이해한다.
• 무적 프레임(I-Frame)의 원리와 가드·패링 시스템의 리스크-리워드 구조를 설명할 수 있다.
• 전투 리소스(마나/스태미나/게이지) 유형과 설계 원칙 5가지를 구분할 수 있다.
• 난이도 스케일링의 4가지 방법을 이해하고 적절한 방법을 선택할 수 있다.

 

재미있는 전투의 3가지 조건

판단의 여지	버튼만 누르는 기계로 만들지 말고, 전투 중에 계속 '고민하고 선택하게' 만드는 것.
성장감	처음보다 지금의 내가 확실히 강해졌고, 전투가 수월해졌다는 느낌을 주는 것
즉각적 피드백	타격감의 본질

 

전투 시스템: 재미있는 전투의 조건 '판단의 여지'

• 행동심리학적 이유:
  • 사람은 남이 시켜서 하는 것보다 '내가 직접 상황을 판단하고 결정해서 성공했을 때' 훨씬 더 큰 성취감을 느낀다. (자율성의 원리)
• 실제 게임 예시:
  • 예시 1: 원신에서 적이 강력한 광역기를 쓰려고 바닥에 장판을 깔았을 때, [대시로 범위를 벗어날 것인가] vs [무적 판정이 있는 스킬로 맞받아칠 것인가] 선택하는 순간.
  • 예시 2: 붕괴스타레일에서 적의 속성 보호막을 보고, 내가 가진 캐릭터 중 어떤 속성으로 카운터를 칠지 덱을 고민하는 순간.
• 기획자로서의 생각:
  • 유저에게 판단을 유도하려면 먼저 적이 뭘 할지 '힌트(전조 동작)'를 줘야 한다. 힌트도 안 주고 알아서 맞추라는 건 판단이 아니라 불합리한 찍기다. 유저가 '내 실력으로 이겼다!'고 느끼게 판을 깔아주자.
  • 다크 소울류 게임들의 보스가 플레이어 캐릭터보다 큰 이유는 보스의 행동패턴을 잘 보이게 하여 힌트를 확실하게 주는 의미도 있다고 생각한다. 또한 보스를 마주하기 전의 그 맵의 잡몹과 엘리트 몬스터들을 통해 보스가 어떤 행동패턴을 사용할지 미리 플레이어에게 학습시키는 것도 하나의 힌트라고 생각된다.

전투 시스템: 재미있는 전투의 조건 '성장감'

 

• 핵심 구분 (성장감의 두 가지 루트):
  1. 플레이어의 성장 (컨트롤/패턴 숙지): 다크소울처럼 유저가 30번 죽어가며 보스 패턴을 다 외워 피지컬로 깨는 맛. 
  2. 캐릭터/시스템의 성장 (스펙/도구): 일반적인 RPG나 오픈월드 게임처럼 레벨업, 장비 세팅, 카운터 캐릭터 조합을 통해 옛날엔 고전했던 정예 몹을 3초 만에 녹여버리는 맛.
• 실제 게임 예시:
  • 원신에서 엔드 컨텐츠인 지맥제압전을 도전할 때 캐릭터 가챠를 통해 카운터 조합을 완성하여 전에는 깰 수 없었던 최고 난이도를 클리어 할 수 있게 되는 성취감 
• 기획자로서의 생각:
  • 성장감을 주려면 반드시 초반의 불리함/답답함과 후반의 유리함/쾌적함의 격차를 의도적으로 설계해야 한다. 바이오 하자드가 이 부분에서만큼은 정말 잘 설계 했다고 생각된다. 엄청난 수의 좀비가 몰려오지만 총알의 수량을 넉넉하게 주지 않고 딱 그 맵의 좀비 수량만큼 처치할 정도로 총알을 맵에 배치 해 놓기 때문에 항상 판단의 순간이 찾아오고 게임 후반부로 갈 수록 의도적으로 더 좋은 성능의 총기류를 해금 해주고 총알도 넉넉하게 배치해뒀다. 

전투 시스템: 재미있는 전투의 조건 '즉각적인 피드백'

 

• 피드백을 주는 방법들:
  1. 시각: 화려한 검기 이펙트, 적이 뒤로 넘어지는 모션, 카메라 흔들기, 묵직함을 주는 '역경직(Hit Stop)'.
  2. 청각: 베기/타격/마법 등 무기 속성에 맞는 찰진 사운드 효과음.
  3. 촉각: 상황에 맞춰 패드가 부르르 떨리는 햅틱피드백.
  4. UI: 크리티컬 터졌을 때 엄청 크게 뜨는 빨간색 데미지 숫자.
• 실제 게임 예시:
  • 명조에서 초거대 로봇이 검을 땅으로 찍는 궁극기를 쓸 때, 화면이 크게 흔들리며 지진이 나는 듯한 사운드 출력 및 몹의 체력바가 줄어드는 연출.
  • 반대로 적의 공격을 타이밍 맞춰 딱 막았을 때(패링), '깡!' 하는 청각적 소리와 함께 화면이 순간적으로 슬로우 모션이 되며 적이 무방비 상태로 비틀거리는 피드백.
• 기획자로서의 생각:
  • 즉각적인 피드백이 밋밋하면 유저는 전투에서 흥미가 떨어진다. 반대로 피드백만 훌륭해도 게임을 조작하는 맛이 산다. 대표적인 게임으로 파이널판타지16이 있을 것 같은데 엄청나게 화려한 전투 스킬 이펙트와 조작이 어렵지 않은데 플레이어가 엄청 전투를 잘해 보이게 만드는 연출이 많이 들어가 있다. 적의 공격을 타이밍에 맞춰 퍼펙트 회피? 닷지를 하면 굉장히 화려한 이펙트 연출과 묵직한 사운드를 출력하면서 회피 한번에 전투 고수가 된 기분을 느끼게 해준다.

 

히트박스, 허트박스, 공격 3단계

히트박스:공격이 적중하는 범위

허트박스:공격 받는 범위

히트박스와 허트박스가 겹쳐지는 순간이 히트 판정

공격 3단계:

단계 1 : 스타트업 (Startup)
  공격 전 준비 동작 단계
  → 히트박스가 아직 없음
  → 길수록 피하기 쉬움 (느린 공격)
  → 짧을수록 반응이 어려움 (빠른 공격)
  → 기획서에서 "선딜레이" 또는 "준비 프레임"으로 표기

단계 2 : 활성 프레임 (Active Frame)
  실제 히트박스가 켜지는 구간
  → 이 구간에 허트박스와 겹치면 데미지 발생
  → 길수록 맞추기 쉬운 공격

단계 3 : 후딜레이 (Recovery / Endlag)
  공격 후 다음 행동 가능까지의 딜레이
  → 길면 공격 후 반격에 취약 = 리스크
  → 짧으면 안전한 공격 = 낮은 데미지로 밸런스 조정 필요
  → "큰 공격 = 높은 후딜레이 = 높은 데미지" 리스크-리워드 균형

 

 

 

텔레그래프

텔레그래프 = 공격 전에 주는 예고 신호.

내일부터 다시 작성