결론부터 말씀드리자면 카메라의 'Depth'때문입니다.

제 경우에는, 카메라가 3개 있는상태인데 위에 메인카메라와 UI카메라만 보이고 

체력바를 나타내는 카메라는 보이지않는 상태였습니다.

분명 캔버스 안에도 잘 들어왔고, 카메라 화면에도 비춰지는데 말이죠..

심지어 처음에는 씬에서 안보이는데, 카메라 인스펙터창에서

어떤 값이든간에 수정하기만 하면 무조건 화면에 비쳐집니다..!

여러가지로 검색해보다가 마지막 검색 'unity3d' 카메라 여러개라는 검색어를 통해서 알게된 사실..

카메라 3개 중 2개의 depth가 같아서 발생한 현상이었습니다.

depth가 0, 1 ,1 이었기에 발생한일..

depth를 0, 1, 2로 바꿔주어 해결했습니다..

어이없습니다.. (´。＿。｀)

프로젝트 작업을하면서 기존 맵에 이동제한구역을 설정해야했습니다..

하지만 이전에 Navigation Bake가 있는상태에서 새로할려면 Clear을 하고나서 해야하는데..

그전에 Bake할때 쓰인 오브젝트들을 어떻게 위치를 지정했고 또 어떤 방법으로 Bake를 했는지 

오래되었기에 아는사람도 없는 상태였습니다.

이미 이전에 다 Navigation으로 캐릭터가 다니는 길, 적이 다니는길을 다 작업해놓은 상태였기에..

기획분과 아트분이 말씀하신 빨간색 네무부분을 이동제한구역으로 새롭게 할려면 다시 Bake해야하는 상황이었습니다..

여러번 bake - clear - bake - clear을 해본 결과!

적이 껴서 움직이지 못하는 사태가 발생했고..

계속계속 다시해보다가 정말 간단하게 해결했습니다! Bake없이!

Compomnent 로 'NavMeshObstacle'을 추가하면 되는일이었습니다! :0!!!

너무 간단하네요!

그리고 Carve 는 해당오브젝트의 모양만큼 네브메쉬에 구멍이 뚫리게되어 캐릭터들이 해당 구멍을 피해서 다니게 됩니다!

그래서 저는 따로 3D오브젝트로 박스를 만들어주고 이동제한구역이 있는 곳에 맞게 박스를 배치한뒤 위처럼 컴포넌트를 추가해줬습니다.

Carve Only Stationary는 정지된 상태에서만 네브매쉬에 구멍을 뚫는것으로 

이를 비활성화하면 실시간으로 오브젝트의 움직임에 따라 구멍을 파낸다고 합니다

저같은 경우에는 기존의 네브매쉬를 건드리면 안되기에 이렇게 Nav Mesh Obstacle을 사용했는데

보통은 움직이는 장애물을 표현할때 많이 사용한다고합니다

하루종일 Bake한게 아깝긴하지만 그래도 해결이 돼서 너무 다행이네요! :D!!

다들 화이팅!

#include<iostream>
#include<algorithm>
using namespace std;

int main()
{
	ios_base::sync_with_stdio(false);
	cin.tie(NULL);
	cout.tie(NULL);

	int a, b, v, day;

	cin >> a >> b >> v;
	
	int minus = a - b;
	day = (v - a) % minus;


	if (day == 0)
		day = (v-a)/minus +1;
	else
		day = (v - a) / minus + 2;

	cout << day;

}

 v(전체높이) 에다가  a(한번 올라갈때의 높이)를 빼준것에다가

하루동안 갈 수 있는 높이를 %해준다면 

최종도착 바로 전 상황(바로전날)을 바탕으로 거리를 계산해준다.

%해주었을때 0이라면 최종도착전날까지 계산했을때 남는거리가 없다라는뜻이다. 

하지만 우린 최종도착전날까지의 거리를 계산한것이므로 한번 더 가야하기때문에 +1을 해줘야한다.

그러나 %해주었을때 0이 아니라면 최종도착전날인데도 불구하고 아직 거리가 남아있단 뜻이다.

그러므로 최종도착날짜 (+1)에다가 남은 거리까지(+1)을 해줘야하기에 +2를 해준다.

날짜는 (v-a)/minus를 통해 최종도착 전날까지를 계산하고 여기에다가 최종도착날까지를 계산해서 +1을 해주는데,

남은거리가 존재한다면 +1을 한번 더 해주어 +2를 해준다.

내가 대학교1학년때 풀었던 문제.. 그 당시에는 for문을 돌려 하루하루를 계산했다.

#include<stdio.h>

int main() {
	int a, b, v, day;
	
	scanf("%d %d %d", &a, &b, &v);

	for (day = 1; ; day++) {
		
		v -= a;
	
		if (v <= 0)
			break;
		v += b;

	}

	printf("day = %d", day);

}

지금보니까 너무 부끄러운데.. 아무튼 정말 직관적으로 아 하루하루 날을 세면 되겠구나! 라고 생각을 하고 더하고 빼고 했던것같다 ㅎㅎㅎ;; 너무 부끄럽지만 그 당시에는 코딩에 익숙치못해서 그랬던것같다. 

한 두번정도 틀리니까 와 이문제는 어려운거구나! 라는 생각에 시도를 하지않기도했고 

지금 다시 풀어봤을때도 괜히 어렵게 꼬아서 생각을 했던것같다.

다시보니까 빙구같다...귀엽기도하고..안타깝기도하고..부끄럽네...

그래도 과거 틀렸습니다에 머무르지않고 맞았습니다로 극복했기에 이렇게 블로그에다가도 쓴다! 뿌듯하다!!😁✨

혼자서 게임을 만들어볼 생각이 있어서 나름 생각만 하던 기획안이 있었습니다.

두개의 캐릭터를 동시에 조작키로 움직이는것이었는데요..

유튜브에서 게임영상들을 보면서 어려운 게임들을 보니 저도 모르게 영향을 많이받았던것같습니다.

여기서 구체화해서 두개의 캐릭터 중 하나는 사람.. 다른 하나는 영혼으로 구상하였습니다 ㅋㅋ

그리고 키보드에서 한명이 WASD와 방향키 조작을 하는것은 그때도 좀 힘들거라고 생각했는지

나름 모바일로해서 양쪽의 2분할 화면을 통해 각각터치로 진행하면되겠구나 라고 생각했죠.

보이시나요? 왼쪽에선 미션을 수행하고 오른쪽 화면에선 총쏘고 앉아있는거! 환장하겠네!

그러다가 두 캐릭터를 동시에 움직이는게 굳이 조작키 두개일 필요는 없지않나? 반대로 움직이면 한번에 두 캐릭터가 다 움직일 수있잖아! 라는 생각을 떠올리게됩니다! :0! 

여기서 또 개연성을 부여해서 귀신은 사람과 반대로 행동한다는 설이 있으니 어떻게 또 말이 맞아보이구요??

그래서 한가지 조작키로 두 캐릭터를 동시에 움직이는 게임을 생각해냅니다!

이 당시에는 2D로 생각을 했고 미로형식을 생각했습니다. 

반대로 움직이다가.. 같은 지점에서 만나게되면 온전한 몸(본체+영혼)이 되어 출구로 나갈 수 있는!

나름 스토리도 구축했고 개연성도 부여하였고 참신성도 있다고 생각했지만..

게임에 넣을 미로에는 이런것들이 있겠지 싶어서 나름 찾아보고 구성해보면서 느꼈습니다.

어 ㅋㅋㅋ 뭐지??

쫌 망했네 ㅋㅋㅋ..?

 미로맵 2개로  2D로 미로를 만들려고하니 서로 겹쳐지는 부분이 있어야하는데..설계해보니

엄청나게 복잡해졌습니다. 그냥 단순히 일자여도 복잡해질까말까? 인데 난이도가 올라갈껄 고려해서

조금이라도 모양이 복잡해지면 정말 복잡해지는것입니다!

심지어 맵이2개가 아니라 1개여도 나름골치가 아파집니다!

서로 반대로 움직이는 캐릭터가 만날려면

양 끝에서 서로 출발을 해야하는데 그러면 무조건적으로 둘은 대충 예상되는

중간부분에서만 계속 만나게됩니다.

난이도가 쉽고 어렵고를 떠나서 게임자체가 갑자기 엄청 재미가 없어지는거죠! 

생각할것도 없고 뭐 똥개훈련시키는것도 아니고.. 

만드는 저도 힘들고 플레이할 사람도 재미없는게 뭔가 눈에 훤히 보였습니다.

이 시점에서 게임을 2D로 할지 3D로할지 많이 고민했습니다. 2.5D는.. 나름 쟤도 2D3D 사이에 차원이라고 생각을 하였으나 현재 고민하고있는 부분에 대해서는 실질적으로 해결책이 될것같진않았습니다.

하지만 선택지가 2가지 밖에 없으니 생각보다는 쉽게 결정했던것같습니다.

지금 제 게임의 정체성(동시에 두 캐릭터를 하나의 조작키로 움직이는것)을 포기하지않는다면 2D는 절대 안된다.

라는 결론이 나왔고 생각보다 3D로 생각하고 난 다음부터는 맵설계가 그나마 쉬워진것같았습니다.

대신 처음2D로 할려고했던 이유는 최적화문제도 있지만..제가 직접 도트를 찍어 기획아트개발 모두를 전담할려고했기에 고민할 필요가 없어 보이던 3D도.. 나름 고민했습니다.. 

그래도 다행인건 2D에서 같은 지점에서 만나야 했던것을

3D에서는 같은y축(세로 선상)에서 만나면 되기에 다행이었습니다.

큰 틀이 바뀌진 않았죠 ㅠㅠ 휴 ㅠㅠ

그 다음부턴 게임 구체화를 했던것같습니다. 구체적으로 어떻게 나타낼것이며 스테이지들을 보여줄때 어떻게 보여줄것이며 게임 메인화면은 어떻게 구상하고 게임오버시, 클리어시 어떻게 나타낼지를 구체화했죠.

직접 손으로 쓴 것들도 되게 많은데.. 지금 개발일지를 적자고 수첩을 찾아서 사진을 찍을려고 하니 이미 태블릿에 있는것들 찾아서 캡쳐만 해도 양이 상당해서 직접 손으로 쓴것들을 따로 안올리겠습니다.

그렇게 틈틈이 게임을 구체화 하고있었는데.. 

위의 컨셉들을 모두 엎기로했습니다.

이유는 다음 개발일지에서....