게임 개발 노트

2주차 : 주요 메카닉 구현 팀 회의 내용 - 진행상황 공유 - 2주차 회고노트 작성 구현한 내용 - 리팩토링 완료 - 해상도 변경으로 UI 디자인 데이터도 Controller로 보내면서 진짜 MVC 패턴이 된 것 같다 사실 MVC와 MVP는 명확하지 않고 애매한 것 같다 찾아보다가 게임쪽에서는 MVC 패턴을 사용하지 않는다는 글을 보게 되었다 MVC는 모델과 뷰의 연결을 느슨하게 해서 로직 코드와 뷰의 리소스를 관리하기가 용이하지만 게임은 특성상 뷰가 바뀌면 컨트롤러나 모델이 바뀔 가능성이 높아서 쓸데없는 코드가 많아지고 코드 파악도 쉽지 않다 라는 글이었다 그래서 추가로 UniRX라는 플러그인을 사용해서 MV(R)P를 쉽게 구현하여 UI에서 사용하면 코드가 깔끔해지고 관리하기 좋다는 말도 있었다 MV..

2주차 : 주요 메카닉 구현 팀 회의 내용 -진행상황 공유 구현한 내용 - 정렬 기능 완성 (가격순->오름,내림) - 리팩토링 4일차에 주요 기능들은 완료를 한 상황이고 데이터 저장 방식을 좀 더 효율적으로 관리하기 위해 변경된 방식으로 리팩토링을 진행하였다 내일은 다른 UI 작업한 팀원분이랑 연결까지 하고 UI 디자인까지 하면 내가 맡은 주요 메카닉은 완료 ! 기술면접 10일차 Q : 제네릭이란 무엇인가요 ? A : 데이터 형식을 일반화하여 다양한 형식의 데이터를 처리하는 메서드나 클래스 등을 작성할 수 있는 기능으로 재사용성과 유연성을 향상시켜주고 컴파일 시점에서 결정되기 때문에 안정성이 보장됩니다 (꼬리질문) 제네릭은 언제 사용하나요? :여러 데이터 형식에 대해 동일한 로직을 적용해야할 때, 컬렉션..

2주차 : 주요 메카닉 구현 팀 회의 내용 - 멘토링 질문 및 피드백 회의 - 해상도 20:9 변경 구현한 내용 - MVC 패턴으로 리팩토링 - 탭 기능 완성 - 주문 내역 완성 MVC 패턴 : model - view- controller 는 사용자 인터페이스로부터 비즈니스 로직을 분리하여 서로 영향 없이 쉽게 고칠 수 있는 개발을 할 수 있다 modle : 데이터와 데이터를 처리하는 로직으로 상태를 나타낸다 . 뷰나 컨트롤러는 알지 못하며, 직접적인 참조를 가지고 있지 않는다 상태의 변경을 통지하기 위한 옵저버 패턴이나 이벤트를 사용할 수 있다 view : 화면에 정보를 표시하고 사용자 입력을 받는다 , 뷰는 모델을 알지만 모델에 대한 직접적인 참조를 가지지 않는다 대신 모델의 상태 변경에 대한 이벤트..

2주차 : 주요 메카닉 구현 팀 회의 내용 - 화면 해상도 정하기 구현한 내용 - 재료 주문 UI 기능 구현 - 재료 추가 slot 데이터 연결 - 재료 추가 기능 연결 - 주문 내역 slot 데이터 연결 어제 만들었던 데이터와 UI 디자인을 바탕으로 각 슬롯에 데이터가 셋팅될 수 있게 연결시켜주고, 각 UI에 맞는 기능들을 연결시켜 주었다 기술 면접 대비 8일차 Q: 박싱과 언박싱에 대하여 설명해주세요 A: 박싱은 값 형식을 Object 형태의 참조 형식으로 변환하는 것을 말하고 스택에 있는 데이터가 힙으로 복사되는 과정입니다 언박싱은 참조 형식을 값 형식으로 변환하는 것을 말하고 에 있던 데이터를 스택으로 복사되는 과정입니다 -> (꼬리질문) 박싱, 언박싱을 사용할 때 주의해야 할 점이 있다면 무엇이..

2주차 : 주요 메카닉 구현 팀 회의 내용 - 에셋 구매 - 프로젝트 셋팅 - 게임 이름 정하기 구현한 내용 - 재료 데이터, 클래스 생성 각 재료들이 가져야할 데이터를 ScriptableObject에 읽기 전용으로 저장하여 런타임중에도 변동되지 않게 설정하여 예기치 못한 상태 변화를 방지하여 데이터의 안정성을 높이고 변동 가능성 있는 데이터들은 각 재료가 가지고 있을 스크립트에서 프로퍼티로 get,set이 가능하게 하고 ScriptableObject에 저장된 기본 데이터로 초기화를 시켜주었다 기술 면접 대비 7일차 Q: 가비지 컬렉션이란 무엇인지 설명해주세요 A: 가비지 컬렉터에 의해 수행되는 프로세스나 동작을 가리키며, 더이상 사용되지 않는 메모리를 해제하는 과정을 말합니다 프로그램에서 동적으로 객체..

ScriptableObject : 클래스 인스턴스와는 별도로 대량의 데이터를 저장하는 데 사용할 수 있는 데이터 컨테이너 주로 언제 사용하는 가 ? : 값의 사본이 생성되는 것을 방지하여 프로젝트의 메모리 사용을 줄이는 것으로 연결된 MonoBehaviour 스크립트에 변경되지 않는 데이터를 저장하는 프리팹이 있는 경우 유용하다 - 에디터 세션 동안 데이터 저장 및 보관 - 데이터를 프로젝트의 에셋으로 저장하여 런타임 시 사용 *ScriptableObject에 데이터를 저장하는 작업은 편집할 때나 런타임에 가능하다 * MonoBehaviour 와는 달리 게임 오브젝트에 ScriptableObject를 연결할 수 없으며 대신 프로젝트의 에셋으로 저장된다 기술면접 대비 6일차 Q: 가비지 컬렉터를 회피하기 ..

최종 프로젝트 개발에 들어가기 전 사용해야 할 UI에 대해 복습하는 시간을 가져보았다 Layout Group : 자식 게임오브젝트로 들어온 UI들이 자동으로 정렬해 주는 컴포넌트 종류 Vertical(수직), Horizontal(수평) , Grid(그리드) Verticla, Horizontal 프로퍼티 Padding : 게임 오브젝트의 넓이나 높이가 늘어나고 자식 게임오브젝트들을 감싸는 공간이 생긴다 Spacing (간격) : 자식 게임오브젝트 사이의 간격 Child Alignment (자식정렬) : 레이아웃 그룹 컴포넌트가 부착된 게임 오브젝트 내부에서 어느 위치를 중심으로 정렬할 것인가를 의미 Control Childe Size (자식 크기 조절) : 단독으로는 큰 의미를 가지지 않지만 Child F..

1주차: 기획/SA 작성 팀 프로젝트 회의 내용 - UI 탭 기능 피드백 받기 - 주요 메카닉 정하기 & 역할분담 - 에셋 정하기 - 게임 이름 정하기 어제 TIL에도 작성했던 UI 탭 기능에 대해서 지금 생각하고 있는 방법이 좋은지 혹은 더 좋은 방법이 있는지 피드백을 받아 하나의 UI를 재사용하는 오브젝트 풀 방식의 구조를 사용하면 좀 더 효율적이게 관리를 할 수 있는 방법을 사용하기로되었다 게임에 필요한 오브젝트를 미리 생성해서 필요할 때마다 꺼내쓰고 사용이 끝나면 오브젝트 풀에 돌려주어 오브젝트가 필요할 때마다 생성하고 파괴하는 것이 아니라 필요한 만큼의 오브젝트만 생성하고 모자라면 추가로 생성하면되는 것이기 때문에 성능을 높일 수 있다 이번 프로젝트에서 중요 최적화 기법이 될 거 같다 나의 주요..

1주차: 기획/SA 작성 팀 프로젝트 회의 내용 - 데이터 설계 - 구조 설계 데이터 설계는 처음 해봤다 이전의 미니 프로젝트에서는 세부 기획과 마찬가지로 일단 각자 개발하는 사람들이 임의의 값을 넣고 게임 마무리 후 밸런스 패치를 하는 방식으로 진행했었다 물론 이번에도 밸런스 패치후에 값을 조정해야겠지만 이전과 달리 규모가 크기 때문에 (출시까지 생각하고 있기 때문에) 이것 또한 확실하게 ! 정하고 또 어떤 데이터를 가져야 하는지 까지 생각하면서 어떤 구조를 가져야하는지에 대해서도 같이 함께 생각하며 회의를 진행하였다 UI 구조설계 부분을 진행하는 중에 런타임용 탭 메뉴 생성에 대해서 어떻게 하면 드로우 콜을 줄이고 최적화를 할 수 있을까 ? 에 대해 신경을 많이 썼다 일단 드로우콜이란 ? GPU에게 ..

1주차: 기획/SA 작성 팀 프로젝트 회의 내용 - USECASE 작성 - 시니어 개발자 분과 멘토링 - 게임 세부 기획 마무리 USECASE 는 시스템을 개발하는 사람과 사용할 사람이 함께 시스템의 사용 방법을 결정하는데 도움을 주는 문서 작업으로 사용자의 입장에서 이해하기 쉽고 간단하게 작성되어야 한다 사전 및 사후조건을 작성하고 작업 흐름을 정상적으로 수행되는 정상 흐름, 작업 흐름이 수행되는 중에 특정 시점에서 여러가지 선택적인 흐름으로 나뉘어질 경우 발생하는 대안 흐름, 작업 흐름이 수행되는 중에 발생할 수 있는 예외 상황이나 오류를 표현하는 예외 흐름으로 구분하여 더 직관적으로 보일 수 있게 작성하였다 시니어 개발자 분과 멘토링 에서는 팀프로젝트 관련, 현업 관련, 취업관련해서 질문을 했다 특..