글

라벨이 프로그래밍인 게시물 표시

근황 잡담..

간만에 몇 자 적어봅니다. 회사를 옮긴 후에 개인 작업을 전혀 못 하고 있는데, 사실 이게 정상인것 같기도 합니다. 이전 회사는 일이 없을 때는 정말 완벽하게 아무 할 일도 없는 상태가 짧게는 며칠에서 길게는 두어주씩이나 유지되곤 했기 때문에 회사에서 대놓고 개인 작업을 했거든요. 아무래도 낮시간에 연속으로 시간을 할애하다보니 진도가 꽤 나가는데다, 옆자리 직원은 미니게임을 만들어 플레이스토어에 올리고 다른 직원은 웹서비스를 만들고 하는 분위기니까 눈치 보고 어쩌고 할 일도 없었지만, 이런 식의 구멍난 스케쥴이면 팀이 통째로 날아가지 않을까 하는 좀 더 근본적인 공포감이 있었던 것도 사실이었죠. 지금 회사는 일이 없는 경우가 없기 때문에 회사에서 개인 작업을 할 시간은 없고, 출퇴근 시간도 예전 회사의 2배로 늘어나서 퇴근 후에 뭔가 해보기도 어려워요. 그래서 개인 작업에 신경을 안 쓰고 지낸지 좀 됐는데, 간만에 회사에 놓여있던 책을 넘겨보게 된겁니다. 게임 프로그래밍 패턴 이라는 책인데, 저자가 블로그에 연재하던 시절에 우연히 찾아서 재미있게 읽었던 기억이 있습니다. 그런데 이번에 다시 읽다 보니 예전에 봤을때는 몰랐던, 제가 개인 작업물에 작성했던 모듈의 문제점과 해결책이 명확하게 서술되어 있는 부분을 찾은거에요. 아, 나 자신의 멍청함(이미 알고 있던 사실이지만; ㅜ_ㅜ)에 한숨을 쉬면서도 이제나마 고칠 수 있어서 다행이라는 생각도 드네요. 한가지 더 얻은 교훈이 있다면, 역시 사람은 책을 읽어야 한다는거겠죠..

Behavior Tree 작업을 하며 느낀 점..

최근에 회사에서 AI 작업을 하는데 비헤이비어 트리(Behavior Tree)를 작성해보며 느낀 점을 간략히 적어봅니다. 장점이야 익히 알려져 있다시피 기존에 주로 쓰이던 FSM/HFSM과 달리 중복 코드가 없어지고 더 깨끗하게 모듈화가 된다는 점이구요. 여기서는 단점을 좀 적어볼게요. 비헤이비어 트리(이하 BT)는 기법 이름이 나타내듯 AI가 하나의 트리로 구성이 되는데, 이게 코드/스크립트로 수정하기에는 직관성이 아주 떨어집니다. 기존의 FSM/HFSM은 기본적으로 스크립트를 읽으면 AI의 동작이 그대로 읽혀서 머릿속으로 시뮬레이션이 편하게 되는데, BT는 스크립트로 트리를 구성하므로 사람이 읽기가 나빠요. 동작 하나를 수정하려 해도 트리를 수정하려면 코드를 수정하는것과 감각이 아주 달라서 프로그래머 입장에서 편하게 작업할 수 있는 환경이 아닙니다. 이걸 편하게 하려면 결국 시각적인 편집 도구를 따로 제공하는 수 밖에 없어요. 근데 쓸만한 시각적인 편집도구를 지원하는게 쉬운 일은 아니잖아요? 참고 삼아 써보니 UnrealEngine4의 경우에는 블루프린트 기반의 BT 편집도구를 제공하는데, 이것도 BT의 특성을 고스란히 반영하는 물건은 아니고, 블루프린트를 BT에 끼워 맞춘듯한 도구더군요. 적당히 편집이 되고 어느정도 디버깅이 된다 정도지 BT를 편하게 편집하는 도구라는 인상은 받을 수가 없어요. 물론 BT를 손으로 직접 편집하는 것에 비하면 훨씬 편한 도구임은 분명하죠. 어찌됐든 BT는 편집도구가 가장 큰 문제가 되더군요. 앞서 이야기한 편집 문제를 겪으며 개인적으로 얻은 결론인데, BT는 편집도구까지 개발해서 기획팀이 AI를 수정하는 작업 방식일 때 쓰는게 가장 좋을 듯해요. 기획팀이 수정하지 않더라도 AI 개발이 많아서 시각적인 개발 및 디버깅 도구를 지원할 필요가 있을때 채용하면 효과가 좋을 것 같습니다. AI 개발을 많이 할 게 아니면 그냥 FSM/HFSM으로 개발하는게 개발 효율면에서 나을 것 같습니다. 중복 코드가 좀 나오더라도 편집의 어려움을...

창 크기를 조절하는 AutoHotkey 스크립트

요즘 남는 시간에 AutoHotkey 를 이용하여 장난감(;;)을 만드는데, 써보니 정말 편합니다. 동일한 기능을 C++로 구현하려고 하면 어떤 지옥이 펼쳐질지 생각해보면 절로 식은땀이.. 다음 스크립트는 지정된 창을 특정 크기로 맞춰주는 기능을 합니다. 간단한 스크립트니까 설명은 생략할게요. 다른 프로그래밍 언어 경험이 있으면 금방 감을 잡을 수 있습니다.  ; ; AutoHotkey Script for Mongil ; Version: 1.0 ; #SingleInstance, Force #NoEnv ; Find Genymotion window if !hWnd := WinExist("Genymotion for personal use") { MsgBox, 48, Genymotion Error, Running instance of Genymotion not found. Please start your Genymotion virtual device. ExitApp } ; Shutdown ResizeGenymotionWindow( 800, 480 ) ExitApp ; Resize Genymotion window size ResizeGenymotionWindow( width, height ) { ControlGetPos,,,ctlWidth, ctlHeight, subWin1, Genymotion for personal use if ( ctlWidth = width AND ctlHeight = height ) return 1 WinGetPos, x, y, winWidth, winHeight, Genymotion for personal use WinMove, Genymotion for personal use,, x, y, width - ctlWidth + winWidth, height - ctlHeight + winHeight ControlGetPos,,,newCtlWidth, newCtlHeight, subWin1, Genymotion ...

게임 프로그래밍이 어려운 이유..

프로그래머의 입장에서 게임 개발이 어려운 이유는 게임이 갖는 다음 2가지 요소가 서로 상충하기 때문입니다. 1. 게임은 소프트웨어 제품(software product)이다. 2. 게임은 엔터테인먼트 제품(entertainment product)이다. 이 2가지 요소는 서로에게 모순을 가져다 줍니다. 컴퓨터 개론 책을 펼쳐보면 입력된 데이터를 처리하여 어떤 결과물로 출력하는 것을 프로그램이라고 정의합니다. 게임이든 개인사용자용 응용프로그램이든 은행전산망이든 입력이 있으면 이를 처리하는 논리(프로그램)를 거쳐 어떤 형태로든 출력이 이루어지게 됩니다. 이것은 모든 소프트웨어 제품이 가진 특징입니다. 특정한 입력에 대하여 출력이 있는거죠. 은행전산망 같은 경우에는 워낙 방대한 입력이 일어나고 다양한 출력을 필요로 하다보니 개발이 복잡해지죠. 게임은 앞에서 예로든 은행전산망만큼 복잡도가 높지는 않지만 입력과 출력이 계속 변한다는게 문제가 됩니다. 왜냐하면 엔터테인먼트 제품이기 때문이죠. 애초에 기획한 게임이 얼마나 재미있을지 정확히 가늠할수가 없기 때문에 만들면서 테스트가 이루어지고, 또 중간에 기획이 변경됩니다. 그러면 프로그램이 처리해야 할 입력과 출력도 같이 변경됩니다. 일부 게임프로그래머들이 자신들이 하는 작업이 SI에서 하는 작업보다 훨씬 어려운 작업이라고 생각하는걸 보아왔는데, 제 생각은 좀 다릅니다. 다른 특징을 가졌을뿐 뭐가 더 어렵고 뭐가 더 쉽다고 할 수 있는건 아닌것 같습니다. SI쪽에서는 복잡도가 높은 작업을 하고, 게임쪽에서는 비정형적인 작업을 하기 때문에 작업의 속성 자체가 다릅니다. 그러므로 SI에서는 man/month라는 단위로 업무의 양을 측정할 수 있지만 게임에서는 이게 잘 안됩니다. 일반적인 소프트웨어 공학 이론이나 관리 방법론이 게임쪽에서 잘 안 먹히는 것도 이런 이유에서죠. 입출력이 계속 바뀌는 비정형적인 프로그램을 만드는데 정형적인 프로그램을 잘 만드는 방법을 적용한들 그게 먹히겠습니까.