내일배움캠프Unity

오늘의 키워드 사전캠프에 늦게 참여하게 돼서 본캠프 시작 전까지 알고리즘 공부를 하기로 했다. 오늘 문제를 풀면서 알게된 사실 2가지를 정리해 보려고 한다. bit 연산 사실 bit 연산은 c언어 초창기에나 몇 번 해보고 말았다. 오늘 푼 문제 중에 bit 연산을

오늘은 프로그래머스 문제를 푸는 도중에 처음 써본 라이브러리 함수를 정리해보려고 한다.c++의 string 클래스의 멤버함수 find()이다.string 내에서 매개변수로 넘어온 문자열을 포함하는지 검사하고, 포함한다면 찾는 문자열의 첫 인덱스를 반환한다. 그렇지 않다

오늘의 키워드 오늘은 게임개발종합반 1, 2주차 강의를 들었다. 1, 2주차 강의는 유니티에 대한 아주 기초적인 내용들로 이루어져있었는데, 그 중에서 앞으로 가장 많이 사용하고 중요한 개념인 GameManager와 Singleton에 대해서 정리해보려한다.

오늘의 키워드 4주차 강의 중에 배열의 원소를 무작위 순서로 정렬하는 구현 과정이 있었는데, 내가 생각했던 것과 다르게 간단하게 코드 한 줄로 구현할 수 있었다. 내가 생각한 방법 정렬할 배열을 arr라 치자. 길이가 같은 arr2 배열과 visited 배열을 선언해

오늘 푼 알고리즘 문제 중에 최대공약수를 이용하는 문제가 있었다. 그냥 막연하게 최대공약수는 유클리드 호제법으로 구한다. 정도만 알고 있었는데, 이번 기회에 정리해봐야겠다.철수와 영희는 선생님으로부터 숫자가 하나씩 적힌 카드들을 절반씩 나눠서 가진 후, 다음 두 조건

오늘까지 제출해야하는 내일배움캠프 Chapter 1의 미니프로젝트가 있었다.게임개발종합반 4주차 강의에서 진행한 카드게임을 따라서 만들면 되는 프로젝트다.추가기능을 구현해도 된다고 해서 여태까지의 클리어타임 중에 가장 빠른 1~5위를 저장해두고, 게임오버 창에 띄워주는

어제 오늘 프로그래머스에서 코테 문제를 10개 풀었는데, 그 중에 절반이 BFS 문제였던 것 같다.원래 BFS/DFS 둘 다 사용해도 되는 문제가 나오면 DFS를 사용하는걸 더 선호했는데, 어제 오늘 BFS만 계속 해서 그런지 이제 BFS가 더 쉬운것 같다.BFS는 D

C각 주차마다 Console에서 실행되는 게임을 만드는 과제가 있는데, 2주차 과제까진 할만 했는데 3주차 과제부터는 조금 어려웠다.3주차 과제는 지렁이 게임과 블랙잭을 구현해야했는데, 구현 과정에서 어려웠던 점과 어떻게 해결했는지를 정리해보려한다.키보드로 지렁이가 진

오늘은 스파르타 내일배움캠프 Chapter 2의 개인 과제인 <스파르타 던전> 개발에 집중했다.본격적으로 클래스를 다루고 추상 클래스와 추상 클래스의 상속, reference type, 클래스 설계, 화면 설계 등등.. 생각할게 많았다.구현해야하는 주요 클래스를

오늘도 개인과제를 진행했다. 과제에 추가적으로 기능을 구현하고 싶으면 해도된다고 목록을 줬는데, 다른 기능들을 다 추가하고 나니까 난이도 별 6개짜리인 게임 저장하기도 해보고 싶은 욕심이 났다.따라서 오늘 구현한 던전입장, 간단한 텍스트 전투 시스템을 정리해보고, 게임

오늘의 키워드 오늘은 개인 과제의 마지막 별 6개짜리 챌린지인 게임 저장/불러오기 기능을 추가하는데 성공했다. 개발 과정에서 겪였던 에러, 고민, 해결한 방법 등등을 써보려고 한다.

오늘은 강의에서 Interface와 delegate, lambda 등의 개념이 나왔다.중요한 개념인데 나는 많이 써보질 않아서 아직 헷갈리기도 하고 손에 안익는다...그래서, 저 3개의 키워드를 다 같이 사용해보기 좋은 Observer Pattern을 Unity로 구현

어제 하던 옵저버 패턴 실습 중에, System.Action 말고도 Unity에서 지원해주는 UnityEngine.Events.UnityAction도 있다는 걸 알았다.실습 진행상황과 함께 저 둘의 차이점도 한 번 정리해보려 한다.OnLevelChanged, OnDea

오늘은 내일배움캠프 프로그래밍 기본주차의 개인 과제인 Sparta Dungeon의 튜터님들의 코드 리뷰가 있었다. 내가 받은 피드백을 갈무리하고, 어떤 점을 보완해하면 좋을지 정리해보기로 했다.git repository : https://github.com/j

오늘 팀 프로젝트 시작과 관련한 발제가 있었다.여태까지의 프로젝트는 프로그래머가 나 한명이어서 괜찮았지만, 이제는 같은 팀이 모두 프로그래머다.따라서, git을 이용한 협업을 진행해야하는데, 그 전에 알아두면 좋은 것들을 정리해볼까한다.commit 메시지도 컨벤션이 있

오늘부터 내일배움캠프 Chapter2의 팀 프로젝트 작업을 시작했다.이전의 개인과제와 아주 유사한 구조의 Text Dungeon RPG 게임을 만든다.나는 인벤토리 작업을 맡았다.개인 과제 때 썼던 인벤토리의 기능을 보강해서 가져와봤다.개인과제 때 썼던 인벤토리의 기능

오늘은 팀 과제에 상점 기능과 상점 씬을 추가하는 역할을 맡았다.Inevntory 작업을 내가 했었어서, 뭔가 내가 상점까지 해야할 것 같아서 회의 때 내가 상점을 맡겠다고 했다.상점 씬 구현은 다른 분들이 작업하신 코드를 이용해서 작업해야했기에, 내가 짠 코드가 아니

어제 상점 씬의 구매 기능만 구현 했으니, 오늘은 판매 기능을 포함하여 상점 씬의 기능 구현을 끝냈다.구현 중에 고민했던 것들, 고쳐본 것들, 앞으로 추가하면 좋은 것들을 정리해보려한다.판매 기능을 추가하기 앞서, 어제 내가 구현한 상점 씬은 상점의 구매 화면이다.씬에

오늘은 상점 작업을 마무리하고 힐링포션을 구현했다.힐링포션을 구현했던 과정을 정리하고, 힐링포션을 Json 데이터로 직렬화, 역직렬화 하는 과정에서 새롭게 알게 된 JsonSerializerSettings에 대해서도 정리해본다.이미 프로젝트엔 Item 클래스를 상속받는

오늘은 던전 클리어 이후 보상을 보여줄 보상 씬을 만들고, 제출 준비 전 버그를 대거 찾아서 고치는 작업을 했다. 팀원들끼리 서로 어느 부분에 버그가 있다 알려주고, 해당 파트를 담당해주신 분은 순식간에 원인을 찾아서 고쳐주시기도 하고, 서로 해결방법을 찾기도 했다.

오늘 대망의 발표가 있었다. 다들 좋게 봐주신 거 같아서 다행이다.튜터님의 자세한 서면 피드백은 내일 받을 수 있다고 하고, 오늘은 발표 직후에 튜터님들이 간단하게 대면으로 피드백 해주셨다.우리 팀에 대한 피드백 뿐만 아니라 다른 팀의 피드백도 나한테 많은 도움이 됐다

오늘의 키워드 오늘은 Unity 게임 개발 입문 1주차 강의를 들었다. 강의에 나온 Unity pakage인 Input System에 대해 정리해보려한다. Input System pakage 소개 공식 docs에서 말하길, 모든 입력기기를 이용하여 유니티의 컨텐츠

오늘은 개인과제에 어제 강의에 나온 new InputSystem을 적용해서 플레이어 캐릭터의 이동을 구현하는데, 강의에 나온 방법은 SendMessage로 호출을 하는데, 나는 SendMessage 방식은 조금 느릴 것 같아서 다른 방법으로 구현해봤다.PlayerInp

오늘도 개인 과제를 진행했다. 필수 요구 사항은 모두 구현했고, 선택 요구 사항도 거의 다 구현했다. 오늘은 NPC 대화를 구현하는 데 많은 시간을 쓴 것 같다. 인터페이스와 이벤트를 둘 다 사용해보려고 노력했다.인터페이스로 NPC들의 기능을 세세하게 분리하고 보니까,

개인 과제를 마무리하고 제출했다.마무리를 하면서 때리면 말하는 NPC를 만들었다.때려야하니까 때릴 수 있도록 마우스 좌클릭을 하면 화살이 나가도록 해봤다.어제 만든 Lizard NPC 코드를 보니까, 사용하지 않는 이벤트가 있는게 거슬려서, 불필요한 이벤트는 Inter

오늘 두 번째 팀 프로젝트가 시작됐다. 유니티를 이용해서 협업이다.구현할 게임의 장르를 정하고, 대략적인 스토리 컨셉과 와이어 프레임을 구상했다.나는 게임 매니저를 구현하기로 했다.그런데 아직 게임을 굴리기에는 프로젝트에 아무것도 없기 때문에 대략적인 틀만 잡아줬다.싱

오늘의 키워드 아침에 코드카타를 하는데, 최대 k명의 랭커만 유지를 시켜야하는 문제가 있었다. > 프로그래머스 - 명예의 전당 (1) 보자마자 우선순위큐를 이용해서 풀어보고 싶었다. 물론 이 문제가 일정 수치 이내의 시간복잡도를 요구하진 않겠지만, 그냥 그러고 싶었다

몬스터가 죽으면 경험치와 재화를 드랍해야한다.드랍할 때 몬스터가 죽은 자리에 뿅 하고 생기는 것 보다는 아이템이 쏟아져 나오는 것 처럼 보여지게 하고 싶었다.베지에 곡선이라는 것을 사용해서 구현해봤다.먼저, 드랍 되는 아이템들의 최상위 클래스인 DroppableItem

어제 경험치 드랍을 만들고 나서 오늘은 플레이어가 먹으면 경험치가 오르게 했다.뱀서에서는 레벨업을 하면 위의 아이템 선택 창이 뜨는데, 우리 게임도 마찬가지다.이미 캐릭터가 레벨업을 하는 기능과 아이템 선택 창은 다른 분들이 구현해주셨기 때문에 나는 레벨업을 했을 때,

오늘은 프로젝트 제출 전날이다. 오늘 있었던 일들을 갈무리 해보려한다.오늘은 플레이어가 아이템을 관리하는 Dictionary를 다음 스테이지 씬으로 정보를 유지하고 넘겨주기 위해서 DataManager에서 참조할 수 있게 하려했는데, Dictionary<strin

오늘 두 번째 팀 프로젝트 발표가 있었다.다른 팀 작업물에서 배울 점과 내가 부족하다고 느꼈던 점들을 정리해보려한다.우리 팀은 발표에서 게임의 기획쪽이나 시연 쪽에 많은 비중을 뒀던 것 같다.때문에 발표에서 프로젝트의 아키텍처나 설계쪽의 내용 설명이 부족했던 것 같다는

오늘부터 Unity 숙련 주차가 시작됐다. 새로운 강의와 함께 개인과제도 나왔다.이번 개인 과제의 목표는 평소와 좀 다르게 설정했다.이번 개인 과제의 목표와 그렇게 설정한 이유를 적어보려한다. (나중에 나약해지면 다시 보자)여태까지는 개인과제가 나오면, 필수 구현 사항

UI 작업 시, 인스펙터 창에서의 작업을 최소로 줄이고 C코드와 함께 친절한 설명을 해준 팀원분께 감사하다고 전하고 싶다.최근 포스트에서 계속 언급했지만, 기존에 대다수가 UI를 작업할 때, 새로운 UI를 만들면 그 UI를 관리하는 스크립트의 인스펙터 창에 Prefab

개인 과제에 간단한 Addressable을 적용했다.Addressable로 로드한 리소스를 Dictionary로 관리하는 ResourceManager도 작성해봤다.Resources의 편리함과 AssetBundle의 버전관리, 원격로드 와 같은 장점들을 합친 에셋 관리

개인과제를 하다가 12시 넘어서 TIL를 쓰게 됐다..오늘 겪은 트러블 슈팅을 간단하게 작성해보려한다..어드레서블로 비동기 로딩을 하는데, Awake나 OnEnable에서 아직 로딩되지 않은 객체에 참조 접근을 해서 NullException Error가 자꾸 발생했다.

오늘은 어제 제출한 개인과제의 UI_Base와 UIEventHandler 클래스를 리팩토링하기로 했다.이번 주에 있었던 클린코드 특강에서 switch문의 사용도 자제하는게 좋다고 하셨는데, 마침 UI_Base에서 switch문으로 40줄이나 써먹고 있었기 때문에 조금

숙련 주차 팀 프로젝트가 시작됐다.Monster 클래스에 FSM을 적용하기로 했는데, FSM을 자동화 하기 위해서 Generic으로 State 열거형을 받아와서 event Dictionary에 key로 등록해보려했다.where T : Enum으로 제네릭에 조건을 걸었는

저번 주 금요일에 작업한 FSM이 상속 구조에서 사용하기에 문제가 있어서 어떻게 사용해야할 지 고민해봤다.Navmesh plus를 이용하여 2D Pathfinding을 구현하였다.내가 만들어둔 FSM은 제네릭을 이용하여 상태를 정의한 enum을 넘겨받아 선언하는 구조로

어제 작성한 TestMonster를 기반으로 근접 몬스터인 MeleeMonster 클래스와 원거리 몬스터인 RangedMonster 클래스를 작성했다.클래스와 프리팹은 만들었는데, 작업물을 팀원분이 만들어두신 ResourceManager를 이용해서 Spawn하게 하기

몬스터를 Spawn할 때 제네릭으로 컴포넌트 추가 중. DeSpawn 이후 다른 몬스터 타입으로 다시 Spawn할 때, 다른 컴포넌트가 추가되는 상황 (ex. 근접몬스터 디스폰 후 원거리몬스터 스폰 시 2개의 컴포넌트를 가지게 됨)Monster.OnDisable에서 D

Navmesh의 생성은 던전의 생성이 끝난 후 이루어져야함.DungeonManager에서 DungeonGenerate(), NavmeshGenerate()를 순차적으로 실행\-> 비정상적인 Navmesh 생성 (맵 전체가 Walkable) 아마도 타일맵이 모두 생성되기

폭풍같았던 한 주가 지나갔다. 배운 것도 정말 많았지만 내 생각보다 시간이 더 부족했었다.결국 미완성인 체로 제출을 하게 됐는데, 나중에 짬 날때 완성을 해야봐야겠다.GameOver : 플레이어가 죽으면 게임이 끝나야합니다패시브 아이템몬스터 사망 시 아이템 드랍보스몬스

[오늘의 키워드] 심화주차 개인과제에 Photon을 이용해 멀티플레이 게임을 구현해보기로 했다. 1개의 Room만 이용하고, 방에 들어오는 유저에게 캐릭터를 1개씩 할당시켜 줄 생각이다. 호스트와 상호작용이 제대로 동기화되는지 테스트하기 위해 건들면 움직이는 공도 하나

어제 포톤 서버 연결, 리소스 로드, 게임 객체 생성을 순서대로 하기 위한 GameManager를 작성했었다.오늘은 게임이 시작되면 1개의 공을 생성하고, 플레이어가 입장할 때마다 해당 플레이어의 캐릭터를 생성하도록 해봤다.멀티플레이 환경에서 유저끼리의 객체 데이터 동

오늘은 개인과제에 타이틀씬을 추가하고 플레이어 캐릭터가 공을 발로 찰 수 있게 했다.공을 차려면 필요한 것들을 추려봤다.근처의 공을 탐색발밑으로 공을 가져옴 (Catch)공 차기 쿨타임공 차기 세기 조절공 차기 방향 조절공에게 Velocity 적용 (Shoot)위 목록

오늘은 개인과제에 필요한 기능은 거의 다 구현하고, 제출 전 마지막으로 Master Client (Host)가 아닌 일반 클라이언트에서 공의 속도가 너무 빠를 때 발생하는 지터링을 해결해보려했다.결론만 말하면, 아직 해결하진 못 했다...공이 벽에 닿을 때마다 울렁거린

심화주차 팀 과제 장르가 정해졌다.FPS게임의 사격훈련장을 만들기로 했다.팀 과제 시작 전 고민해봐야할 것들, 생각해보면 좋을 것들을 정리해보려한다.캐릭터 이동, 카메라 에임, 서서 쏴 앉아 쏴좌클릭 발사, 우클릭 스코프모드, R키 재장전돌격소총, 산탄총, 저격소총총기

기존에 내가 사용하던 ResourceManager는 Addressable을 이용했지만, 이번 팀 과제에는 Resources 폴더를 이용해 리소스 로드를 하기로 해서, ResourceManager의 구조를 Resources 폴더에 맞게 구조를 변경했다.FPS 시점 구현을

플레이어 캐릭터에게 FSM을 적용했다.이제 앉기, 서기가 가능하다.카메라를 빠르게 흔들면 총기의 transform이 카메라의 transform과 동기화 되지 못하고 지터링이 발생하던 버그를 고쳤다.Weapon 객체에 애니메이터를 적용해서 ADS 시점 변환 연출을 구현했

플레이어 캐릭터에 천천히 걷기와 전력 질주를 추가했다.위 두 기능을 추가 하면서 InputManager에 조작키 끼리 상호작용을 추가하고 상태에 따른 플레이어 이동속도 계산로직을 추가했다.별건 아니고, 전력 질주를 하는 도중에 정조준 키를 누르면 전력 질주 키 입력을

카메라에 총기 반동을 적용해야하는데,, 어떻게 적용해야할 지 많이 고민했다.총기 데이터에서 수평, 수직 반동 수치를 받아온다.반동 수치를 RigidBody.velocity에 set 했을 때 처럼 작동하게 해보려고 한다.reference: 최대한 배틀그라운드처럼 보이게.

발표 때 사용할 개발 과정에서의 트러블 슈팅들을 정리해보려한다.빌드 후에는 발생하지 않지만 Unity Editor에서는 발생하는 문제들로 괜히 밑바진 독에 물을 붓는 일이 없도록 정리해보려한다.여러가지 에셋을 추가하는 과정에서 머티리얼과 셰이더가 추가됐는데, 테스트 중

프로젝트에 이런 연출이 들어가면 어떨까~ 싶어서 심심풀이로 만들어봤다.간단한 Voxel Cube를 만들어봤다.OnPlayerSteps() 메서드가 호출되면 큐브가 살짝 내려앉고, ExitPlayerSteps()가 호출되면 원상태로 복구된다.플레이어는 발밑으로 레이를 쏴

오늘은 Voxel 맵 최적화를 어떻게 해야할지 고민해봤다.모바일 게임을 만들 거라서, 최적화에 정말 많은 노력을 해야겠다고 생각했다.테스트 용으로 Voxel 큐브를 10000개 생성하여 테스트해봤다.말이 10000개지, 100x100밖에 안된다. 실제 게임엔 훨씬 많은

Unity Editor에서 Test Play를 빠르게 할 수 있는 Enter Play Mode 설정과 설정 하기 전 주의해야할 점 등을 정리해보려한다.유니티 에디터에서는 실행 버튼을 눌렀을 때 대략 다음의 프로세스를 진행한 후 게임이 실행된다.Edit Mode Exit

오늘은 이전처럼 큐브를 n개 그려내는 방법 대신 메쉬를 통째로 합치는 방법으로 최적화를 해봤다.Chunk는 사전적인 의미로 큰 덩어리이다.Voxel 큐브들의 정점 좌표들을 이용해 하나의 거대한 메시(Chunk)를 생성한다.Voxel 큐브들은 정점 데이터만 존재하고 인스

Voxel 타일에 텍스처링 기능을 추가했다.Chunk를 World 클래스에서 관리하도록 하고, 여러 개의 청크 생성 시에도 맞닿은 면을 그려내지 않도록 했다.블럭의 각 면마다 텍스처를 지정할 수 있게 해줬다.텍스처 아틀라스를 사용할 예정이기 때문에, 아틀라스의 n번째

ValueTuple이라는 자료형 정리Dictionary의 key와 GetHashCode() 메서드 트러블슈팅오늘 푼 알고리즘 문제에서 Queue에 (int idx, int priority)라는 자료형을 넣어봤는데, 잘 실행됐다.나는 이게 익명 형식 (anonymous

런타임에서 비동기로 NavMesh 생성/업데이트하기활성화된 Chunk만큼만 NavMesh 업데이트하기NavMeshBuilder라는 정적 클래스를 이용해서 런타임 중에 NavMesh를 생성/업데이트할 수 있다. 비동기 방식도 지원한다.UnityEngine.AI, Unit

NavMeshBuildSource 리스트 갱신 로직 최적화Slide Block 추가해야할 것 정리기존에는 청크가 활성화 될 때마다 WorldNavMeshBuilder 클래스에게 source를 갱신하도록 요청하고 있었는데, 이 로직의 문제가 있었다.활성화되는 청크가 여러

Chunk.cs 리팩토링초간단 맵 에디터 설계미끄럼틀처럼 생긴 Slide 블럭을 추가하면서 BlockType을 NormalBlock과 SlideBlock 두 가지로 파생시키게 됐다.때문에 블럭 데이터를 Chunk에 추가할 때, Map에서 불러온 BlockType이 어떤

딕셔너리 직렬화맵 디자인을 할 수 있는 씬 제작3Map Edit 씬에서 생성한 딕셔너리 정보를 JSON으로 저장해야했는데, 딕셔너리는 바로 직렬화가 안되서 직렬화가 가능한 다른 객체를 거쳐서 저장할 수 있게 했다.간단하게 keys, values 리스트를 갖는 직렬화 가

로딩 씬 UI 만들기메인 씬 진입 시, 게임의 준비 과정동안 보여질 로딩 UI를 작업했다.따로 로딩 씬을 만들지는 않고, 한 씬에서 로딩 중에는 로딩 UI가 보여지게 할 생각이다.이유는, 현재 로딩의 대부분은 Chunk의 생성 부분인데, 이 작업은 MainScene에서

월드 생성 로직에 불필요한 연산이 많아서, 불필요한 연산을 줄였다.월드를 생성하면, 월드는 청크들을 미리 생성한 후 비활성화 해둔다.기존 청크의 생성 로직에는 큰 문제점이 있었다.현재 청크의 범위 내에 들어오는 모든 좌표에 블럭이 있는지 검사한다.청크의 범위 안에는 대

Resource Object SpawnerResource Object신규 자원 오브젝트 - 밭SpawnData 스크립터블 오브젝트를 이용해서 데이터의 SpawnList에 있는 오브젝트들을 생성하게 해줬다.생성 시, World가 있는 MainScene에서는 각 위치에 맞

원하는 위치에 오브젝트들을 배치하고 싶다.하지만 씬은 비워놓아야하고, 로딩이 끝난 다음 객체를 생성해야한다.그래서, 에디터에서 씬에 배치해둔 오브젝트들의 위치를 싹 다 받아와서 Scriptable Object로 받아와서 저장하게 만들었다.세이브 버튼을 누르면 현재 씬에

프로그래머스 - 다리를 지나는 트럭 (Lv.2)자원 오브젝트 리팩토링아이템 드랍 테이블 클래스옛날에 한 번 C++로 풀어봤던 문제다.근데 다시 보니까, 큐를 써놓고 다 꺼냈다가 다시 집어넣고,, O(n^2)로 풀어놨다.푸는 방법이야 여러 방법이 있겠지만, 내가 생각한

현재 플레이어의 일정 거리 밖의 청크들은 비활성화되도록 해놓은 상태다.청크만 비활성화 되는게 아니라, 몬스터, 상호작용 오브젝트 등등 다른 객체들도 비활성화 돼야한다.비활성화된 청크 내부에 있는 오브젝트를 비활성화해야한다.현재 객체의 위치값을 이용해서 간단하게 현재 어

[오늘의 키워드] 프로그래머스 - 쿼드압축 후 개수 세기 (Lv.2) [프로그래머스 - 쿼드압축 후 개수 세기 (Lv.2)]

알고리즘 - 정렬 알고리즘 정리해보기개발일지 - 절차적 맵 생성 알고리즘의 필요성 고민매 회전마다 정렬되지 않은 부분의 최소값을 선택한 다음, 가장 앞쪽에 배치해나가며 정렬하는 알고리즘시간복잡도 O(n^2)현재 인덱스와 다음 인덱스를 비교하여, 다음 인덱스가 더 크다면

절차적 맵 생성 방식을 도입했다.새 게임을 시작할 때마다 새로운 맵을 랜덤으로 생성하진 않을 거지만, 자연스러운 지형 생성을 위해 도입했다.펄린 노이즈는 난수를 생성할 때, 인접한 부분끼리는 연속된 값으로 난수를 생성한다.연속적인 난수 값을 생성하기 때문에 랜덤한 커브

오늘은 섬의 절차적 생성 방식에 슬라이드 블럭을 추가하는 로직을 추가했다.원래는 브러시 같은 툴을 만들어서 직접 하나하나 배치하려고 했지만, 코드로 자동으로 생성되게 하는게 더 편하고 빠를 것 같았다.섬마다 슬라이드 블럭의 머티리얼이 다르다.분명 섬마다 다른 머티리얼이

버섯은 죽은 나무 옆에서 생성될 수 있고 바위 근처엔 돌멩이가 생성될 수 있다.이러한 부산물?을 생성하는 객체를 만들었다.이외에도 바위, 나무와 같은 큰 자원 오브젝트들도 절차적으로 생성할 수 있는 알고리즘을 구상중이다.부산물을 생성하기위한 ByproductCreato

Update 호출 줄이기자원 오브젝트 절차적 생성현재 씬에 오브젝트가 엄청 많다. 얼마나 많냐면 몬스터는 대략 150마리, 자원 오브젝트는 아직 중앙 섬만 배치했는데 800개다.얘네들이 매 프레임 Update를 호출하면 그것만큼 낭비가 또 없을거라고 생각했다.어제 부산

자원 오브젝트 배치용 씬 추가NavMeshSourceObject 클래스 작성기존의 자원 오브젝트 배치 작업은 되게 험난했다...이미 생성된 맵 위에 ray를 쏴서 ground 레이어에 닿아야 생성되므로, 메인씬을 실행해서 world를 생성하고, 몬스터들을 지우고, 비활

다른 팀과 서로 테스트를 해주기로 했다.테스트 파일을 뽑기 전에 미뤄뒀던 버그 수정들을 조금 했다.검은 3연타까지 있는데, 1타는 나가지만 몬스터가 맞질 않았다.평소엔 데미지를 주는 콜라이더가 꺼져있다가 ComboAttackState에서 일정 시간 이후 켜지는 구조인데

ByproductCreator 최적화TemperatureManager 작성현재 바위 오브젝트는 돌멩이 부산물을 100퍼센트 확률로 생성하도록 되어있다.그리고 맵에는 대략 500개 정도의 바위 오브젝트가 있다.부산물의 생성 시도는 DayCycle 클래스가 관리하는 1시간

계절 클래스 작성아티팩트 생성기 클래스 작성아티팩트 컴포넌트아티팩트 저장/불러오기온도 시스템을 만들었으니 섬들의 온도를 바꾸기 위한 계절 클래스를 만들기로했다.계절 클래스에 필요한 기능을 정리해봤다.DayCycle 클래스와 통신하여 특정 날짜마다 계절이 바뀐다.Game

아티팩트 구현게임매니저 버그 수정어제 임시로 만들어둔 아티팩트 클래스를 기획에 맞게 구현했다.먼저, 프리팹과 데이터를 만들었다.프리팹은 하나만 쓰고, 생성할 때마다 모델을 바꾸는 구조로 하기 위해 Mesh 데이터는 배열로 선언해줬다.마찬가지로 드랍될 아이템도 다르게 적

몬스터 웨이브 클래스 구조 변경아티팩트가 몬스터 웨이브 요청트러블 슈팅기존에는 매일 밤이되면 GameManager가 몬스터웨이브를 시작하는 구조로 작성돼있었다.이제는 Artifact 클래스가 몬스터 웨이브와 통신할 것이기 때문에 MosnterWave 클래스의 구조를 살

청크의 생성을 병렬로 처리해보기 위해 Job System 관련 자료를 찾아봤다.Job System이란 유니티에서 멀티 스레드를 안전하게 사용할 수 있도록 제공해주는 기법이다.유니티에서 메인 스레드를 제외한 다른 스레드는 메인 로직의 객체에는 접근할 수 없도록 막혀있다.

World 클래스와 Chunk 클래스의 맵 데이터 딕셔너리 구조 변경Chunk 생성에 Job System 적용World 클래스에서 모든 블럭의 데이터를 딕셔너리로 관리하나의 딕셔너리에 대략 70만개의 블럭 데이터가 있게 됨\-> 아무리 딕셔너리라도 검색 시 약간의 병목

Player State 리팩토링 방향 결정Player Interact 개선 방향 결정PlayerIdleState, PlayerRunStatePlayerTwoHandIdleState, PlayerTwoHandRunStatePlayerTwinToolIdleState, Pl

Player State 리팩토링 진행 상황Player Interact 개선 진행 상황들고 있는 도구마다 상태 클래스가 있었는데, 하나로 합친 뒤 현재 들고 있는 도구에 따라 다른 애니메이션을 재생하도록 했다.이제 다른 상태에서는 if-else문으로 걸러줄 필요가 없어졌

InteractSystem 클래스 구현현재 PlayerBaseState에서는 플레이어의 각 상호작용을 순서대로 진행하는 코드가 모두 몰려있다.이 기능이 워낙 크고, 중요한 작업이고, 코드도 긴데, 나중에 이 기능을 수정할 일이 생기면 어디에 구현되있는지도 찾아야하고,

애니메이터 트러블슈팅Cycle OffsetTransition OffsetBlend Tree플레이어 캐릭터가 이동 중에 무기를 스왑하면, 해당 무기에 따라 다른 달리기 애니메이션이 재생된다.ex) 기본 달리기, 두손으로 대검을 들고 달리기, 양손에 쌍검을 들고 달리기스왑

InsteractSystem 플레이어와 타게팅 오브젝트의 거리 계산 로직 개선PlayerStateMachine 캐릭터가 공격 상태일 때 판단플레이어와 타겟 오브젝트의 단순 Position 거리 비교를 진행하고 있었다.이렇게 계산하니 문제가 발생했다. OverlapSph

트러블 슈팅 - 아웃라인 셰이더메시를 통째로 키우기정점을 법선 방향으로 늘리기스무스 노말자료조사를 해보니, 아웃라인 셰이더를 구현하는 방법은 크게 3가지 정도가 있었다.2Pass메시를 통째로 키운 다음, 앞면 대신 뒷면을 그리기각 정점을 법선 방향으로 잡아 당긴 다음,

InteractSystem 클래스 구조 변경InteractSystem의 추가로 캐릭터가 상호작용 시 주변 오브젝트들 중 우선순위에 따라 상호작용이 진행되는 기능이 생겼다.유저가 현 시점에서 상호작용 할 오브젝트가 뭔지 알 수 있도록 상호작용할 오브젝트에 아웃라인으로 하

최종 발표 준비 - 브로셔 제작카테고리 별 작성 양식프로젝트 결과 및 성과기능에 대한 간단한 설명이 있으면 좋을 것 같다.이 기능을 사용하게 된 이유, 왜 그렇게 생각했는지 등의 고민 등이 있으면 좋을 것 같다.브로셔를 보는 사람을 설득할 수 있어야한다.프로젝트에 이

프로젝트를 진행해오면서, 딕셔너리와 관련해 겪어오던 문제가 하나 있었다.\[\[\[세 TIL의 트러블 슈팅의 공통점은, 딕셔너리 검색 시 병목이 발생한다는 것이다. 왜 병목이 발생했고, 어떻게 해결됐는지 정리해보기로 했다.이 TIL 작성 당시 문제는, ChunkCoor

[오늘의 키워드] Mesh.vertices 프로퍼티 접근 시 GC 생성 [Mesh.vertices 프로퍼티 접근 시 GC 생성] Code Profiler 정점이 4400개 정도 되는 나무 오브젝트에 코드를 적용해보니 1초 정도 병목이 발생하길래 원인을 찾아보니

WebGL 빌드 후 Itch.io 업로드GetComponent 사용하지 않고 Component 검색하기

최종발표 후기2달이라는 시간이 정말 빠르게 지나간 것 같다.내배캠을 시작하면서 배우기도 많이 배웠지만, 얼마나 모자란지도 알게 된 것 같다.학생 시절에 진행한 프로젝트에는 SOLID원칙도 지켜지지 않고 지금 보면 많이 부끄럽다.내배캠을 진행하면서 SOILD원칙, 디자인