![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FLlZax%2FbtrI7LyHC63%2FXa1ZPawGRE3hE2YFNKr3UK%2Fimg.jpg)
몬스터 혹은 자동사냥 기능을 만들다보면 AI 작성은 꼭 필요하다. 그 중 많이 사용되는 FSM(유한기계상태)과 BT(행동트리) 중 이번에는 FSM에 대해 설명을 하려고한다. FSM의 장점 1. 디버깅이 쉽다 2. 상태에 대한 코딩이 해당 상태에서만 작동하기 때문에 코드 작성이 쉽다. 3. 문제가 되는 상태만 수정하면 되기때문에 버그 수정이 쉽다. 단점 1. 상태의 규모가 커지면 복잡해진다. 2. 해당 상태에 대한 적용만 가능하다. 사실 위와같이 장단점만 작성하면 느낌이 잘 오지않는다. 예를들어 -IDLE (대기상태) -ATTACK (공격상태) -DEAD (사망상태) 3가지 상태가 있다고 가정하자. "가만히 있는데 몬스터에게 맞아도 반격을 하지 않아요." 라는 버그제보가 들어왔다. 가만히 서있다는 것은 I..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FCsf2A%2FbtrI7MRVP8r%2Fu7bOWHKLiFZRJyF9o8H4k0%2Fimg.jpg)
Xml을 사용하는 데이터 관리에 이어 이번에는 Excel Sheet를 사용하여 관리하는 방법에 대해 장단점을 작성해보려고 한다. 엑셀로 데이터를 관리하게 된다면 장점으로는 1. 보편화되어 누구나 쉽게 접근이 가능하다. 2. 보편화되어 있기 때문에 정보가 많아 Data Extract 툴 제작도 쉽다. 3. 함수를 통해 파일 내에서 자체 검증이 가능하다. 4. 데이터누락을 허용하지 않는다. (회사마다 차이는 있을 수 있다) 5. 구글 스프레드 시트를 사용한다면 공동작업이 가능하다. 단점으로는 1. 함수를 사용하며 파일과 파일간의 데이터 참조가 많아지면 스파게티형식이 될 우려가 있다. 2. 구글 스프레드 시트를 사용한다면 데이터 실수가 발생할 수 있다. 위와 같은 장단점에 대해 많이 느꼈다. 하지만 무엇보다 ..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FFkYWG%2FbtrIXXeEtdW%2FlMmKroDNKlG6O9u0Nsw8M0%2Fimg.png)
회사를 다니며 Xml, Excel, Json, Csv 을 이용한 데이터 관리를 사용했었다. 이번에는 그 중 Xml에 대해 장점과 단점을 작성해보려고 한다. Xml (eXtensible Markup Language) 확장가능한 마크업 언어 (마크업 언어 는 태그 등을 이용하여 문서나 데이터의 구조를 명기하는 언어의 한 가지이다) 뜻 그 자체로 확장가능한 Xml은 확장이 정말 편하다. 여러가지의 특징 중 정말 와닿게 느껴진 특징으로 2가지만 작성하자면 1. 작성 방법이 편하다 2. 데이터의 표현 방법이 자유로워 확장이 편리하다 예시) 아이템1 10 개발 초기단계에서 아이템1의 데이터를 작성할 경우 현재는 아이템의 이름(Name) 그리고 공격력 수치(Attack) 2개의 변수만 존재하지만 해당 데이터에 방어력..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fb8NL88%2FbtroT6414xZ%2FE5CnS1pNaw2UAjtL5PRho1%2Fimg.png)
Unity 버전이 2021로 버전업이 되면서 Unity C#에 대한 언어 버전이 C# 8.0으로 업데이트 되었다. 이번 C# 8.0에서 많은 새로운 기능이 추가되었지만 이번에 다룰 내용은 Switch문의 개선이다 패턴 일치 개선 사항: Switch 식 속성 패턴 튜플 패턴 위치 패턴 우리가 기존에 알고 익숙하게 사용 하던 Switch 문의 사용 방식 switch (type) { case ItemType.SWORD: { name = "SWORD"; break; } case ItemType.SHIELD: { name = "SHIELD"; break; } case ItemType.ARMOR: { name = "ARMOR"; break; } case ItemType.NONE: default: { break; }..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbCVuOB%2FbtroITEnzpL%2F5b3pdxitpJEsQKhG8TXnI0%2Fimg.png)
유니티 캐시서버에 대해 알아보자. 협업을 하면서 git, svn, cvs 등 형상관리 툴을 사용하다 보면 버전별 branch가 다양하게 나뉘는건 당연한 일이다. 이때 branch를 옮겨다니다 보면 Unity 에서는 바뀐 에셋 파일을 감지하고 해당 에셋들에 대해 다시 import를 진행한다. (.psd, .fbx, (psd,fbx).meta, texture들의 내부 버전번호, AssetPostprocessors 버전의 해시가 변경되면 import를 다시 진행한다) 이렇게 에셋들에 대한 임포트를 다시 실행할때마다 대기시간이 걸린다 프로젝트의 크기에 따라 짧게는 몇초 길게는 몇시간까지도 소요된다. 이걸 해결하기 위한 기능이 Cache Server의 기능이다. Local서버 혹은 Remote서버에 임포트된 파일..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FHXD5I%2FbtqEAL4z75P%2FOCbWXTBWGgW16oHF522PKk%2Fimg.png)
지난 포스팅에서 Debug.Log에 이어서 로그 콜백을 한 번 더 써보려고한다. Unity에서는 로그를 전송한 후에 콜백이 이루어진다. 공식문서를 살펴보자. public delegate void LogCallback(string condition, string stackTrace, LogType type); Description Use this delegate type with Application.logMessageReceived or Application.logMessageReceivedThreaded to monitor what gets logged. See Also: Application.logMessageReceived, Application.logMessageReceivedThreaded, L..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FmIMVM%2FbtqEyKlFeDA%2F4tvKSSiLCfQ1xPAImK8fB0%2Fimg.png)
모든 개발자는 Log 없이 개발을 할 수 없다. (할 수 있는 천재가 있을 수도... 하지만 난 아니다) printf(), Console.WriteLine(), Logger.debug() 등 언어에 따른 로그를 찍는 방법이 많이 있고, 유니티에도 Debug.Log() 를 통해 로그를 찍어볼 수 있다. 많은 개발자가 알고 있다. 하지만 대부분 일반적으로 로그를 그냥 평범한 텍스트형태로 출력할 것이다. 이번에 사용해 볼 디버그 로그 사용 방법은 UGUI에서 사용하는 RichText 사용법과 동일하다. 위 Text에 사용된 문자열들 처럼 이번 로그는 볼드다 이번 로그는 이탤릭다 이번 로그는 사이즈다 이번 로그는 컬러다 위 텍스트들을 그대로 Debug.Log(string value)로 넣어보자. void Sta..
![article thumbnail](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbhRTAn%2FbtqEo62rJEq%2F7nE36eyX4dlYvlhnPUyncK%2Fimg.gif)
어느날처럼 회사에서 개발을 하는중이였다. 나에게 걸려온 미션은 전투가 끝나는 시점에 게임이 느려지는 하이라이트 연출을 보여주는 시점에 다른 UI에는 배속에 영향이 없도록 수정 작업이였다. 이렇게 전투가 끝날때의 화면이 느려지는 연출 상황이다. (첨부한 GIF파일들은 회사의 프로젝트와 상관없음) 회사에서 진행중인 프로젝트는 Spine을 사용한 게임이였다. Spine은 기본적으로 Unity의 Time.timeScale 값을 따라간다. 이미 프로젝트에서 전투에 대한 작업이 이루어졌기때문에 Unity의 timeScale값을 건드리지 않는 방법을 사용하기엔 이미 너무 많은 강을 건너버린 상태였다. 상상해보자 UI뒤에서는 전투를 하면서 시간값을 변경하고 있는데 UI에서는 Spine 캐릭터들이 시간값에 영향을 받는다..