monstrosite

GameplayTag는 GAS 뿐만이 아닌 다른 경우에서도 매우 유용하게 사용할 수 있습니다.GameplayTag는 열거형이지만, 훨씬 더 체계화되고 정교해진 열거형이라고 생각하시면 됩니다. GAS에서 GameplayTag는GameplayTag Container안에 저장되고, GameplayTag Manager에 의해 관리됩니다. 뿐만 아니라 GameplayTag는 블루 프린트가 아닌 C++ 단계에서도 사용이 가능한데인터페이스인 IGameplayTagAssetInterface로 사용할 수 있습니다.사용가능한 메서드는 대표적으로 GetOwnedGameplayTags - 갖고 있는 GameplayTag를 가져옴HasMatchingGameplayTag - 지정한 특정 GameplayTag를 갖고 있는지 확인H..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

기존의 소켓 프로그래밍 예제에는 치명적인 문제가 남아있습니다.치명적인 문제점은 바로 블로킹 즉, 동기 방식으로 서버가 클라이언트의 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..