개요



[ 5.3. 플레이어 입력 ] 에서 어떤 플레이어 입력이 있는지 살펴 보았습니다. 이 섹션에서는 이동과 관련한 로직 및 애니메이션에 대해서 살펴 보도록 하겠습니다.


이동( locomotion, 보행, 운동 )과 관련된 로직에 대해서 다루도록 하겠습니다. 간단하게 요약하자면 UT 의 이동 로직은 UUTCharacterMovment 컴포넌트에 의존합니다. Character component 의 처리 결과에 따라서 어떠한 애니메이션들을 블렌딩할지를 결정하게 됩니다.


1인칭 캐릭터에서는 "Content/RestrictedAssets/Universal/1stPerson/UT4_Base_1stP_AnimBP.uasset" "Main_Motion" FSM( finite state machines ) 을 사용하며, 3인칭 캐릭터에서는 "Content/RestrictedAssets/Animations/Universal/UT4_Base_AnimBP.uasset""Locomotion" FSM 과 "Landing" FSM 을 사용합니다.


일단 Character Movement 컴포넌트의 주요 역할은 물리와 애니메이션에서 사용할 자료( 변수 )를 준비하는 것입니다. 만약 Character Movement 컴포넌트가 없고 Player Controller 만 존재한다면, Player Controller 나 Character 에서 물리 및 애니메이션을 처리해야만 할 것입니다.


Character Movement 컴포넌트



UT 에서 기본 Character Movement 컴포넌트의 클래스는 UUTCharacterMovement 입니다. "DefaultCharacter" 블루 프린트를 열어서 "Components" 뷰를 보면 아래쪽에 "UTCharacterMovment(Inherit)" 라는 항목을 볼 수 있습니다. 오른쪽의 "Details" 뷰를 보면 매우 많은 속성 카테고리들이 존재함을 알 수 있습니다.



보시면 알겠지만 게임에서 사용할 만한 상황들은 거의 다 들어 가 있습니다. 물론 상황에 맞춰 FSM 을 구성하는 수고는 해야 합니다.


이동 모드 



Character Movement 컴포넌트에서 이동 모드의 전환은 FSM 으로 표현될 수 있습니다만 여기에서 다루지는 않겠습니다. 애니메이션 블루프린트마다 애니메이션 FSM 을 따로 구성하기 때문에 코드 상에서의 상태 전환에 대해서 언급하는 것은 크게 의미가 없을 것 같습니다. 애니메이션 FSM 에 대해서는 다른 문서에서 다루도록 하겠습니다. 단지 다음과 같은 이동 모드들이 있다는 것만 알아 두시면 될 것 같습니다.


    • Walking : 땅바닥에 붙어서 걸어다니는 이동 모드.
    • NavWalking : AI 등이 네비게이션 메쉬와 길찾기를 통해서 걸어다니는 모드.
    • Swimming : 물에 들어 갔을 때의 이동 모드.
    • Falling : 점프를 하거나 바닥에 닿지 않아 떨어지고 있을 때의 이동 모드.
    • Custom : 사용자의 커스텀한 이동 모드.
    • Flying : 날아다니는 이동 모드.


이제 각 이동 모드와 관련한 중요한 속성들을 살펴 보도록 하겠습니다. 대부분 어렵지 않은 속성들을 가지고 있기 때문에 이해하는데 큰 어려움은 없을 것입니다. 일단 어떤 기능들을 가지고 있는지 이해하고 있어야지 이미 존재하는 기능을 또 구현하는 불상사를 막을 수 있기 때문에, 지루하더라도 한 번씩은 읽어 보시기 바랍니다. 


제가 밥상은 차려줄 수 있지만, 떠 먹는건 알아서 하시기 바랍니다.


Character Movement




각 이동 모드의 가속도 및 감속도를 설정하는 곳입니다.


 이름

 설명

 MaxFallingAcceleration

  • Falling 시의 최대 가속도( 이는 AirControl 속성에 의해 스케일링 됨 ).

 MaxSwimmingAcceleration

  • Swimming 시의 최대 상수 가속도.

 MaxRelativeSwimmingAccelNumerator

  • Swimming 시의 부가적 가속도인데, 속도 크기에 의해 나눠짐. Swimming 가속도는 MaxSwimmingAcceleration + MaxRelativeSwimmingAccelNumerator / ( Speed + MaxRelativeSwimmingAccelDenominator ) 임.

 MaxRelativeSwimmingAccelDenomitor

  • Swimming 가속도 공식의 일부.  Swimming 가속도는 MaxSwimmingAcceleration + MaxRelativeSwimmingAccelNumerator / ( Speed + MaxRelativeSwimmingAccelDenominator ) 임.

 BrakingDecelerationSliding

  • Sliding 시의 정지 감속도.

 DefaultBrakingDecelerationWalking

  • Walking 시의 정지 감속도 - BrakingDecelerationWalking 과 같은 값으로 설정하라.

 IgnoreClientMovementErrorChecksAndCorrection

  • true 이면, 이 이동 컴포넌트 상에서 클라이언트 에러를 위한 서버 위치 차이 검사를 무시한다.
  • 이는 캐릭터가 잠시 동안 극단적인 속력으로 움직이는데 클라이언트에서 부드럽게 보이도록 만들고 싶을 때 유용하다. 사용하고 나면 비활성했는지 확인해야 한다. 왜냐하면 이것은 캐릭터의 서버-클라이언트 이동 보정을 오동작하게 만들기 때문이다.


Character Movement(General Settings)




일반적인 설정을 하는 곳입니다.


 이름

 설명

 GravityScale

  • 커스텀 중력 스케일. 캐릭터를 위한 중력에 이 값이 곱해진다.

 MaxAccelleration

  • 최대 가속도( 속도가 변하는 비율 ).

 BrakingFrictionFactor

  • 정지할 때 사용되는 실제 마찰력 값에 곱해지기 위한 요소이다.
  • 이는 현재 사용되는 모든 마찰력 값에 적용된다. UseSeperateBrakingFriction 에 의존한다.
  • @note : 이는 경험적 이유로 2 값이 기본값이다. 1 값은 실제 drag equation 이다.

 BrakingFriction

  • ( Acceleration = 0 이거나 캐릭터가 최대 속력을 초과하고 있을 때마다 ) 정지시에 적용될 마찰력 ( drag ) 상수; 실제 사용되는 값은 BrakingFrictionFactor 와 곱해진다.
  • 정지중일 때, 이 속성은 바닥을 통해 움직이고 있을 때 얼마나 많은 마찰력이 적용될지를 제어할 수 있도록 해 준다. 이는 현재 속도를 스케일링하는 반대쪽 힘을 적용하게 된다.
  • 정지는 마찰력( 속도 의존적인 drag )와 상수 감속( deceleration )으로 구성된다.
  • 이는 모든 이동 모드에서 사용되는 현재값이다; 만약 이것을 원하지 않는다면, 이동 모드가 바뀔 때 이 값이나 bUseSeperatedBrakingFriction 을 재정의하라.
  • bUseSerperatedBrakingFriction 이 true 일 때만 사용된다. 그렇지 않으면 GroundFriction 같은 현재 마찰력이 사용된다.

 UseSeperateBrakingFriction

  • 만약 true 이면, ( 가속이 없을 때 ) 캐릭터를 천천히 멈추게 하기 위해서 BrakingFriction 이 사용될 것이다.
  • 만약 false 이면, CalcVelocity() 에 넘겨지는 것과 같은 마찰력을 사용할 것이다( 예를 들어 걸어다닐 때의 GroundFriction ). 이는 BrakingFrictionFactor 와 곱해진다.
  • 이 설정은 모든 이동 모드에 적용된다; 만약 특정 모드에서 이를 원하지 않는다면, 이동 모드가 변경될 때 토글링하는 것을 고려해 보라.

 CrouchedHalfHeight

  • Crouching( 앉기 )시에 사용할 충돌 절반 높이( 컴포넌트 스케일이 각각 적용됨 ).

 RotationRate

  • 초당 회전률. UseControllerDesiredRotation 이나 OrientationToMovement 가 true 일 때 사용된다. Infinite rotation rate 와 instant trun 을 위해서는 음수값을 설정한다.

 OrientRotationToMovement

  • true 이면, 가속 방향을 향해 캐릭터를 회전시킨다. 이 때 회전률은 RotationRate 를 통해 지정된다. UsecontrollerDesiredRotation 을 덮어 쓴다.
  • 보통 캐릭터의 UseControllerRotationYaw 같은 다른 설정들이 클리어되어 있기를 기대할 것이다.

 Mass

  • 폰( pawn )의 질량( 운동량( momentum )이 주어졌을 때를 위해 ).
 DefaultLandMovementMode
  • 물 속에 있지 않을 때의 기본 이동 모드. 플레이어 스타트업이나 텔레포트시에 사용됨.
  • Walking
  • NavWalking
  • Falling,
  • Swimming
  • Flying
  • Custom
 DefaultWaterMovementMode
  • 물 속에 있을 때의 기본 이동 모드. 플레이어 스타트업이나 텔레포트시에 사용됨.

 JustTeleported

  • 위치 변화가 일반 이동에 의한 것인지 텔레포트에 의한 것인지 결정하기 위해서 이동 코드에서 사용됨. 만약 텔레포트가 아니면, 위치 변화 기반해 속도가 재계산될 수 있음.

 WantstoCrouch

  • true 이면, 다음 업데이트시에 crouch( 혹은 crouch 유지 )를 시도함. false 이면 다음 업데이트시에 crouching 종료를 시도함.
 UseControllerDesiredRotation
  • true 이면, 컨트롤러의 회전을 향해서 캐릭터를 부드럽게 회전시킨다. 이 때 회전률은 RotationRate 를 통해 지정된다. OrientRotationToMovement 에 의해 덮어 써 진다.
 EnableScopedMovementUpdates
  • If true, high-level movement updates will be wrapped in a movement scope that accumulates updates and defers a bulk of the work until the end.
  • When enbled, touch and hit events will not be triggered until the end of multiple moves within n update, which can improve performance.
  • 역주 : 이동을 누적시키는 것과 관련한 업데이트들을 한 번에 묶어서 처리하고, 나머지 업데이트들은 지연시켜서 나중에 처리하는 기능을 의미하는 듯하다.

 RunPhysicsWithNoController

  • true 이면, 캐릭터 소유자를 위한 컨트롤러가 존재하지 않더라도 이동을 실행할 것이다.
  • 일반적으로 컨트롤러가 없으면, 이동은 무시되며, 캐릭터가 걷고 있다면 속도와 가속도가 0 이 될 것이다.
  • 컨트롤러 없이 생성된 캐릭터에서 이 플래그가 활성화되면, 이동 모드를 DefultLandMovementMode 나 DefultWaterMovementMode 로 적절히 초기화할 것이다.

 MaxSimulationTimeStep

  • 각각의 분절된( discrete ) 시뮬레이션 스텝의 최대 타임 델타이다.
  • 주로 큰 타임 스텝을 쪼개는 진보된 이동 모드에서 사용된다( usually those applying gravity such as falling and walking ).
  • 이 값을 작게 하면, 빠르게 움직이는 오브젝트 시나리오나 복잡한 충돌 시나리오를 해결할 수 있는데, 성능 비용을 지불해야 한다.
  • @경고 : 만약 ( MaxSimulationTimeStep * MaxSimulationIterations ) 가 최소 프레임율보다 너무 작다면, 마지막 시뮬레이션 스텝은 시뮬레이션을 완료하기 위해서 MaxSimulationTimeStep 을 초과할 수도 있다.

 MaxSimulationIterations

  • 각각의 분절된 시뮬레이션 스텝들을 위해 사용되는 반복( iteration ) 횟수.
  • 주로 큰 타임 스텝을 쪼개는 진보된 이동 모드에서 사용된다( usually those applying gravity such as falling and walking ).
  • 이 값을 증가시키면, 빠르게 움직이는 오브젝트 시나리오나 복잡한 충돌 시나리오를 해결할 수 있는데, 성능 비용을 지불해야 한다.
 CrouchMaintainsBaseLocation
  • true 이면, crouching 은 쪼그라든 캡슐의 중심을 낮춤으로써 캡슐의 바닥을 그대로 유지한다. false 이면, 캡슐의 바닥이 위로 올라가고 중심은 그대로 남는다.
  • 같은 행위가 uncrouch 시에도 적용된다: true 이면 바닥은 같은 위치를 유지하고, 중심이 올라 간다. false 이면, 캡슐이 커지고 바닥이 무엇인가와 충돌할 때만 올라간다. 
  • 기본적으로 이 변수는 이동 모드가 변경될 때만 설정된다: walking 일 때 true 로 설정하고 그렇지 않으면 false 로 설정한다. 이동 모드가 변경될 때 이 행위를 재정의하는데 부담가질 필요가 없다.
 RequestedMoveUseAcceleration
  • path following 을 위해 가속도를 사용할지 여부를 결정한다.
  • true 이면, path following 시에 목표 속도에 도달하기 위해서 가속도를 적용한다.
  • false 이면, path following 속도가 직접 설정되며, 가속도를 고려하지 않는다.


CharacterMovement : Walking




걷기와 관련한 설정을 하는 곳입니다. 


 이름

 설명

 MaxStepHeight

  • 캐릭터가 걸어 올라 갈 수 있는 ( 계단의 ) 최대 높이. 

 WalkableFloorAngle

  • 걸어다닐 수 있는 표면의 최대 각도. 이보다 큰 각도이면 걷기에는 너무 뾰족한 것임. 

 WalkableFloorZ

  • 바닥의 법선( normal )에 대한 최소 z 값. 이것보다 크면 걸을 수 없음. WalkableFloorAngle 로부터 계산됨.

 GroundFriction

  • 이동 제어에 영향을 주는 설정. 값이 높을수록 방향이 빠르게 변함.
  • 만약 bUseSeperateBrakingFriction 이 false 라면,  ( Acceleration 이 0 일 때마다 ) 멈출 때 더 빠르게 정지하는 능력에 영향을 주기도 함. 이는 BrakingFrictionFactor 와 곱해짐.
  • 이 속성은 땅바닥 위를 이동하다가 정지할 때 마찰력이 얼마나 적용되어야 하는지를 사용자가 제어할 수 있도록 하는 속성임. 이는 현재 속도를 스케일링하는 반대방향의 힘임.
  • 이 값을 변경함으로써 이는 눈이나 기름과 같은 미끄러운 표면을 시뮬레이션하기 위해서 사용될 수도 있음( 아마도 폰이 서 있는 재질에 기반해서 설정해야 할 것임 ).

 MaxWalkSpeed

  •  걸어다닐 때의 최대 속력. 떨어지고 있을 때의 최대 측면( lateral ) 속도를 결정하기도 함.

 MaxWalkSpeedCrouched

  •  앉아서 걸어다닐 때의 최대 속력.

 BrakingDecelerationWalking

  • 가속도 없이 걸어 다닐 대의 감속도. 이는 상수값에 의해서 속도를 직접적으로 감소시키는 지속적인 반대방향의 힘이다.

 CanWalkOffLedges

  • true 이면 캐릭터가 절벽 가장자리( ledge )에서 걸어서 떨어질 수 있음.

 CanWalkOffLedgesWhenCrouching

  • true 이면 캐릭터가 앉아서 걸어다닐 때 절벽에서 걸어서 떨어질 수 있음.

 CurrentFloor

  • 캐릭터가 서 있는 바닥에 대한 정보( 걷기 이동시에만 갱신됨 ).

 MaintainHorizontalGroundVelocity

  • true 이면, 걷기 이동시에 경사로를 올라 가더라도 항상 수평 속도를 유지하는데, 이는 경사로가 아닌 평면에서 이동했을 때보다 더 빠르게 이동하게 만든다. 
  • false 이면, 경사로가 아닌 평면에서 이동했을 때와 같은 속도로 이동하게 된다.

 IgnoreBaseRotation

  • 캐릭터가 그것이 서 있는 바닥의 회전을 무시할지 여부.
  • true 이면, 캐릭터가 현재 world 회전값을 유지한다.
  • false 이면, 캐릭터가 움직이는 바닥의 회전값만큼 회전한다.

 PerchRadiusThreshold

  • 캐릭터의 캡슐의 가장자리와 표면의 가장자리가 가까울 때 캐릭터가 표면의 가장자리에 걸쳐 있지 못하게 하는 문턱값.
  • 걸어다닐 수 있는 표면보다 낮은 값의 MaxStepHeight 를 가지는 캐릭터는 떨어지지 않는다는 것에 주의할 것.

 PerchAdditionalHeight

  • 절벽 가장자리에 걸쳐 있을 때, MaxStepHeight 에 이 값을 더해서 걸어다닐 수 있는 바닥에서 얼마나 떨어져 있는지를 검사한다.
  • 걸어 올라가도록 하기 위해서 MaxStepHeight 강제로 바꿈; 이는 캐릭터를 가장자리에서 떨어지게 하거나 바닥에서 약간 높게 떠서 올라가도록 함.

 ForceNextFloorCheck

  • 캐릭터가 걷기 이동중 상태일 때 그것이 실제로 이동하지 못했더라도 강제로 유효한 바닥을 검사하도록 함. 다음 바닥 검사 이후에 클리어됨.
  • 보통 AlwaysCheckFloor 가 false 일 때는 특정 상황이 발생하지 않는다면 바닥 검사를 피하려고 시도할 필요가 없다. 하지만 이는 다음 검사를 항상 실행하도록 강제하기 위해서 사용됨.

 LedgeCheckThreshold

  • 폰이 절벽 가장자리로 가서 떨어지는지 여부를 검사하기 위해서 사용됨. 만약 이 값보다 가장자리의 길이가 짧다면 폰은 절벽에서 떨어질 수 있다.

 AlwaysCheckFloor

  • 캐릭터가 걷고 있는 동안에 stationary character 를 위한 바닥 검사를 항상 강제할 것인지 여부.
  • 보통 움직이고 있지 않을 때는 바닥 검사를 피하는 것이 좋다. 하지만 ( 오브젝트들이 캐릭터 위로 타고 올라 가는 상황과 같이 ) 깡총깡총 뛰다가 잘못되는 상황이 존재한다면 바닥 검사를 강제하기 위해서 사용될 수 있다.

 UseFlatBaseforFloorChecks

  • 캐릭터가 평평한 바닥을 가진 도형을 사용하고 있는 것인양 바닥 검사를 수행함.
  • 이는 캐릭터가 절벽 가장자리에서 ( 캡슐이 가장자리에서 균형을 이루는 것처럼 ) 천천히 떨어지는 상황을 방지한다.


CharacterMovement : Jumping / Falling



캐릭터가 점프하거나 떨어지고 있는 상황을 제어하는 곳입니다.



 이름

 설명

 JumpZVelocity

  • 점프할 때 초기 속도( 즉각적인 수직 가속도 ).

 BrakingDecelerationFalling

  • 떨어질 때 측면 감속도. 가속도에 영향을 주지 않음. 

 AirControl

  • 떨어질 때, 캐릭터에 대해 가능한 측면 이동 제어의 양.
  • 0 = 제어 없음. 1 = MaxWalkSpeed 의 최대 값에서 완전한 제어.

 AirControlBoostMultiplier

  • 떨어질 때, AircontrolBootVelocityThreshold 보다 작은 측면 속도일 때 Aircontrol 에 곱해질 값. 
  • 이 값을 0 으로 설정하면 air control boosting 이 비활성화됨. 최종 결과는 1 로 잘림.

 AirControlBoostVelocityThreshold

  • 떨어질 때, 측면 속도의 크기가 이 값보다 작으면, AirControl 에 AirControlBoostMultiplier 가 곱해짐.
  • 이 값을 0 으로 설정하면 air control boosting 이 비활성화됨.

 FallingLateralFriction

  • 떨어질 때, 측면 공중 이동에 적용될 마찰력.
  • bUseSeperateBrakingFriction 이 false 이면, ( 가속도가 0 일 때마다 ) 멈출 때 더욱 빠르게 멈추는 능력에 영향을 줌.

 ImpartBaseVelocityX

  • true 이면, ( 점프를 포함해 ) 떨어지는 것이 끝났을 때 기저 액터의 X 축 속도에 전달됨. 

 ImpartBaseVelocityY

  • true 이면, ( 점프를 포함해 ) 떨어지는 것이 끝났을 때 기저 액터의 Y 축 속도에 전달됨.

 ImpartBaseVelocityZ

  • true 이면, ( 점프를 포함해 ) 떨어지는 것이 끝났을 때 기저 액터의 Z 축 속도에 전달됨.

 ImpartBaseAngularVelocity

  • true 이면, 점프나 떨어지는 것이 끝났을 때 기저 컴포넌트의 각속도의 접선( tangential ) 성분에 전달됨.

 NotifyApex

  • true 이면, 꼭대기( apex )에서 점프할 때 CharacterOwner 의 컨트롤러에 NotifyJumpApex() 이벤트를 전달함. 이는 이벤트가 트리거되면 클리어됨.

 JumpOffJumpZFactor

  • 캐릭터 밑에 있도록 허용되지 않은 액터로 점프해서 올라갔을 때 사용될 JumpZVelocity 의 분수값( 예를 들어, 여러분이 다른 플레이어의 위에 서 있도록 허용되지 않았다면 ).


Character Movement : Swimming



캐릭터가 물에 빠졌을 때의 이동을 제어하는 곳입니다.



 이름

 설명

 MaxSwimSpeed

  • 최대 수영 속력.

 BrakingDecelerationSwimming

  • 수영시의 감속도이며 가속도에는 영향을 주지 않음.

 Buoyancy

  • 물의 부력. 비율( 1.0 = 자연스런 부력, 0.0 = 부력 없음 ).

 MaxOutOfWaterStepHeight

  • 물에서 나가기 위한 최대 높이.

 OutofWaterZ

  • 폰이 물에서 나가려 할 때 적용되는 Z 축 속도.
 JumpOutofWaterPitch
  • 물 속에 있을 때, 이 값 이상의 pitch 각을 올리면 jump 함.


Character Movement : Flying



날아 다닐 때의 이동을 제어하는 곳입니다.



 이름

 설명

 MaxFlySpeed

  • 최대 비행 속력.

 BrakingDecelerationFlying

  • 비행시의 감속도이며 가속도에는 영향을 주지 않음.


Character Movement : Custom Movement



사용자가 커스텀하게 설정하는 이동을 제어하는 곳입니다.


 이름

 설명

 MaxCustomMovementSpeed

 최대 속력.


Character Movement : Physics Interaction


캐릭터 이동시 물리의 영향을 어떻게 받을 것인지 설정하는 곳입니다.



 이름

 설명

 EnablePhysicsInteraction

  • 만약 활성화되면, 걸어다닐 때 플레이어는 물리 개체들과 상호작용함.

 TouchForceScaledtoMass

  • 만약 활성화되면, TouchForceFactor 가 영향받는 오브젝트의 kg 질량마다 적용됨.

 PushForceScaledtoMass

  • 만약 활성화되면, PushForceFactor 가 영향받는 오브젝트의 kg 질량마다 적용됨.

 PushForceUsingZOffset

  • 만약 활성화되면, PushForce 위치가 PushForcePointZOffsetFactor 를 사용해 이동됨. 그렇지 않으면 단순하게 충돌 지점을 사용함.

 ScalePushForcetoVelocity

  • 만약 활성화되면, 적용된 push force 는 물리개체의 속도를 플레이어의 속도와 같게 만들려고 시도함. 이는 힘을 감소시킬 것이며, PushForceFactor 에 의해 정의된 것보다 더 많은 힘을 적용하지는 않을 것이다.

 StandingDownwardForceScale

  • 플레이어가 서 있는 개체에 적용되는 힘이 ( 질량과 중력 때문에 ) 이 만큼 스케일링 됨.

 InitialPushForceFactor

  • 플레이어가 blocking 하는 물리 개체로 튕겨졌을 때 적용하는 초기 충격력( impulse force ).

 PushForceFactor

  • 플레이어가 blocking 하는 물리 개체와 충돌했을 때 적용할 힘.

 PushForcePointZOffsetFactor

  • 힘이 적용되는 위치에 대한 Z축 오프셋. 0.0 은 물리 개체의 중심이며, 1.0 은 천장. -1.0 은 바닥.

 TouchForceFctor

  • 플레이어가 터치했을 때 물리 개체에 적용되는 힘.

 MinTouchForce

  • 플레이어가 터치한 물리 개체에 적용되는 최소 힘. 만약 0.0 보다 작으면, 최소값 없음.

 MaxTouchForce

  • 플레이어가 터치한 물리 개체에 적용되는 최대 힘. 만약 0.0 보다 작으면 최대값 없음.

 RepulsionForce

  • 모든 겹쳐있는 요소들에게 지속적으로 적용되는 kg 당 힘.


개요



UT 에서 캐릭터 관련 애셋들이 실제로 어떻게 사용되는지 구체적으로 알아 보기 전에 캐릭터의 로직에 대해서 살펴 볼 필요가 있습니다.


플레이어가 게임 도중에 취할 수 있는 행동은 Input 매핑과 관련이 있습니다. "Edit >> Project Settings >> Input" 항목에는 두 종류의 Input Mapping 이 존재합니다; Action Mapping 과 Axis Mapping.




이 문서에서는 어떠한 입력 매핑이 존재하고, 그런 것들이 어떻게 캐릭터와 연관되는지에 대해서 살펴 보도록 하겠습니다.


입력 매핑



다들 알고 계실거라 생각하지만 노파심에 설명하자면 Action Mapping 은 단일 이벤트이며, Axis Mapping 은 지속 이벤트입니다. 이러한 Input Mapping 과 관련한 자세한 내용이 궁금하시다면, 언리얼 공식 문서의 [ 입력 (Input) ] 항목을 참조하십시오. 참고로 매핑을 할 때는 특정 키가 연관되어 있다는 것만 지정하지, down, up, double click 등의 정보를 명시적으로 지정하지는 않습니다.


어쨌든 UT 의 Action Mapping 은 다음 표와 같습니다( 여기에서는 PC 관련 매핑만 다루도록 하겠습니다 ).


 매핑 키

  매핑 입력 키

 설명 

 AUTPlayerController 메서드

 Jump

 Space Bar

 점프.

 IE_Pressed : Jump()

 Crouch

 C

 Left Ctrl

 앉기.

 IE_Pressed : Crouch()
 IE_Released : UnCrouch()

 Slide

 Left Shift

 슬라이딩.

 IE_Pressed : Slide()
 IE_Released : StopSlide()

 PrevWeapon

 Mouse Wheel Up

 이전 무기를 선택.

 IE_Pressed : PrevWeapon()

 NextWeapon

 Mouse Wheel Down

 다음 무기를 선택.

 IE_Released : NextWeapon()

 ThrowWeapon

 M

 무기를 버림.

 IE_Released : ThrowWeapon()

 StartFire

 Left Mouse Button

 Right Ctrl

 총질을 시작.

 IE_Pressed : OnFire()

 StopFire

 Left Mouse Button

 Right Ctrl

 총질을 멈춤.

 IE_Released : StopFire()

 StartAltFire

 Right Mouse Button

 아마도 alternative fire( secondary fire ).

 Alternative fire 를 시작.

 IE_Pressed : OnAltFire()

 StopFire

 Right Mouse Button

 Alternative fire 를 멈춤.

 IE_Released : OnStopAltFire()

 StartActivatePowerup

 Q

 Powerup( U Damage, Invisibility, Berserk, Jump Boots ) 을 활성화함.

 IE_Pressed : OnActivatePowerupPress()

 SlowerEmote

 Mouse Wheel Down

 감정 표현 애니메이션을 느리게 만듦.

 IE_Pressed : FasterEmote()

 FasterEmote

 Mouse Whee Up

 감정 표현 애니메이션을 빠르게 만듦.

 IE_Pressed : SlowerEmote()

 Play Taunt

 J

 첫 번째 도발 애니메이션 재생.

 IE_Pressed : PlayTaunt()

 Play Taunt2

 K

 두 번째 도발 애니메이션 재생.

 IE_Pressed : PlayTaunt2()

 TapRight

 D

 오른쪽으로 회피.

 IE_Pressed : OnTabRight()

 IE_Released : OnTapRightRelease()

 TapLeft

 A

 왼쪽으로 회피.

 IE_Pressed : OnTabLeft()
 IE_Released : OnTapLeftRelease()

 TapForward

 W

 앞쪽으로 회피.

 IE_Pressed : OnTabForward()
 IE_Released : OnTabForwardRelease()

 TapBack

 S

 뒤쪽으로 회피.

 IE_Pressed : OnTabBack()
 IE_Released : OnTabBackRelease()

 SingleTapDodge

 V

 앞의 TabXXX 시리즈가 더블 클릭을 요구하는데 단일 클릭만으로 회피.

 IE_Pressed : OnSingleTabDodge()

 ShowScores

 Tab

 점수 현황판을 보여 줌.

 IE_Pressed : OnShowScores()
 IE_Released : OnHideScore()

 ShowMenu

 Escape

 메뉴를 보여 줌.

 ShowMenu()

 Talk

 T

 전체 채팅창을 보여 줌.

 IE_Pressed : Talk()

 TeamTalk

 Y

 팀 채팅창을 보여 줌.

 IE_Pressed : TeamTalk()


Axis Mapping 은 다음 표와 같습니다.


 매핑 키

 매핑 입력 키

 스케일

 설명 

 AUTPlayerController 메서드

 MoveForward

 W

 Up

 1.0

 1.0 

 앞쪽으로 이동. 

 MoveForward()

 MoveBackward

 S

 Down

 1.0

 1.0 

 뒤쪽으로 이동.

 MoveBackward()

 MoveLeft

 A

 1.0

 왼쪽으로 이동.

 MoveLeft()

 MoveRight

 D 

 1.0 

 뒤쪽으로 이동.

 MoveRight()

 TurnRate

 Left

 Right

 -1.0

 1.0

 비율로 Yaw 회전.

 TurnAtRate()

 Turn

 Mouse X

 1.0

 Yaw 회전.

 AddYawInput()

 LookUp

 Mouse Y

 -1.0

 Pitch 회전.

 AddPitchInput()

 MoveUp

 C

 Space Bar

 1.0

 -1.0

 수직으로 이동. 

 MoveUp()


이러한 입력 매핑들은 AUTPlayerController::SetupInputComponent() 에서 수행됩니다.



이동 입력



이동을 위한 이벤트 처리 로직은 아래의 sequence diagram 에 나와 있습니다. 간단한 실행 흐름만을 보여 주려고 했기 때문에, 내부적으로 설정되는 필드같은 것은 생략했습니다. 여기에서 전부 표현해 주기에는 너무 많습니다. 


반복되는 호출에 대해서는 하위 호출을 생략했으니 보시는데 주의하시기 바랍니다.




위의 다이어그램은 매우 복잡해 보이지만 사실 매우 단순합니다. 입력은 Player Controller( AUTPlayerController ) 에서 처리합니다. 그리고 Character( AUTCharacter ) 로 전달하죠. 그러면 Character 는 최종 TM 을 결정하기 위한 플래그나 정보를 설정합니다. 그런데 애니메이션 피드백이나 물리 피드백을 위해서 Movement Component( UUTCharacterMovement ) 에 상태 정보를 전달합니다. 


이벤트 처리 단계에서는 대부분 현재 상태나 플래그를 설정하는 것으로 끝납니다. 애니메이션 피드백이나 물리 피드백을 위한 실제 처리는 UUTCharacterMovement::PerformMovement() 에서 처리됩니다.


PerformMovement() 의 내부가 어떻게 구성되는지 좀 더 자세히 알고자 하신다면 [ UE4 캐릭터 이동 시스템 가이드 ]를 참조하시기 바랍니다.


전투 입력



FPS 게임이다보니 전투와 관련한 입력은 그리 많지 않습니다; fire, alt-fire, select weapon, drop weapon.


전투 입력이나 이동 입력이나 전반적으로 그 처리의 흐름이 크게 다르지 않습니다. 단지 Movement Component 와의 연관성이 더 적습니다. 특이한 것은 FDeferredFireInput 의 인스턴스는 UUTCharacterMovement::TickComponent() 호출 시점에서 소비된다는 것입니다.


나가며



여기에서는 플레이어 입력과 관련한 로직들을 간단하게 살펴 보았습니다.


그런데 근본적으로 우리가 관심을 가지고 있는 것은 이런 로직들이 최종적으로 다른 애셋들( 메쉬, 애니메이션 등 )과 어떤 식으로 연관되는지 알아 내는 것이므로 아직 성에 차지 않을 수 있습니다. 하지만 내용이 너무 복잡해져서 여기에서 모두 담기 어려운 면이 있어서 나눠서 분석할 계획입니다.

개요



1인칭 캐릭터는 말 그대로 1인칭 카메라 모드에서 동작합니다.


UT 에서는 하나의 캐릭터 내에 1인칭 캐릭터 메쉬와 3인칭 캐릭터 메쉬를 모두 포함하고 있습니다. 일단 플레이를 시작하면 플레이어를 위해서 DefaultCharacter 블루프린트의 인스턴스를 생성하게 됩니다.


그림1. DefaultCharacter 블루프린트.


노란 엣지를 가진 메쉬를 확인할 수 있습니다. 이 블루프린트의 상속구조는 다음과 같습니다.


그림2. DefaultCharacter 상속 구조.



[ 그림1 ]의 블루프린트에서 "(Inherited)" 라고 표시되어 있는 컴포넌트들은 모두 AUTCharacter 클래스에서 정의한 컴포넌트들입니다. 그래서 위치를 바꾸거나 이름을 변경하는 것이 불가능합니다. 만약 변경하고 싶다면 소스 코드를 수정해야 합니다.


어쨌든 이 문서에서는 1인칭 캐릭터와 관련한 컴포넌트에 집중하도록 하겠습니다. [ 그림1 ]의 "Components" 뷰에서 선택한 두 개의 컴포넌트( CharacterCameraComonent 와 FirstPersonMesh )들이 1인칭 캐릭터 전용 컴포넌트입니다. UTChracterMovement 는 1인칭 캐릭터와 3인칭 캐릭터에서 공용으로 사용합니다. 이 CharacterMovement 컴포넌트에 대한 간략한 설명은 [ UE4 캐릭터 이동 시스템 가이드 ] 에서 찾아볼 수 있습니다.


FirstPersonMesh



[ 그림1 ]의 FirstPersonMesh 컴포넌트는 USkeletalMeshComponent 의 인스턴스입니다. 이것은 UStaticMeshComponent 와 대응되는 것으로서 본애니메이션이 가능한 메쉬 컴포넌트를 의미합니다.


[ 그림3 ] 은 이 컴포넌트의 가장 중요한 속성들을 보여 줍니다.


그림3. FirstPersonMesh 컴포넌트의 주요 속성들.


속성들은 다음과 같은 의미를 가집니다. 여기에서는 간략하게 설명하도록 하겠습니다.

    • Animation 카테고리에서 "Content/RestrictedAssets/Animations/Universal/1stPerson/UT4_Base_1stP_AnimBP_C.uasset" 이라는 애니메이션 블루프린트를 사용할 것임을 지정합니다. 
    • Mesh 카테고리에서 "Content/RestrictedAssets/Character/Human/Male/malcolm_ut4_1stp_SKELMESH.uasset" 이라는 스켈레탈 메쉬를 사용할 것임을 지정합니다.
    • Materials 카테고리에서 "Content/RestrictedAssets/Character/Malcom_New/Materials/M_Malcom_Body_Panini.uasset" 이라는 머티리얼을 사용할 것임을 지정합니다.
    • Collision 카테고리에서 "NoCollision" 프리셋을 지정합니다. 즉, 부모 컴포넌트인 CapsuleComponent 의 콜리전 설정에 의존하겠다는 것입니다. 참고로 CapsuleComponent 의 콜리전 프리셋은 "Pawn" 으로 지정되어 있으며, [ 그림 4 ] 에서 확인할 수 있습니다.


그림4. CapsuleComponent 컴포넌트의 Collision Preset.


CharacterCameraComponent



CharacterCameraComponent 는 1인칭 카메라를 의미합니다. CharacterCameraComponent 가 FirstPersonMesh 를 자식으로 가지고 있기 때문에 카메라를 회전시키거나 이동시키면 자동으로 FirstPersonMesh 도 카메라의 영향을 받게 됩니다.


반대로 캐릭터 컨트롤러를 회전시키게 되면 자동으로 카메라도 회전합니다. 이는 CameraSettings 카테고리의 "UsePawnControlRotation" 속성을 true 로 만듦으로써 가능합니다.




"UsePawnControlRotation" 는 카메라가 플레이어 컨트롤러의 forward 방향을 바라보도록 강제하겠다는 것입니다. 다시 말하면 카메라가 항상 캐릭터의 등짝을 바라보게 된다는 의미입니다. 1인칭에 딱 맞는 카메라라 할 수 있겠죠. 세부적인 구현은 다음과 같습니다. 



정리



여러 가지 컴포넌트들이 존재하지만, 1인칭 캐릭터와 관련된 핵심 컴포넌트는 FirstPersonMesh 스켈레탈 메쉬 컴포넌트와 CharacterCameraComonent 카메라 컴포넌트입니다.


중요한 것은 FirstPersonMesh 가 CharacerCameraComponent 의 자식이어서 캐릭터의 TM 이 카메라에 종속되며, 카메라가 항상 등쪽을 바라보도록 하기 위해서 "UsePawnControlRotation" 을 사용한다는 것입니다.


이 문서에서는 간략하게 구조에 대해서만 언급하고 다른 문서들에서 1인칭 캐릭터의 세부 사항에 대해서 다루도록 하겠습니다.

개요



UT 에는 여러 종류의 캐릭터들이 있습니다. 그런데 N 개의 캐릭터에 대해 M 개의 애니메이션을 가지고 있다면, N X M 개의 애니메이션이 필요할 것입니다. 게다가 1인칭과 3 인칭을 모두 표현해야 한다는 것을 감안한다면 몇 개의 애니메이션을 만들어야 할지 감도 잡기 어렵습니다. 제가 대충 살펴 보니 3rdPerson 폴더에만 327 개의 애니메이션 애셋이 존재하더군요. 그리고 애니메이션의 개수도 문제지만 용량도 무시할 수 없습니다.


그런데 다행히도 UT 의 캐릭터들은 모두 인간형( Humanoid )이라는 공통점을 가집니다. 그래서 UE4 의 애니메이션 리타게팅( Animation Retargeting ) 기능을 사용하면 큰 힘을 들이지 않고도 하나의 스켈레톤( Skeleton )과 애니메이션을 공유할 수 있게 됩니다. 하지만 UT 에서는 리타게팅 기법을 사용하지 않고, 그냥 모든 스켈레탈 메쉬( Skeletal Mesh )의 스켈레톤을 공유하고 있습니다. 아마도 신체 비율이나 메쉬의 모양이 큰 차이가 없다고 판단한 것 같습니다.


공유하고 있는 스켈레톤 애셋의 경로는 "/Content/RestrictedAssets/Character/Human/Male/ut4_base_Skeleton" 입니다.


이 스켈레톤을 중심으로 크게 2 부류의 애니메이션으로 나뉩니다; 1인칭3인칭. 대부분의 애니메이션 애셋들은 "Content/RestrictedAssets/Animations/Universal" 에 저장되어 있습니다. "Content/RestrictedAssets/Animations""Human", "Necris", "Skaarj" 같은 하위 폴더들이 존재하지만, 거기에는 특정 캐릭터에 국한된 애니메이션들만 저장되어 있습니다.


1인칭의 경우에는 "Content/RestrictedAssets/Animations/Universal/IstPerson/UT4_Base_1stP_AnimBP" 라는 애니메이션 블루프린트를 사용하고, 3인칭의 경우에는 "Content/RestrictedAssets/Animations/Universal/UT4_Base_AnimBP" 라는 애니메이션 블루프린트를 사용합니다.


Animation Blueprint



애니메이션 블루프린트는 UAnimInstance 를 부모로 하는 블루프린트입니다. 가끔 애니메이션 블루프린트를 캐릭터 블루프린트같은 곳에서 어떻게 찾느냐는 질문을 하시는 분들이 있는데, 다음과 같이 찾으시면 됩니다. 아래 그림은 BaseUTCharacter 블루프린트에서의 예제입니다.



GetAnimInstance 를 통해 얻은 인스턴스를 UT4_Base_AnimBP 로 변환하는 것을 보실 수 있습니다. Target 으로 Mesh 가 설정되어 있는데, 그것은 3인칭 캐릭터에 대한 USkeletalMeshComponent 인스턴스입니다.


어쨌든 중요한 것은 애니메이션 블루프린트는 애니메이션 인스턴스라는 것입니다.


애니메이션 블루프린트를 열게 되면 크게 3 종류의 그래프가 존재한다는 것을 알 수 있습니다.


    • EventGraph
    • AnimGraph
    • StateMachine


UE4 에서는 이러한 그래프들을 적절하게 다룸으로써 최종 애니메이션 포즈를 결정하게 됩니다.


EventGraph



EventGraph 는 AnimGraph 와 StateMachine 에서 사용할 변수들을 공급하거나 AnimMontage 같은 애니메이션을 실행하기 위한 그래프입니다. 여기에서는 보통 Player Controller 나 Character 에 접근해서 필요한 정보를 뽑아 옵니다.



EventGraph 는, 그 이름이 의미하는 것처럼, 특정 이벤트가 발생했을 때 특별한 처리를 하게 됩니다. 이것은 일반적인 블루프린트의 EventGraph 와 같은 방식으로 동작합니다. 여기에서는 Animation 이나 State Machine 에서 발생하는 이벤트( notify )도 받을 수 있기 때문에 매우 활용도가 높습니다.




AnimGraph



AnimGraph 는 애니메이션 블렌딩을 위한 그래프입니다. 여러 종류의 애니메이션을 블렌딩할 수 있습니다. 



여기에서 특이한 점은 최종 포즈에서 사용되지 않는 블렌딩 노드들은 평가되지 않는다는 것입니다. 위의 그림을 보면 "Blend Poses by bool" 노드의 "True Pose" 슬롯에 바인딩되어 있는 라인은 평가되고 있지 않은 것을 볼 수 있습니다.


블렌딩 대상은 개별적으로 플레이될 수 있는 대부분의 애니메이션 요소이며, State Machine, 개별 애니메이션, Animation Montage 등을 블렌딩할 수 있습니다.


StateMachine



다들 잘 아시겠지만 StateMachine 은 특정 조건을 통해 노드를 전환할 수 있는 그래프입니다. 이것은 AnimGraph 의 하위요소입니다. AnimGraph 가 블렌딩을 통해 최종 포즈를 결정하는 것이기 때문에, 이러한 구조는 당연한 것이라 할 수 있습니다. UE4 의 StateMachine 은 HFSM( Hierarchical Finite State Machine ) 입니다.



UE4 의 StateMachine 에서 가장 좋은 점을 꼽으라고 한다면, transition 의 유연성이라고 할 수 있을 것 같습니다.


Unity3D 의 Mechanim StateMachine 같은 경우에는 파라미터를 넘겨서 transition 조건을 판단하는데, 이것은 복잡한 조건을 판단해야 하는 경우에는 매우 불편합니다. 그러므로 조건이 복잡해지면 하드코딩을 해야 합니다.


하지만 UE4 StateMachine 은 EventGraph 를 통해 복잡한 조건을 검사해서 StateMachine 에 변수를 공급할 수도 있고, transition 자체에서 조건을 만들 수도 있습니다.



게다가 transition 에 다양한 옵션들이 존재하고 있으며, blueprint 로 Notify 를 보낼 수 있다는 점이 매우 좋습니다.



나가며



정리하다가 보니 UE4 광고가 되 버린 것 같습니다. 어쨌든 UT 는 UE4 의 기본 애니메이션 메커니즘을 사용하고 있습니다.


애니메이션 애셋들은 1인칭 용과 3인칭 용으로 나뉘어 있으며, 모든 캐릭터가 스켈레톤을 공유하고 있습니다.


사실은 이 문서에서 애니메이션 애셋을 용도별( Animation Offset, Animation Montage, Animation Blend )로 구분해 놓으려고 했으나 좀 복잡해서 나중으로 미루도록 하겠습니다.


1인칭과 3인칭에 대한 애니메이션 애셋들의 종류나 그것이 사용되는 방식들에 대해서는 다른 문서를 통해 다루기로 하겠습니다.

개요



UE4 에서는 어떤 인스턴스의 근본 구조와 로직은 C++ 클래스를 통해 정의하고, 인스턴스당 특성들은 블루프린트 및 그것의 상속을 통해서 정의합니다.


UT 에서의 캐릭터도 마찬가지의 방식으로 정의되어 있으며, 그 구조는 다음과 같습니다.



GhostCharacter 라는 것은 튜토리얼에서 사용하는 특별한 캐릭터입니다. 그런데 이 구조를 보면서 뭔가 미진함을 느끼시는 분들이 있을 겁니다. DefaultCharacter BaseUTCharacter 에는 메시를 바꿀만한 이벤트같은 것이 존재하지 않습니다. 그러면 어떠한 경로를 통해서 다양한 메시가 나올 수 있는 것일까요? 


결론적으로 이야기하자면 UT 에서 모든 캐릭터는 DefaultCharacter 만 사용해서 생성됩니다. 다음 섹션에서는 이러한 일들이 어떻게 가능한지에 대해 구체적으로 설명하도록 하겠습니다.


Character Content



UT 에서 DefaultCharacter 의 Mesh 컴포넌트는 AUTCharacterContent 라는 액터를 참조하여 대체될 수 있습니다. Mesh 컴포넌트는 이전에도 이야기했듯이 3인칭 관점에서의 캐릭터를 표현하기 위한 컴포넌트입니다.


이 Mesh 컴포넌트를 어떻게 채워야 하는지에 대한 정보를 담고 있는 것이 바로 character content 입니다. UT 에서 AUTCharacterContent 를 상속하여 만든 블루프린트들은 "Content/RestrictedAssets/Character" 폴더에 있습니다.



그중에 NecrisFemaleBase 라는 블루프린트를 열어 보도록 하겠습니다.



열어 보시면 매우 실망스러울 것입니다. Mesh 라는 컴포넌트가 달랑 하나 있는데, 내용이 전혀 채워져 있지 않습니다. 그것은 Base 클래스이기 때문에 그렇습니다. 그렇다면 실제로 뭔가가 할당된 것이 있을까요?


네 있습니다. 단지 하나밖에 없어서 문제지요. "Content/RestrictedAssets/Character/Malcom_New" 폴더에 가면 Malcolm_New 라는 블루프린트 애셋이 있습니다( 폴더 이름과 애셋 이름이 다른 것은 오타가 아닙니다. 실제로 그렇게 되어 있습니다 ). 이것은 HumanMaleBase 를 상속하고 있으며, SkeletalMesh'/Game/RestrictedAssets/Character/Human/Male/malcolm_ut4_SKELMESH.malcolm_ut4_SKELMESH' 를 사용합니다.



여기까지 보시고 나서 "그래서 뭐 어쩌라고?" 라는 질문을 던지시는 분이 계실 겁니다. 당연한 질문입니다.


AUTCharacter 에는 ApplyCharacterData() 라는 메서드가 있습니다. 여기에서 AUTCharacterContent 를 인자로 받아 AUTCharacter 가 가지고 있는 Mesh 컴포넌트를 변경하게 됩니다.



코드를 조금만 읽어 봐도 금방 이해하시겠지만, 요약하자면 팀 재질과 메쉬를 설정합니다.


용례 : Bot



실제로 DefaultCharacterAUTCharacterContent 가 어떤 식으로 연결되는지에 대한 예를 들어 보도록 하겠습니다.


UE4 에서 플레이어의 상태를 저장하기 위해서는 PlayerState 라는 것을 사용합니다. Character 나 Pawn 에 정보를 직접 저장할 수도 있지만, 서버와의 연동을 생각하면 PlayerState 를 사용하는 것이 좋습니다. 언리얼 공식 문서의 [ 게임플레이 프로그래밍 ] 에서는 PlayerState 에 대해 다음과 같이 정의합니다.


인간 플레이어 또는 플레이어인 척 하는 봇과 같은 게임 참여자의 상태를 말합니다. 게임의 일부로서 존재하는 플레이어가 아닌 AI 에는 PlayerState 가 없습니다.

PlayerState 에 적합한 예제 데이터라면, 플레이어 이름, 점수, MOBA 게임류에서의 대전상대 레벨, CTF 게임에서 플레이어가 현재 깃발을 운반중인지 여부 등입니다. 모든 플레이어에 대한 PlayerState는 ( PlayerController 와는 달리 ) 모든 머신에 존재하며, 동기화 상태 유지를 위해 자유로이 리플리케이트 가능합니다.


어쨌든 정리하자면 이 PlayerState 는 플레이어의 정보를 유지하는데 사용됩니다. UT 의 경우에는 AUTCharacterContent  AUTPlayerState::SelectedCharacter 라는 속성을 통해 현재 플레이 대상의 CharacterContent 를 공급합니다.


자 원래 주제로 돌아 와서, UT 에서 Bot 은 UUTBotCharacter 라는 데이터 애셋으로 정의됩니다. "Content/RestrictedAssets/Character/Bots" 폴더에 보면 봇 캐릭터를 정의하는 애셋들이 있습니다. 이것은 실제 캐릭터가 아니라 UDataAsset 을 상속하고 있는 데이터입니다. "Content/RestrictedAssets/Character/Bots/ThunderCrash/Taye" 라는 봇의 데이터를 한 번 살펴 보도록 하겠습니다.



봇의 성격이라든가 목소리라든가 하는 여러 가지 특징들을 정의할 수 있군요. 하지만 우리가 집중할 것은 노란 박스로 강조해 둔 Character 속성입니다. 이것은 다음과 같이 정의되어 있죠.



앞에서 언급한 AUTCharacterComponent 를 사용하도록 메타 클래스를 지정하고 있음을 알 수 있습니다. 그런데 지금은 "None" 으로 비어 있죠? 이 경우에는 위에서 언급한 Malcolm_New 라는 기본 CharacterContent 를 사용하게 됩니다. 이것을 바꾸는 방법에 대해서는 "실습" 섹션에서 논의하도록 하겠습니다.


자 이제 이것이 전체적으로 어떤 관계를 가지는지 클래스 다이어그램을 통해 살펴 보도록 하겠습니다.



우리가 Character 속성에 CharacterContent 애셋을 지정하면, 그것은 AUTPlayerState.SelectedCharacter 에 설정되며, 그것은 다시 ( DefaultCharacter 의 부모인 ) AUTCharacter ApplyCharacterData() 의 인자로 넘겨집니다. 이를 통해서 DefaultCharacter 의 ( 3인칭 메쉬의 ) 외형이 결정되는 것입니다.


여기에서는 봇의 경우만 예로 들었지만, 다른 플레이어 캐릭터의 경우에도 PlayerState 를 가지기 때문에 다를 것이 없습니다.


실습 : Taye



이제 실제로 우리가 원하는 CharacterContent 의 봇에 지정해 보도록 하겠습니다. Taye 는 왠지 여자 이름인 것 같으므로 여자 캐릭터를 지정해 보겠습니다. 일단 "Content/RestrictedAssets/Character/Necris_Female" 폴더로 이동합니다.


1. 먼저 CharacterContent 부터 생성해야겠죠. 다음과 같이 블루프린트 부모로 NecrisFemaleBase 를 지정한 후에, 블루프린트가 생성되면 이름을 "NecrisFemale" 로 변경합니다.



그리고 나서 Mesh 의 "Skeletal Mesh" 항목에 "necris_female_ut4_SKELMESH" 를 할당해 줍니다. 이것으로서 CharacterContent 애셋 생성은 끝입니다. 굳이 애니메이션 돌아 가는 것을 확인하고 싶으시다면 "Anim Class" 항목에 애니메이션을 할당해 봐도 좋겠죠.



다음으로는 봇에다가 이 CharacterData 를 할당할 차례입니다. Taye 봇 데이터 애셋을 열어 "Character" 항목에 "NecrisFemale" 을 할당합니다.



"ExmapleMap" 의 시작부에는 다음 스샷과 같이 봇을 생성하는 곳이 있습니다. 게임에 들어 가서 그 위치에서 "Enter" 키를 누르면 봇이 생성되었다가, 다시 "Enter" 키를 누르면 봇이 죽습니다. 이렇게 몇 번 하다가 보면 Taye 가 생성됩니다. 기본으로는 Malcolm_New 가 생성되므로 구분하기는 어렵지 않을 것입니다. 랜덤으로 생성되기 때문에 인내심이 필요할 것입니다( Blue Team Spawn 에 서서 생성하면 초반에 잘 나오더군요 ). 




아래 그림은 possession 을 해제하고 찍은 스샷입니다. 이상하게도 빙의를 해제하면, 1인칭 메시도 같이 나오더군요. 이 부분은 왜 그런지 나중에 확인해 봐야겠습니다.




원하는 봇만 생성되기를 원한다면 AUTGameMode::AddBot() 메서드를 수정하십시오.

개요



Example_Map 을 플레이하게 되면 게임모드와 캐릭터가 생성되는 것을 볼 수 있습니다. 여기에서, 경험자라면 프로젝트 세팅을 떠 올리게 될 테지만, 초보자나 저같이 간만에 UE 를 다시 본 사람들은 혼란에 빠지게 됩니다.


"Edit -> Project Settings..." 메뉴를 클릭하게 되면 "Project Settings" 라는 다이얼로그가 뜹니다. 여기에서 "Maps & Modes" 카테고리를 선택하게 되면 다음과 같은 화면을 볼 수 있습니다.



프로젝트 세팅과 관련한 전반적인 내용은 다음 링크에서 확인하시기 바랍니다.


  • Default Maps
    • Editor Startup Map 은 에디터를 처음 실행할 때 열어 줄 맵을 지정합니다.
    • Game Default Map 은 게임을 실행할 때 열어 줄 맵을 지정합니다. 그러나 PIE( Play In Editor ) 에서 게임을 실행하면 현재 맵에서 게임을 실행합니다.
    • Local Map OptionUEngine::LoadMap() 호출시 넘어 갈 부가인자를 설정합니다. 현재는 "?listen" 을 붙여 listen server 기능을 강제하는 기능이 있다는 것만 알고 있습니다. 자세한 내용은 더 연구를 해 봐야 알 수 있을 것 같습니다.
    • Transition MapSeamless Travel 이 활성화된 상태에서 맵을 전환할 때 중간에 사용되는 맵입니다.
    • Server Default Map 은 서버를 실행할 때 열어 줄 맵을 지정합니다.
  • Default Modes
    • Default GameMode 는 맵의 "World Settings" 에서 "GameMode Override" 를 지정하지 않았을 때, 기본적으로 실행해 줄 게임모드를 지정합니다.
    • Selected GameMode 는 "Default GameMode" 에 선택된 게임모드의 내용을 간략하게 보여 줍니다.
    • Global Default Server Game Mode 는 서버의 게임모드를 지정합니다.
  • Local Multiplayer
    • Use Splitscreen 은 로컬에서 멀티플레이를 실행할 때 화면을 분할할 것인지 여부를 결정합니다.
    • Two Player Splitscreen Layout 은 로컬에서 2 마리에 대한 멀티플레이를 실행할 때 화면을 분할할 레이아웃을 결정합니다.
    • Three Player Splitscree Layout 은 로컬에서 3 마리에 대한 멀티플레이를 실행할 때 화면을 분할할 레이아웃을 결정합니다.
  • Game Instance
    • Game Instance Class 는 게임 인스턴스의 유형을 결정합니다.

UUTGameInstance



UE 4.4 버전부터 GameInstance 라는 개체가 생겼습니다. UE 문서에 따르면 게임인스턴스는 다음과 같은 역할을 합니다.


GameInstance: 실행중인 게임의 인스턴스를 위한 고수준 관리자 개체. 게임 생성시 생성되지만 게임 인스턴스가 닫힐때까지 파괴되지 않습니다. Standalone 게임으로서 실행중일 때, GameInstance 는 하나만 생성될 것입니다. PIE( Play-in-editor ) 에서 실행하면 PIE 인스턴스당 하나씩 생성될 것입니다.


뭔가 설명을 어렵게 해 놨는데, 결국은 게임 그 자체를 의미하게 됩니다. 레벨이 전환되더라도 공유할 수 있는 데이터를 저장할 수 있는 전역 개체입니다.


UE 위키에서 열심히 활동하는 Rama 는 [ Game Instance, Custom Game Instance For Inter-Level Persistent Data Storage ] 라는 아티클에서 다음과 같이 활용예를 들었습니다.


현실적인 예로써, Solus 에는 다른 레벨로 들어 갔을 때도 같은 상태를 유지할 필요가 있는 통신탑( Comms Tower )이 존재합니다. 마치 그것이 엄청나게 먼 거리에서 보이는 것처럼 말이죠.


플레이어는 통신탑의 상태를 발전시키는 행동을 취할 수 있습니다. 그리고 그런 변화는 플레이어가 입장하는 다른 레벨에서도 반영되어야만 합니다.


GameInstance 클래스를 사용하면, 나는 플레이어가 통신탑의 상태에 변화를 줄 때마다 그것을 기록해서, 그 정보를 플레이어가 새로운 레벨에 진입할 때 넘겨줄 수 있습니다. 


UT 의 경우에는 UUTGameInstance 라는 클래스를 기본 게임 인스턴스 클래스로 지정합니다( asset-field 에 클래스가 들어 갈 때는 접두어를 배제한 이름이 들어갑니다. 그래서 실제 클래스는 UTGameInstance 가 아니라 UUTGameInstance 입니다 ).


이 게임 인스턴스 클래스는 다음과 같은 정보를 담고 있습니다:

    • 마지막 플레이한 데모 정보.
    • 매칭 정보.
    • 파티 정보.
    • 세션 정보.


AUTDMGameMode



게임 인스턴스가 게임 자체를 의미한다면, 게임 플레이를 의미하는 것은 게임 모드입니다. 일단 "A" 는 "Actor" 의 머리글자이며, "UT" 는 "Unreal Tournament" 의 머리글자이고, "DM" 은 "Death Match" 의 머리글자입니다. 데스 매치를 위한 게임 모드라 할 수 있습니다. 왜 게임 모드가 액터냐는 질문을 던지신다면야, 실제로 씬에 배치되기 때문이라고 대답하겠습니다. 왜 씬에 배치되야 하느냐고 질문하신다면, 그건 언리얼을 만든 사람의 마음이라 잘 모르겠습니다. 아마도, Unity 3D 처럼, 게임 인스턴스를 제외한 모든 개체는 월드( 씬 ) 단위로 유지되기를 원한 것 같습니다.


어쨌든 게임 모드는 게임에서 사용하게 될 핵심 액터들을 정의하게 됩니다. 각각은 다음과 같은 역할을 수행합니다.


    • DefaultPawnClass AGameMode.DefaultPawnClass 프라퍼티입니다. 아래에서 리스팅된 이름들도 다 마찬가지입니다. 다들 잘 아시겠지만 노파심에 설명하자면, 프라퍼티는 C# 프라퍼티가 아니라 UPROPERTY() 특성 매크로를 지정한 필드를 의미합니다. 이것은 일종의 메타 데이터( metadata )로, UnrealHeaderTool 은 이것을 파싱해서 C++ 클래스로 만듭니다. 어쨌든 DefaultPawnClass 는 게임 모드를 생성했을 때 자동으로 생성할 플레이어를 위한 을 의미하는 클래스입니다.
    • HUDClass 는 게임에서 사용할 HUD 를 지정하는 프라퍼티입니다.
    • PlayerControllerClass 는 플레이어를 위한 컨트롤러를 지정하는 프라퍼티입니다. 그것은 폰과 그것을 제어하는 사람간의 인터페이스를 제공합니다. 플레이어 컨트롤러는 플레이어의 의지( 조작 )를 반영합니다.
    • GameStateClass 는 게임 상태를 모니터링 할 게임 스테이트를 지정하는 프라퍼티입니다.
    • PlayerStateClass 는 플레이어 컨트롤러가 사용하는 플레이어에 대한 리플리케이트 정보를 포함하는 플레이어 스테이트를 지정하는 프라퍼티입니다.
    • SpectatorClass 는 관전모드에 들어 갔을 때 사용할 관찰자를 지정하는 프라퍼티입니다.


이러한 정보들에 대한 더 자세히 알고자 한다면, 공식 문서의 [ 게임플레이 프로그래밍 ] 항목을 참조하시기 바랍니다.


게임 모드들



여기까지 읽으시면 게임 모드가 하나밖에 없다고 착각하실 수 있으실텐데요, UT 에는 수 많은 게임 모드들이 있습니다.



개요


 

UT 는 1인칭 슈팅 게임입니다. 그런데 내 입장에서는 1인칭이지만 적이나 아군 입장에서는 3인칭입니다. 또한 ( 관전모드와 같이 ) 자신을 관찰해야 하는 모드에서는 3인칭으로 보여야 합니다. 그래서 UT 에서 캐릭터는 2 개의 skeletal mesh 와 각각의 mesh 에 할당된 animation blueprint 를 소유하게 됩니다.

 

UT 를 컴파일하고 에디터를 열면 Exmaple_Map 이라는 레벨을 볼 수 있습니다다. 이 레벨에서 Play 를 실행하면, PIE( Play In Editor ) 모드로 게임이 실행되는데, DefaultCharacter 라는 것이 생성되어 있는 것을 볼 수 있습니다.

 

 

플레이중에 화면 바깥으로 나가려면 "ALT + ENTER" 를 눌러야 합니다. "ESC" 를 누르면 플레이가 중지됩니다.

 

어쨌든 월드 아웃라이너( World Outliner )에서 흰색 액터( actor )는 원래 씬에 배치되어 있던 것이고, 노란색( ? ) 액터는 플레이 이후에 생성된 것입니다. 오른쪽에 있는 "Edit DefaultCharacter" 라는 하늘색 링크를 누르면 블루프린트가 뜹니다.

 

 

처음에는 그냥 property-grid( Class Default 탭 )만 나오는데, "Open Full Blueprint Editor" 라고 써진 하늘색 링크를 누르면 전체 블루프린트를 볼 수 있습니다. 그리고 "Parent class" 항목은 이 블루프린트의 부모 블루프린트나 부모 클래스가 무엇인지 알려 줍니다. 이름이 하늘색으로 써져 있으면 블루프린트 애셋이며 흰색으로 써져 있으면 C++ 클래스입니다. DefaultCharacter 의 경우에는 "BaseUTCharacter" 라는 블루프린트를 부모로 하고 있습니다.

 

이제 Viewport 항목으로 이동하면 두 개의 mesh 가 존재한다는 것을 알 수 있습니다; Mesh, FirstPersonMesh. 컴포넌트 뷰( Components )에서 (Inherited)라 되어 있는 것은 C++ 클래스에서 정의하고 있는 컴포넌트들이며 계층구조나 이름을 변경할 수 없습니다.

 

 

BaseUTCharacter 는 AUTCharacter 클래스를 상속합니다. 아래 그림에서는 "Parent class" 항목에 "UTCharacter" 라고만 써져 있는데, 이 클래스는 액터 클래스이므로 "A" 라는 접두어가 붙습니다. 만약 헷갈린다고 생각하시면, 그냥 헤더 파일 이름이라 생각하셔도 좋을 것 같습니다. 클릭하면 실제로 Visual Studio 에서 헤더 파일이 열립니다.

 

 

앞에서 언급하지는 않았지만 DefaultCharacter 블루프린트의 EventGraph 는 텅 비어 있습니다. 하지만 BaseUTCharacter 의 EventGraph 에서는 뭔가 열심히 하고 있습니다. 즉, 현재 DefaultCharacter 는 mesh 와 animation 을 재정의하기 위한 용도로 BaseUTCharacter 를 상속하고 있는 것입니다.

 

일반적으로 언리얼 엔진을 사용할 때는 액터의 구조 및 핵심 기능은 C++ 클래스에서 구현하고, 기본 동작은 블루프린트에서 구현합니다. 그리고 variation 은 블루프린트 상속을 통해 구현합니다.

 

다른 요소들 : Reference Viewer


 

지금까지는 mesh 와 animation 에 대해서만 언급했지만, 이것과 연관된 모든 요소들을 확인하고 싶을 경우가 있습니다. 이 때 사용하는 것이 reference viewer 입니다.

 

애셋 브라우저에서 애셋을 선택한 다음에 마우스 오른쪽 버튼을 클릭하면 context menu 가 나옵니다. 이 중에서 "Reference Viewer..." 라는 항목을 선택하면 참조 그래프가 나옵니다. 열어 놓은 블루 프린트에서 "Asset > Reference Viewer..." 를 선택해도 동작은 같습니다.

 

 

이제 DefaultCharacter 의 참조 그래프를 살펴 보도록 하겠습니다.

 

 

중심에 있는 노드가 "DefaultCharacter" 입니다. 그리고 왼쪽의 노드들이 DefaultCharacter 를 참조하고 있는 애셋들이며, 오른쪽에 있는 노드들이 DefaultCharacter 에 의해 참조되고 있는 애셋들입니다.

 

"Search Depth Limit" 와 "Search Breadth Limit" 를 조절하면 그래프를 모두 볼 수 있습니다. 노드의 가장 아래쪽을 보면 "Collapsed nodes" 라는 노드가 있습니다. 이는 "Search Breadth Limit" 를 늘리면 펼쳐집니다.

 

 

 

다른 노드를 클릭해서 다른 애셋의 참조 그래프를 볼 수 있습니다. 익스플로러에서처럼 좌상단의 좌우 버튼을 눌러 뒤로 돌아 가는 것도 가능합니다.


각 요소들의 세부사항에 대해서는 다른 섹션에서 다루도록 하겠습니다.

개요



UT 를 설치하고 나면 게임을 어떻게 실행해야 하는지 몰라서 답답함을 느끼게 될 것입니다. 이 때 도움을 줄 수 있는 것이 "ServerLaunch.exe" 라는 프로그램입니다.


이 파일의 경로는 "$(SolutionDir)/UnrealTournament/Binaries/ServerLaunch.exe" 이며, 이것을 디버깅하거나 분석할 수 있는 소스 파일 패키지( ServerLaunchSource.zip )도 같은 디렉토리에 들어 있습니다.




이 파일을 실행하게 되면 다음과 같은 윈도우가 뜹니다.



로고 버튼 혹은 LAUNCHER 버튼 : Settings



가장 위쪽에 있는 로고나 LAUNCHER 라는 글자를 클릭하면 Settings 다이얼로그가 나옵니다.



  • "Location of the UE4Editor.exe" 항목은 "UE4Editor.exe" 의 경로입니다. 즉 게임을 실행할 때 "UE4Editor.exe" 를 통해서 실행한다는 의미입니다. 물론 "UE4Editor.exe" 도 "UnrealTournament" 모듈을 포함하기 때문에 게임을 실행하는 데는 문제가 없습니다.
  • "Client IP" 는 클라이언트 프로그램의 IP 인데요, 로컬에서 띄울 것이기 때문에 "127.0.0.1" 로 설정되어 있습니다.
  • "Add Custom Server Command Line" 항목은 서버 실행시에 넘길 매개변수입니다. 어떠한 매개변수가 추가될 수 있는지는 아직까지는 잘 모르겠습니다. 거기까지는 분석을 안 했거든요...
  • "Game Types" 의 의미는 다음과 같습니다.
    • DM : Death Match.
    • TDM : Team Death Match.
    • CTF : Capture The Flags.
  • "Client Resolutions" 는 클라이언트 해상도입니다. 원하는 해상도를 추가하시면 됩니다. 게임 내에서 해상도를 바꿔도 다시 실행했을 때 런처의 설정으로 덮어 써 집니다. 해상도 말고 다른 설정들은 유지됩니다.


참고로 왜인지 모르겠지만 다이얼로그의 크기가 맞지 않아서 "Save" 버튼이 안 나오고 있는데, 현재 그 버튼에 포커스가 가 있으므로 엔터를 치면 "Save" 가 눌립니다. 맘에 들지 않으면 소스를 수정하시면 됩니다. 소스의 윈폼 디자이너에서 다이얼로그 크기를 늘렸다가 다시 줄이면 제대로 나옵니다.


"Single Player" 버튼



"Single Player" 버튼을 누르면 하나의 싱글 모드 클라이언트가 실행됩니다. 다음과 같은 식으로 인자가 넘어 갑니다.


UE4Editor.exe UnrealTournament ?Game=DM?GoalScore=5?TimeLimit=6 -game -log -winx=20 -winy=40 -resx=1600 -resy=900 -consolex=20 -consoley=960


의미를 이해하는 데는 큰 어려움이 없을 거라 생각합니다.


이 모드에서는 "Map To Play" 드롭다운박스에서 선택한 맵을 플레이를 시작하게 됩니다.


클라이언트를 띄우면서 콘솔이 같이 뜨는데, 그건 서버가 아닙니다. 서버는 따로 "Launch Server" 버튼을 통해 띄우게 되어 있습니다.



이 모드에서는 튜토리얼같은 싱글플레이만 즐길 수 있습니다. 멀티 플레이에 입장이 안 되는 건 아니지만, 입장해 봐야 다른 클라이언트가 들어 올 수 없으므로 의미가 없습니다.


현재 초기 맵이 "ShockAttaches" 라는 DM 맵이므로, 초기 화면으로 가려면 ESC 버튼을 누르고 Back 버튼을 누르면 됩니다.



클라이언트가 하나 뜨면 "DESKTOP-XXX" 와 같은 플레이어 아이디가 생성됩니다. 확인해 본 결과 싱글 플레이를 띄우면 항상 같은 아이디를 할당하는 것을 알 수 있었습니다.


이제 "BASIC TRAINING" 과 같은 싱글 모드 contents 를 즐길 수 있습니다. 아까도 말했듯이 멀티 플레이는 들어 가 봐야 의미가 없습니다. 트레이닝 맵에 처음 입장할 때는 텍스쳐 압축같은 것을 하느라 시간이 걸릴 수 있으므로 로그 창을 잘 보고 인내심을 기르시기 바랍니다.


"Launch Server" 버튼



"Launch Server" 버튼을 누르면 서버를 띄우게 됩니다. "Listen Server" 가 선택되지 않았을 때 다음과 같은 인자가 넘어 갑니다.


UE4Editor.exe UnrealTournament ?Game=DM?GoalScore=5?TimeLimit=6 -SERVER -log


그리고 나서 다음과 같이 서버 콘솔이 하나 뜹니다.



하지만 "Listen Server" 에 체크를 하게 되면, 게임을 띄웁니다. 제가 listen server 의 의미는 잘 몰라서 더 이상은 설명드리기 어려울 것 같습니다.


UE4Editor.exe UnrealTournament ?Game=DM?GoalScore=5?TimeLimit=6?Listen=1 -GAME -winx=20 -winy=40 -resx=1280 -resy=720 -consolex=20 -consoley=780 -log


"Connect Local Client" 버튼



"Connect Local Client" 는 "127.0.0.1" 에 접근하는 클라이언트를 "Number of Clients" 에 설정된 개수만큼 띄워 줍니다. 그 서버는 "Launch Server" 버튼을 통해 미리 띄워 둔 서버입니다. 물론 "Listen Server" 에 체크를 해서는 안 됩니다.



Single Player 의 인자와 다른 점이 있다면, "127.0.0.1" 이라는 주소가 들어 가 있다는 것과 클라이언트마다 창 위치를 다르게 한다는 것입니다. 만약 본인이 서버를 따로 구축했다면, 소스 코드에서 이 주소 부분을 수정하면 됩니다. 그렇게 되면 더 이상 "Local" 은 아니겠지만 말이죠.


이 클라이언트들도 싱글모드에서와 마찬가지로 각자 ID 를 할당받게 됩니다.


개요


 

UE4 는 모듈이라는 개념을 사용해서 프로젝트를 관리합니다. 각 프로젝트에는 "*.Target.cs" 라는 파일이 존재합니다. 이는 빌드타겟을 지정하고 있으며, 내부의 SetupBinaries() 메서드에서는 사용하고자 하는 모듈을 지정하게 됩니다.

 

UT 의 UnrealTournament 는 세 개의 빌드 타겟을 가집니다.

 

    • UnrealTournament
    • UnrealTournamentEditor
    • UnrealTournamentServer

 

그 중에서 UnrealTournamentEditor 빌드 타겟은 다음과 같은 모듈들을 포함합니다.

 

 

아래의 섹션들중에서 클라이언트 및 에디터와 관련한 두 모듈에 대해서 설명하도록 하겠습니다.

 

UnrelTournament 모듈


 

이 모듈의 정의파일은 UnrealTournament.Build.cs 입니다.

 

다음과 같은 기능들을 포함합니다. 모든 기능에 대해서 언급하기는 어렵고 관심이 있으신 분들은 관련 모듈 파일들을 살펴 보시기 바랍니다.

 

 

대부분 게임을 구동하는 데 사용하는 모듈들입니다. NetworkReplayStreaming, Json, JsonUtilities 등은 json replay data streaming 을 위해 사용됩니다.

 

 

UnrealTournamentEditor 모듈


 

이 모듈의 정의파일은 UnreaTournamentEditor.Build.cs 입니다.

 

당연한 이야기지만 UnrealTornament 의 기능을 포함하며, 편집을 위한 기능들을 추가적으로 가집니다.

 


이 문서는 https://github.com/EpicGames/UnrealTournament 의 How to get started (Windows) 항목에 대한 번역입니다. 해당 github 에 접근하는 것에 실패했다면, [ GITHUB 계정 연동 ] 문서를 참조하시기 바랍니다.

 


 

현재 언리얼 토너먼트 프로젝트는 언리얼 엔진 4.12 프리뷰 버전에 기반합니다( 역주 : 나중에는 버전이 더 올라갈 수 있습니다 ). 편의를 위해서 이 엔진 소스는 이제 우리 저장소에 포함됩니다. 윈도우즈에서의 사용을 위해서는 비주얼 스튜디오 2015 가 필요합니다.

 

언리얼 토너먼트 프로젝트 다운로드하기:

    • 이 페이지에 있는 Download ZIP 파일을 클릭해서 프로젝트를 다운로드하십시오.
    • 여러분의 컴퓨터에 있는 폴더에서 파일의 압축을 해제하십시오( 역주 : zip 파일의 크기는 작지만, 설치과정을 마치고 에디터를 실행하게 되면 최종적으로는 60 GB 이상의 용량이 필요합니다 ).
    • 여러분이 생성했던 디렉토리 내의 Setup.bat 파일을 실행하십시오. 이는 GitHub 에 저장되어 있지 않은 필요한 바이너리들을 다운로드하게 됩니다.
    • Engine\Extras\Redist\en-us 폴더에 있는 UE4PrereqSetup_x64 를 실행하십시오. 이는 누락되어 있을 수도 있는 다른 종속성 파일들을 설치할 것입니다( 역주 : Setup.bat 파일을 실행하는 과정에서 이것이 같이 실행되었다면, 굳이 설치할 필요가 없습니다 ).

 

언리얼 토너먼트 프로젝트 컴파일하기:

    • Engine\Source\Programs\UnrealSwarm 에 있는 UnrealSwarm.sln 을 열기 위해서 비주얼 스튜디오를 사용하십시오. 솔루션 구성( Solution Configuration ) 드롭다운 메뉴에서 Development 모드를 선택하십시오.
    • Agent 프로젝트에서 마우스 오른쪽을 클릭해서 속성( Properties )를 선택하십시오. 서명( Singing ) 탭으로 이동하여, "Sign the ClickOnce manifests" 에 대한 선택을 해제하십시오( 역주 : 소스를 받으면 기본값으로 해제되어 있습니다 ).
    • 마우스 오른쪽을 클릭해서 Agent 프로젝트를 빌드하십시오. 빌드가 끝나면 UnrealSwarm 솔루션을 닫아도 됩니다.
    • 프로젝트 압축을 해제한 디렉토리에서 GenerateProjectFiles.bat 를 실행하십시오. 이는 UE4.sln 을 생성할 것입니다.
    • UE4.sln 을 비주얼 스튜디오로 열어서, 솔루션 구성을 Development Editor 로 변경하십시오.
    • Programs 폴더에 있는 ShaderCompileWroker 와 UnrealLightMmass 를 빌드하십시오.
    • UnrealTournament 프로젝트를 빌드하십시오. UE4Editor.exe 가 Engine\Bindaries\Win64 에 생성될 것입니다.
    • 명령줄에서 "UE4Editor.exe UnrealTournament" 를 실행하거나, 비주얼 스튜디오에서 UnrealTournament 프로젝트에서 마우스 오른쪽을 클릭해서 디버그로 실행하십시오.
가끔 GenerateProjectFiles.bat 을 호출하면 Social 모듈 파일이 없다고 나오는데, 그건 zip 파일이 잘못 올라 가 있는 것입니다. 다른 버전의 파일을 받으시든지 [ 이 페이지 ] 의 Common issues 항목을 참조하시든지 하십시오. 


Unreal Tournament( UT ) 란 Epic Games 와 Digital Extremes 에서 공동개발한 1인칭 슈팅( First Person Shooting ) 게임입니다. UE4 로 넘어 오면서는 그냥 Epic Games 에서만 개발하고 있는 것으로 보입니다. UT 사이트에 가 봤더니 다른 공동 개발사에 대한 언급은 없더군요.

 

어쨌든 UT 는 Counter Strike 와 같은 전통적인 FPS 게임과는 다르게 총을 쏘는 즉시 반응하는 것이 아니라 나가는 궤적을 볼 수 있으며 곡사도 가능합니다. 그리고 매우 다양한 패턴의 무기가 존재합니다. 이런 부분들이 우리나라 게이머들에게는 별로 취향에 맞지 않는지 우리나라에서는 인기가 없습니다.

 

그럼에도 불구하고 제가 UT 를 분석하려고 하는 이유는 다음과 같기 때문입니다.

    • 최신버전에 맞게 갱신된 소스가 공개되어 있습니다.
    • 매우 오랜 기간동안 개발해 와서 안정성이 상당히 높습니다.
    • Epic Games 에서 개발하고 있기 때문에 UE4 사용법에 대한 훌륭한 레퍼런스가 될 것으로 보입니다.

 

UT 분석을 통해서 다음과 같은 부분에 대한 이해도를 높이려고 합니다.

    • Character.
    • Animation.
    • Cosmetic.
    • Physics.
    • Networking.
    • Gameplay.
    • Slate.
    • Optimization.

 

어느 정도 깊이로 분석할지는 모르겠지만, 최선을 다해 볼 생각입니다.

+ Recent posts