치킨 날다

오늘은 기본 Windows Application Template Project에 책에서 예시로 제시된 코드를 작성하려 했습니다.

그런데 DX11와 DX12가 생각보다 많이 다르더군요.

이론 부분은 검색을 하면 어느정도 나오는데 코드는 이게 잘 안됩니다.

가장 먼저 DX11에서 DX12로 넘어올 때 원래 있던 코드가 어떻게 바뀌었는지가 검색이 잘 안됩니다.

예를 들어서 ID3D11DeviceContext에서 하던 작업이 ID3D12GraphicsCommandList로 넘어 왔다던가.

dxerr.h의 DXTrace 함수가 사라진 것이라던가.

이 부분이 검색이 되어 인지가 되었다 해도 바뀐 이후에는
어떻게 작성해야 하는지 기반 지식 없이는 검색으로 숙지를 할 수 없었습니다.

여기서 DX11 책에 검색을 더해 DX12를 공부하는 것에 한계를 느꼈습니다.

그래서 DX12 책을 구매했습니다.

아마 내일 쯤 올텐데 내일 오후에나 올테니 오늘 내일은 더 진행할 수 없을 것 같습니다.

가능하면 금요일부터 상황을 봐서 진행하도록 하겠습니다.

오늘 마지막 남은 회사의 면접을 보느라 개발하지 못했습니다.

내일과 모래는 DirectX를 공부하고, 금요일에 마저 개발하겠습니다.

https://redchiken.tistory.com/209

면접을 갔다 오느라 많이 시간을 투자하지 못했습니다.

입력값을 처리하는 부분을 구현하였는데, 몇가지 index 오류가 발생하고 있습니다.

이 부분을 수정하면 생각한 방식이 옳은지, 시간 안에 동작 하는지 알 수 있을 것 같습니다.

https://www.acmicpc.net/problem/3300

어제도 상당히 복잡해서 하다가 말았는데 오늘도 역시 복잡했습니다.

꽤 시간을 투자 한 끝에서야 대략적인 구조를 완성 할 수 있었습니다.

일단 가정은 다음과 같습니다.

1. 비어있는 심볼에 공백 문자는 들어올 수 없다.

2. 비어있는 심볼 없이 일치하는 문장이 완성된다면 비어있는 심볼을 유일하게 유추할 수 없다.

사실 중요한건 2번입니다.

만약 2번이 성립하지 않으면 지금보다 더 복잡할 것입니다.

제가 생각하는 방식은 대략 다음과 같습니다.

1. 괄호가 열리면 높이를 1 증가시킨다.

2. 괄호가 닫히면 높이를 1 감소시킨다. 변화된 높이가 저장된 높이보다 1 작을 경우 입력 트리거를 킨다.

3. 알파벳('_' 포함)이 입력된 경우, 입력 트리거가 켜져 있으면 입력된 값을 Stack에 담는다.

4. '|'이 입력 되면 index를 저장하고 입력 트리거를 끈다.

5. 마지막 문자까지 연산이 마친 뒤 값을 비교한다.

문장에 '_'이 포함되어 있지 않고 예시 문자와 동일하다면 결과에 '_'를 저장하고 탈출한다.

문장에 '_'이 포함되어 있고 나머지 문자들이 예시 문자와 동일하다면 결과에 '_'에 대응하는 문자를 저장한다.

이 외에는 저장된 '|' index로 iterator를 이동시킨다.

현재 4번까지는 정리 되었고 5번만 구현해서 테스트를 하면 됩니다.

이렇게 구상한 이유와 기타 주의사항 등은 정답을 맞춘 뒤 작성하겠습니다.

사람은 역시 큰일이 나야 정신을 차리는가 봅니다.

과제 제출한 회사가 느낌이 좋아 요 몇일 멍하니 쉬면서 지냈는데 탈락해버렸습니다.

탈락하니까 손은 떨리고 기운은 빠지는데 머리는 더 잘 돌아가는 것 같습니다...

원래는 바로 Melee Attack을 건드려보려 했는데 저번에 선언했던 Interface 중 누락 된 것도 있고,
Interface가 혹시 모를 문제가 생길 수 있어 Movement(Locomotion, FullBody, Layered)와 관련된
Interface들을 먼저 적용해 보았습니다.

문서로 읽을 때에는 미처 깨닫지 못했는데 직접 해보니까 알 수 있던 것이 있었습니다.

하나는 Interface 함수는 virtual이나 BlueprintImplementEvent나 BlueprintNativeEvent 선언만 가능하다는 점.

때문에 RPC 함수를 선언 할 수는 없었습니다.

개인적으로 RPC함수까지 모두 Interface로 제공하고 싶었으나,
RPC 함수는 Class별로 선언하고 각 Client가 호출하는 함수만 Interface로 다형성을 제공하는 형태가 되었습니다.

이런 형태도 괜찮기는 하지만 아쉬운 것은 어쩔 수 없는 것 같습니다.

하지만 덕분에 THCharacterBase와 AnimInstance 사이에 존재하던 Coupling은 지울 수 있었습니다.

이쪽을 수정하는 김에 Movement와 관련하여 사용되지 않는 변수들을 삭제하였습니다.

또한 Jump를 누를 시 연속 Jump를 하지 못하여 1번만 가능하게 해놓은 것을 Animation Notify로 해결했습니다.

그리고 시간이 남아 Damage 관련된 Interface들을 선언하고 각각 Projectile와 Character에 부착했습니다.

아직 테스트는 하지 않았으나, 조만간 테스트가 가능할 것 같습니다.

그리고 이 부분이 아직 완전히 끝나지 않은 것이, Melee Attack 시 Damage 계산에 이 방식을 적용해야 합니다.

Melee Attack에 대해서는 고민이 많았습니다.

우선 Damage를 주는 Interface의 적용입니다.

이것을 Character에 적용한 경우 내부 함수가 복잡하게 계산될 가능성이 높았습니다.

그렇다고 Capsule Component에 붙이자니 새 Class를 만들어야 하고,
기능 선언이 Capsule Component와 Character 양 쪽으로 분할 될 수 있습니다.

여기서 저는 그래도 좀 더 정확한 판정을 위해 Capsule Component를 새로 만드는 쪽을 선택했습니다.

두번째로 Hit 이벤트 발생 위치입니다.

Hit 이벤트가 타격자에게 발생 할 경우 아무 문제가 없습니다.

하지만 피격자에게 발생할 경우 여태까지 생각했던 모든 것이 날라갈 수 있었습니다.

처음에는 테스트를 잘못 하여 피격자에게 발생하는 줄 알고 시간을 많이 날렸지만, 
제대로 테스트 해본 결과 다행히도 타격자에게 발생하고 있었습니다.

지금 제가 생각하는 Melee Attack 개선안은 다음과 같습니다.

1. ICheckInRangeCharacter를 구현하여 Semaphore 기능을 먼저 구성한다.
2. ICheckInRangeCharacter, Damage Activity, Capsule Component를 상속 받는 새로운 Component를 생성한다.
3. Character의 모든 Hit Component를 2의 Component로 교체한다.
4. Hit 이벤트 발생 시 Semaphore에 Character를 할당하고, 데미지를 계산한다.
   1. Notify를 이용해 주먹을 뻗을 때까지만 판정을 하고, 그 이후로는 판정이 불가능 하도록 할 수도 있다. 
5. Animation이 종료될 시점에 Notify를 발생시켜 Semaphore를 모두 리셋한다.

이 방식은 여러모로 장점이 있습니다.

첫째. 이후 Melee Attack이 확장 될 때에도 큰 문제가 없습니다.

콤보 어택은 필연적으로 Notify가 발생하는데,
각 Notify마다 어떤 Component가 Hit 판정이 가능하게 할 것인지 지정할 수 있습니다.

덕분에 얼마나 늘어나든 중복 타격이 될 가능성이 낮습니다.

둘째. 현재 굉장히 후한 판정을 줄여줍니다.

4.1.와 같이 어느 시점까지만 판정을 받을지 지정이 가능합니다.

때문에 무자비로 일어나는 타격 판정을 줄일 수 있습니다.

셋째. 공격 방식이 확장 가능합니다.

현재 Melee Attack은 오른손 펀치입니다.

이것이 콤보 어택이 되든, 다른 형태의 공격이 되든 판정은 Component가 합니다.

Character는 모션만 계산하고, 각 모션 때마다 어느 부위가 타격이 가능하게 할 것인지만 지정하면 됩니다.

때문에 얼마나 늘어나든 문제가 될 것이 없습니다.

이런 이유로 다음에는 ICheckInRangeCharacter를 먼저 구현하고, 이후 Child Capsule Component를 만들 계획입니다.

당일 시간이 된다면, Melee Attack까지 수정을 해서 마무리할 계획입니다.

그 이후에는 ICheckInRangeCharacter를 Trap에 적용하고, Trap 기능 완성에 필요한 Interface들을 우선 구현할 것입니다.

마지막으로 한가지 더 적어보자면, Projectile이나 Puzzle에 Pool을 적용하고자 합니다.

이들은 실제로 Spawn된 Actor가 작업을 모두 마치면 destroy되게 구현되어 있습니다.

하지만 실제 게임에서는 이들이 얼마나 많이 작동해야 할지 모릅니다.

만약 두번 이상 작동한다면, 그때부터는 수 많은 Actor를 Runtime 상에서 Spawn해야 합니다.

이 때문에 발생하는 부하를 막기 위해 작동을 마치면 InActive 상태로 두고,
Active 하기 전에 Reset하여 지정된 위치로 되돌릴 것입니다.

https://www.acmicpc.net/problem/3300

원래 Frogger를 풀려고 했는데 문제 해석까지만 되고 규칙을 찾지 못하여 다른 문제를 선택했습니다.

입력되는 직병렬 무어 기계와 입력값을 보고 지워진 심볼을 유추하는 문제입니다.

유추가 된다면 유추값을, 안 된다면 _를, 잘못된 입력 값이라면 !를 출력하면 됩니다.

처음에는 모든 경우에 대한 그래프를 만들어서 그래프 순회를 할까 싶었지만,
그래프 만드는 것 자체가 시간이 많이 드는 작업이라 시간 초과가 될 것 같았습니다.

그래서 Array로 Tree를 만들듯이 단순 순회로 입력을 조정해보려 합니다.

이에 대한 제대로 된 로직은 차후 짜보겠습니다.

어제서부터 피로가 쌓였는지 낮에도 비몽사몽해서 일찍 정리하고 하루종일 쉬려 합니다.

컨디션이 좋지 않아 문제 해석 후 풀다가 멈췄습니다.

내일 더 풀어보고 어느정도 정리해서 올려보겠습니다.

컨디션이 좋지 않아 오늘과 내일은 일단 휴식을 취하겠습니다.

따로 공부는 할 수도 있지만 보장을 못하니 비개발일지를 적습니다.

https://www.acmicpc.net/problem/2258

백준 사이트에서 풀 수 있는 정육점 문제입니다.

카테고리는 Greedy입니다.

19일 전에 처음 시도했던 이 문제를 중간에 과제 기간이라 하여 일주일 쉬긴 했지만 3주만에 드디어 풀었습니다.

풀면서 제가 막히거나 신경 쓴 부분은 다음과 같습니다.

1. 가격이 더 싼 고기를 무료로 얻을 수 있으므로 가격을 오른차순으롱 먼저 정렬하고,
무게를 빠르게 채워야 하므로 가격이 동일 한 경우 무게를 내림차순으로 정렬한다.

2. 가격이 더 싼 고기를 무료로 얻는다고 했지 가격이 같은 고기를 무료로 얻는다고는 안했다.

동일한 가격에 대해 누적된 가격을 계산해야 한다.

3. 2의 과정이 무게가 목표치보다 낮을 경우와 높을 경우에 필요한 연산이 다르다.

목표치보다 낮으면 항상 가격이 누적되고, 변동된 가격이 들어오더라도 이전 가격을 무시하면 된다.

반대로 목표치보다 높으면 가격을 더이상 누적하지 않고, 현재 최소 가격과 현재 가격만을 비교한다.

4. 모든 고기의 무게와 가격의 각 합인 unsigned int의 최대 값보다 작거나 같다.

때문에 조건에 부합하지 못해 -1을 출력해야 할 때 단순한 삼항연산자 등을 이용하면 <2^32 - 1>이 출력된다.
번거롭더라도 if문을 사용하거나, 출력 전에 string으로 형변환을 하는 등의 작업을 선행하자.

매우 간단하고, 처음에도 간단하다고 생각 했는데 3번 부분을 항상 놓치거나 잘못 작성하여 정답을 맞추지 못했다.

그리고 여태까지 문제를 풀면서 몇몇 문제는 정답 코드를 참조하기도 했는데,
이 문제는 정답률이 낮아서인지 마땅한 코드가 거의 없다.

아니, 그냥 검색 결과가 2개 정도 밖에 없다.

그래서 일부로 글 앞에 검색에 걸릴만한 내용을 추가하고, 하단에 코드를 작성했다.

이 문제에 막혀 참고를 하고자 하시는 분들은 다음 코드를 참고하시면 될 것 같다.

#include <iostream>
#include <vector>
#include <algorithm>

struct chunk {
	unsigned int weight;
	unsigned int price;
};

using namespace std;

int main()
{
	unsigned int length = 0, needs = 0, weight = 0, price = 0, before = -1;
	vector<struct chunk> meatlist;

	cin >> length >> needs;
	for (int i = 0; i < length; ++i)
	{
		cin >> weight >> price;
		meatlist.push_back(chunk{ weight, price });
	}

	sort(meatlist.begin(), meatlist.end(), [](const auto& a, const auto& b) { return ((a.price < b.price) || (a.price == b.price) && (a.weight > b.weight)); });

	weight = price = 0;

	for (const auto& iter : meatlist)
	{
		if (weight < needs)
		{
			if (before == iter.price)
			{
				price += iter.price;
			}
			else
			{
				before = price = iter.price;
			}
		}
		else
		{
			if ((before != iter.price) && (price >= iter.price))
			{
				before = price = iter.price;
			}
		}
		weight += iter.weight;
	}

	if (weight < needs)
	{
		cout << -1 << endl;
	}
	else
	{
		cout << price << endl;
	}

	return 0;
}

혹 몇가지 testcase가 필요하신 분들은 아래 파일에 있는 것을 참고하시길.

유의미 하지는 않지만 그래도 없는 것 보다는 나을 것이다.

Puzzle을 기능 기준으로 수정 하려다가 수 많은 에러에 맞고 쓰러졌습니다.

Puzzle의 코어한 부분들이 모두 Blueprint로 구현되어 있었기에 기능 구현이고 뭐고
일단 C++ 스크립트로의 수정 과정이 선행 되어야 했습니다.

그래서 안타깝게도 하루만에 순서를 바꾸어 Interface 적용을 앞땡겼습니다.

Interface를 적용하고자 하는 부분을 탐색해보자 정말 수 많은 선택지가 펼쳐졌습니다.

그 중에서 단순 생성과 관련된 함수나, 외부에서 접근할 필요가 없는 트리거에 대한 변경 함수를 제외하고 
나머지 상태 확인이나 트리거 변경, 선언 함수들을 Interface로 엮었습니다.

그 결과는 다음과 같습니다.

이들을 하나씩 적용하고, 이미 기능이 적용 되어 있다면 이를 수정 할 예정입니다.

이 외에 변경점이라면 이전에 Climb 기능 구현을 하면서 터득한
Animation Notify를 이용해 Melee Attack 기능을 개선하고자 합니다.

우선 Hit 이벤트가 여러번 발생하는 것을 막아주는 Lock을 Semaphore로 변경하고자 합니다.

이를 통해 한 Character에게는 한번의 이벤트만 발생하지만, 한번에 여러 Character에게 이벤트가 발생할 수 있습니다.

그리고 데미지 계산이나 Semaphore 연산을 RPC 함수를 이용하고자 합니다.

그리고 Wall을 분할하고자 합니다.

현재의 Wall은 Character의 이동 경로를 막는 방해물과 등반 가능한 등반 Object가 동시에 혼용되고 있습니다.

이를 두개로 나누어 기존의 Wall은 후자의 것으로 사용하고, 

전자의 것에 어울리는 새로운 Object를 생성하고자 합니다.

마지막으로 Puzzle을 새로 개발하고자 합니다.

BP 기반에 이전 Trap에 너무 의존적이었기에 완전히 삭제하고, 새로운 Puzzle을 개발하고자 합니다.

이번에는 UI 등 편의성을 개선할 계획도 있습니다.

새로운 Puzzle은 기존의 Break, Select를 우선 구현하고, 새로운 것을 구현할지 그때 가서 고민하려 합니다.

진행 순서는

1. Character 자체 기능 개선

2. Wall 분할

3. Climb 기능 개선

4. Trap 기능 개선

5. Puzzle 생성

입니다.