어쩌다 쓰게된 질문지의 답변을 적다보니 재밌어서 (허락을 얻은후) 블로그에도 공유해봅니다. 1. 자기 소개를 해주세요. – 경력이어도 좋고 그냥 자신이 생각하는 자기 얘기여도 좋습니다. ** ** 프로그래밍이란걸 시작한지 30년이 좀 넘은 낡은 프로그래머로 유부남 - SINK 족 ( single income no kid ) 이며 돈많이 벌어서 은퇴해서 프로그램 짜며 여생을 보내고 싶어하는 사람 입니다. ** ** 2. 지금 무슨 일을 하고 계신가요? 조그마한 게임 회사(40명정도?) 에서 모바일 게임 서버 개발을 하고 있습니다.

요즘 나오는 언어들은 프로그램 내의 identifier이름으로 unicode 를 지원 하는 경우가 많습니다. http://rosettacode.org/wiki/Unicode_variable_names 애초에 새로 언어를 디자인 하면서 이를 지원하지 않게 디자인 하는게 이상한것이겠지요. 아마 제가 처음으로 한글 변수 명 한글 함수명이 사용 가능한것을 보게 된것은 java 였던 것 같습니다. 뭐 그전에 “씨앗"이라고 하는 한글 프로그래밍 언어도 있었습니다만.. 그래서 이제는 unicode를 지원하니 이제는 맘껏 한글 이름 변수명과 함수명 클래스 이름을 사용해도 좋을까 하는것이 주제 입니다. 그 전에 잠시 집고 넘어갈것이 있는데, 회사에서 프로그램을 작성할때 한글 이름 파일명을 사용하는지 궁금합니다.

사진 설명 : go4game web client 소스코드는 언제나 처럼 https://github.com/kasworld/go4game 에 있습니다. go언어는 서버에서 사용하는 것을 중점으로 하고 있기 때문에 client UI 를 작성할 만한 라이브러리가 적당한 것이 없습니다. 기본 라이브러리만이 아니고 3rd party 에서도 아직까지는 딱히 이거다 라고 할만한 것이 없더군요. 그에 반해서 서버를 만들기 위한 라이브러리는 tcp/http 불문하고 넘칠 정도로 많고 또 잘되어 있는데 아마도 go언어로 만든 프로그램의 UI는 당연히 web으로 작성하라는 의미 같습니다. 그런 관계로 go4game도 client UI는 웹으로 작성해야 겠다는 생각이 들어서 ( 사실은 클라이언트 UI 라이브러리를 찾다 포기하고 ^^; ) 웹 작업을 했습니다.

몇 년 전부터 생각하고 있던 go언어를 사용한 게임 서버의 개발을 시작했습니다. 일단 첫 번째 작동 버전은 언제나처럼 github에 있습니다. 지금까지 만들어진 것은 서버를 구성하기 위한 가장 기본 적인 구조들 GameService, World, Team, GameObject 과 client 와 tcp 로 패킷을 주고 받을 수 있는 구조들 정도 입니다. 지금 사용하는 패킷은 int32 len + json 형태의 패킷입니다. 참고로 그동안 제가 적은 go 관련 스터디 포스트 들입니다. The Go Programming Language : 2009년 글입니다.

새로 바뀐 스크린 샷 client/server 실행법 서버는 인자없이 그냥 실행하면 됩니다. python wxgame2server.py 또는 이번 C/S 분리의 목적중 하나인 wxpython 코드 제거로 wxpython코드가 서버에는 없기 때문에 pypy를 사용할 수도 있습니다. 클라이언트 실행 python wxgame2client.py -s serverip -t teamname -s 는 접속할 서버의 주소, port는 고정입니다. -t 는 클라이언트 AI의 팀 이름 -t 옵션이 생략되면 서버에 observer mode로 접속합니다. ( 서버가 보내주는 정보를 화면에 표시만 하는 모드 ) 각 팀은 랜덤한 teamcolor를 가지며 그 color대로 표시됩니다.

사진 설명 - 서버에 네개의 네트웍 클라이언트를 접속하여 실행 중인 화면. 이전 글들 이후로 개인적 여유 시간을 대부분 투자하여 ( 아직 버그가 좀 남아있긴 하지만;) wxgame2 의 네트웍 버전을 거의다 만들었습니다. github의 코드 를 보시면 알게 되겠지만 기존 wxgame2 코드의 상당부분이 재 작성 되었으며 네트웍 쪽 코드도 수차례 재 작성하였습니다. 정식 MMORPG처럼 모든 판단은 서버에서 이루어지며 각 클라이언트는 시각화와 클라이언트 AI 만 작동하는 형태 입니다. 서버 사이드 AI도 존재 하는데 이것은 서버의 NPC를 시뮬레이션 하는 것입니다.

이전 글 이후에 강의 준비를 하면서 코드를 보니 코드가 오래 되기도 했고 또 설계상의 결정들이 맘에 들지 않아 전체적인 재 정리를 해야겠다고 생각하고 있었습니다. 지난 주부터 시간 되는 대로 작업을 진행해서 로직을 수행하는 wxgame2server.py와 서버로 부터 받은 정보를 시각화하는 뷰어인 wxgame2client.py 로 만드는 것을 일정부분 끝냈습니다. 현재까지는 네트웍으로 데이터를 주고 받는 것은 안되어 있으며 간단하게 file/pickle 을 상용해서 서버-> 클라이언트간 정보를 전달하고 있습니다. 코드를 작성하다 보니 구조가 맘에 들지 않아 거의 뜯어 고치게 되었습니다.

파이썬과 wxpython을 사용해서 간단한! 2d 슈팅게임을 만들 수 있는 프레임웍과 예제 삼아 만들어본 AI만 있는 게임?을 github에 올렸습니다. 코드 내부의 주석을 보니 2011년에 만들어둔 것이군요. 그 동안 python홍보용으로 잘 써먹었던 프로젝트입니다. ( 파이썬으로 이런 게임도 만들 수 있어. 너도 배워 보지 않을래? 등 ^^ ) 원래는 더 일찍 공개하려고 했으나 코드 정리등이 귀찮아서 미루다가 모 후배의 압박으로 대충 정리해서 올립니다. 관심 있으신 분은 https://github.com/kasworld/wxgame2 에서 받으면 됩니다. 원래 코드는 제가 개인적으로 만들어 사용하고 있는 kaswlib이란 것을 사용하도록 되어 있는데 github에 올리려니 서로다른 두개의 프로젝트가 되고 또 참조를 하려면 import path를 설정하는 것도 해야 해서 쓰기 불편할 듯 하여 아예 프로젝트 내부에 wxgamelib 파일에 사용하는 코드만 복사해 넣었습니다.

지인으로 부터 뜬금 없이 “게임프로그래밍"라는 주제로 특강을 해달라는 부탁을 받아서 ( 아직 할지 말지는 미정이긴 하지만 ) 이런 저런 생각이 들어 적어보고 있는( 즉 아직 작성중인 ) 문서입니다. “게임을 만든다는 것은 무엇일까?” 게임이란 무엇일까? 게임의 정의를 논하는 것은 프로그래머 입장에선 쓸데없는 것일 테니 무시하기로 하고 ^^;;; 게임을 만드는 회사를 10년 넘게 다녔던 프로그래머로서 게임을 만든다는 것을 생각해보면 게임을 만들기 위한 직능을 준비하고 그 실무를 진행하는 것으로 정의해볼 수 있을 것 같습니다.

회사 세미나용으로 http://web2py.com/books/default/chapter/29/09/access-control 을 요약한 내용 입니다. 접근제어 access control web2py 는 Role Based Access Control 제공 (RBAC) 역할을 기반으로하는 접근제어로 context-based access control (CBAC) 과는 다르다. ( message의 context에 따라 달라지지 않는다, 상태, 혹은 데이터 ) user - role - job function 형태 web2py 에서는 Auth class를 통해서 구현된다. 아래와 같은 테이블이 필요한데 프로젝트를 만들때 자동으로 코드가 생성된다. auth_user : 유저이름 , email , 암호 , 상태 (등록 대기, 완료, 블럭됨 ) auth_group : 유저의 그룹(롤) 정보 , 이게 role ( 사용자 역할 ) auth_membership : group - user link table , user - group의 다대 다 연결.

회사에서 세미나 용으로 작성한 글인데 쓰고 보니 이것 만으로도 web2py의 소개 용으로는 충분 할 것 같아서 그리고 블로그에 올려도 좋을 듯한 내용이어서 올려 봅니다. 원문은 http://web2py.com/books/default/chapter/29/03 이며 번역을 한 것이 아니고 업무에 필요한/필요할 것 같은 것들을 정리한 글이라 원문과 같이 놓고 보셔야 이해가 될 듯 합니다. 제가 맡은 부분인 Overview 부분 만 입니다. ^^ web2py 개요 - overview ** ** 시작하기 - startup web2py는 윈도우와 맥에선 실행 프로그램으로도 제공되기 때문에 따로 python 이 필요하지 않다.

uwsgi 사용시 (http://projects.unbit.it/uwsgi/wiki) post data를 처리 하고 싶으면 결과 return/yield 를 내보내기 전에 읽어 와야 한다. 그렇지 않으면 메롱한 에러를 내는 경우가 왕왕 생긴다. ( 검색해보니 알려진 버그인듯. ) 이것때문에 오늘 시간좀 소비 했음. 아 그리고 web service 개발할때 curl 이 정말 편하다. command line으로 http post를 할수 있으니 코드 테스트가 정말 편하게 이루어지더라. ;;; 역시 인간은 검색을 생활화 해야 하는 것이었다 ;;;

를 하기전에 ^^;;; web server : apache , lighttpd, nginx , cherokee, cherrypy, simplehttpserver(python) web app protocol : static file, wsgi , uwsgi web app frame work : node, cherrypy, django , web2py, 중 어떤 조합을 사용할지를 결정해야 해서 그동안 써왔던 것을 모두 점검하는 의미로 간단/대충 벤치마크를 해봤음. 즉 이글은 그 기록을 남기기 위한 글. ^^ 기본적으로 다 hello world 를 리턴하는 static file 또는 print 코드 를 사용 해서 테스트 했습니다.

우분투를 설치하고 아파치를 설치하면 http://localhost/doc/ 으로 들어가서 로컬 기계에 설치되어 있는 패키지의 문서를 볼수 있습니다. 만.. 이게 들어가보면 엄청나게 많은 디렉토리가 있어서 원하는 문서 디렉토리로 찾아 가는게 귀찮더군요. ( 제기계에는 1400여개의 디렉토리가 있습니다. ) 너무 많은 정보는 없는것과 같기에 *-doc 디렉토리만 목록에 나오도록 조그만 프로그램을 만들어 봤습니다. 1 <?php 2 **$dir = “/usr/share/doc/”; 3 $urlbase = “http://localhost/doc/”; 4 5 // Open a known directory, and proceed to read its contents 6 if (is_dir($dir)) { 7 if ($dh = opendir($**dir)) { 8 echo ‘<table>’; 9 **$**i = 0; 10 **$dirlist = array(); 11 while (($f = readdir($**dh)) !