2025/03 20

47일차 - RPGProject 팀 프로젝트 3

▶▷ ShopUI 리소스 적용상점 UI의 슬롯을 기존에서 가로 스크롤 뷰로 변경한 다음 리소스를 넣었다.슬롯을 클릭하면 아이템 데이터에 작성해두었던 Description이 하단에 나오고 설명에는 이름과 가격을 포함시켜두었다.남은 부분은 슬롯에 아이템 이미지를 적용하고 구매하면 골드 차감 및 인벤토리로 이동, 인벤토리의 아이템을 클릭하면 판매가를 설명하는 부분에 보여준 다음 인벤토리에서 제거 후 골드를 추가하는 기능이다. ▶▷ 일시정지private void Start(){ // UIManager에 BaseUI 연결 UIManager.Instance.SetBaseUI(this); pauseBtn.onClick.AddListener(OnPause); resumeBtn.onClick.Add..

45일차 - RPGProject 팀 프로젝트 1

▶▷ 계획이번 프로젝트는 최종 프로젝트 전 마지막 프로젝트로 지금까지 배우면서 쌓아온 나의 능력치를 확인해보고 가다듬는 프로젝트이다.장르는 3D RPG이고 내가 이번에 맡은 역할은 UI와 각종 아이템 데이터 관리이다.UI는 앞에서 진행했던 인벤토리와 동일하게 캔버스를 통해 제작할 것이고 아이템 데이터는 SO(Scriptable Object)로 생성하려고 한다. ▶▷ UIUIManagerpublic class UIManager : MonoBehaviour{ // 싱글톤 인스턴스 private static UIManager instance; public static UIManager Instance { get { return instance; } } // 항상 활성화 되는 UI 참조 ..

44일차 - UI 복습 3

MonoBehaviour를 상속받는 클래스 사용 시 생성자 대신 초기화 메소드를 사용하여 외부에서 해당 메서드를 호출하는 방식 필요Character 초기화 메소드 Init()public class Character : MonoBehaviour{ // 캐릭터 기본 정보 public string Title { get; private set; } = "뉴비"; public string Name { get; private set; } = "Lee"; public int Level { get; private set; } = 10; public int MaxExp { get; private set; } = 12; public int CurExp { get; private set; }..

43일차 - 최적화 1

▶▷ 최적화최적화는 "렌더링 측면"과 "스크립트 코드 측면" 두 가지로 나눌 수 있음렌더링 최적화 (Rendering Optimization)1. Stats 탭에서 확인할 수 있는 항목들FPS (Frames Per Second): 초당 렌더링 프레임 수Batches: 렌더링 호출 횟수 (Static/ Dynamic batching 포함)Draw Calls: GPU에게 화면을 그리라고 명령한 횟수SetPass Calls: 재질(Material)이 변경되거나 셰이더가 바뀔 때 발생하는 호출로, GPU 상태 변경 비용이 크기 때문에 줄이는 게 중요→ SetPass Calls는 일반적으로 Draw Call보다 줄이기 어렵지만, Material batching, 동일 셰이더 사용으로 줄일 수 있음Tris/Vert..

42일차 - UI 복습 2

▶▷ 트러블 슈팅막히는점1. Status 창과 Inventory 창에서 뒤로가기가 각각 나누어지지 않거나 둘 중 하나만 이루어지는 현상2. 각각의 UI 클래스에서 해당하는 오브젝트들을 직접 접근하는 방식에서 객체지향적으로 구조를 변경하는 부분 해결1. bool 형식의 isStatus, isInventory 변수를 추가하여 각각의 상태 분리2. UIManager를 싱글톤으로 만들어서 이것을 통해 각 클래스들을 연결하는 방식으로 수정 알게된 점오브젝트를 직접 선언하지 않아도 ~~.gameObject로 접근 가능ex) UIManager.Instance.UIStatus.gameObject.SetActive(false);

41일차 - 컴퓨터 구조와 메모리 / 최적화

▶▷ 컴퓨터 구조와 메모리컴퓨터 드라이브의 기원초기 PC에는 A드라이브와 B드라이브가 있었고, 각각 운영체제와 응용 소프트웨어를 위한 플로피 디스크를 삽입하는 용도로 사용됨.기술이 발전하면서 디스크가 내장형으로 바뀌고, 드라이브 명은 그대로 이어져 C드라이브부터 시작하게 됨.➡️  우리가 흔히 사용하는 윈도우의 기본 드라이브가 C부터 시작하는 이유컴퓨터의 역사와 비트 개념과거 컴퓨터는 전구를 기반으로 작동, 전구의 켜짐/꺼짐으로 1과 0을 표현.이후 반도체로 진화하면서 이진법의 기반이 된 비트(Bit) 개념이 등장함.두 개의 비트를 조합해 숫자를 표현하는 방식 등 기초적인 컴퓨터 원리를 설명함.➡️ 이런 기초 개념은 컴퓨터가 정보를 어떻게 저장하고 처리하는지 이해하는 데 매우 중요함.int 자료형의 한계..

40일차 - UI 복습 1

▶▷ 메인화면 UI이번주는 다시 복습을 하는 느낌으로 UI에 관해서 다룰 예정이다.MainMenuUI먼저 메인 메뉴에서는 항상 활성화 되어있어야 하는 배경, 정보, 캐릭터, 골드 등의 오브젝트들은 Always라는 이름으로 묶었다.버튼은 클릭 시 해당 오브젝트들이 활성화되면 버튼은 보이지 않아야 하기 때문에 MainBtn으로 따로 빼서 묶어주었다.StatusUIStatus 버튼을 누를 경우 상태를 볼 수 있는 창이 활성화된다.상태창에서는 공격력 방어력 체력 치명타 등의 정보를 볼 수 있다. InventoryUIInventory 버튼을 누를 경우 인벤토리 창이 활성화된다.인벤토리의 슬롯은 하나 하나 직접 위치를 지정할 필요없이 Grid Layout Group이라는 컴포넌트를 이용하면 가지런하게 배치할 수 있..

39일차 - Path Of Survival 팀 프로젝트 마무리

▶▷ 병합 오류 수정마무리를 위해 최종으로 각자의 씬을 결합하는 과정에서 각 오브젝트를 프리팹화를 했음에도 불구하고스크립트 컴포넌트에 할당해두었던 오브젝트들이 누락되고 잘됐던 기능이 안되는 현상 때문에 이것을 해결하는데 대부분의 시간을 사용하였다.보통 충돌이 나게되면 충돌을 해결하라는 문구가 나오면서 해결할 방법을 제시하는데 이 문구가 없는 상태라 마음놓고 병합을 해도 날아가는 경우도 종종 생겼다.열심해 해놓고 병합 과정에서 날려먹는 경우가 자꾸 생기다보면 점점 힘이 빠지게 되면서 지친다고 대충 사용하면 더 꼬여버릴 수 있으니 깃허브를 사용할 때는 정말 신중하게 사용할 필요가 있다.건축 기능 관련해서는 병합이 잘못되어 다시 되돌린 다음 코드가 이상하길래 이전 커밋에서 코드를 복사하여 그대로 붙여넣고 오브..

38일차 - 에셋 관리

1. 기본 개념 및 필요성앱 용량 제한 극복:구글 플레이 등의 플랫폼에서 앱 용량 제한(예: 150MB)이 존재함. 에셋을 외부 서버(FTP 등)로 관리하여 APK 용량을 줄일 수 있음.에셋 관리 효율성 향상:어드레서블을 사용하면 필요한 리소스만 로드함으로써 전체 앱 용량과 로딩 시간을 개선할 수 있음.2. 어드레서블과 에셋 번들의 비교설정 방식 차이:에셋 번들: 모든 기능을 코딩으로 직접 구현해야 하며, 매 프로젝트마다 별도 설정이 필요함.어드레서블: 유니티 에디터의 GUI를 통해 설정이 가능하여 관리가 용이함.자동화 기능:어드레서블은 CRC 코드 등을 활용하여 에셋 변경 여부를 자동으로 판단하고, 변경된 경우에만 다운로드함.에셋 번들은 해당 기능을 직접 구현해야 함.3. 시스템 구성 및 사용 방법어드..