불면증 도사 님의 블로그

유니티를 본격적으로 다루면 피할 수 없는 것이 바로 '외부 데이터 연동'이다.세이브 파일 부터 시작해서 데이터 파일 작성 까지, 이런 저런 요소들이 외부 데이터 연동을 활용하면 훨씬 할 수 있는 폭도 넓어지고, 수정 편의성도 높이지기 때문이다. 자, 그렇다면 이 '데이터 연동'을 위해서 사용할 수 있는 경로는 어떻게 정하면 될까.사실 의외로 매우 간단하다. 유니티 상에서 미리 정해진 경로들을 제공하기 때문이다.이에 대해서 간략하게 알아보자.[참고 URL: https://3dmpengines.tistory.com/1745, https://sam0308.tistory.com/83] Application.dataPath읽기 전용. 프로젝트 폴더 내부의 Assets 폴더를 지정한다.이를 통해서 Resources..

※ 금일 정리할 내용은 다소 간단한 내용이 될 예정이다. 캐릭터의 행동 패턴을 제작할 때에는 자연스럽게 활용하게 되는 것이 유한 스테이트 머신이다.다만, 만약에 NPC가 행할 수 있는 행동의 종류가 어마어마하게 방대하고 복잡하다면 어떨까.상황에 따라서 다른 작동을 해야한다거나, 장비에 따라서 사용하는 상태가 달라진다던지 하는 식으로 말이다.이걸 전부 하나의 스테이스 머신에서 관리한다고 한다면 헷깔리기도 할 것이고, 무엇보다 '사용하는 측'에서는 이 정도로 많은 상태에 접근할 필요가 없다. 이럴 때 유용한 것이 다단계 유한 스테이트 머신이다.계층적 유한 스테이트 머신?문자 그대로, '여러 단계로 구성된 FSM'이다.행동을 큰 단위로 묶어서 1차적인 FSM을 만들고, 그 FSM 안에서 또 다시 FSM을 구성..

자, 오늘은 지형의 절차적 생성 방법에 대해서 조금 더 자세하게 정리 해 보자.지형의 절차적 생성 알고리즘을 분류하면 대략 5가지 조합으로 구성이 가능하다.격자형특정한 간격으로 임의의 블럭을 배열하는 형태.가장 간단하고 부하가 적다.대신 정해진 형태로만 구성이 가능하다는 난점이 있다.구조 선택형특정한 알고리즘을 통해서 배치 구역을 형성, 그 구역에 맞는 지형을 배치하는 구조불규칙적인 지형을 형성하는 알고리즘 중에서는 가장 간단하면서 부하가 적은 방식.다만, 형성된 구역을 어떻게 이을 것인지에 대한 알고리즘이 필요하다. 배치 확장형정점이나 도형 등을 배치한 다음, 그 위치관계를 이용해서 선택, 확장하는 방식.2D 필드 제작에 유용하게 쓰인다. 특히 로그라이크 게임에서 매우 유용하게 쓰이는 알고리즘.다만, ..

유니티 상에서는 AI 길찾기 로직을 기본적으로 제공한다.이에 대해서는 다소 순서가 어긋나긴 했지만, 응용 버전인 2D 환경에서의 활용을 먼저 다뤘었다.[참고 URL: https://lsu0503.tistory.com/114] [이걸 안다뤘을 줄은 몰랐지...] AI 네비게이션 자체는 성능이 이래저래 많은 편인데, 본문에서는 간단하게 사용법 만 글로 설명하고, 본론으로 넘어갈까 한다.[아무래도, 지금 다루기에는 다소 늦은 감이 있어서...;;] AI Navigation?AI Navigation은 유니티 상에서 기본으로 지원되는 자동 경로 탐색 패키지다.[사용법은 간단한데, 지원되는 기능이 많아서 사실 좀 더 알아봐야 할 거 같은 기능이긴 하지만...;;]알고리즘으로는 A*알고리즘을 사용한다. 사용법은 간단..

이제 최종 프로젝트에서 절차적 생성을 이용한 필드 확장 기능을 작업하기 시작했다.그러니, 오늘은 절차적 생성에 대해서 정리 해 보자.절차적 생성이란?'절차적 생성', 최근 들어 게임계에서 매우 자주 듣게 되는 단어다.이 절차적 생성 자체를 주요 포인트로 삼은 게임도 있고, 반대로 '손으로 그린' 것을 특징으로 삼은 게임도 있다.그렇다면 절차적 생성이 무엇이길래 이렇게 최근 들어 키워드로서 자주 활용되는 것일까. 일반적으로 '절차적 생성'이라고 말하면 레벨의 절차적 생성을 이야기 하는 경우가 많다.그도 그럴게, 가장 눈에 띄로 체감도 잘 되는 영역이 레벨의 적차적 생성이라서...그렇다 보니, 절차적 생성이 '필드 구성을 자동으로 생성하는 기능'으로 오해하는 경우도 있다고 알고 있다. 결론 부터 말하자면, ..

유니티를 다루다 보면 자연스럽게 다루게 되는 것이 바로 씬이다.Scene이라는 그 명칭마냥, 하나의 '장면'을 담당하는 요소.이래저래 활용법은 간단하긴 하지만, 플레이 경험에 비교하면, 로딩 최적화를 고려하면 이것도 좀 복잡하게 구성해야 한다. 그렇다면, 어떻게 하면 될 것인가.사실, 여기에는 꼼수가 좀 많이 쓰인다.사실 최적화 요소들도 대부분 '보이지 않는 영역'을 이용한 꼼수이지만 말이다.실내와 실외는 알고보면 같은 공간가장 기초적인 사항. '실내'를 구현한다고 해서 씬을 새로 작성하면 안된다는 내용이다.이유는 간단하다. 그 만큼 씬 로딩이 자주 일어나니까.씬 로딩 자체가 Don't Destroy On Load로 지정된 오브젝트들 이외에는 전부 날려버리고 새로 쌓아올리는 것이다 보니 부하가 크고, 그..

유니티에서 외부 파일을 할당하는 가장 기초적인 방법은 하나는 '인스펙터에서 직접 넣어주는 것'이다.사실상 인스턴스에 직접 배정해 주는 셈이라서 이렇게 구성하면 별다른 복잡한 과정 없이 외부 파일을 할당할 수 있지만, 동적 생성되는 오브젝트나 오브젝트 풀 같은 곳에서 활용하기에는 메모리 최적화 상으로도 그렇고 이래저래 난감한 편이라는 문제가 있다.물론, 스크립터블 오브젝트를 활용해서 구성한다던가 하는 것도 가능은 하긴 한데, 어찌되었건 인스펙터를 건드려야 한다 [= 유니티를 만져야 한다.]는 점에서 기획자가 능동적으로 사용하기는 난감하다. 그렇다 보니, Resources.Load와 Adressable Asset 등의 방법으로 스크립트를 통해서 불러오게끔 구성하고, 이를 Json 등의 문서화 파일과 연동시킴..

유니티로 프로그래밍을 하다 보면은 자주 사용하게 되는 것이 바로 오브젝트 풀이다.공격 오브젝트 부터 시작해서 몬스터 오브젝트 등, 생성과 파괴가 잦은 것들은 일단 오브젝트 풀에다가 넣어버리게 되는 것이 보통이다 보니, 별 수 없지 않나 싶다. 다만, 이 오브젝트 풀에도 난점은 있다.간략하게 알아보자.'오브젝트' 풀오브젝트 풀에 대해서는 일전에 정리한 바 있다.[참고 URL: https://lsu0503.tistory.com/84] 일반적으로 오브젝트 풀을 설명할 때에는 게임 오브젝트를 풀의 내용으로 기술하는 경우가 많다.그도 그럴게, 그렇게 하면 굳이 다른 작업을 할 필요 없이 오브젝트 풀을 구현할 수가 있으니까.그렇다 보니 오브젝트 풀을 처음 접하는 경우에도 GameObject 기반으로 만드는 경우가 ..

※ 오늘은 간단한 내용이 될 예정이다. 간혹가다가 드는 생각.조건문을 만들 떄 마다 라인이 4개 이상이 된다는 것, 조금 불편하지 않은가.물론, 엔터로 정리를 하지 않는다고 하면 2줄으로도 충분히 작성 가능하긴 하다.익숙해지면 if else 정도는 그냥 무감각하게 입력하고 있기도 하다. 그래도 1줄로 줄일 수 있다면 코딩하는 데에 드는 시간이 조금은 줄어들 것이다.조건 연산자피연산자의 개수가 3개인 연산자로, 조건에 따라서 결과물이 달라지는 연산자다.a = b b  여기에 함수를 넣으면 함수가 조건식 혹은 결과값이 되는 형식.물론 if else 구문을 쓰는 방법도 있지만, 이 경우에는 ?와 :만 추가하면 되기 때문에 익숙해지기만 하면 이래저래 편하게 사용할 수 있는 것이 장점. 다만, 너무 길게는 쓰지 ..

이번에는 델리게이트의 심화편, event에 대한 글이다.사실, 델리게이트 중에서 가장 많이 쓰이는 형태이다 보니, 어느 의미 기본에 해당하는 영역이기도 하다.그러니까 개념 위주로 간단하게 설명 해 보자. event란?event는 델리게이트의 일종으로, 특정한 상황에 대한 반응을 만들어내는 용도로 사용된다.event로 선언된 델리게이트는 event가 선언된 그 클래스 내부에서만 사용 가능하다. 이러한 구성을 이용해서 '특정 객체의 현상에 대한 반응'을 구성할 때 자주 쓰이는 기능.이제 이걸 선언하는 방식을 정리 해 보자.public event Action OnActionEventpublic event Func OnFuncEventAction은 반환값이 없는 경우에 사용하고, Func는 반환값(Treturn..