2011년 2월 27일 일요일

easing animation in Corona SDK

easing library를 통해서 함수형 언어의 특징을 잘 흉내내었다.

http://developer.anscamobile.com/content/animation


Manual animation Using transition
local rect = display.newRect(
  0, 0, 100, 100 )
rect:setFillColor(255,255,255)
 
local tMax =1000+system.getTimer()
local function fadeOut(event)
  local t = event.time
  local rect = event.target
  if t < tMax then
    rect.alpha = 1 - t/tMax
  else
    rect.alpha = 0
    -- done, so remove listener
    Runtime:removeEventListener(
         "enterFrame", fadeOut )
  end
end
 
-- Add listener to begin animation
Runtime:addEventListener(
   "enterFrame", fadeOut )
local rect = display.newRect(
  0, 0, 100, 100 )
rect:setFillColor(255,255,255)
 
transition.to(
  rect, {time=1000, alpha=0})


현재의 상태과 이전될 상태간의 interpolation을 easy library가 알아서 해주는 것이다. interrupt가 낄 수 있을 경우에는 cancel을 할 수 있다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Responsibility #2 : Estimation of Schedules

CTO가 할일 이전에 TD가 할일을 더 이야기 하고자 한다.



TD가 할 일중에 하나는, 기획의 요구사항을 듣고,그것을 'make it done'하기 위해서,

계획을 잡는 일일 것이다.



우선순위는 기획의 요구사항을 따르되,

개발의 우선순위는 다를 수 있다.

왜냐하면, 업무를 분해(decomposition)하다보면, dependent task들을 미리 해 놓아야 하기 때문이다.

그런 일들에는 library 구축, tool 구축, framework 구축등이 포함될 수 있다.

아무리 TDD에 Agile한 환경이 효율적이라고 하지만, 먼저 해야 할일은 먼저 해야 할 일인 것이다.

이렇게 일을 늘여놓다보면, 목표 시간에 일정을 소화할 수 없게 된다.

여기서, 그러한 dependent task를 살펴보면, 그 TD의 성향을 파악할 수 있다.

1) 고집스럽게 선수 과제를 먼저 하는 사람

2) 선수 과제를 무시하고, 스케쥴을 밀어부치는 사람

3) 기획을 수정하여 일을 줄이는 사람

4) 기획의 의도를 파악하고 일을 줄이는 사람 

5) 필수 선수 과제를 최소화하여, 스케쥴을 다시 잡는 사람



6) 선수 과제를 부분적으로 외부에 의존하거나, 도입하는 사람

7) 100중에 70~80 정도를 소화하는 프레임워크 전체를 도입하는 사람





어떤 TD가 가장 유능한 사람일까?



1번의 경우, 매우 위험하다. 미션이 실패하면, 책임을 피할 수 없다. 하지만 성공할 경우에, 이후 달콤한 개발 속도가 약속될 수 있다. 그러나, 개발팀이 할 수 있는 능력이 될 경우에 할 수 있는 방법이라고 생각한다. 그렇지 않으면, 개발팀은 잦은 야근으로 조기에 지쳐버릴 수 있다. 오만과 교만의 댓가를 받게 될 수 있다.

2번의 경우, 어떻게든 되겠지 하는 경우이다.

하나님이 편들어지시지 않는한 매우 피곤한 여정이 기다리고 있을 것이다. 결과물이 잘 나오긴 하지만, 역시 개발팀의 수많은 삽질의 결과였을 가능성이 매우 높다. 이렇게 할 것이라면, TD가 왜 필요할까?

3번의 경우, 기획에 리스크를 떠 넘기는 경우이다.

기획자는 선택의 폭이 좁아진다. "해보고 안되면 내리지." 하는 방법을 쓸 수 없다. 유능한 기획자가 없는 한 매우 위험한 방법이다.

4번의 경우, 기획자와 긴밀한 유대관계가 필수이다.

게다가 기획 내용에 대한 파악 능력이 필요하다. 기획 의도를 지키면서, 개발 시간을 단축할 수만 있다면, 얼마나 좋겠는가? 하지만, 기획자는 다시 기획을 해야 할 것이다. 또한, 자칫 밋밋한 개발이 되어 소비자에게 어필할 수 없게 될 수 있다.

5,6,7번의 경우 어떻게 하느냐에 따라서 다르겠지만,

그 방향은 현재의 개발팀의 역량과 자신의 역량에 비추어 잘 선택하여야 할 것이다.

나는 5,6,7번을 모두 선택하는 편이다. 7번을 선택할 수 있는 상황은 게임개발에서는 많지 않다. 그리고 있다해도 50~60% 정도 커버하는 수준일 것이다. 그래도, 웹 개발에서는 많은 편이다. 다른 프레임워크를 선택하게 되면, 교육 기간과 적응기간이 꼭 필요할 것이다.



5,6,7번을 할 경우, 리스케쥴링은 다음과 같은 방법으로 해야 할 것이다.

처음에는 Goal Driven으로 Top-Down식으로 일을 분해하면서 일정을 만들었을 것이다.

이제는 Objective Due Day 를 기준으로 Task의 일정을 봐야 한다.

그렇게 되면, 첫 일정이 아마도 과거로 되어 있을 것이다.;;;;

과거에 했어야 할 일들을 어떻게 테스트가 된 상태로 프로젝트에 도입할까?

부분 부분 오픈소소를 이용하고, 과거에 했던 일들에서 가져오고, 어떤 것들을 나중에 하기로 하고 포기하고....

그래도 안되면 그때서야 기획자와 협의를 해야 할 것이다.

그래도 안되면, 야근을 할 수 밖에 없을 것이다. 외주를 줘서라도 일정을 소화시켜야 할 것이다.

이러한 상황이 팀내외에서 공유되는 것이 바람직하다. 리스크에 대해서 모두 알고 있는 편이 문제 해결에 도움이 된다.

2011년 2월 26일 토요일

Corona as 2D mobile engine

cocos2D로 개발을 하려다가 보니, class들이 낯익지 않고, tutorial도 쉽지 않았다.(난 마음이 급한데!)
게다가, multi-platform 으로 deployment를 하려면, cocos2Dx로 개발해야 하는 등, 까다로왔다.
이럴바엔, 간단한 2D엔진을 만들어서, script로 로직(haskell로 할까? 응?)을 만들고, VM만 달리도는 엔진이 있으면 좋겠다 생각했다.
그런데, 검색해보니, corona가 내 생각과 맞아 떨어졌다.




http://www.anscamobile.com/corona/

http://www.burtonsmediagroup.com/blog/2010/06/game-engines-for-iphone-ipad-android-cocos2d-corona-torque-unity-3d/

그리고, 이 링크의 의견에 완전히 공감했다.


1) Easy Deployment/Development : cross-platform에서 가장 중요한 것은 이식성이라고 생각한다. lua로 코딩을 한 후, 다른 플랫폼으로 바로 거의 수정없이 이식이 가능하므로, 가장 편한 엔진으로 생각된다.tutorial도 친절하고, 예제도 풍부하다.
2) API : 지원하는 API들도 다양하다!
3) 툴: texture packer,sprite editor(spritedeck)등 3rd party 툴도 다양하게 지원되고,
4) 안정성:16만개 이상 팔린 게임에서도 쓰였다.

다만, 유료라는 것.(Free Trial이 있다.)
소스를 제공하지 않는 듯 보이니, 만들 게임내에서 지원하는 API 로 가능할지 잘 봐야 함. 다행히, 안정성은 확보된 것으로 보인다. (소스 판매는 contact 를 통해서 가능하다.)
소스가 제공되는 엔진을 고른다면, cocos2D(x)정도인데, corona에 비해서 기능이 미약하고, 구조가 특이한 편이라서 추천하지 않는다. 앞으로 경쟁할 듯 보인다. cocos2d가 경쟁해서 이기려면,built-in 기능뿐 아니라, lua지원과, tool 지원이 필요해 보인다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 21일 월요일

OCaml,SML

OCaml이 다른 함수형 언어에 비해서 빠른 것으로 알려져 있다.
Language Shootout 결과들을 보면...
하지만, OCaml은 functional way로 코드하는 것이 강제가 아니기 때문에 그렇다.
functional way로 코드하면 결과가 많이 다르게 나온다고 한다.
(직접 확인은 못했지만...;;)

SML은 비록 아직 멀티코어로 구현이 안된 상태이지만, 함수형 언어중에서 가장 빠른 성능을 자랑한다고 한다.(역시 직접 확인을 못했다.;;;)
그리고, SML은 Parallel과 Concurrency에 대해서 아직 진행형인 상태이다.


결론적으로, 함수형 언어를 선택한다면, Haskell과 Erlang 중에 선택하는 수 밖에 없다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Photon Socket Server

http://photon.exitgames.com/Photon

iphone뿐만 아니라 다양한 클라이언트에서 돌릴 수 있도록 network library를 제공한다.
특히, unity3d에서도 된다.
게다가, cloud 환경까지 제공하여, deploy를 쉽게 하였다. 이것이 수익모델인 듯!
일본회사들에서 많이 쓰고 있다.

이 정도의 솔루션으로 돈 벌 수 있는게 놀랍다.
한달 정도 시간만 들이면 만들 수 있을텐데... ㅎㅎ

Yesod Web Framework in Haskell

http://docs.yesodweb.com/

Rails와 같은 식으로 프로그래밍하는 것이 요즘 대세이다.
그래서 그런지, 프레임웍들도 Rails식으로 따라 하고 있다.

Haskell문법 역시 간결하다!  semi-colon(;) 없는 코드를 보니 마음이 시원할 정도;;;


소개 비디오를 보면 정말 놀랍다.


Yesod Screencast: Yammer from Michael Snoyman on Vimeo.

core팀 3명으로 짧은 기간에 해낸 것도 놀랍다.

하루 빨리, Haskell이 hot-code swap이랑, process간 통신, distributed 환경을 위한 feature들이 추가되면 좋겠다.
당장은, Haskell도 단일한 독립 사이트 만들기에는 부족함이 없어보인다.
Ruby on Rails보다 성능은 물론이고, 생산성에서 앞지르는 것은 시간 문제로 보인다.

Erlang은 대규모 서비스용이다보니,
Agile Development에 맞는 framework가 나오지 않는 것이 안타깝다.
(내가 할까? ㅎ)
그것만 맞춰준다면, 인기를 얻었을때, 다시 아키텍쳐를 잡지 않아도 될텐데 말이다.
mochi-web등이 잘 해주길 응원한다.


도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

3D objects

I think game programming needs to deal with only game objects.



In order to do that, the preparing step is needed.

Prior to code, there should be prepared game objects composed of 3D meshes,3D animations,3D geometry,material settings,and blabla... There are many things to do.



Conceptually, what are the essential components of game objects?

The components should be Mutually Exclusive and Collectively Exhaustive.



This discriminations should take some time.

If you have 10 years, what shall you do?

쓸만한 프로젝트들은 적어도 10년이상 성숙과정을 거쳐서
대중들에게 인정/인기를 얻는 것 같다.

이 기간을 짧게 만드는 방법을 연구해야한다.
시간은 짧고 예술은 길다.
많은 예술 작품을 만들고 싶으니까...

새로 시작한 프로젝트가
3년내에 대중에게 인정받고,
오픈소스 또는 커머셜로 될 수 있는 방법을 연구해보자.

2011년 2월 20일 일요일

rotation in jMonkey

http://jmonkeyengine.org/wiki/doku.php/rotate

어떤 그래픽스책보다 아주 쉽게 설명되어 있다.

Rotation around Axis? Use this Axis Vector! Examples for this kind of rotation
X axis (1,0,0) A plane pitches. Nodding your head.
Y axis (0,1,0) A plane yaws. A vehicle turns. Shaking your head.
Z axis (0,0,1) A plane rolls or banks. Cocking your head.




Nodding,Shaking,Cocking ^^
“pitch”, “yaw”, and “roll”

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Erlang use of the Year 2010

http://www.javalimit.com/

자바 숙련자인데, Erlang을 배우기 시작했다고 한다.
배우면서 Erjang(Erlang on JVM)을 만들었다.

2010년도 Erlang User로 뽑히신 분.
대단하신 분!


http://www.slideshare.net/drkrab/erjang-a-journey-into-erlangland


도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

OpenCL binding for Erlang and Haskell

cuda와 Erlang binding은 아직 나오지 않은 듯 하다.

대신 OpenCL과 Erlang binding은 나와있다.
https://github.com/tonyrog/cl


다음은 OpenCL Haskell binding이다.

http://hackage.haskell.org/package/OpenCLRaw



OpenCL에 대한 tutorial도 몇개 있다.
http://www.multicoreinfo.com/2009/08/parprog-part-9/

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

DSLs required for every type of workers - Part 1

I think haskell or erlang is one of the best programming languages for productivity and concurrency, and blabla.

However, in the real game developerment, there are various worker types such as art deirector, 3d modeller, 3D animator, 2D graphic designer, game director, game designer , game logic scripter, game logic script programmer, GUI programmer, animation programmer, special effect programmer, GPU programmer , DBA, system engineer and so on.



I want to focus on some parts.

 

First, lua-like language for game logic scripter.



Lua gained popularity for it simple syntax.

However, it is not easy for game designer or game logic scripter without preliminary programming knowledge or skills.

I want to add or focus on some design goals.



1. easier than Lua, as easy as HTML

2. edit and run in run-time.

3. syntax check or some tests in editing.

4. need not to be sick in object synchronization with peers or servers.



Second, jQuery(javascript)-like language for GUI programmer



GUI is important part in UX(user experience).

However, in many cases,GUI programming are in charge for novice programmers.

So, GUI programming needs to be more productive for novice programmers, or needs to be changed to charge GUI designer without programming skills.



1. GUI WYSWYG editor(probably visual programming?) in run-time2. rich built-in examples

3. extensible for advanced GUIs.



4. easier than javascript



5. edit and run in run-time



Third, declarative language NPC(non-playable-character) AI programmer



AI programming is also an important part.



1. Goal Oriented Design

2. as easy as HTML

3. rich built-in examples

4. edit and run in run-time

5. built-in AI technologies.



Fourth, intuitive and visual language for Special Effects, Animations.



1. Visual and Intuitive

2. rich examples

3. edit and run in run-time

4. supports GPU acceleration



Futhermore, all of these languages must be built in one VM.

Erlang in action

Erlang을 입문하기 위한 방법!

개발환경 셋업
1. erlware.org의 방법대로 셋업한다. erlang, faxien(erlang package manager),sinan(erlang build system)
2. emacs를 erlang-mode로 셋업한다.


다음 세가지를 읽는다.
1. Programming Erlang
2. Erlang in Action
3. Learn You Some Erlang for Great Good  http://learnyousomeerlang.com/

그리고, http://www.erlang.org/course/course.html 요 링크에서 간단한 설명들이 쉽게 이해가 가면 일단 Erlang에 대해서 이해가 된 것으로 봐야 할 듯 하다.

그리고, google에서 Erlang, Erlang Examples, Erlang Tutorials 들을 찾아보면서 익힌다.
C/C++,Java등으로 구현했던 자신의 프로그램들을 Erlang으로 차근차근 구현해 나간다.
Erlang 으로 구현한 대표적인 오픈소스들을 익힌다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

erlang with higher order function

http://learnyousomeerlang.com/higher-order-functions#get-functional


-module(hhfuns).
-compile(export_all).
one() -> 1.
two() -> 2.
add(X,Y) -> X() + Y()

> hhfuns:add(fun hhfuns:one/0, fun hhfuns:two/0).


fun function_name/arity를 붙여줘야만 one,two가 atom으로 해석되지 않고, 함수를 넘겨준 것으로 이해된다.

다른 방법은 없을까? 즉, one(),two()가 함수였다는 것을 알 수 있는 방법이 있어야 한다.

* type system이 있었다면? compile type때 미리 오류를 알 수 있었을 것이다.
 Erlang의 아쉬운 장면이다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 19일 토요일

Two Sides

There are two sides in Online Game Engine Architecture.

: a Server Side, and a Client Side.



The server side must fully make use of its determined service machine.

For example, you can serve your service via Intel Xeon Quad-core 2.33Ghz, 4GB RAM , 100GB HDD, high speed GPU and so on. you must fully make use of that machine thoroughly.



The client side must fully support various customer machines such as various version Windows , Macs, Linux , iPhones, androids, and so on.



Before you architect your engine, You must decide what platforms you target for.



In the server side,I decided to use Erlang VM for various platforms, and to use cuda for making use of GPU power.

Erlang has many fascinating features including hotcode swap, easy inter-process communication, and stable VM.



In the client side, I want to support an many platforms as I can do.

But, I don't or can't know all.

Therefore, I decided to study jMonkey Engine that is implemented in Java for desktop cross platforms , to study unity3D that is popular for smartphones, and to study Ogre3D(or promising 3D engines whatever it is commercial or opensource) that is implemented in C++ with many open source supports.

Then, I will implement a 3D engine and client-side game logic engine in Haskell.

Haskell is to easily make use of multi-cores, to produce codes rapidly and to focus on logics.

Furthermore, I must study Cuda or OpenCL to make use of enormous GPU power.

I wish Haskell could be sit in various desktop OSes, and smart phone OSes in the future.

2011년 2월 18일 금요일

mmo engines in Erlang


http://sunweaver.blogspot.com/

어떤 사람이 Erlang으로 MMO엔진을 만들고 있다.KVS(key-value store),KVS2 로 메모리 캐쉬를 쓴 것과 Simulation,Logic,Physics 를 분리한 면에 눈여겨 봐야 한다.
아쉽게도 오픈소스가 아니라서, 소스를 볼 수는 없다. 블로그를 보면, AI NPC를 만드는데, 많은 노력을 한 것처럼 보인다.
Goal에서 Erlang을 활용한 이유가 보인다.
"Once SMASH is finished you will be able to create a Massive Multiplayer Online Game (MMO), a messenger-, a dynamic webpage-, an IRC- or SMS-network or anything that requires sending messages across groups of users on different servers, while being completely independent of the platform, as long as Erlang compiles on the OS. SMASH can be upgraded in run-time without missing a beat"

즉,서버를 다운시키지 않고, 업그레이드가 가능하게 한다는 이야기이다.
그러나, 이것은 클라이언트에서도 dependency분리를 잘 해야지만, 동적으로 다운로드와 업그레이드가 가능할 것이다. 이러한 구조를 구현한 솔루션도 없지 않다. Hero Engine이 그 예이다.

그런데, Erlang을 선택한 이유가 그것만 되서는 안된다고 생각한다.
이른바 '서버군'으로 나누어지는 이유는 DB의 용량때문이다. 그 한계를 넘어야 한다.

또한, 만약 서비스가 인기를 얻어, 200만명이 한꺼번에 하나의 월드에서 한다면?
(200만명은 중국에서 인기를 얻으면 가능한 숫자이고, 기록된바 있다.)
200만명이 하는데, 코드 에러 때문에, 200만명이 한꺼번에 튕긴다면?



아래 그림은 여러 노드들을 합친 형태이다.


그림에서는 정확한 아키텍쳐를 알 수는 없지만, 하나로 합치려는 시도로 보여진다.

다음은, 참고할 만한 다른 소스들이다.

: 또 다른 Erlang으로 만든 MMO Engine

:Online Poker를 Erlang으로 구현했다.

: ragnarok online을  Erlang으로 구현했다. 소스를 보면, packet parsing을 어떻게 하는지 볼 수 있다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

explaining time server in Erlang

http://www.erlang.org/examples/klacke_examples/time_server.erl
%%%----------------------------------------------------------------------
%%% File    : time_server.erl
%%% Author  : Claes Wikstrom <klacke@erix.ericsson.se>
%%% Purpose : 
%%% Created :  3 Nov 1998 by Claes Wikstrom <klacke@erix.ericsson.se>
%%%----------------------------------------------------------------------
%%% 이 예제는 다른 예제보다, 매우 practical하기 때문에 
%%% 초보자는 반드시 이해하면 좋겠다.
-module(time_server).
-author('klacke@erix.ericsson.se').
%%% module 이름과 저자에 대한 명시이다. module은 반드시 명시해야 한다.
-export([start/0, loop0/1]).
%%% 외부에 공개할 인터페이스이다. start와 loop0가 공개가 되고, 
%%% loop0의 arity(인수의 수)는 1이다.
-define(PORTNO, 2345).

start() ->
    start(?PORTNO).
start(Pno) ->
    spawn(?MODULE, loop0, [Pno]).
%%% 시작시 loop0를 실행하는 process를 생성한다.
loop0(Port) ->
    case gen_tcp:listen(Port, [binary, {packet, 0}, {active, false}]) of
 {ok, LSock} ->
     loop(LSock);
 _ ->
     stop
    end.
%%% gen_tcp의 모듈에 있는 listen을 호출하고, 그 결과가 ok이면 LSock을 
%%% 받아서 loop를 호출한다.
%%% 그렇지 않으면 stop한다.
loop(Listen) ->
    case gen_tcp:accept(Listen) of
 {ok, S} ->
     gen_tcp:send(S, io_lib:format("~p~n", [{date(), time()}])),
     gen_tcp:close(S),
     loop(Listen);
 _ ->
     loop(Listen)
    end.

%%% accept가 성공하면, Socket(S)를 받아서 date(),time()을 찍어서 send하고, 
%%% close한다. 그리고 다시 loop를 돈다. 

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

using make,rake,emake for building Erlang Project

http://medevyoujane.com/blog/2008/8/21/erlang-make-rake-and-emake.html

emake는 파일 이름들을 나열하면 된다.
make는 emake를 활용하면서, clean,run기능과 같은 것을 넣을 수 있다.
이 필자는 더 많은 일을 위해서 rake를 추천한다.

아쉽게도,cmake를 활용한 예제는 찾지 못했다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

.emacs for erlang in MacOSX

emacs는 macosx용 GNU emacs를 설치하면 된다.
(emacs를 처음 쓰더라도 당황하지 말자. 메뉴들에 hot key들이 다 명시되어 있다.
한글로 된 간단한 emacs소개 )

mac에서 erlang emacs를 쓰기 위한 설정 방법
.emacs파일을 홈디렉토리에 다음과 같이 설정한다.



(setq load-path (cons  "/usr/local/lib/erlang/lib/tools-2.6.6.2/emacs" load-path))
(setq erlang-root-dir "/usr/local/lib/erlang")
(setq exec-path (cons "/usr/local/lib/erlang/bin" exec-path))
(require 'erlang-start)

참고로 각 editor의 learning curve이다. emacs는 무한루프를 돈다. ㅎㅎ



http://www.erlang.org/doc/apps/tools/erlang_mode_chapter.html

이 링크의 내용은, editing,compile을 포함하여, tags,etags등에 대해서도 설명한다.

http://alexott.net/en/writings/emacs-devenv/EmacsErlang.html

이 링크의 내용은 좀 더 실전적인 방법을 다룬다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Erlang IDE

netbeans의 erlybird
eclipse의 erlide
모두 아직 초기 단계이고, 쓸만하지 않다. 왜냐하면, run이 잘 작동하지 않는다.

emacs를 쓰는 편이 낫겠다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 17일 목요일

video streaming server in open source

http://www.kaltura.org/

오픈소스로 된 비디오 스트리밍 솔루션이다.

클라이언트쪽 위젯등도 풍부하다.
사용자도 많아 보인다.

다른 것 별로 찾아 볼 필요 없을 듯 하다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 16일 수요일

tinch++ ,interface c++ with erlang

There's no erlang support in Swig,for now.

I found an alternative to interface with c++;

That's tinch++.



In c++, I plan to make some high performance modules that has to be thoroughly tested and to be unchanged.

Because, c++ module cannot be changed or swapped at runtime.



Thanks, God.

2011년 2월 15일 화요일

Elliot Game Engine Blog

My Name is Elliot Shin.

I am from South Korea.

I've been working primarilly as a programmer in Game Industry for about 16 years.



Thanks to my boss, I come to have a chance to make use of my full time for myself,at last.



I decided to start to make a new MMO game engine.



I chose Erlang for server-side,and Haskell for client-side.

I will use jMonkeyEngine or somethine else temporarilly.



This challenge will be a long and lonely journey.



I am just learning the two languages.



And, I decided to blog in English to become better at.

I want to make good foriegn friends,too.



I will post my decisions,references I search, and on-going results.

Any help would be greatly appreciated.

Erlang vs Haskell in Server Side Programming

Erlang은 산업에서도 증명되었고, 특히 concurrent oriented programming과 Hotcode swap이 매우 매력적이다.
Haskell이 문법적인 면에서 우수하나(staticcaly typed), 아직 증명해야 할 것들이 많다.

Erlang은  soft real-time application에 적합하다. 즉, 아직 single-core에서 C++만큼의 성능이 나오지 않는다. 따라서, frontend보다는 middle-tier에 적합하다. hard real-time이 요구되는 상황에 적합하지 않다. Haskell도 아직 증명하지 못했다.

Hard Real-time이 요구되는 상황에 대해서 C++프레임워크와 비교해가면서 테스트를 해야되겠다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Re-enginnering

Reengineering?

다시 만들기, 속된말로 '다시 짜기'
무엇을 위해서 할까?
더 빠르게? 더 안정적으로? 더 많이 받게? 더 생산성을 높이기 위해?

어떤 기술과 레퍼런스를 가져야 할까?
1. 역공학 능력
2. 요구사항을 충족하는 숙련된 기술
3. 외부 성공 레퍼런스, 성공 경험들 축적

가치와 지속성은?
1. 안정적인 서비스 제공
2. 성공적인 회사와 파트너쉽 관계 유지
3. 고급 프로그래머 유지
4. 고급 솔루션 구축과 이전

쉽지 않구나;;;

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 14일 월요일

Qt for cross-plaform Desktop applications

cross-platform GUI library로서 대표적인 것이 두개 있다.

Qt와 wxWidget

여러 논쟁들이 있지만,
결론적으로 Qt가 우월하다.

cloud computing에
desktop application을 만들고자 한다면, Qt를 쓰는 것이 좋을 듯 하다.
실제로 많은 어플리케이션들이 쓰여지고 있다.

다만, mobile platform이 문제인데,
mobile platform인 iphone,android에서 지원하도록 프로젝트가 진행중이다.
하지만, OS특유의 look&feel을 구현해내기엔 어려울지 모른다.
결국, 현재는 cocoa-touch,android sdk에 익숙해지지 않으면 안 될 것 같다.
(android는 qt를 이용한 프로젝트가 잘 되는 것 같다.
http://gitorious.org/~taipan/qt/android-lighthouse )

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 11일 금요일

learning objective-c

Objective-C를 써보지 않았던 개발자들이 Obj-C소스들을 보면, 머리가 아프다.
"이렇게 난잡하다니! 우욱!"
도대체 머리에 안 들어온다!
긴 설명서를 읽기엔 부담스럽다!
그런 분들은, 아래 링크들만 읽어보면 입문 할 수 있을 것이라 확신한다.
다 읽는데 한시간도 안 걸린다.


http://theeye.pe.kr/entry/introduction_to_object_c_with_class_object_message?category=26

http://theeye.pe.kr/entry/compare_object_c_with_java_and_c?category=26

http://theeye.pe.kr/entry/iPhone-Object-C-Class-Method-VS-Instance-Method?category=26

http://theeye.pe.kr/entry/object_c_allocating_and_initializing_objects?category=26

http://theeye.pe.kr/entry/iPhone-Object-C-Declared-Properties?category=26

http://theeye.pe.kr/entry/Object-C-Fast-Enumeration?category=26


이제 좀 익숙해지셨으니, iPhone 개발서들을 읽을 자신이 생기는가?

http://cocoadevcentral.com/d/learn_objectivec/
이 링크의 설명도 좋다.

그러나, 저의 Obj-C에 대한 평가는,
나름대로 생산성 추구를 한 흔적이 보이지만,
표준화와 거리가 먼,
홀로 개발하는 슈퍼개발자가 자신을 위해 만든 언어처럼 보인다.
아이폰을 개발하려면, 아 이런 언어를 배워야 하다니~ 안습~

잡스 아저씨가 VM을 막은 전략적인 이유는 알겠는데,
개발자들을 강제 노동시키는 기분이 들잖아~

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 9일 수요일

Erlang , Haskell hybrid?

http://haskell.org/haskellwiki/Applications_and_libraries/Interfacing_other_languages/Erlang

Erlang Application과 Haskell Application간의 IPC를 위해서 준비하고 있는 모습.

Erlang은 Fault-tolerant, Scability, Stability가 인정되었기 때문에,
Frontend Server로 사용하고,
Haskell은 Logic Solver로 쓰려고 하려는 시도인 듯 하다.

하지만, Erlang을 쓸바에야, 차라리 C++ Frontend를 쓰는 편이 낫다.
왜냐하면, Erlang의 강력한 기능인 Hot code swap을 쓰지 못하고,
Logic Programming의 안정성을 Haskell에서 확보한다는 뜻인데,
결국, Logic Programming의 안정성(특히, 위기상황 대처능력)은 Haskell의 수준에 맞춰지고,
Latency만 올라가는 꼴이 된다. C++이 안정성은 확보 못할지라도, latency를 줄여줄 것이다.

Erlang은 VM의 garbage collection을 per-process단위로 heap을 만들었다.
그것은, 작은 프로세스 단위로, 분산 컴퓨팅이 되길 바라는 의미이다.
그런데, Erlang을 frontend로 쓰는 것은 어불성설인 것 같다.
( http://yarivsblog.blogspot.com/2008/05/erlang-vs-scala.html )

다른 구조로, Erlang의 작은 process들을 여러개 쓰고, 반대로 haskell process가 main controller역할을 한다고 해도, Erlang의 hotspot swap기능을 살릴 수 없다.

기본적으로 hybrid형태는 복잡도를 증가시키기 때문에 바람직한 architecture가 아니라고 생각한다.

하루 빨리 Haskell에 Distributed Computing(Actor Style System), Frontend Server로서의 안정성이 확보되길 바라고, Erlang의 hot code swap/remote shell기능마저 자체적으로 들어가길 바란다.
( http://stackoverflow.com/questions/394645/haskell-for-a-server )
( http://www.haskell.org/pipermail/haskell-cafe/2010-July/080427.html: hot-swap 빨리 구현 되길 ^^
 http://www.flickr.com/photos/48809572@N02/5304662424/lightbox/
http://www.0x61.com/forum/programming-haskell-cafe-f245/hot-swap-with-haskell-t1289472-10.html )


아직까지는 Erlang이 대규모 서비스에는 적합한 듯 하다. 다만, dynamic typing 만 보완되면 좋겠고, syntax도 보완되면 좋겠다;;
( http://jjinux.blogspot.com/2009/02/haskell-or-erlang.html )
( http://stackoverflow.com/questions/532176/erlang-type-system )

현재는, Erlang on server-side, Haskell on client-side가 답이다.
( http://learnyousomeerlang.com/content )
( http://learnyouahaskell.com/chapters )

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

complains about some programming languages

C++은 생산성이 떨어지고,
Haskell은 concurrent programming 이 아직 부족하고,
ErLang은 dynamically-typed라서 생산성이 조금 부족하고,
OCaml은 pure-functional이 아니고, 세미콜론이 거슬린다!;;; 게다가, community가 활성화 안되고 있다.
Scala는 JVM에 종속되어 있고,
Python은 성능이 떨어지고,
Ruby도 성능이...,

Java은 C++과 생산성이 비슷하고,
Lua는 Garbage Collection이 안 좋고,함수형 언어들은 처음에 배우기 어렵고...

그래도 haskell에서 희망을 찾아본다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 8일 화요일

akka

Akka( http://doc.akka.io/ ) 의 Design Goal은 Simple ( Scalability , Fault-tolerant , Concurrency )이다.
 아주 잘 구현한 듯 하다.

개념적으로 잘 정리되어 있고, 성능도 scala의 actor보다 latency가 낮다.
(
기대가 되는 프로젝트이다.
공부 해 볼만한 프로젝트로 추천한다.

play framework에서 scala와 함께 써볼만하다!
( http://implicit.ly/akka-module-for-the-play-framework )

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Django runs on pypy?

PyPy는 Python의 JIT이다. Python의 성능 문제를 해결해줄꺼라 기대하고...

Python의 가장 Popular한 Webframework인 Django에서 실행되는지를 확인해 보고 싶었다.
최신 버젼인 1.2에서는 확인되지 않고, 1.0에서는 실행된다고 한다.

PyPy위에서 안정적으로 잘 돌아가면서 생산성 높은 Python Webframework이 나오길 기대한다.

아쉽지만, 시간 될 때, 더 알아봐야겠다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 7일 월요일

short comments on bazaar

bazaar는 peer-to-peer version control system이다.
mercurial이나, git가 비슷한 종류이다.(subversion은 client-server구조이다.)

bazaar의 특징은,처음부터 서버가 필요없다.
.bzr folder에 저장하고 있다가, 나중에 merge하거나, 옮기면 된다.
서버가 필요없으므로, SE에게 서버를 설치해달라고 불평할 필요 없다.;;;


백업이 필요하거나,다른 사람과 협업을 해야 할 때 그 때 비로소 서버가 필요하게 된다.
서버는 물론, 자신의 컴퓨터에도 설치 가능하다.

설치 방법도 간단하다.

백업을 위해서, 또는 호스팅을 위해서 bazaar private hosting 업체를 찾아서 설치하면 된다.

개인 작업을 위해서 안성맞춤으로 보인다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 6일 일요일

comments on play framework tutorial

java용 framework인 play framework의 tutorial을 따라서 해보고 있는데,
따라하기 너무 쉽고, 필요한 설명이 빠짐없이 설명되고, 필요한 최소한의 기능을 구현해 볼 수 있다.
MVC기반의 다른 언어의 프레임워크를 써본 사람은 금새 적응되는 수준이다.

바야흐로, 플랫폼 전쟁인 요즘, 상세히 설명된 tutorial은 필수라고 생각한다.
1. 인기를 얻기 쉽다.
2. 다른 프레임워크를 만들더라도 이런 식으로 구현해야 할 듯 하다.
( ruby on rails가 이런 식의 tutorial의 시초였나? ruby on rails의 tutorial은 빨리 만들 수 있는 것에 너무 집중해서, 필요한 기능에 대한 설명이 부족했던 것으로 기억한다. )
3.특히,여러 IDE(eclipse,netbean등)를 위한 project workspace 파일 생성기가 매우 좋았다.
4. Popular한 Domain Specific Task에 대해서 정확히 파악하고 있다.
5. Step-By-Step으로 잘 나누어져 있는 것도 물론이지만, Step마다 결과물을 줘서,성취감을 주었다.

Scala/Lift , OCaml/Ocsigen , ErLang/OTP , SmallTalk/Seaside , Haskell/Snap 등의 tutorial도 이런 식으로 나왔으면 좋겠다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

phonegap as cross platform for mobile apps

비록, HTML5기반이라서, device dependent API 를 쓸 수는 없지만...(HTML5에서 가능했으면 좋으련만.... )
현재는, open source 기반에서 cross platform mobile app개발을 위해서 유일한 대안이네요. device dependent와 그래픽스까지 지원하는 airplay sdk도 있는데, 지금은 iphone을 제외하고 commercial이 되었습니다. airplay sdk는 게임까지 지원하므로, 비교적 무겁습니다.

다음은 phonegap,titanium,rhodes를 비교한 글입니다.
http://surgeworksmobile.com/iphone/mobile-apps-cross-platform-development-challenge-phonegap-vs-titanium-vs-rhodes

node.js 와 함께 쓰면 왠만한 것은 만들 수 있을 것 같습니다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

using playframework,siena,gae

java기반인 play framework을 사용하여, 웹 어플리케이션을 만들어보기로 했는데,
문제가 있었다. play framework내의 jpa를 그대로 사용하면 google app engine에 deploy시 문제가 있다.
대신에, siena를 사용해야 한다.
google app engine을 쓰지 않는 것은, google 보다 덜 믿을만한 호스팅 업체를 쓴다는 뜻이므로, 매우 중요한 요소이다. 본격적으로 상용 서비스를 하지 않고, 시범 삼아 웹 어플리케이션을 만든다면, 더욱 더 중요하다.

여기 입문자를 위한 설명이 잘 되어 있다.

http://viralpatel.net/blogs/2011/01/first-play-framework-gae-siena-application-tutorial-example.html

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

why does Domain Specific Language(DSL) gain popularity?

DSL이 인기를 끄는 이유는?

도메인 문제 해결을 빠르게 하기 위해서다.
arithmetic operation은 언어마다 차이가 조금씩 있지만, 차이는 so-so하다.
그래서 매우 빠르게 적응한다.
인기를 얻는 프로그래밍 패러다임들도 그 직관성에서 기인한다고 생각한다.

도메인 프로그래밍이 인기 있는 이유는, 쉬운 문제를 쉽게 풀기 위해서다.
도메인 오브젝트들만으로 오퍼레이션 함으로써(하위 프로그래밍을 안하고)만 프로그래밍하는 즐거움을 모두 원하고, 그러기 위해서 많은 프레임워크가 탄생하는 것 아닌가?

문제는 정말 생산성 있는 프레임워크는 매우 많은 경험과 통찰에 의해서만 생긴다는 것이다.

이제는 DSL을 만들 수 있는 프로그래머냐 아니냐가 프로그래머의 실력을 가늠하는 척도 중의 하나가 아닐까 생각한다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

seaside in smalltalk

smalltalk란 언어는 대학교때 프로그래밍언어 시간에 잠깐 다룰 뿐, 대부분 실전에서 잘 쓰이지 않는 언어였다. ( 정말? )
아뭏든, 주류 언어는 분명히 아니다.
ADA와 함께 OOP를 설명할 때 자주 등장하는 언어이다.

seaside란 프레임워크를 최근에 알게 되었는데,
웹 프로그래밍에 입문하면서 답답했던 것을 이 프레임워크가 풀어내고 있었다.
바로, 유저 컨텍스트에 기반한 플로우 콘트롤이다.
( http://seaside.st/about/examples/task?_k=8o4aoROk )
처음 웹 프로그래밍에 접했을때, 프로세스를 모델링하면서, 있어야 한다고 생각했던 것이 없어서 당황했는데, 바로 이 플로우 콘트롤 매니져 개념이었다.

Essential complexity 와 Accidental complexity란 말이 있다.
전자는, "복잡하고 지저분한 어려운 문제를 풀려고 할 때"
후자는,"왜 이렇게 간단한 문제를 어렵게 풀고있는 거지?"의 상황이다.

그런데, 전자는 결국 해결될 문제가 아닌데, 후자는 풀릴 수 있을 것 같다. 그런데, 이런 것이 반복되면 개발 속도에 큰 지장을 주는 문제라고 생각한다. 아마도 최근 ruby on rails가 각광받는 이유가 바로 후자의 문제를 잘 풀어주고 있기 때문이리라.
seaside의 플로우 콘트롤이 해결하고 있는 듯 해서 매우 큰 관심이 간다.

비록 smalltalk/seaside는 커뮤니티에서도 큰 인기를 못하지만,

다른 프레임워크에서도 이러한 플로우 콘트롤이 지원되지 않는 한, 존재가치가 분명히 있다고 생각했다.  다른 프레임워크에서 이러한 구조를 지원하는지는 아직 확인 못했다.

그렇다면, smalltalk/seaside를 메인 언어 및 프레임워크로 쓸 수 있느냐?
그 문제에 대한 해답을 아직 못 찾은 듯 하다.
현실적으로 인기를 못 얻는 탓이 그 때문인 것 같다.
다음 링크에, 경험자의 이야기가 있다. 그 사람 이야기는 모든 프로젝트에 사용 가능하고, 크고, 복잡한 어플리케이션에 오히려 적합하다고 말한다.
( http://unhandledexpression.com/2011/02/04/smalltalk-for-engineers/ )

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 4일 금요일

haskell for an alternative programming languages

주류(main-stream)가 아닌 프로그래밍 언어를 대안 프로그래밍 언어라고 부른다.

나는 C++프로그래머이다.
최근 3년 동안, 여러 언어들을 알아보았다.
Erlang,OCaml,Scala,Python,Java,Ruby,SmallTalk,Ada,Lua
ErLang은 가장 reliable,fault-tolerant한 것으로 잘 알려져 있다. CouchDB등에서 쓰여지고 있다.
OCaml은 Imperative,OOP에 익숙했던 사람도 쉽게 함수형 언어로 넘어갈 수 있게 되어있다.MS도 OCaml을 차용하여, F#을 만들었다. 즉, MS도 인정한 언어이다.
Scala는 JVM내에서의 OCaml과 같은 식이다. 다양한 패러다임들을 수용하고 있다. 프로그래머에게 많은 편안함을 제공한다. Scala는 이름처럼 Scalability를 위해서 많이 수용되고 있다.
Python은 극한의 생산성을 제공하는 듯 하다. 대규모 서비스의 front-end언어로는 적합하지 않아 보인다. 중급 이하에서는 문제가 되지 않아 보인다. 툴 제작에는 아주 훌륭한 언어라고 생각한다.
Java는 대안언어라기 보다는 주류언어지만, 비판을 많이 받아왔다. 하지만 요즘은 나쁘지 않다. 왜냐하면, Java기반의 좋은 framework들이 많이 나왔다. spring,playframework등... 게다가 성능이 이들 중에서는 가장 최적화가 많이 된 상태이다.
Ruby는 Ruby on Rails를 통해 인기를 얻기 시작하여, 커뮤니티가 매우 크다. 천재적인 패러다임들이 가장 먼저 적용되고 있는 언어이다.
smalltalk,ada도 관심을 두고 알아보았고, 나름 매력이 있다. ADA는 literate programming에 가장 가까운 언어인 듯 하다. 구문이 영어와 많이 닮아 있다.
lua는 큰 규모에는 쓰기 어렵다.

불행히도, 이들 언어에 모두 제대로 입문하진 못했다.
모든 언어를 경험해보고 몸소 그 장단점을 깨달아보고 싶다.
모든 언어로 하나 이상의 프로젝트를 해 볼 계획이다.
하지만 간접적으로나마 깨달은 것 중에 가장 중요한 깨달음은 다음과 같았다.
1. 커뮤니티의 크기 : 커뮤니티가 크다는 것은 도메인 문제들을 잘 해결해주고 있다는 증거이고, 헌신하는 팬들과 투자가 많다는 것이다.
2. 프레임워크가 언어를 압도한다. : 루비의 예에서 보듯이, 언어 자체의 한계성보다는 마찬가지로 도메인 문제를 잘 해결해주기 때문에 인기를 얻을 수 있는 것이다.

앞으로 10년을 개발할 프로젝트에 쓰일 언어의 기준은 뭐가 되어야 할까?
패러랠,멀티코어,CPU/GPU 컨버젼스의 시대이다.
아키텍쳐의 변화를 수용하지 못하면, 결국 성능 결쟁에서 밀려날 것이다.
그러려면, 가장 자연적스러운 병렬 프로그래밍이 가능해야 한다!

아직 어느 언어도 그 기준에 맞지 않다.
그래서 새로운 언어를 만들어 보고 싶다.
그러기전에 '최선'의 선택, 또는 '차선'의 선택이 될 수 있는 언어에 익숙해지는 순서가 필요하다고 생각한다.
그 생각에서 가장 적합안 언어로 꽂힌 언어는 haskell이다.
haskell : 순수 함수형 언어이다. 배우기 어려울 뿐, 함수형 언어에 익숙해지면, 생산성이 매우 높아진다고 한다.(나도 아직 경험해 보지 못했고, 그렇게 되길 바란다. ) 최근 커뮤니티가 급성장하고 있다.

programming language shoot-out 을 보면, 성능 비교가 잘 되어 있다.
http://shootout.alioth.debian.org/
아마도 특정 분야에서는 C/C++을 버리지 못할 것 같다.
haskell에 기대를 걸어본다. 커지고 있는 커뮤니티가 더 최적화된 컴파일러를 만들어주리라 기대해 본다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

2011년 2월 2일 수요일

java web start vs java plugin

"The fundamental difference between Java Web Start and the Java Plug-in is that the Java Plug-in is restricted to running Java applets within the context of a Web browser. The Java Plug-in relies heavily on the JRE of the Web browser and cannot be executed without the browser running. Java Web Start, on the other hand, can launch a Java application from a single click on a link within a Web page or from a single click from the Java Application Manager. "
http://www.ibm.com/developerworks/java/library/j-webstart/

* minecraft와 같이 웹 브라우저에서 자바 어플리케이션을 실행하게 하려면, java web start기술을 써야 한다. plugin기술과 다르다.
* browser-independent한 installer를 만들고자 한다면, java web start 를 사용하면 된다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

todo for installing OIS in MacOSX

OIS는 Ogre3D를 build하기 위해서 필요하다.
Ogre3D가 제공하는대로 설치를 해도 되지만, 다음과 같이 시도해도 될 것 같다.
(아직 설치 해보진 않음!;;;)

#svn co https://wgois.svn.sourceforge.net/svnroot/wgois wgois 
#cd wgos
#cd ois
#cd trunk
#vi bootstrap
modify libtoolize -> glibtoolize ( 이것이 중요하다. mac에서는 glibtoolize이다.)
#chmod 755 bootstrap
#./bootstrap
#./configure
open xcode
open Mac/XCode-2.2/OIS.xcodeproj


release,debug를 iOS용으로 duplicate한 후 고친다.
모두 빌드 한다.
왜냐하면, Ogre용으로 MacOSX용 및 iphone용 모두 필요하기 때문이다.
그런 다음에 sudo make install 한다.( lib 파일 이름이 다르게 설치되어야 한다. )

이런식으로 되게 OIS에서 고쳐줘야 할 텐데;;;


결국, Ogre에서 제공하는 precompiled를 사용하는 편이 좋다.;;


도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

installing cocos2d for iphone

0.95버젼을 설치해 보았는데, 설치가 깔끔하고 사용하기 간편하다.
xcode에서 개발하기 편하게 잘 되어 있다.

아이폰용 2D게임을 만드는데 더 이상이 없을 듯 하다.
기능도 매우 많다.
던전앤파이터 정도도 만들 수 있을 듯 하다. ^^
MacOSX도 지원된다.
Mac App Store도 열려 있으므로, 시장이 크게 열려있다.
이러한 기세라면, MS의 소프트웨어들을 따라잡는 것도 그닥 오래 걸리지 않을 것 같다.

c++버젼으로 포팅되고 있는 cocos2d-x도 있는데,
곧 안드로이드 및 바다폰도 지원한다고 한다.
플랫폼 시대이니만큼,
크로스플랫폼 기능은 매우 중요하다!
cocos2d-x도 설치가 매우 잘 된다.

cocos2d 설명하는 동영상
http://www.youtube.com/watch?v=pdVNahZb1PU

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Hunger는 왜 없어졌을까?

예전에 머드를 할때엔, 플레이어는 Hunger(배고픔)를 느껴야 했다.



그 Hunger는 움직이게 할 하나의 이유가 되었다.



Online Game들은  현실 세계가 모델인 Fantasy(상상) 세계이기 때문에,

현실 세계에서 느끼는 배고픔은 너무나 당연한 것이었다.



그러나, 문제는 Game은 재미있어야 한다.

현실에서는 그 배고픔을 풀 수 있는 다양한 방법이 존재한다.

가끔 외식도 가고, 요리책을 보고 요리를 하고, 가족과 모여 단란한 담소를 나누기도 한다.

하지만, Online Game에서 그러한 다양한 해소 방법은 없고, 배고픔만 있었던 것이다.



그렇다면, Online Game에서 이러한 해소방법을 재밌게 만들면 해결될까?

Online Game에서 재미는 여러가지 요소들로 구성되는데, 이 '배고픔 해결하기'는

그 중에서 큰 비중이 아닐 것이다. 핵심 재미가 그것이 아닌 한.

RPG게임들은 전투가 핵심 재미가 아닌가?

그러니, 이 '배고픔 해결하기'는 중심이 될 수 없고, 의무적인 '배고픔 해결하기'는

성가시고 재미 없는 일이 되어버린 것이다.



하지만, 예전에 게임하던 기억을 떠올리면, 사람들이 배고픔 해결과 회복을 위해서

한 곳에 모여서 서로 이야기할 수 있는 시간을 제공하여, 커뮤니케이션의 장을 열어주기도 했다.

Responsibility #1: Help the Project Director having in mind that I am just a Technical Director.

CTO(Chief Technology Officer)의 역할은 무엇인가?



CTO는 회사내의 최고 기술 책임자이다.



Project Director(또는 Project Producer)나 CSO(Chief Service Officer)와의 팀워크가 좋아

발전적인 시너지가 날 수 있다면 좋겠지만,

많은 경우 오래된 팀워크가 아니면 그렇게 되기는 쉽지 않고,

잘 되는 경우는 이 글이 다룰 문제가 아니다.



그런데, 이 말을 한번 생각해보라.

"CTO때문에 성공하는 프로젝트는 없어도, CTO가 잘못해서 망하는 프로젝트는 많다."

따라서, CTO는 성공에 커다란 공헌을 하는 것이다.



물론, CTO가 직접 프로젝트를 지휘하는 경우는 일부 회사에서 일어나는 일이다.

그러나, 현실은 One Project Company(프로젝트 하나에 의존하는 소규모의 회사)가 많다.

One Project Company에서는 특히 CTO 가 그 Project의 TD(Technical Director) 역할을 해야 한다.

그러므로, CTO의 역할을 알아보기 위해서는 TD의 역할을 먼저 알아야 한다.



TD는 그 Project에 있어서 Technical Issue(기술 이슈)에 대한 최고 결정권자이다.

Project Director(PD)는 Project 의사결정의 최고 결정권자이다. 

간단히 결론부터 말하면, 협력하는 의사결정 구조가 중요한 것이다.



PD는 기술 이슈뿐 아니라, 비즈니스 이슈, 서비스 디자인 이슈들에 대한 큰 책임을 지기 때문에, 기술 이슈까지 신경쓸 수 없기 때문에 TD에 의존해야 하고, 신뢰하여야 한다.



그런데, TD가 알아야 할 것이 있다.

반대로 TD는 비즈니스 이슈,서비스 이슈에 관심이 없진 않겠지만, 결국 PD가 책임지는 이슈에 대해서 의존해야 한다. 따라서, PD의 결정을 존중해야 하고, 특히 PD가 필요한 요구사항에 대해서 관심을 갖고 '실현'되도록 해야하는데 집중해야 한다.



그러나, 그 '실현'이 미래를 망쳐서는 안된다. TD의 존재이유 중에서 아주 중요한 면이다.

고객의 요구에 맞춰서 잘 왔더라도, 문제들이 문제를 만들어 점점 감당할 수 없는 상황이 된다면, 변화하는 고객의 요구를 결국에는 대응하지 못할 것이기 때문이다.



고객의 요구사항은 끊임없이 변화하고 진화하기 때문에, 그것들을 실현하려면 항상 시간이 촉박하다.



유한한 자원과 TD가 바라보는 미래와의 밸런스를 유지하고 있어야 하는 것이다.

Rapid Development도 필요하지만, Stable Development에 대해서도 관심을 갖지 않을 수 없다.



또한, '실현'을 위해서 '실행능력'과 '요구사항의 핵심'의 밸런스에 견주어 PD에게 '실현'방안을 제시할 수 있어야 한다.

그러려면, 탄탄한 아키텍쳐링 능력과 다양한 경험, 현재 개발팀의 역량에 기초한 바른 판단력이 필요한 것이다.

그 판단력에는 할 수 있다는 자신감과 집요하게 문제를 해결하려는 문제해결 능력이 필요할 것이다.





그렇지만, 그 밸런스와 PD의 요구사항 중에서 어떤 것이 더 중요한가?

PD의 요구사항이 중요하다.

왜냐하면, PD가 고객의 요구사항중에 어떤 것이 중요한 가를 결정하는데,

그 결정 사항중에서 시도도 못해서, 잘 될 수 있는 서비스가 고객을 실망시킬 수 있지 않겠는가?

만약에 시도해서 성공한다면, TD에게는 시간과 자원을 얻을 수 있는 기회를 얻을 수 있게 되고, 그것이 선순환을 일으킬 수 있다.

실패한다면, 그러한 기회를 얻지못하고, 유한한 자원에 쫓겨 더 나쁜 선택을 해야 할 수 밖에 없을 것이고, 그것은 악순환으로 이어지는 것이다.





정리하면, 우선순위는

1) PD의 요구사항에 맞추는 실행력

2) TD 개인의 전문적인 역량(지식과 경험)과 개발팀의 역량에 따른 촌철살인적인 판단력

3) 개발팀의 역량과 프로젝트의 미래를 보는 균형감각

순으로 될 것이다.



CTO로 다시 돌아가면, CTO는 이러한 TD들을 돌봐야 한다.

a design goal on yake

yake 프로젝트.( http://yake.org )

전에 눈여겨 봤던 프로젝트인데, 작년 3월 이후로 소식이 없다. 아쉽다.

다음의 목표가 맘에 들었었다.



The goal is, to provide an genre-independent engine which can be used for a variety of VR applications and to provide essential tools to import/edit/create content (to give an example: in-application editors allowing remote object inspection through runtime reflection).

2011년 2월 1일 화요일

compiling irrlicht for iOS 4.2

일단 도플광어님이 작성하신
http://gbox3d.tistory.com/entry/1
링크를 참조하시면 됩니다.

1. 현재 날짜로 최신 소스를 받습니다.

2. xcode를 구동합니다.

3. MacOSX/Irrlicht/libraries/zlib/gzio.c 를 제외합니다.
    MacOSX/Irrlicht/libraries/libpng/pngcrcd.c 를 제외합니다.
( 이부분은 도플광어님 블로그에는 없습니다. 아마도, svn update 날짜가 달라서 그런 것 같습니다. )

4. AppDelegate.mm
  CIrrDeviceMacOSX.mm
  OSXClipboard.mm

요 3개 파일을 프로젝트에서 제외합니다.(맥에서도 하고 싶다면, 다른 세팅을 설정하셔서 하시고요. )
 
5. - source/Irrlicht/wglext.h
- source/Irrlicht/eglext.h
- source/Irrlicht/gles-ext.h
- source/Irrlicht/COGLESDriver.h
- source/Irrlicht/COGLESDriver.cpp
- source/Irrlicht/COGLESExtensionHandler.h
- source/Irrlicht/COGLESExtensionHandler.cpp
- source/Irrlicht/COGLESMaterialRenderer.h
- source/Irrlicht/COGLESTexture.h
- source/Irrlicht/COGLESTexture.cpp
- source/Irrlicht/CIrrDeviceIPhone.h
- source/Irrlicht/CIrrDeviceIPhone.cpp
- source/Irrlicht/CIrrDeviceIPhone.m 



이 파일들을 프로젝트에 추가합니다.


6. xcode의 macosx와 
 targets의 밑의 libIrrlicht.a,01.HellowWorld등에  info를 누르시고,



Project Build Settings:
  • Architectures: Standard (armv6 armv7)
  • Base SDK: Latest iOS Build Active
  • Architectures Only: Checked Valid
  • Architectures: armv6 armv7
을 확인합니다.

7. 컴파일이 잘 됩니다.
 ( 컴파일이 잘 되는 것을 확인했으니, release도 compile해보시고,
 실제 프로젝트와 함께 할 위치로 옮기면 더욱 좋습니다. )

8. 그 이후는 도플광어님의 블로그를 따르면 됩니다.
http://cafe.naver.com/jcga.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=2064

다음엔 안드로이드와 같은 소스코드 베이스에서 개발할 수 있도록 만들어봐야겠습니다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^