i3 Cpu가 하나 남아 돌아서 미니 PC로 하나 장만을 했다. 노트북처럼 쓸 생각이다. 다시 우분투를 세팅을 하고 있는 중인데 크리타와 XP-Pen하고 키세팅하는 노하우를 공개를 해야 할듯 싶다.

 이렇게 단축키를 해놓으면 크리타에서 꽤 편하게 사용을 할수가 있다. 

 오늘 고닷 플러그인 설명 보려고 라이더 가서 보고 있는데 == && ||  이 is and or로 바뀌었더라. C라이크 문법은 더는 안쓰고 이제 부터는 F#에 가깝게 쓰도록 방향을 정했기 때문에 이것도 이걸로 바꿔 쓰도록 해야 겠다. 

 잘 동작하는지 테스트를 한번 해보자. 

 테스트는 저번에 만들어 둔 고도엔진으로 한다.

 잘 작동한다. 다만 이런 매칭은 새로운 switch 문법을 쓰는게 좋다. 자동완성이 되기 때문이다. 여튼 앞으로는 이 문법을 쓰도록 해야 겠다. 

 오브젝트간에 통신을 하는 방법은 여러가지가 있다. 일반적으로 처음 접하게 되는게 파블릭으로 선언해 주고 손으로 다는 건데 이거는 가끔 오브젝트가 떨어져 나가는 경우가 있어서 막 배울때 빼고는 별로 사용하지 않는다. 

 그래서 가장 많이 쓰는 방식은 static으로 메인 메니저들을 만들어 놓고 중앙집중적으로 이어서 만드는 거다. 문제는 이거는 프로젝트의 설계가 무너지면 리스크가 빠르게 전파가 된다. 회사에 대표가 개발에 대해서 무지한 경우 혹은 기획자가 개발에 대해 무지한 경우에 이 방식을 쓰면 프로젝트도 무너진다. 

 그래서 유니티에서 추천하는 방식은 유니티 이벤트를 활용하거나 조금 범용적으로 델리게이트 이벤트를 활용해서 오브젝트간 통신을 하도록 한는 경우가 많다. 분산적인 구조로 가는 것이고 분산적인 구조를 짤때는 이 방식을 가장 많이 쓴다. 델리이트 문법은 고급 문법에 속하기 때문에 실력있는 팀원을 충원할수 있는 팀에서 이 방식을 많이 사용한다.

 내 방식은 조금 독특한데 파인드 오브젝트 타입을 이용해 자동으로 접근하는 거다. 이 방식에는 치명적인 문제가 있는데 매니저가 하나가 아니라 복수로 다는 경우 엉뚱한 것을 찾거나 같은 타입에 오브젝트를 실수로 붙이는 경우에는 버그를 야기할 수가 있다. 죄다 다 찾아 버리기 때문이다. 이 방식은 팀원을 믿을수 있고 소통이 원활한 경우에만 쓸수가 있다. 

 그래서 보통 7명 내외에 소규모 인디 팀들이 이 방식을 많이 쓰는 편이다. 안티 패턴에 가깝긴 한데 장점이 있기 때문에 쓴다. 유니티가 왜 작은 팀에 최적화 되어있는지 알수 있는 패턴이다. 

 맨마지막은 종합 설명이다. 여기까지하고 끝인듯 싶다. 이게 마냥 따라하는 것은 재미가 없기 때문에 안보고 삽질하면서 만들어 보는 것도 하나의 방법일지도 모르겠다는 생가이 든다. 

 홈페이지 만들어 주는 사이트를 발견해서 이리저리 만져 보는중이다. 코드를 손을 대려면 돈을 내야 하는 거여서 편집에 한계가 있는거 빼고는 마음에 드는 사이트이다. 

 프로토타밉만 만들어 보고 본격적인건 직접 만들어서 AWS에 올려야 할듯 싶다. 

https://webflow.com/d

https://aigoia.webflow.io/

 요 형태이고 이걸 시간을 내서 실전으로 만들어 봐야 할듯 싶다.