Intro 제목은 조금 그럴듯해 보이지만, 사실 개발을 하면서 생기는 구조적인 문제들을 해결할 수 있는 방법들 도구들을 소개하고, 연습하는 프로젝트이다. 사실, 앞으로 다룰 내용들은 문제에 대한 절대적인 정답이 될 수는 없다. 요구사항에 따라, 쉽게 말하면, 내가 현실화하려는 문제들에 따라 직면한 문제에 대해 대응할 방법은 다채롭게 변화할 수 있기 때문이다. 디자인 패턴은 단순히 우리가 그 솔루션을 숙고할 때 사용할 수 있는 도구들이다. 개인적으로 이를 공부하는 이유는 궁극적으로 개발 아키텍팅에 관심이 있고, 유니티 개발자로서 일을 하면서 퍼포먼스를 더욱 끌어올리고 싶다는 욕심이 생겼다. 이를 위한 방안으로서, 현재 친숙한 엔진인 unity로 게임 프로그래밍 아키텍처를 구현 해보고, 파고 들고자 한다. ..

현재 재직중인 회사에서, 자율 회로 조립 시뮬레이션 컨텐츠를 추가 하기로 하였고, 1월 중순에 1차 마무리가 되었다. 정리를 하자하자 하고 나서 이제야 하게 되었는데, 바로바로 정리하는 습관을 기르도록 해야겠다. 작업 영상 Structure(구조) 대략적인 구조를 그리자면 위와 같다. 위에서 부터 전체적인 그림부터 그밑의 작은 부분들로 구분해보도록 하겠다. page(UI) 기본적으로 ui를 위한 frame구조가 있다. 그중 비즈니스 로직의 주된 처리를 담당하는 controller에서 주요 로직들을 담당하고 있다. Input Contoller, Assembly Controller들을 할당 하고, ui의 이벤트가 일어났을 때, 그에 걸맞는 시뮬레이션 모델들을 조작한다. page에서는 주로 ui의 변경에 이용..

먼저, 핸드폰을 랩탑에 연결한다.빌드세팅에서 connected device에 기기가 뜬다면, 성공. 그다음, preferences에 들어가 sdk path를 복사 해준후, 명령 prompt를 열어서 cd [sdk path, 방금 본사한 folder path] 를 입력하여 폴더이동을 해준다. 그후 dir을 입력하여 platform-tools가 제대로 있는지 확인해준다. adb tcpip 5555 입력. adb connect 자신아이피:5555(포트) 를 입력해준다. 만약, 제대로 설치가 안되어 있거나 adb가 없다면, brew cask install android-platform-tools을 해준다. (필자는 버전이 바뀌었는지 brew install -cask android-platform-tools)로 ..

아키텍처의 지향은 스크립터블 오브젝트이다(유니티에서). 뭔소리인가?? -> 좋은 아키텍처란 모듈화에서 온다. 기능을 잘게 세분화하는 게 중요한데, MonoBehav는 최소한의 프로퍼티를 명시하고, 참조하는 시점과 조건의 틀만 정의한다. 즉 틀에 프로퍼티를 넣는 역할만 한다. 프로퍼티가 기능을 정의하려면 Mono로 만든 system, 컴포넌트, 스크립터블 오브젝트가 필요하다. 여기서 아키텍처는 SO를 선호한단 소리다. 이점이 뭘까 - mono만 작성해주면 되는 데 프로퍼티에 대한 SO를 따로 만들면 귀찮을 수도 있다. 하지만, 초기화 작업, 수정 작업은 인스펙터 창에서 가능하고, 확장 작업은 신규가 아닌 기존 소스재사용과 에셋생성으로 한다. 모두에게 언제든지 참조 가능한 인스턴스이므로 유연하다. 모듈화/ ..

-계기 text컴포넌트에서 html태그를 활용하여 글자색을 바꾸는 등, 글자를 꾸미거나 할수 있다. 하지만, 많은 기능을 제공하지 않고 있고, text mesh pro를 사용하여야 원하는 태그를 사용할수 있다. 그래서 text를 이용하여 tmp에서 제공하는 태그 기능을 만들어 볼수 있지 않을까? 생각하여, parser를 만들어 보았다. 거두절미하고, 결과는 만들기 어렵다(가능하지만, 투자시간이 너무 오래걸리고, 기존에 계획했던 방식으로는 할수 없었다)였다. 특정 text를 클리하였을 때, 이벤트를 주고 하려면 그text의 coordinate값이 필요한데, text에서는 없고, tmp에서는 인덱싱 별로 좌표값을 받고 있었던것이었다..물론 방법을 꾸준히 찾다 보면 있을수도 있겠지만, 나는 스택계산긴를 활용하..

ObjectPooling이란? 게임에 필요한 오브젝트를 미리 생성해서 필요할때마다 꺼내서 쓰고 사용이 끝나면, 다시 돌려놓는 개념이다. 필요할때마다, 오브젝트를 생성, 파괴를 하는 것이 아닌, 필요한만큼을 미리 만들어 두고 모자라면 추가 생성을 해주고, 게임이 끝나면 파괴를 해준다. 이로써, 생성 파괴 횟수를 줄일수있다. 언제 쓰이나? 주로, 총알이나 먼지 이펙트 같은곳에서 많이 쓰인다. 객체를 빈번하게 생성/삭제 해야할때, 객체들의 크기가 비슷할 때 객체를 힙에 생성하기엔 느리거나 메모리 단편화가 우려될 때 DB 연결이나 네트워크 연결같이 객체 생성시 비용이 비쌀 경우 미리 생성해두고 재사용할 필요가 있을 때 (메모리 단편화? RAM에서 메모리의 공간이 작은 조각으로 나뉘어져 사용가능한 메모리가 충분히..