오늘부터 일요일 마다 개발일지를 작성할 것이며 이 글은 첫번째 개발일지다. (저녁에서 밤사이 올림)
우선 제일 먼저 해야할 말이 두개가 있는데
하나는 현재 당장 보여줄 수 있는게 많이 없다.
말 그대로 최종적으로 천리길을 가야한다면 정말 한 걸음만 갔다고 할 수 있다.
내가 프리한 시간이 목요일부터 일요일까지라 시간 투자를 많이 못한점도 있지만 외적으로 보이는것 보다 내적으로 안보이게 코딩한게 많다.
미안하다.
또 다른 할말은 편하게 작성하기 위해 반말로 하겠다.
우선 보여줄 수 있는것부터 설명하겠다.
UI구성은 왼쪽에 5-7개 정도 메뉴탭을 놓을 생각이다.
임시로 배치한 메뉴는 맨위부터 배치, 선택, 제거, 세팅(레시피, 필터), 회전, 카메라 이동이다.
각탭을 누르면 해당 모드로 전환하여 제어할 생각이다.
메뉴들은 개발진행에 따라 바뀔 수 있다.
(의도치 않게 LGBT의 상징인 무지개색으로 했는데 나는 LGBT가 아니다)
위에 살짝 배치 탭이 짤려보이는데 이는 버그가 아니다.
저번에 내가 뿌렸던 설문조사를 통해 16:9가 가장 많은 해상도로 지목되었기 때문에 기준을 그걸로 잡아서 18.5:9인 내 폰이랑 해상도가 안맞아서 그렇다.
16:9에서 테스트 해보면 꽤 잘나옴
현재 완성된 탭은 카메라 이동 밖에 없다.
카메라 이동탭을 누르면 드래그로 카메라를 이동 할 수 있다
줌인 줌아웃 기능도 넣었는데 이 기능은 손가락 두개로 줄였다 늘렸다 할 수 있다.(핀치)
딱히 다른 모드에선 손가락 두개를 사용할것 같진 않아서
카메라 이동 모드가 아니여도 확대, 축소는 할 수 있게 해놨다.
제작중인 배치 탭이다. 보면 생산칸에 조립기계123을 놓기만 했다 (배치 불가)
아이템 하나 하나 추가해서 데이터 넣어주는 노가다를 해야한다. 작업할 아이템이 약 100개 이상있다.
(레시피는 더 많음)
여기까지가 그저께부터 어제까지 작업한 보이는 부분들이다.
아래부터는 오늘 작업한 보이지 않는 작업들에 대해 글로만 설명한다.
코딩을 모르는 사람이 읽으면 재미 없을것 같으므로 넘어가도 된다.
코딩을 알아도 재미 없을것 같으므로 넘어가도 된다.
(댓글로 질문 하면 받아줌)
방금 아이템 하나 하나 추가하는 노가다에 대해 말했었다.
또 아이템만 노가다 하느냐? 레시피 정보도 따로 만들어야 한다. 아이템 고유 이름이며, 스프라이트 위치며, 크기며 제작 재료며 걸리는 시간이며 결과물이며 등등 하나 하나 노가다 하는건 프로그래머 답지도, 팩토리오 답지 않다.
그래서 직접적으로 보이는 작업을 멈추고 데이터를 추출하고 저장하는 자동화 를 만들어 보려고 했다.
먼저 factorio 파일을 뒤져서 data₩prototype₩item
과 recipe를 찾아냈다.
그 다음으로 파싱하는 작업을 하고 있었다
파싱하는 코드를 만들고 데이터를 분석해 조립기계 코드에 모두 저장한다.
여기서 문제가 발생된다.
모든 조립기계마다 레시피를 가지고 있는게 되기 때문에 조립기계 갯수 * 레시피 용량 만큼 메모리가 소비된다.
내가 뿌렸던 설문조사에 따르면 60퍼 이상이 평균 이하의 성능(본인들이 생각하기에)인 휴대폰을 사용중이기 때문에 메모리, 계산 최적화는 필수이다.
그래서 unity에서 제공하는 able로 모든 레시피와 아이템의 정보를 저장하려 했다. unity를 배울 당시 원리가 이해가 안되서 대충 넘긴 개념이였기에 다시 공부했다. (여기서 시간이 걸림)
그래서 다 잘됨? 아니다. able 개념을 배우고 나니 able를 복제, 불러오기, 데이터 삽입, 저장 등 몰랐던 함수와 기법등을 또 공부했다.
그러고 나니까 잘됨? 또 아니다 안드로이드에서 작동안하는 코드가 있어서 구글을 통해 안드로이드에서도 동작하는 코드로 바꿔주는 일도 있었다.
그러고 나니깐 2시에 작업중인게 8시 반이더라...
별로 진전은 없었지만 노트북도 지치고 피곤했는지 멈춤 그래서 오늘은 그만뒀다.
(그래서 사진이 휴대폰 스샷밖에 없다)
그럼 한거 좆도 없네?
라고 생각할수 있지만 변명을 좀 하자면 더 좋은 퀄리티와 많은 기능들을 제공하기위해 꼼꼼하게 만들고 있다고 생각해주면 고맙겠음
아니면 내게 시간과 예산이 좀 더 있었더라면...
다음주 목표
+ 아이템, 레시피, 건물 데이터 추출과 저장 자동화 마무리
+ 맵에 그리드 그리기
+ 조립 기계를 그리드에 맞춰 배치 가능
+ @
이거 하느라 게임을 줄이니깐 힘들긴 한데
나한테 이 프로젝트는 또 다른 팩토리오같은 느낌이다.
노트북이 다운되서 휴대폰으로 썼다.
모든 유용한 요청사항은 나중에 다 받아드릴 생각임
댓글로 질문 하면 받아줌
- dc official App
글쓰는 법도 공부해서 오겠음 가독성 존나 떨어지네 - dc App
scriptableobject에서 script랑 object가 예약어여서 짤려서 able로 표현되네 - dc App
서문 - 프로젝트 개요 / KPI(Key performance indicator)소개 본문 - 현재 진행한 내용에 대한 개괄적인 설명 후문 - KPI지표 도달치 제시 / 다음 리포트 내용 간략히 제시 REF - 본문에서 자세히 다루면 늘어지는 내용 후문 이하에 첨부
조립기계에 얘한테 할당된 레시피가 몇번레시피인지 저장시켜 - 팟수
레시피자체는 글로벌하게 다쓰는거니까 글로벌로 주고 조립기계에선 포인터마냥 몇번레시피를 생산할 조립기계에요! 하는게 맞아보임 - 팟수
어차피조립기계 123에서 뽑을수잇는 레시피가 다르긴한데 레시피 번호마다 123에서 사용가능한지 변수하나씩주고 그러면될거같샘 - 팟수
3이면 3에서만 생산가능 2면 2 이상 1이면 1 이상 등등 - 팟수
스크립터블 이새끼는 유니티내에서 인스턴스를 에셋화할 때나 좋지 그냥 데이터만 다룰거면 위에 다크붐 말처럼 쉐어드 리소스 관리하는거 하나 만들어서 xml이든 json 로드해서 쓰는게 나음 유니티 json 이 잘되있으니까 json이 낫다
고맙소 동무들 - dc App
스크립터불 쓰는법도 좆같았고 쓸모없는 새끼였네 이거 그냥 데이터는 앱 실행시 파싱해서 가져오도록 해야겠다 - dc App
스크립터블이 좋은건 이새끼가 유니티 Object에서 상속된 놈이라 인스턴스에 대한 레퍼런스로 직렬화시킬 수 있다는 점. 이거 안쓸꺼면 걍 플레인 타입으로 작업하는게 편함.
Foreman도 C# 개발이던데 소스 참고할 거 꽤 많을듯
조언 고맙 - dc App
저작권 크리 안 당함?
저작권 문제는 최대한 피하려고함 마켓에 올릴것도 아니고 깃헙엔 이미지 리소스는 뺄거고 파일 배포는 이메일로 보내줄라고 함 - dc App
시뮬레이션을 시뮬레이션 하다니... 이 얼마나 무섭고 끔찍한 생각인가