https://github.com/kasworld/wasmclockcal go언어의 webassembly 생성 기능을 사용해서 만든 시계/달력 입니다. build.sh을 실행하면 파일을 http로 서비스 해줄 dir2http 와 실제 index.html을 통해 로딩되어 시계/달력을 표시해줄 wasmclock.wasm 파일이 생성됩니다. wasm_exec.js 은 wasm을 로딩해서 실행하는 데 사용 됩니다. go를 설치하면 /usr/local/go/misc/wasm 폴더에 설치되어 있습니다. (linux 의 경우 ) dir2http를 실행하면 접속할 클라이언트 url을 보여 줍니다. dir2http dir=. port=:8080 http://localhost:8080/ open bgclock http://localhost:8080/?bgimg=image open youtube clock http://localhost:8080/?mvid=youtubeid 클라이언트 접속 URL 에 bgimg=이미지이름(url) 을 주면 배경그림이 설정되고

지난글 http://kasw.blogspot.com/2018/01/tcp-udp.html 이후로 goguelike2에 udp 지원을 넣기 위해 작업을 계속하고 있었는데 드디어 오늘 udp로 goguelike2 server 와client을 연결 tcp와 똑같이 작동시키는데 성공했습니다. udp 작업만 한것은 아니고 필요한 다른 작업들도 동시에 하고 있었기 대문에 생각보다 좀 오래 걸린듯 합니다. 좀 집중해서 작업했으면 2주 정도는 당길수 있었을것 같지만 이런 저런 일들을 처리 하기도 하느라 시간을 좀 썼습니다. 그리고 부산물로 tcp 와 udp 를 동시에 지원 가능한 net 라이브러리가 생겼습니다. ^^ udp를 지원 하도록 바꾸면 tcp와의 차이를 비교 하는 것이 힘들 것 같아서 고민하다가 두가지를 거의 같은 구조로 지원 할수 있게 기반 작업들이 이루어지고 나니 그러면 동시에 지원하게 하면 좋겠네?

지난 2년간 회사에서 개발한 게임서버 개발을 한번 정도 정리 해보고 싶다고 생각 하고 있었습니다만. 몇주전에 golang korea 에 올라온 GDG seoul meetup 발표자 모집 글을 보고 (꽤나 즉흥적으로 ) 신청을 했더니 덜컥 발표자로 등록 되어 버렸습니다. https://www.facebook.com/groups/golangko/ 결국 지난주 토요일 (2017-09-16) “Meta-programming으로 만드는 게임 서버” 라는 주제로 발표를 했습니다. https://www.meetup.com/GDG-Seoul/events/242054608/ https://docs.google.com/presentation/d/1P6wykg33jnbTM0GVB3AwXUJZlkp20yC0i6XcbOfPlG4/edit?usp=sharing 발표 준비를 하면서 “너무 실무적 내용들이고 또 자세한 설명은 생략한다. 식이라 이래도 좋은가?” 라는 걱정을 좀 했는데 다들 열심히 들어 주시고 해서 어떻게 무사히 끝냈습니다.

이전에 go 언어용 serial id generator 에 대한 글을 올린적이 있었는데. http://kasw.blogspot.kr/2015/01/go-serial-id.html 그 내용의 개량판에 대한 이야기입니다. 업데이트된 코드는 https://github.com/kasworld/idgen 에 있습니다. 작업하다 보니 ID를 꼭 0부터 시작하는 것이 아니고 이전에 기록해둔 부분 부터 시작해야 하는 경우가 생기더군요. ( 서버가 종료 되었다 다시 시작할때 ID를 사용하는 object들의 persistent 가 보장 되어야 하는경우. ) 그래서 기존의 idgen 을 수정/업데이트 했습니다. 주 변경점은 여러 생성기를 만들수있도록 factory 함수를 만들고 인자로 시작 값을 받도록 했습니다.

이전글 에 잠깐 언급했었던 http://kasw.blogspot.kr/2014/10/pythongolang-web-framework.html go 용 web framework를 비교 테스트 해봤습니다. 그때 이후로 beego, revel , martini 이외에 딱히 떠오르는 것은 없는것 같아서 일단 평가가 별로인(듯한) martini는 빼고 ( 나중에 시간나면 한번 보고 싶긴 합니다. ) beego와 revel 만을 검토해 보았습니다. 사용한 기계의 spec linux mint 17.1 cinnamon x64 Linux kasw-work 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux i7-4790 3.6x4 4c8t ram 8G single channel ab -c 100 -n 500000 http://localhost:8080/

세계 최초?의 MMORLG(MMO roguelike game) 인^^;; goguelike2의 최근 작업진행사항입니다. 간단히 말하면 potion을 추가 하려고 했는데 일이 커져서 약 한달 넘게 bag (== 인벤토리 , 기존에는 장착 슬롯만 있었습니다. ) 돈(과 지갑), 무게 ( 아직 제한은 없습니다만.. ) 그리고 포션의 존재이유인 status effect 과 affected statues effect 등을 작업했습니다. status effect는 간단히 말해서 buff 와 de-buff 입니다. 그리고 이 모든것들을 지원하기위한 시스템의 수정과 업데이트;; 그래서 그 결과물이 위의 스크린 샷 입니다.

update 15-03-29) http://blog.labix.org/2011/10/09/death-of-goroutines-under-control 를 같이 보시는 것도 재밌을것 같습니다. 비슷한 고민을 다르게 해결한 경우라고나 할까요. update) 페북에 올라온 의견을 읽다보니 이글의 설명이 부족한듯 합니다. 아래 상황은 같은 context를 공유하는 goroutine들 간에 종료 신호를 주고 받기위한 방법중 (아마도 )가장 가볍고 빠른 방법을 만들어본것입니다. 이 제한이 없다면 다른 무수한 방법들이 가능할것입니다. 당장 map + mutex를 사용해서도 동일한 효과를 볼수 있을껍니다. ( 크고 무겁겠지요 ^^ ) 여기서 context를 공유한다는 것은 runstate를 struct의 field로 만들고 만들어진 object를 공유하는 여러 goroutine을 생각하시면 됩니다.

(업데이트)2d slice 를 추가하고 수정하였습니다. 기존 idpos 라이브러리를 대대적?으로 정리 했습니다. idpos는 object의 위치를 저장하고 관리하는 목적의 패키지인데 ( 2d 공간에서 object들을 관리 하는 것이 주 목적 ) 기존 구현은 pos2objs map[[2]int]idposi.IDPosIList 과 같이 map을 사용해서 구현 하고 있었습니다. 그런데 프로파일링을 해보니 map access에서 대량의 시간이 소비되고 있다는 것을 깨닿고 ( 25% 정도의 cpu 가 사용되고 있었습니다. ) map들을 가능한 줄인 pos2objs []idposi.IDPosIList 내부적으론 [2]int를 int로 변환하는 (xlen*y +x ) hash 함수를 사용하는 slice 기반으로 수정하였습니다.

이전에 cpu profile 하는 글을 썼지만 http://kasw.blogspot.kr/2015/02/go-profiling_4.html 이번에는 memory profile을 하기 위한 수정을 했습니다. 시작과 끝을 지정해야하는 cpu profile과는 달리 memory profile은 현상태의 snapshot을 떠내는 형태로 사용하게 됩니다. 프로파일을 위한 shell script는 //start #!/usr/bin/env sh PRGNAME="$1" shift go build ${PRGNAME}.go ./${PRGNAME} -memprofilename ${PRGNAME}.mprof $* go tool pprof ${PRGNAME} ${PRGNAME}.mprof rm ${PRGNAME}.mprof //end 과 같고, 실제 프로그램에서 사용할때는 //start package main import ( "flag" "fmt" "log" "math/rand" "os" "runtime" "runtime/pprof" "time" ) func init() { rand.

만들고 보니 너무 간단한것이라 별로 적을 내용이 없지만.. linux/unix 계열에 들어 있는 fortune cookie 파일을 읽어 주는 패키지 입니다. 단 binary file(strfile) 인 .dat 파일이 아니고 확장자가 없는 text 파일을 읽어줍니다. 사용예는 fortune_test.go를 보시면 됩니다. 소스 코드는 https://github.com/kasworld/fortune 에 있습니다.

정확히 말하면 go-sdlgui 에 추가 한 것이 아니고 제가 사용하고 있는 라이브러리에 https://github.com/veandco/go-sdl2 에 utf8 표시기능을 추가 한것입니다. 일단 pull request를 보내 놓긴 했지만 위의 라이브러리가 (사용 법이) 종종 바뀌므로 branch를 하고 https://github.com/kasworld/go-sdl2 제 repository를 사용하도록 모두 수정하였습니다. 이전 글들 http://kasw.blogspot.kr/2015/02/go-tcp-server-gui-client.html http://kasw.blogspot.kr/2015/02/go-gui.html 업데이트된 GUI https://github.com/kasworld/go-sdlgui 그림이 없으면 심심하니 스크린 샷 한글 표시예 예제 컨트롤 - 아나로그 시계 ps) 같은날 저녁 - pull request가 받아져서 merge 되고 contributor 이름도 올라 갔습니다. 별거 아니지만 기분은 좋군요.

기록을 위해 적습니다. 4000 클라이언트 동시 접속 ( 1000 x 4 ) 테스트 서버 와 클라이언트 가 바뀐것 같은 느낌이 들면 기분탓^^ 입니다. ( 테스트 클라이언트가 클라이언트 AI 지원을위해 메모리 사용량이 많은 탓.) 총 active object는 6000여개로 이중 2000여개는 서버사이드 AI 4000 개는 클라이언트 AI 즉 테스트중에 서버에서는 6000여개의 AO가 활발하게 활동중이었음. 클라이언트 i5-2500 3.3Ghz 4c4t 16Gbyte ram cpu 50% 정도 사용 메모리는 1000클라이언트 당 6G : 결국 넘쳤음. 서버 ( 한성 인민에어 ;; ) 하스웰 i5 4250U ( 1.

3000라인 이상을 공용 package로 분리해 내고도 goguelike에 남은 코드가 아직도 9000라인이 넘기 때문에 TCP server 와 GUI client로 사용할만한 예제를 따로 만들었습니다. 결과적으로는 http://kasw.blogspot.kr/2015/02/go-tcp-serverclient.html http://kasw.blogspot.kr/2015/02/go-gui.html 을 합치는 프로그램을 만드는 것이됩니다. 원래 계획으로는 framework으로 만들어 볼 생각이 있었는데 생각보다 framework과 custom logic의 분리가 까다로운 관계로 그냥 server와 client의 예제가 되었습니다. 코드는 새로 작성된 것이지만 전체 적인 구조와 작동은 goguelike와 거의 같은 형태입니다. ( 적당히 단순화 되긴 했지만 ) 예제가 하는 일은 ( logic을 가능한 단순한것으로 선택했습니다.

이미 두곳을 통해서 부분부분은 소개 했었지만 http://kasw.blogspot.kr/2015/02/go-goroutine.html http://kasw.blogspot.kr/2015/02/goguelike.html 기존 netspeed 테스트 프로그램과 goguelike에서 사용하고 있던 tcp server/client 구조를 본격적으로 재사용 가능하게 수정한 것입니다. ( 그래봐야 간단합니다. ^^) tcp책에 나오는 전형적인 tcp server의 구조는 대부분의 언어에서 새 process / thread를 실행하는 비용이 너무나도 큰 관계로 이론적으로 설명하는 용도로만 사용하고 실제 서비스를 만드는 데에는 사용할수 없습니다. 다만 go언어에서는 go routine이 존재 하기때문에 이 “전형적"인 구조가 실용가능하게 됩니다. ( 꼭 go 언어가 아니라도 python stackless, greenlet , 또는 이와 유사한 micro thread를 지원 하는 모든 언어에서 가능합니다만 이를 지원 하는 대중적 언어가 별로 없지요.

goguelike는 애초 목표가 필요한것은 찾아 쓰고 없으면 만들어 사용한다. 였고 필요한 기능은 다중 client를 지원하는 TCP server GUI client with mouse and keyboard input server info by web auto generated terrain server and client side AI 그외 system의 contents에 해당하는 부분들 정도였습니다. 대부분의 기능은 구현이 가능했는데 go 언어용 GUI 라이브러리 만은 잘 보이지 않더군요. 실제로 검색해 보면 대부분의 GUI 라이브러리들이 만들다 만것들이거나 아니면 더이상 관리되지 않는 것들, 시험삼아 만들어 본것들 이었습니다.

제목이 저모양ㅜㅜ 인 이유가 goguelike에서 재활용성이 좋아 보이는 라이브러리를 뽑아내고 있는데 딱 저 카테고리용(그리고 뭔가 예로는 쓰기 그저 그런 ) 라이브러리 들이라 그렇습니다. goguelike가 딱 이차원 tile기반 으로 만들어진것이라 가장 바닥을 구성하는 것들인데 기능으로 보면 꽤나 범용성이 있기에 공개/소개 합니다. 2d path finding https://github.com/kasworld/go-astar 이건 제가 만든건 아니고 다른 분이 만든것을 fork해서 살짝 추가해서 사용하고 있는 것입니다. 2차원을 다루기 위한 기본 자료구조인 좌표 처리용 2d vector (정수용) https://github.com/kasworld/ivector2d 영역을 다루기 위한 ( 역시 정수용) https://github.

go를 사용하다보면 처음에는 channel과 goroutine에 감동^^ 하고 나중에는 interface에 감탄하게 됩니다. C++ 에 pure abstract class 나 java의 interface를 접한 분들은 의외로 헛갈리기 좋은것이 이 go언어의 interface입니다. 실제로 go 프로그래밍을 하다보면 처음에는 C++ 에서 header로 분리 하듯이 interface를 정의한 패키지를 분리하게 되는 데 작업을 하다보면 약간 이상한 느낌이 들기 시작합니다. 여러 패키지에서 공유하기 위해 interface 파일을 만들었는데 나중에 확인해보면 처음에 쓰려고 만든 그 패키지 말고는 아무곳에서도 사용하지 않는다는 것을 알게 되지요.

TLDR python 에서 행복했던 분들은 Go를 C++/Java 에서 행복했던 분들은 Rust를 고민해 보는 것도 좋을 것으로 생각합니다. go에 대한 해외의 평가는 C++을 잡으려고 go를 만들었더니 python을 잡고 있다. 라고 하더군요. ^^ C++ 프로그래머는 go로 전향하는 경우가 적은데 python 프로그래머는 go로 전향하는 비율이 꽤 높답니다. 구글+ 에 올린 http://kasw.blogspot.kr/2015/02/goguelike.html “python에서 죽어라 고생해도 달성할수 없던 것을 너무 간단히 달성해서 허탈할뿐.. " 이란 멘트에 달린 Go가 좋은 가요? 란 (의미의) 질문에 아무생각없이 “추천할만 합니다.

goguelike의 webinfo 페이지를 보면 Stat total:4660/ 3.0/s lap:1/ 39.4/s 같은식의 실시간 통계를 볼수 있습니다. 이런식으로 어떤 행동의 총 횟수, 초당 일어난 시간(즉 평균) , 최근 횟수, 마지막 초당 횟수 등을 조사 기록하려면 꽤나 귀찮은 프로그래밍이 필요합니다. 그래서 제가 만들어 쓰는 것는 actionstat 패키지입니다. 사용 예는 https://github.com/kasworld/netspeed 의 서버 코드를 보면 됩니다만.. 간단히 적어보면 // init obj stat := actionstat.NewActionStat() // see stat log.Info("%v", stat) stat.UpdateLap() // update info stat.Inc() 같은 형태가 됩니다.

goguelike 작업을 하면서 만들어진 모듈들 중 범용성이 높은 모듈들을 정리해서 공개하는 작업을 시작합니다. 이미 기존의 글들을 통해 소개된 모듈들은 id 생성 :http://kasw.blogspot.kr/2015/01/go-serial-id.html rand : http://kasw.blogspot.kr/2015/02/go.html runstep : http://kasw.blogspot.kr/2015/02/goroutine.html 이 있습니다. - 각각의 글을 수정해서 github 링크를 추가해 두었습니다. 이번에 소개할 모듈은 pyhon log처럼 사용하는 log package입니다. log 용으로 만든 것으로 rand 때와 같이 기존 go 언어의 표준 라이브러리를 확장하는 개념으로 만든것 입니다. 만든 이유는 아무래도 python을 쓴 기간이 길다보니 python 스타일의 로그 함수가 익숙한 관계로 최대한 비슷한 느낌으로 사용할수 있게 만들어 사용 중입니다.

일단 python에서 네트웍 속도로 이것 저것 해본 글들 http://kasw.blogspot.kr/search/label/wxgame goguelike를 튜닝하던 중에 네트웍 패킷 처리량이 얼마나 되나 하고 테스트 해보니 20000 packet/sec 정도 밖에 안나와서 충격을 먹고 네트웍 부분을 집중적으로 검사및 튜닝을 한 이야기.. 결론만 말하면 go 언어의 능력이면 1000 클라이언트 ( 10000클라이언트 에서도 속도 저하는 10% 이하) 에서 150000 패킷 / 초 정도를 처리 할 수 있습니다. 파이썬에선 정말로 최후까지 쥐어 짜야 60000넘기는 것도 힘들었던것에 비하면 깨끗한 구조를 유지하면서도 2.

2015-02-24 추가 구글+ Jae-min Park 님께서 제가 잘못알고 있던부분을 알려주셨습니다. sync 의 waitgroup은 goroutine의 종료를 wait하는 것이 아니고 Done을 wait하는 것이므로 충분히 아래의 코드를 대치하는 것이 가능한 듯합니다. ( 결국 아래 코드는 뻘짓인 셈입니다. ^^;; ) Jae-min Park, Jongmin Kim 께 감사드립니다. RunStep 과 sync.groupwait의 차이는 실행/완료시 인자를 전달 할수 있느냐 + 각각 step을 제어 할것이냐 아니면 group으로 제어 할것이냐 의 차이가 있어 용도에 맞게 쓰면 될것 같기도 합니다. 이하 원문입니다.

python도 그렇지만 go언어도 기본적으로 profiler를 제공합니다만, 정작 쓰려면 약간 귀찮은 관계로 제가 만들어 두고 거의 cut/paste 해서 사용하는 방법입니다. 아래 코드는 간단한 프로그램을 짤때 복사해 쓰는 파일의 내용입니다. 뭔가 파일 하나 짜리 프로그램을 짜서 테스트 할때 사용하곤 합니다. 이 자체로도 실행가능한 형태이며 그냥 실행하면 프로파일링이 실행되진 않고 더 아래에 있는 쉘 스크립트를 사용하거나 인자로 -pfilename을 주면 됩니다. 실행이 끝나면 자동으로 프로파일러가 실행되어 command를 기다리는 형태가 됩니다. 간단하게 프로파일 결과를 보고 싶으면 top30 같은 형태로 top + 수자 ( 빈칸 없이) 를 실행하면 됩니다.

goguelike용 loadtester를 만들면서 사용하는 방법입니다. loadtester는 일정시간동안 서버에 클라이언트로 접속해서 부하를 주는 프로그램으로 부하를 주는 시간과 동시에 몇개의 connection을 사용할것인지를 인자로 받습니다. 서버 입장에서는 하나 하나가 실제 user처럼 보이게 되는 것이 중요하고, 따라서 loadtester는 UI가 없는 dummy client와 client side AI를 사용하게 됩니다. 그리고 또 중요한 것이 부하를 거는 시간 내내 접속을 유지 하는 것이 아니라 각 dummy client를 무작위 시간동안 작동한후 connection을 종료 합니다. 그러면 loadtester는 이를 감지한후 새 dummy client를 실행 접속해야 합니다.

이것 역시 대단한 팁이라긴 뭐합니다만 “작업하다 보니 이런 형태의 코드를 많이 짜고 있더라” 입니다. 주로 나오는 형태는 array/slice 들의 내용에서 조건에 맞는 뭔가를 찾아야 하는 경우에 쓰게 되더군요. 그중에 제일 짧은 코드를 예로 보면 //start var Dir2Info = []struct { Name string Vt [2]int Len float64 }{ Dir_stop: {".", [2]int{0, 0}, 0.0}, Dir_n: {"N", [2]int{0, -1}, 1.0}, Dir_ne: {"NE", [2]int{1, -1}, 1.4}, Dir_e: {"E", [2]int{1, 0}, 1.0}, Dir_se: {"SE", [2]int{1, 1}, 1.

너무 간단해서 적기도 뭐한 팁이지만 가끔씩 표준 라이브러리가 제공하는 struct( class 가 아니지요 ^^) 를 확장해서 내가 필요한 함수들을 추가 하고 싶을때가 있습니다. goguelike 에선 표준 분포에 따른 랜덤 함수를 상당히 많이 사용하는데 표준 라이브러리는 기초적인 함수만을 제공하여 더 쓰기 편한 형태의 함수를 추가해서 사용하고 있습니다. 기본적으로는 go 언어의 embedded field를 사용하는 것이고 이것을 통해서 embedded된 struct가 제공하는 함수들이외에도 원하는 함수를 추가해 사용할수 있습니다. //start package rand import ( r "math/rand" "time" ) type Rand struct { *r.

1. struct embedding 한 경우 embeded struct에 exported filed 가 없으면 embeding한 struct를 gob encode를 할수 없다. ( type xxx has no exported fields 에러가남 ) 간단한 해결책은 dummy exported field를 추가 하는 것이다. ( 좀 보기 싫긴 하지만 ) type AAA BBB 형태로 정의한 경우 AAA 형 변수와 BBB 형 변수는 대입조차 안되지만 ( 에러가 남 ) 함수 인자로는 사용할수 있다. 즉 AAA를 받는 함수에 BBB 형 변수를 인자로 사용 할수 있다.

package id var genCh chan int64 func init() { genCh = make(chan int64) go func() { var i int64 for { i++ genCh <- i } }() } func GenCh() <-chan int64 { return genCh } 과 같이 쓰면 goroutine safe 한 id 생성기를 사용할수 있습니다. 실제 위 코드는 goguelike 의 id module의 일부 코드이기도 합니다. 사용할때는 objid := <-id.GenCh() 과 같은 형태를 사용하면 됩니다. genCh 변수를 글로벌 변수 GenCh로 선언하지 않고 로컬 변수로 선언 한것은 다른 모듈에서 수정할 가능성을 막기 위해서 이며,

go 언어는 테스팅을 위한 전용 패키지 testing을 가지고 있어 아주 유용하게 사용할수 있습니다. 다만 이를 사용할때는 source code의 naming rule을 따라야 하는데 테스트할소스코드이름_test.go 형태를 지켜야 합니다. 이를 지키지 않으면 flag 패키지를 사용해서 command line argument를 받는 프로그램 작성시 -? 등으로 command line help를 보게 되면 -test.bench="": regular expression to select benchmarks to run -test.benchmem=false: print memory allocations for benchmarks -test.benchtime=1s: approximate run time for each benchmark -test.blockprofile="": write a goroutine blocking profile to the named file after execution -test.

딱히 외적으로 변화한 부분이 없는 관계로 포스팅이 뜸했습니다만.. 내부적으로는 격변이라고 할 만큼의 수정이 있었습니다. ( 거의 모든 코드가 수정된 듯. ) 기본적으로는 기존의 코드를 모두 refactoring해서 30여개의 모듈로 분리하는 작업이 완료 되었습니다. 그리고 client AI 를 위한 a-star 모듈과 이를 사용한 client AI 작업이 진행되었고 또 이를 이용한 loadtester 역시 만들었습니다. 클라이언트 쪽 변경사항이라면 서버와 같이 모듈화 작업이 진행되면서 다양한 형태의 클라이언트를 만들기 위한 clientbase 모듈을 만들고 이를 sdlclient 와 loadtester에 적욯하였습니다.

asm.js를 보다가 갑자기 궁금해져서 기록삼아 적는 포스트 google 의 chrome/V8 에 이어서 mozilla 가 야심차게 밀고 있는 http://asmjs.org/ : http://ejohn.org/blog/asmjs-javascript-compile-target/ 와 이를 활용하는 http://kripken.github.io/emscripten-site/ 등이 나오고 있는 와중에 요즘 주로 작업하고 있는 golang도 이 대세에 동참할수 있을까 하고 찾아본 기록들 . 더이상 개발이 진행되고 있지 않은 https://github.com/kless/go2js emscripten 은 llvm 을 asm.js로 변환 하는 프로젝트이니 go 를 llvm으로 변환 하는 ( Go -> LLVM -> Emscripten -> asm.js ) https://github.com/axw/llgo

지난 주 부터 작업해오고 있던 맵 에디터가 일단 작동하는 수준 까지 만들어 졌습니다. 에디터에는 여러가지 gui component 가 필요해서 무엇을 사용할까 계속 고민 하고 있었습니다만, 아무리 찾아보고 고민해봐도 클라이언트 라이브러리가 적당한 것이 없어서 결국 웹으로 만들어 보기로 결정하는 데 까지도 꽤 오래 걸렸습니다. 에디터가 아닌 클라이언트는 sdl 기반 라이브러리를 사용하였는데 이 것은 그야말로 간단한 그래픽 기능만 있는 것으로 각종 gui control을 지원 하지 않습니다. 게다가 이 sdl 라이브러리는 go의 goroutine 사용에도 여러 제약이 있는 관계로 서버 기능을 사용해야 하는 에디터용으로는 부적합하더군요.

(제목은 반이상 낚시성 ) 블로그에 쓰기는 좀 정리가 덜된 글이라 페북에 끄적끄적 하려다 길어 질것 같아 블로그로 작업. ^^ ( 그래서 반말 투입니다. ) golang의 매력에 푸~~욱 빠져서 조강지처 python을 버리고(?) golang으로만 작업을 하고 있는 중에 web작업을 할일이 생겨 golang용 web framework을 찾아보다 생각난 것들.. python에서는 django 가 대규모 작업 시장에서 절대 강자의 위치를 차지하고 있는중에 ( 대항마이었던 turbogear를 귀도가 죽여 버려서) flask가 호시탐탐 기회를 노리고 있고 web2py라고 하는 걸출한 all-in-one이 신규 개발자를 노리고 있는 상황이었다면 .

지난주 이번주 동안 기본적인 서버/클라이언트의 안정화가 이루어져서 성능테스트를 해가면서 튜닝을 하고 있는 중입니다. 방금 끝낸 테스트를 기록차원에서 적어보면 사용 기계 cpu i2500 ( 4c4t ) , ram 16Gbyte에서 서버는 각 클라이언트당 5패킷 / 초 모드로 작동중이고 5000 클라이언트 시뮬레이터를 다른 기계에서 실행한 결과 입니다. goguelike 13:41:44 server.go:169: tower test1 frame total:3801/ 4.0/s lap:5/ 4.8/s, gotoutine 5025 goguelike 13:41:44 server.go:173: floor0 AO(72/2232) PO(42/561) Packet(0/1157) goguelike 13:41:44 server.go:173: floor1 AO(69/2401) PO(42/630) Packet(5/2024) goguelike 13:41:44 server.

동영상으로 보면 색감도 이상하고 해서 스샷을 올려봅니다. 상태 정보를 간단하게 설명하면 맨 위로부터 현재 타워의 이름 , 층(floor) 번호, 층 종류 사용자의 faction(자동으로 지정된 bias 그룹) , karma ( 자신의 bias와 faction간의 차이 ) action point( 행동력 ), hp ( 생명력 ) , 위치 , 현위치의 타일 종류 수동/자동 모드 , 사용자가 선택한 행동 + 방향 현재 층을 얼마나 발견 했는가 % , 죽은 수 , 킬 수 공격력( bias ) , 방어력 ( bias ) 8개 위치의 장비 및 공/방 영향 ( Attack/Defence ) 위칭으로 가는 계단 위치 ( 발견시 표시 ) , 아랫층으로 가는 계단위치 (발견시 표시 ) hp bar , 미니맵 , ap bar ( hp/ap는 중요한 값이라 잘보이게 bar로 표시 )

reference 구현이라고는 해도 보기 좋고 쓰기 좋아야 한다고 생각해서 손을 대고 있는데 생각보다 손볼곳도 많고 시간도 꽤 들어가고 있습니다. 일단 grid를 추가하고 이전에 시야에 들어 왔던 부분은 현재 시야에서 안보이더라도 화면에 약간 어둡게 표시하도록 수정했는데 이것 만으로도 많이 좋아 보이게 되더군요. ^^

이런 저런 시도후에 제일 보기 좋은 형태를 찾았습니다. 화면 표시와는 별개로 아직 조작감은 좀 떨어지는 문제가 있지만 일단 이런 형태로 개선해 나갈 생각입니다.

그리고 추가로 클라이언트의 움직임을 부드럽게 만드는 시도를 하고 있는 중인데 꽤 까다롭습니다. 일단 모든 좌표는 타일단위의 좌표인데 이것을 그대로 적용하면 이동이 뚝뚝 끊어지듯 이루어져서 계속 보고 있으면 멀미가 나더군요. 그래서 일단 여러가지로 보정해서 부드럽게 타일간을 미끄러지도록 하는 시도를 하고 있습니다. 그리고 전체 시야의 이동도 타일단위가 아닌 중간 보간을 통한 스크롤을 하도록 해봤습니다. 그래도 예상한 쪽이 아닌 다른 방항으로 이동하는 경우 끊기는 움직임이 보이는 것은 어쩔수 없군요. C/S 완전 분리는 이번이 처음 해보는 것도 아니고 처음 설계시 부터 준비하고 있던 것이라 예상보다 일찍 수일 만에 완료 되었습니다.

13일 동영상 15일 동영상 일단 karma 가 추가 되었고 , 장착 가능한 아이템들(그림은 아직 없지만) 그리고 ai 끼리의 전투가 추가 되었습니다. 기본적으로 상대방이 system ai인지 사람인지 구별을 하지 않는(못하는) 시스템으로 계획하고 있기에 사람끼리의 전투도 같은 형태입니다. 지금은 테스트 용이라 frame이 좀 빠릅니다만 실제 사용자가 control 하려면 속도를 좀 낮춰야 할것 같습니다. 동영상에서 오른쪽에 나오는 글 정보를 참고하시면 도움이 될듯 합니다. 그리고 층간 이동시 효과가 없어서 효과를 추가했습니다.

보기만 해도 숨막히는 표준 - 미로 지형 입니다. AP에 따른 행동 제약 - @ 끼리의 진로 방해 가능 + faction-skill 준비까지 진행되었습니다. 추가로 ice-town 지형 동영상입니다. 지형에 따라 ap가 줄어들어 이동에 제약이 생기는 것을 볼수 있습니다.

표준 - 필드 타입 플로어 에서의 random walk 다른 윈도우로 맵을 보려니 불편해서 미니맵을 추가 했습니다. 그리고 동영상을 보시면 지형에 따라 이동속도가 다른 것을 보실수 있습니다. 준비하고 있는 플로어 타입은 도시, 마을, 필드 , 미로 표준, 불, 물 , 얼음, 땅, 공백 타입입니다. 조합해서 24 가지 파라메터를 기본으로 지형을 생성합니다.

가제 goguelike - adventure of @ 의 스샷입니다. 추가된 미니? 맵 창을 통해서 집내부를 보는 상황 + 불 지형에서 가시거리가 제한 되는 상황 20개의 faction ( 동일 성향 집단 )을 만들었고, 그 faction에 따라 타 active object(user) 과의 관계가 형성되며 , passive object에도 faction을 부여하여 강화 또는 방해 효과를 줄수 있도록 했습니다. 동영상 ( 좀 깁니다. ) 과 동영상 촬영시 만들어진 미니맵

^^;; 일단은 nethack 과 classic ultima 사이의 어딘가 가 될것 같습니다. 자동 생성 지형 + 방(집?) + 방을 연결하는 길 + 테라스 불,마그마,땅,물,얼음,(높은)돌벽, 창문(낮은 벽), 돌길, 열린문, 닫힌문, 잠긴 문 땅에 떨어져 있는 아이템, 돌아다니는 user . 사방으로 무한 반복되는 floor 여러 플로어로 이루어진 tower (들) 정도의 구성 요소를 가질 계획 입니다. 만들어질 서비스의 종류는 Role Playing Simulator. 줄여서 RPS ^^ 또는 (+system을 해서 ) RPSS 제작자의 특성상 Game이라기 보단 로그인 해서 사용하는( use , not play) simulator 가 될것 같습니다.

클라이언트 프로토타입 랜덤워크 지형 생성 기반 데이터 시각화 생성된 지형 ( 표준 도시형 ) 궁금해 하시는 분도 있는 것 같아서 올려 봅니다. 기본 적으로 online server - client , 턴제 , tile 기반의 floor, 자동 생성 지형등을 특징으로 하는 것일 예정입니다. 아직 클라이언트 그래픽이 없는 관계로 위와 같은 모양입니다.

설명: ai3의 회피 알고리즘 테스트 동영상 - 글내용과 무관함 ^^ 기존 wxgame2에서 부터 충돌 검사와 AI 를 의해 사용해 오던 준 동적 공간분할 대신 나름 정통 공간 분할인 octree로 바꿨습니다. 기존에는 공간을 매 프레임 마다 총 object의 수에 비례하는 (축당 math.pow(ocount, 1/3)) 배열로 분할 해서 충돌 검사 및 AI에게 주변 환경정보를 제공하는데 사용해 왔습니다. 하지만 아무래도 약식이라 부족한 점이 많아서 공간 분할을 하는 몇가지 알고리즘 중에 일단 octree를 선택, 구현 해봤습니다.

github commit log로 부터 역으로 만들어낸 내용입니다. 설명: 실제 여러 월드가 동작하는 화면 설명: 월드내 팀의 자세한 상태 - 배경색이 team color 설명: 추가된 장식물, home object 최근 부터 역순으로 team 의 world 간 이동 기능 homepos to home object json config load / save log format 정리 장식물(decoration object)들 추가 collision 관련 성능, 구조 개선 object, team, world struct 간 상호 pointer 줄이기. 같은 기능이 추가 되었습니다. 코드상으로는 많은 변화가 있었지만 실제 외견(어차피 서버라 외견이랄게 없지만)상으로 변화한 것은 별로 없습니다.

설명: 여러개의 월드를 지원하는 요약 페이지 설명: 하나의 월드의 자세한 상태를 보여주는 페이지 게임의 규칙을 악용하는 것은 사람만 할 수 있는 것은 아닙니다. go4game처럼 단순한 규칙의 게임에서도 룰의 헛점을 찾아내서 그것을 활용하는 것이 가능합니다. AI를 만들다 보니 몇가지 고민스러운 것이 생겼는데 그 중 하나는 AI의 강함의 정도를 어떻게 정량화 할 것인가 하는 점입니다. 얼핏 생각하면 하나의 월드에 두개의 AI를 넣고 일정 시간후 승점(격추수) 가 높은 쪽이 강한 것이 아닌 가 생각 되지만 테스트를 하다보면 1:1 에 강한 AI 도 있고 , 다대 다 에 강한 AI 도 있으며 서로 상성이 있는 AI 가 있는 경우도 있습니다.

AI 만이 아니고 게임을 구성하기 위해선 게임의 룰도 정리되어야 하기에 적어봅니다. ( 아주 사무적인 문서라 말이 짧습니다. ^^;; _ 설명:업데이트된 게임 상태창. 설명:새로 추가된 AICloud의 동작모습 한개의 gameservice 에는 실제 team간 interactaction 이 발생하는 여러개의 World 가 존재 각각의 world에는 team들이 소속 team은 tcp client , websocket client , ai client 가 존재 world는 60 frame / sec 로 각 팀에게 frame action을 요청 각 팀의 frame action은 goroutine을 사용 concurrent 하게 진행.

설명 : go4game webgl client 플레이 동영상. 사진 설명 : 서버의 상태를 보여주는 페이지 ( 팀 이름 , AI 종류 , 팀 object 수 , 팀 점수, 팀 AP , 팀 패킷 통계 ) go4game도 이제 wxgame2 정도로 작업이 진행되어 여러 AI끼리 대전을 시키고 그 진행사항과 순위를 볼 수 있는 페이지를 만들었습니다. 위 와 같은 형태로 만들어서 여러 형태의 AI를 만들고 AI끼리 대전을 시키면서 개선을 해나 가고 있는데 이전 wxgame2 작업할 때도 썼지만 AI를 개량해서 그 AI가 이전에 만든 것보다 좋도록 만드는 것은 참 생각대로 안됩니다.

사진 설명 : 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년 글입니다.

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

오랫만에 다시 go 이야깁니다. 오랬만에 기억을 되살리기 위해 이런 저런 이야기를 잠깐 해보면 go 언어의 특징중 가장 두드러지는 것을 하나 들면 goroutine을 들 수 있을 텐데요. 많은 서버와 대용량의 데이터(소위 big data)를 처리 하고 있는 구글은 이를 위해서 여러 언어를 사용하고 있다고 알려져 있습니다. 하지만 각각의 언어들은 장단점이 있는 관계로 구미에 딱 맞는 언어가 필요하여 go 언어를 만들었다는 게 사람들의 짐작 입니다. 그래서 go 언어에는 구글이 가장 필요로 하는 goroutine 과 channel 이 기본으로 존재합니다.

서브라임 에디터로 go 개발을 하기 위해 필요한 패키지를 찾아보면 바로 보이는 것이 go build 패키지라서 일단 설치는 해두었습니다. 이번 주말에 집에서 오랫 만에 go 코드를 만질 일이 있어서 ( 실은 요즘 매일 python 만 하고 있어서 go 도 좀 해두려고.. ) 서브라임에서 전에 만들어둔 go 소스를 열고 작업을 시작했습니다. 이왕 하는 김에 제대로 환경을 세팅하려고 프로젝트도 만들고 빌드를 했는데 아무 반응이 없습니다. 물론 터미널을 열고 빌드하면 당연히 잘 되고 .. 에디터 내의 빌드 명령인 <ctrl-b> 로 빌드를 시도하면 아무 반응이 없는 겁니다.

금방 끝날줄 알았는데 남은것이 많더군요. 이제부터는 좀 두서없는 내용이 이어집니다. reflection package 를 사용해서 func TypeOf(i interface{}) Type func ValueOf(i interface{}) Value 를 사용할수 있습니다. 이런게 얻어진 Value object에 대해서 struct object 였다면 Method( 2 ).Call( some args ) 형태로 실행을 시킬수도 있습니다. os.Stdin : 표준 입력입니다. os.Open 을 사용해서 파일을 열수 있습니다. io/ioutil 패키지에 ReadFile 을 사용하면 파일을 한번에 읽고, WriteFile로 한번에 씁니다. fmt.Fscanln을 사용하면 space separated file 을 편하게 읽을수 있습니다.

그 세번째 입니다. 이전글은 http://kasw.blogspot.com/2012/09/go-2n.html Interface Interface는 object의 behavior 를 규정한다. ( 수행 가능한 method 들의 signature 를 정의한다. ) type InterfaceNamer interface { Method1( params ) returns Method2( params ) returns } 관용적으로 er로 끝나는 이름을 사용한다. ( Printer, Reader, Logger 등등 ) 가능한 짦게 만든다 ( primitive 하게 만든다 ) var interfaceReference InterFaceNamer = someObject struct를 정의할때 어떤 interface를 구현하는지 지정할 필요가 없다. interface에 정의된 method가 구현되어 있다면 자동으로 사용가능하다.

그 두번째 입니다. ( 총 몇회가 될지 모르니 2/N 입니다. ^^ ) 첫 글은 http://kasw.blogspot.com/2012/09/go.html 를 보시면 됩니다. Maps key 로 사용 가능한 것은 == , != 이 정의 된 type string,int,float 는 가능 array,slice,struct 는 불가능 pointer, interface 는 가능 struct 를 key로 쓰고 싶으면 Key() 나 Hash() method 를 만들고 그 결과를 키로 사용할것. value 는 아무거나 사용 가능 var map1 map[keytype]valuetype = make( map[keytype]valuetype , capacity ) map1 := map[keytype]valuetype{} map is reference type len(map1) map1[notInMapKey] is zero-value of value type not error val1,isPresent = map1[key1] 형태로 존재하는지 확인 가능 delete(map1, key1) 로 항목을 삭제 가능하면 없는 항목이어도 에러는 없다.

다음 프로젝트에 go 언어를 쓸 생각이어서 공부하는 김에 몇가지 중요 포인트들을 메모 하고 있습니다. 원래는 다 끝나면 한꺼번에 블로그에 올리려고 했는데 적다보니 양이 많아져서 일단 앞부분만 먼저 정리합니다. 주의 할 것은 제가 보기 위해 적은 것이라 기본적으로 C/C++/java/C# 에대한 지식과 추가로 python 같은 스크립트언어도 안다고 가정한 상태에서 적은 것입니다. 게다가 go 언어의 구체적인 syntax 에 대해서도 http://golang.org/ref/spec 같은 곳에서 한번 정도 읽어 봤다고 가정합니다. ( 조건이 너무 까다롭군요. ;; )

세월이 하수상하지만 ( 정치건 it 판이건 ) 곰곰히 생각해보니 python을 실무에 적용해서 써 온지도 어느덧 10000시간이 넘어간듯 합니다. 얼마전 아는 후배가 첫 8bit kid들이 아직 프로그래밍을 하고 있으면 대충 30년이 되었다고 하는글을 올렸는데 그 글을 보면서 만감이 교차 하더군요. 정말로 30년이 된겁니다. ㅠㅠ 살아온 시간의 3/4 이상을 컴퓨터와 함께 지낸거지요. 그래서 생각해본 언어별 투자? 시간입니다. ( 중복 시간이 있으니 총합은 30년이 넘을수 있습니다 ) basic ( apple soft ) : 5년 Assembly : ( 6502 ) : 3년 ?

구글에서 만든 언어랩니다. ^^ http://golang.org/ 구글정도되면 이미 충분한 파워와 실력이 있으니 궁금해서 조금(^^) 공부해 봤습니다. 블럭으로 {}를 써서 마치 C/C++/java/C# 유사품 처럼 보이지만 ^^ 내용은 pascal/modula 2의 후계자에 더 가까운듯 합니다. coroutine의 강화(?)판인 goroutine이 있는것도 재미있고, 컴파일이 빠르다고 주장(표준 라이브러리를 풀빌드하는데 10초가 안걸립니다.)하는것도 turbo pascal 생각이 나구 말이죠. 덤으로 대입 연산이 := 입니다. ㅋㅋㅋ native binary를 만들면서 garbage collection이 되는 점은 D language가 생각 나기도 하고 말이죠. ^^ 무어보다 맘에 드는건 생성된 바이너리의 속도가 C의 80~90%속도가 난다는 점입니다.