2024년 4월 17일 스파르타캠프 TIL

아주 중요한 개념을 깨달았다. 

 

과정은 이러했다. 전 날 내가 구현한 버튼 누르면 배경색 바뀌기 기능에 애로사항이 있었는데 씬이 넘어가면 그 색이 그대로 가는 것이 아니라 원래의 색이 나오는 것이었다. 이 것을 해결 하기 위해 생각을 해봤지만, 생각이 나지 않아 튜터님께 가 질문을 하였다. 그리고 튜터님은 아주 좋은 설명을 해주셨다.

 

일단 씬이 넘어갈 때는 모든 오브젝트가 파괴 되고 재생성이 된다. 그리고

방법은 두 가지였다. 카메라를 DonDestroyLoad 를 사용 해 파괴 되지 않고 넘어가게 하는 것이었다. 그렇게 되면 메인씬과 스타트씬에 카메라가 2개이니 메인씬 카메라를 파괴 시키게 하는 코드를 작성 하면 된다. 

 

그리고 다른 한가지의 방법인데 그 방법은 스타트씬에 게임매니저유형의 오브젝트를 만들고 그걸 싱글톤과 파괴가 되지 않게 설정을 한 다음에 메인씬에서 활용을 하는 방법이다. 

 

그러면 데이터는 메인씬으로 넘어가도 남아 있을 것이고 Start 함수에서 배경색을 게임매니저의 정보로 바꾸는 코드를 사용 하면 된다.

 

나는 두 번째 방법으로 사용을 하려 했지만, 미리 사용 하고 있던 게임매니저스크립트를 써보려 하니 의문점이 생겼다. 게임매니저에 오브젝트를 가져와야 하는데 그 오브젝트들은 메인씬에 있어서 생긴 의문점이였다. 

 

나는 이 경우 스타트 함수에 겟컴포넌트 등을 사용 해서 오브젝트를 가져와야 하냐고 물어 보았는데 Find 라는 함수가 있다고 알려줬다. 이 함수는 하이어라키에 있는 모든 것들을 찾아서 값을 가져오는데 성능이 너무 안 좋아서 사용하지 않는 다고 한다. 

(겟컴포넌트를 하려면 오브젝트가 있어야 하는데, 그러면 파인드를 사용 해야 해서 비효율적이다)

겟오브젝트는 없는 것 같다.

 

그래서 일반적으로 사용 하는 방법이 스테이지나 씬마다 스테이지매니저, 씬매니저 등을 만들고 거기에 미리 오브젝트의 정보를 담아두고 게임매니저의 정보를 활용 하게 하는 것이다. 

 

그러면 게임매니저에서 함수를 작성 할 때 함수명(오브젝트형 매개변수)로 작성을 해야 한다고 생각은 했는데 맞는지는 아직 안 해봐서 모르겠다. 이 것도 해봐야 난 개발자로써 성장을 하는데 아직 난 멀었나 보다. 

============================

 

Static은 클래스에 사용을 해야 한다. 함수에 사용 하더라도 클래스가 Static이 아니므로 사용을 할 수가 없다. 

 

============================

 

헷갈렸던 것에 대한 답을 드디어 알았다. 

나는 싱글톤화라는 것에 대해 항상 의문점이 있었다. 

 

다른 스크립트에서도 사용 가능 하게 한다면은 되게 좋은 기능인데 왜 하나만 작성을 해야 하는가 였다.  

 

질문을 했는데 싱글톤을 여러 개 만들면 싱글톤을 사용 할 때 찾는 게 오래 걸린다고 하였다. 

 

하지만 그런 것보다 내가 궁금한 것에 원하는 답변은 이거였다. 

 

싱글톤화는 한 스크립트에서 한 개만 있어야 하는 거지, 스크립트마다 싱글톤으로 만드는 것은 상관이 없는 것이였다. 

 

그동안에 알고 싶었던 궁금증이 해소 되는 순간이었다. 그 동안 이걸 사용 안 하면 번거로울 것 같은 작업들이 있었는데 이 해답을 알게 돼서 앞으로 코드를 구성 할 때 되게 편해지는 순간이었다.

 

하지만 이 또한 내가 설명을 제대로 안 들어서 생긴 문제 였겠지라고 생각 했다. 

==============================

 

오늘은 Git 특강이 있었다. 

되게 쉽게 생각 했던 녀석이였는데 생각보다 복잡한 녀석이였다. 

 

이 녀석 때문에 카드게임에 기능추가를 하기로 했었는데 시간을 다 잡아먹어서 기능추가를 하지 못 하였다. 

 

하지만 매우 좋은 녀석이였다 ..

==============================

 

Vector3와 Vector2를 사용 할 때의 구분

연산의 경우에는 두 개의 Vector3 값을 필요로 하고 값을 할당/대입 할 때는 z 값이 없으면 0으로 세팅해주는 로직이 있기 때문입니다

무슨 느낌인진 알겠는데 모르겠다. 한 번 경험이 생기면 알 것 같다.

 

==================================

게임매니저유형에 대해서 생각을 해보자면 나는 게임매니저에 오브젝트 등을 넣어주고 함수도 만들고 했는데 나중에는 정보들만 남겨두고 함수들만 남겨둬야 할 것 같다. 

 

각각의 씬마다 스테이지매니저등을 만들고 거기에 오브젝트들을 넣고 매개변수를 활용 해야 할 것 같다. 

 

좀 더 복잡 해지겠지만 더 깔끔한 구성이 될 것이다. 하면서 재밌을 것 같다.

 

===============================

 

버튼에 이미지를 적용 할 때 버튼 이미지의 색상에 영향을 받는다. 

ex) 이미지가 검은 색이면 어두운 이미지(사진 등)로 된다.

===============================

 

로컬 레포지트리 - > 개인 저장소 느낌이다. 

커밋 - > 기록 하는 하나의 단계 (저장 하는 것을 커밋이라고 하는 것 같다)

히스토리 - > 이 커밋들이 쌓여 있는 곳이다.

그리고 히스토리를 업로드 하는 것을 push 

푸쉬를 하면 저장소에 업로드가 된다. 

 

그리고 내 개인 저장소에 저장 돼있는 걸 메인에 적용을 해야 한다. 

 

이 메인은 리모트 레포지트리 라고 한다. 

 

이 리모트 레포지트리에 적용 하는 것을 머지라고 한다. 

 

그리고 리모트 레포지트리를 다운 받는 것을 full이라고 한다. 

 

사람들이 보통 리모트 레포지트리에 저장을 하면 내가 full을 해야 내 프로젝트에 적용이 된다.

 

그리고 브렌치. 브렌치는 중요한 것 같다. 

 

지금은 작업을 할 때마다 브렌치를 새로 생성 하고 작업을 하는 느낌으로 알고 있지만 이건 나중에 제대로 개념을 잡아야 할 것 같다. 

 

그 의미는 그냥 저장소 하나하나를 브렌치라고 하는 것이지만 잘 활용을 해야 겠다. 

원만한 협업을 위해서.

 

git이 뭐냐고 물어본다면?

버젼을 관리 하는 시스템이다. VCS
version Control System

라고 하면 된다는 좋은 것을 알려주셨다. 

 

유용한 기능들 

 

git ignore = 이그노어로 설정 돼 있는 것을 자동으로 git에 등록이 되지 않게 해준다. 

매우매우 중요하다고 일러주셨다. 왜냐면 귀찮은 작업을 하지 않게 해주기 때문이다. 

유니티에는 별로 중요하지 않은 폴더들이 있는데 그것들을 등록이 안 되게 해준다. 이런 것들이 다 등록이 된다면 용량이 커지고 매번 full을 받을 때마다 좋지 않기 때문이다. 이 외에도 내가 등록 하고 싶지 않은 것들, 유료에셋이라던가 등도 이그노어 설정 해서 등록이 자동으로 안 되게 할 수 있다. 

이건 따로 찾아봐서 설정을 하면 될 것이다. 

 

Amend = 코밋한 내용을 수정해서 작성

 

Undo = 원격으로 보내기 전에 할 수 있다. 커믹 내역을 없앤다. / Changes에서 복구가 가능하다. 

 

Revert = 커밋한 내역을 없애는데 없앤 내용을 기록한다. 히스토리에. 

 

그리고 푸시버튼은 함부로 누르지 말고, 이제 완벽해라고 느끼는 순간 눌르자.

 

Discard all changes 
다 삭제

Stash all changes
임시저장 
임시로 치워둘 수 있음
Restore 누르면 다시 채워짐
dicard 삭제

 

그리고 머지를 하기 전에 부모 브렌치에 변경점이 있는지 확인 하고 변경점이 있다면 자식브렌치에 머지를 하고 오류가 있는지 확인 하는 게 안전하다. 

 

Checkout commit 
옛날 코드가 좀 더 나은 거 같은데?
그 커밋이 끝난 상태로 바꿔줌 .

 

그리고 같은 스크립트에서 같은 줄을 수정하면 오류가 난다.

 

가장 중요한 건 소통인 것 같다. 머지를 할 때 무조건 머지를 한다고 사람들에게 소통하자. 

 

그리고 가장 중요히 강조 하신 게 있다. 

절대 하나의 파일을 여러 명이 작업 하지 말 것! 

 

커밋 우클릭 해서 뉴브렌치 하면 그 커밋을 기점으로 브렌치가 생성이 된다. 

 

그리고 깃허브는 순서개념이란 것인 게 중요하다. 

 

순서다. 

 

그리고 팀원들끼리 원활한 활동을 위해 커밋의 이름을 적는 규칙 같은 것을 정하는 게 좋다. 

뭔가를 삭제 했을 때 생성 했을 때 수정 했을 때 

 

그리고 큰 프로젝트를 할 경우에 기능별로 브렌치를 만든다. 

 

깃플로우 전략!

 

브렌치도 잘 나눠야 하고 커밋도 잘 해야 한다.