monstrosite

기존의 소켓 프로그래밍 예제에는 치명적인 문제가 남아있습니다.치명적인 문제점은 바로 블로킹 즉, 동기 방식으로 서버가 클라이언트의 Connect 요청에 Accept를 수행한다는 것입니다. 동기 방식에서는 서버가 Connect 요청이 오기전그러니까 서버가 Accept를 수행하기 전까지는 다른 작업을 하지 않고 계속 기다리게 됩니다.그리고 이는 작업을 처리하는데 있어서 낭비로 이어지게 됩니다. 따라서 기존의 코드를 수정하여 논블로킹, 즉 비동기 방식으로 변경하여클라이언트로부터 Connect 요청이 오는 경우, Accept를 수행하고그렇지 않은 경우 다른 작업을 수행하는 방식으로 변경하겠습니다. 코드 작업을 하기 전,간단하게 동기와 비동기 방식을 시각적으로 표현해보았습니다. - 동기 방식(=블로킹) 서버에서 ..

1) 경계 상태를 의미하는 SkeletonStateEngagepublic class SkeletonStateEngage : EnemyState{ // 경계 상태를 의미하는 SkeletonStateEngage SkeletonController _skeletonController; Transform _player; float _moveDir = 1; public SkeletonStateEngage(EnemyController enemyBaseController, EnemyStateMachine enemyStateMachine, string animatorBoolParamName, SkeletonController enemyController) : base(enemyB..

이제 기존의 Enemy 3총사를 사용하여새로운 적인 Skeleton을 만들어보겠습니다. 기존의 코드에서 볼 수 있듯이 새로운 적의 타입별로 Controller가 필요하므로 이를 수행하겠습니다. 1) SkeletonControllerpublic class SkeletonController : EnemyController{ // Skeleton States public SkeletonStateIdle _idleState { get; private set; } public SkeletonStateMove _moveState { get; private set; } public SkeletonStateEngage _engageState { get; private set; } public..

이번에는 플레이어를 공격할 적을 만들어보겠습니다.그전에 플레이어와 적은 어느정도 공통적으로 사용하는 부분이 존재합니다.이를 해결하기 위해 플레이어와 적 모두 공통적으로 상속받는 클래스를 하나 만들겠습니다. 1) 플레이어와 적의 공통 부모인 BaseCharacterControllerpublic class BaseCharacterController : MonoBehaviour{ [Header("Collision Info")] [SerializeField] protected Transform _groundCheck; [SerializeField] protected float _groundCheckDistance; [SerializeField] protected Transf..

서버 - 클라이언트 프로그래밍에서 소켓 프로그래밍은서버와 클라이언트 모두 연결을 위한 대리자, 즉 소켓을 이용하여 서로 연결하는 프로그래밍입니다.이때 서버와 클라이언트의 진행 방식에 있어서 서로 차이점이 존재합니다. 1) 클라이언트 단계의 소켓 프로그래밍클라이언트는 소켓을 준비하여 서버 주소로 Connect를 요청할 수 있습니다.그리고 Connect 요청이 받아들여진 후 서버 소켓을 통해 Session 소켓과 패킷을 서로 송신/수신할 수 있습니다. 2) 서버 단계의 소켓 프로그래밍서버는 클라이언트와 다르게 소켓 프로그래밍을 위한 준비 절차가 조금 복잡합니다.그 절차를 간단하게 다음과 같이 표현할 수 있습니다. 클라이언트로부터 접속 요청(=Connect)을 받는 Listener 소켓 준비준비된 Listen..

1) Attribute에 Clamp를 적용기존의 Attribute가 동작하는 방식을 보면,따로 Clamp 함수를 사용하지 않아 Attribute에 반영할 변경 수치를 조정하지 못하고 있습니다.이를 위해 2개의 함수를 사용할 예정입니다. 1) PreAttributeChangePreAttributeChange 함수는 실제 Attribute에 변환이 적용되기 이전에 호출되는 함수입니다. Attribute의 BaseValue와 CurrentValue 중에서 CurrentValue를 바꿔주기 위해 사용하는데,CurrentValue를 바꾼 값으로 계속 유지하지 않고 바꾼 값만 리턴하게 됩니다. 따라서 PreAttributeChange 함수 이후의 연산들은 바뀌기 이전의 CurrentValue를 다시 사용하게 됩니다..

지난 포스트에 이어서 설정을 구성하는 작업을 다시 시작하겠습니다.그 전에 먼저 Gameplay Effect가 작동하는 명세를 간단한 이미지로 표현하였습니다.  1) Instant GE한 프레임동안 동작하는 Instant GE의 경우BeginOverlap과 EndOverlap 이벤트에서 모두 적용합니다.EndOverlap에서 해당 GE를 적용하는 이유는 Instant GE의 경우 적용되어도한 프레임이 지난 후에 삭제되기 때문입니다. 2) Duration GE지정한 Duration 동안 동작하는 Duration GE의 경우도 Instant GE와 비슷하게 동작합니다.BeginOverlap과 EndOverlap 이벤트에서 모두 적용합니다.마찬가지로 EndOverlap에서 해당 GE를 적용하는 이유는 Durat..

Duration Policy가 Inifinite로 설정될 Gamplay Effect를 사용하기 위해서는기존의 코드를 조금 변경해야 할 필요가 있습니다. 이전에는 Gameplay Effect를 사용하는 Actor에게서 Overlap 이벤트가 발생해도Duration이 끝나거나 Instant라면 알아서 종료되기 때문에 큰 문제가 없었지만 Infinite인 경우 종료되지 않아 영구히 적용되 때문입니다. 따라서 코드를 수정하도록 하겠습니다. 1) Gameplay Effect를 발동하는 AuraEffectActorUENUM(BlueprintType)enum class EEffectApplicationPolicy : uint8{ ApplyOnOverlap, ApplyOnEndOverlap, DoNotApply};UE..

이번에는 Effect Stacking에 대해 알아보겠습니다.동일한 GE가 중복되어 적용되는 것을 Effect Stacking이라고 하는데,적용되는 방식으로 크게 2가지로 구분할 수 있습니다. 1) Aggregate by SourceGE를 적용하는 Source를 Stack 대상으로 삼아 동작합니다.GE를 적용할 때마다 Stack에 Count를 하나씩 쌓아 놓게 됩니다.이때 Stack Limit Count라는 Count의 제한 범위를 두는데만약, Stack에 쌓인 Count의 수가 Stack Limit Count와 동일하다면 그 이후의 GE는 적용하지 않습니다. 2)  Aggregate by TargetGE를 적용하는 Target을 Stack 대상으로 삼아 동작합니다.GE가 적용될 때마다 Stack에 Cou..

GameplayEffect의 경우 다음과 같이 3개로 정의할 수 있습니다. 1) Instant GECurrent Value와 Base Value 중에서 Base Value에 영향을 주는 GE입니다.이 변화는 영구적으로 Base Value에 적용됩니다. 2) Duration 또는 Infinite GECurrent Value와 Base Value 중에서 Current Value에 영향을 주는 GE입니다.GE가 끝나면 해당 변화는 사라지게 됩니다. 3) Period GECurrent Value와 Base Value 중에서 Base Value에 영향을 주는 GE입니다.지정한 Period마다 GE를 Base Value에 영구히 적용하게 됩니다. 1) Period GE이번에 알아볼 GE는 바로 Period GE입니..