프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 알콜코더

안녕하세요. 알콜코더 민군입니다.

 

현대 게임 개발의 가장 기본적인 모토는 데이터 주도 개발(DDD. Data Driven Development)입니다.

바로 순수한 게임 클라이언트 자체는 일종의 게임 엔진과 같은 역할을 하면서, 외부의 데이터를 기반으로 게임을 제작하는 아키텍쳐입니다.

, C++로 제작된 게임 클라이언트는 게임의 핵심 요소만을 구성하면서,  외부에서 사용할 수 있는 API를 제공하고,  게임 코어 외부에서는 루아와 같은 스크립트로 게임 로직을 제작하고,  XML같은 데이터 파일로 게임의 요소등을 정의합니다.

이러한 방식을 가장 잘 활용한 것이 바로 WOW입니다. 와우의 경우에는 UI면에서 이러한 루아 스크립트와 XML을 유저들에게 제공하여, 유저들에게 맞는 다양한 커스터마이징 UI와 애드인들을 제작할 수 있게 되어 있습니다. 그리고 이러한 방법이 크게 성공하여, 수많은 유저들이 만든 다양하고 유용한 애드인 역시 상당히 많습니다.

그래서 와우 이후에도 수많은 게임들이 스크립트를  개발에 다양하게 활용하고 있고, 유니티나 언리얼 같은 게임 엔진은 스크립트만으로도 게임을 제작할 수 있는 형태입니다.

 하지만 제가 이야기 하려는 것은 이런 외부 사용자나 엔진 사용자를 위한 스크립트가 아니라,  실제 게임 개발 내부에서 사용되는 스크립트의 사용에 대해서 이야기를 하려고 합니다.

게임 개발에서 스크립트는 필수 불가결한 요소라는 의견도 많고, 저 역시 그런 의견들에 상당히 동의합니다. 그런데 과연 대한민국의 게임 개발에서 스크립트란게 정말로 유용할까요? 결론부터 이야기하면, 제 개발 경험에 비춰 보았을 때  저는 그렇지만은 않다고 생각합니다.

 

스크립트는 누가 작성하는가?

원래 스크립트의 용도는 앞서 이야기했듯이, 게임 코어에서 제공하는 API들을 가지고, 게임의 로직을 개발하는 용도입니다.

, 일반적으로 게임 코어는 프로그래머가 제작을 하고, 레벨 디자이너나 퀘스트 디자이너 같은 기획자들이 스크립트를 가지고 게임을 제작하는 형태입니다. 실제로 해외 게임의 포스트모텀들을 보면 이런 형태로 스크립트가 사용되어서 개발되고 있습니다.

그러면 과연 대한민국에서도 그럴까요? 아닙니다. 대한 민국의 대부분의 게임 회사에서는  루아 스크립트는 바로 프로그래머가 개발하고 코딩합니다! 전 이것이 가장 큰 문제라고 생각합니다.

한국 게임 개발에서의 스크립트 사용은 간단히 말해서 아래처럼 이루어 집니다.

1.    프로그래머가 게임 코어에서 API를 제작한다

2.    프로그래머가 루아 편집기를 열어서, 자신이 뽑아낸 API를 사용하여 로직을 구현한다.

3.    프로그래머가 만들어진 루아 스크립트를 호출하는 코드를 게임내에 작성한다

4.    게임을 돌려서, 루아 코드를 테스트한다.

5.    부족한 기능이 있으면, 또다시 API를 제작하고, 빌드하고, 루아 코드를 수정한다.

사실 이럴거면, 굳이 기능들을 루아 스크립트로 뽑아낼 필요가 없습니다. 그냥 C++ 코어단에서 직접 로직을 만드는게 훨씬 편하고 간단합니다.

굳이 API로 뽑아내고, 익숙하지 않은 루아 코드로 로직들을 어렵게 구현하고, 그것을 게임에서 다시 호출한 코드를 만들 시간과 노력이 왜 필요하겠습니까? 더불어 루아는 브레이크 포인트도 없고, 디버깅도 어렵습니다.. ==;

그냥 C++로 게임 내에서 작성하면 몇줄로 끝날 코드도, 굳이 루아 스크립트를 사용하기 위해서 코드를 작성하면 몇배의 코드와 몇배의 함수들이 생기는 경험은 다들 해보셨을 겁니다.

이것만큼 잘못된 프로세스가 또 어디있을까요? 이건 마치 억지로 루아를 사용하기 위해서, 개발 프로세스를 끼워 맞추는 꼴입니다.

 

프로그래머가 스크립트를 작성해야 하는가?

왜 위와 같이 잘못된 프로세스가 생겼을까요? 원래 루아를 사용할려는 것은 코어 개발자와 게임 로직/컨텐츠/UI 개발자를 구별하기 위한 것이 목적입니다.

, 기획자(디자이너)가 프로그래머가 제공된 기능들을 가지고, 기획 의도대로 마음껏 게임을 개발하고, 변경하고 테스트하기 위한 것이 목적이었던 것입니다.  그래서 프로그래머들은 그런 해외에서 성공한 프로세스들을 공부했고, 그것이 맞다고 배웠습니다.  그렇기 때문에 지금도 열심히 스크립트를 게임에 적용하고 있습니다.

하지만, 한국에서 정작 루아를 공부하는 기획자는 정말로  드뭅니다. 실제로 저도 10년 가까운 개발 경력동안 루아를 코딩할 줄 아는 기획자를 거의 못 봤습니다. 또한 공부하는 기획자 역시도 보지 못했습니다. …. 물론 루아를 공부하는 프로그래머라면 지겹게 봐왔죠. ==;;

실제로 기획자들과 스크립트에 관련된 회의를 하면 아래 처럼 됩니다.

 

프로그래머 : 캐릭터 FSM을 루아로 빼줄 테니, 직접 작성해서 만드세요

기획자 : ?? 내가 왜요? 내가 왜 코딩을 해야 합니까? 나 루아 할줄 몰라요. 그냥 테이블로 만들어 줄께요. 루아 하기 싫어요.

프로그래머: ..그럼 테이블로 만들어주세요. (해달라는데로 해줘야지.ㅅㅂ..)

(그리고 프로그래머는 FSM 관련 API를 만들고, 루아 스크립트로  FSM 코딩을 하고, 게임에 넣어서 개발한다)

 

이렇게 되면 처음 이야기한 것처럼, 굳이 필요없이 스크립트를 사용하는 프로세스가 됩니다. 다시한번 이야기하지만, 이럴 거면 걍 C++ FSM 만드는게코드도 훨씬 간결해지고, 로직도 간단해 집니다. FSM을 루아로 빼기 위해선, 수많은 상태 체크와 관련 함수들을 전부 루아 API로 빼줘야 하기 때문입니다.

 

억지로 스크립트를 써야만 하는가?

위에 언급했듯이 스크립트의 단점은 개발 프로세스가 복잡해지는 것만은 아닙니다.

l  스크립트는 디버깅이 상당히 어렵다

l  스크립트는 VS처럼 전문 개발툴이 없다

l  스크립트는 로딩과 실행 속도가 C++에 비해 몇십배나 느리다.

 

위와 같은 다른 문제점들도 많습니다. 사실 그래서 꼭 스크립트 안 써도 됩니다. 물론 개발하는 게임의 규모가 상당히 커서 스크립트가 꼭 필요한 경우도 많지만, 사실 안 써도 되는 경우도 훨씬 많습니다. 그냥 스크립트가 있으면, 스크립트를 사용하면 더 좋다는 막연한 잘못된 환상으로 억지로 스크립트를 사용하기 위해서 잘못된 프로젝트 구조를 만드는 경우를 훨씬 더 많이 봐왔습니다.

물론, 가장 좋은 사용법은 앞에서 언급했듯이 코어 프로그래머와 로직을 구현하는 디자이너가 분리되어 자신의 역할을 잘할 때 가장 효율적으로 스크립트를 사용할 수 있습니다. 그렇지 않은 것이 현재 한국 개발의 현실인 것을 감안하면굳이 억지로 스크립트를 사용해야 한다는 환상을 가지고 개발 프로세스를 더욱 복잡하게 만들어 버리는 케이스가 더욱 많습니다.

 

이러한 경우라면 저는 억지로 스크립트를 사용하지 않아도 된다고 생각합니다. 왜 굳이 무엇을 위해서 어렵게 코드를 만들고, 디버깅할때 C++에서 루아를 따라가야 하며, 제대로 디버깅도 되지 않는 스크립트를 써야 할까요? (디버깅하다가 루아 호출 함수를 만나면, 노트패드에서 루아 코드를 꺼내 봐야 하죠. 그것도 브레이크 포인트도 안걸리는 코드를…)

지금 혹시여러분도 억지로 스크립트를 사용해야 하기 위해서, 스크립트를 게임 코드에 붙이고 있지는 않나요? ^^;

댓글을 달아 주세요

  1. AKer 2011.12.15 14:05  댓글주소  수정/삭제  댓글쓰기

    뭔가 눈물이 흐르는 글이다. ㅠㅠ

  2. Favicon of https://gamedevforever.com 월하 2011.12.15 14:09 신고  댓글주소  수정/삭제  댓글쓰기

    그렇죠! 기획자가 코딩을 하면 그것도 이상하죠!

    하지만 위 예시처럼 FSM같은 경우는 몇몇 코드만 알면 금방 익히기 때문에 기획자가 하는게 정답이라고 생각 합니다.
    (물론 금방 익히는대신 금방 까먹지만요 ㄷㄷㄷㄷ)

    스크립트 방식으로 해야 기획자가 계속 수정 하면서 테스트를 할 수 있으니깐요.

    FSM 상태 조건값에 수치 1을 고치고 그걸 프로그래머에게 전달하고 다시 코딩하고 테스트하는건 정말 비효율적이죠.

    덧//FSM이 유한 상태 AI... 맞죠? 날아다니는 스파게티 괴물이 아니라...

  3. Favicon of https://gamedevforever.com 끼로 2011.12.15 14:13 신고  댓글주소  수정/삭제  댓글쓰기

    저도 무작정 스크립트를 넣기 위해 억지로 넣는것은 잘못된것이라고 생각합니다. 그런데 정말 간단한 코드로 조금씩 수정이 가능하게끔 빼면 그 간단한것들이 모여서 더 복잡한것들도 수정하고 만질 수 있다고 생각합니다. 실제로 예전에 제가 작업했던 프로젝트에서는 루아 스크립트라는걸 말하지 않고 '이걸하면 이게 된다' 정도로 여러개의 함수들을 정리해서 사용법 매뉴얼을 만들고 적용을 했었는데 나중엔 기획자분들뿐만 아니라 애니메이터분들도 스크립트를 쉽게 만지더라구요(물론 애니메이션 프레임에 스크립트를 연동했는데 그걸 위주로 만지셨죠) 물론 복잡한 로직 처리는 C++로 했었습니다 ㅎㅎ

    • Favicon of https://gamedevforever.com 월하 2011.12.15 14:18 신고  댓글주소  수정/삭제

      그렇죠.
      저도 루아를 쓸 줄은 모르지만 이전 프로젝트에서 AI를 전부 루아로 코딩 했죠.
      샘플 예제 하나만 만들어 달라고 부탁 한 다음 그걸 수정 하면서
      어떻게 돌아가는지 테스트 하면서 익혔죠.
      덕분에 수정을 자유롭게 하면서 테스트 할 수 있어 엄청 편했죠.
      (물론 지금은 다 까먹었지만요 ^^;;)

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.15 14:24 신고  댓글주소  수정/삭제

      글에서 언급한것처럼 원래 그렇게 사용하는게..
      제대로 된 루아 스크립트의 사용입니다. ^^

      전 스크립트 사용에 반대한다는 내용이 아니라, 잘못된 스크립트 사용을 반대한다는 내용입니다.

      다만 아쉬운 점은..
      기획자가 요구하는것이 아니라.. 프로그래머가 조금씩 빼줘야.. 디자이너들이 받아서 작업한다는게 아쉬운 현실..

      원래라면 디자이너들이 "이 기능 수정할 수 있게 빼줘요!!" 라고 요구하는게 맞는걸텐데요...T^T

  4. levites 2011.12.15 14:16  댓글주소  수정/삭제  댓글쓰기

    말씀하신 것처럼 스크립트가 데이터 드리븐을 위해서 사용하기도 합니다만, 스크립트 언어 자체의 장점으로 프로그램 작업에 속도를 얻는 경우도 있습니다.

    http://www.lameproof.com/index.php?mid=neolith&order_type=desc&sort_index=readed_count&page=8&document_srl=171123

    예를들자면, 위 이야기처럼 Lisp 를 사용하면 디자인 패턴을 굳이 사용하지 않아도 된다던가, 김학규씨의 이야기 처럼 '타입을 값으로 처리할수 있는' 스크립트 언어들의 강점등이 대표적이라고 생각합니다.

    http://ricanet.com/new/view.php?id=blog/110608a

    NDC11 에서 이승재씨가 발표했던 "온라인 게임 처음부터 끝까지 동적언어로 만들기" 에서도 '생산성의 비약적 향상' 을 언급하고 있구요. (물론 개발 환경과 유지 보수에는 다소 조심스러운 언급도 있습니다만.)

    말씀하신 것처럼 전문 툴이 없고, 디버깅이 힘든 부분도 있습니다만 컴파일이 필요없다는 스크립트 언어 본연의 속성, 그리고 언어 자체의 강점등으로 더 많은것을 얻었던 기억이 있어서 짧막하게 적어보았습니다.

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.15 14:21 신고  댓글주소  수정/삭제

      좋은 내용 감사드립니다. ^^

      저도 NDC 강연은 들었습니다. 그런 규모가 작은 웹게임의 경우에는 C++로 제작하는것보다 순수 스크립트만으로 게임을 제작하는게 더 맞을 수 있습니다. ^^

      제 내용은 C++로 코어를 개발하는 온라인 게임에 대한 이야기라고 생각해 주시면 됩니다. ^^

      ps. 그때 그 강연때도.. 이런내용을 제가 질문을 했었죠. ㅎㅎ

    • levites 2011.12.15 14:48  댓글주소  수정/삭제

      이전에 참여했던 MMO 프로젝트 중에 Python 으로 전체를 작업해서 런칭한 프로젝트가 있었습니다. (물론 속도가 필요한 3D 엔진 같은 부분은 C++ 모듈로 만들었습니다만.) 결과적으로 꽤 효율적이었고, 작업 속도도 빨랐습니다. 스크립트 의존도가 그렇게 높았음에도 10년전 PC에서도 속도는 신경쓰이는 수준이 아니었구요.

      반론을 제기하고 싶은 것은 아닙니다. 단지 스크립트의 사용이 프로젝트 규모가 문제가 아니며, 다른 프로젝트들이 스크립트를 사용하는 의도도 데이터 드리븐만이 아니라는 점을 기억해주셨으면 해서 몇자 더 적어보았습니다. :)

    • 죠쉬 2011.12.19 12:55  댓글주소  수정/삭제

      원글을 쓰신분의 의도와는 약간 다른 맥락의 댓글로 보입니다.
      ㅎㅎㅎ

  5. Favicon of https://gamedevforever.com 끼로 2011.12.15 14:32 신고  댓글주소  수정/삭제  댓글쓰기

    그렇죠.. 가끔씩 보면 개발자들 사이에서 '내가 할 일은 여기까지다' 라고 선긋기를 하는 개발자들이 있는것 같아요 게임을 만드는게 목적이 아니라 단순히 일하는게 목적인것처럼요.. 디자이너들이 적극적으로 이런저런 요청을 하고 프로그래머들도 최대한 그런 요청들을 구현하기 위해 노력하는 커뮤니케이션이 잘 되는 팀문화가 많이 많이 만들어졌으면 좋겠어요 ㅎㅎ

  6. GoodBen 2011.12.15 15:00  댓글주소  수정/삭제  댓글쓰기

    저도 스크립트를 넣고 나서 스크립트 로직 작성은 전부 제가 했던지라..심히 공감이 가네요.
    막연히 지금 이렇게 고생 하는 것이 나중에 나에겐 더 득이 될꺼야..라는 생각으로 작업 했던 기억이 납니다.

  7. Favicon of http://myrodin.jaram.org 로딘 2011.12.15 15:37  댓글주소  수정/삭제  댓글쓰기

    말씀하신대로 제대로된 철학없이, 스크립트를 쓰기 위해서 스크립트를 쓰는 것은 오히려 독이 되는게 사실입니다.

    하지만 한국의 기획자들에게 희망을 버리신 것 같은 말씀은 좀 안타깝습니다.
    저희 팀은 운좋게도 "이 기능을 커스터마이징할 수 있게 빼줘요!!"라고 말하는 게임 디자이너들과 함께 일하고 있습니다. 그런 디자이너가 7명이나 있는 덕분에 상대적으로 적은 수의 프로그래머들은 단순한 컨텐츠 물량 작업에서 한 발 물러나, 보다 기술적인 부분에 집중할 수 있는 환경입니다. 게임 디자이너들이 직접 물량을 늘리면서 자체적으로 테스트까지 해보게 되니 생산성도 확실히 올라가고요.

    덧붙여 Lua의 경우, Decoda( http://www.unknownworlds.com/decoda )라는 IDE가 존재합니다. break point, watch window가 제공되고요.
    Lua의 언어 특성상 callstack은 좀 보기가 안 좋지만요. :)

    어찌됬든 하고싶은 말은 꿈과 희망을 잃지말자는... 뭐 그런 이야깁니다. ㅎㅎ

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.15 15:38 신고  댓글주소  수정/삭제

      ㅎㅎ 좋은 말씀과 정보 감사합니다. ^^

      내용은 우리나라 기획자를 포기한 내용이 아닙니다. ^^
      다만 현실이 안타깡울뿐입니다.

      언제나 꿈과 희망을. ㅎㅎ ^^

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.15 15:39 신고  댓글주소  수정/삭제

      그런데 Decoda에서 Lua 자체를 그냥 실행해서 디버깅은 가능하지만...
      C++ 코드에서 바인딩해서 호출한 루아 함수를 디버깅 하는 기능이 가능한가요?

    • Favicon of http://myrodin.jaram.org 로딘 2011.12.15 15:45  댓글주소  수정/삭제

      네, 사실입니다...가 아니고 가능합니다.

      dll을 후킹하는 방식이라...
      저희는 luabind로 C++ 코드에 바인딩해서 쓰고 있답니다.

  8. Favicon of https://gamedevforever.com 김포프 2011.12.15 17:12 신고  댓글주소  수정/삭제  댓글쓰기

    제가 게임플레이쪽은 전혀 안해서 잘 모르는데 저희 회사에서는 Kore를 쓰더라구요. Lua용 VM으로... 비주얼 스튜디오에서 디버깅 까지 할 수 있다고 들었어요.. 지금은 Havok이 사서 Havok Script라고 브랜딩 하고 있는게 바로 이놈....

  9. Favicon of http://gaebit.tistory.com/ zinzza 2011.12.15 18:38  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다.
    저는 게임프로그래머나 코어한 프로그래머는 아니라 다른 글보다 편하게 읽었습니다.
    게임뿐만 아니라 다른 분야에서도 군더더기 일이 많지요.
    그런 맹락에서 이해해야 할 거 같습니다.

  10. Favicon of https://gamedevforever.com 김포프 2011.12.16 04:19 신고  댓글주소  수정/삭제  댓글쓰기

    태그에 '알콜코더'라고 달았습니다. 필자별 글 검색이 안되서 태그로 분류중... 담에 쓸땐 달아주세용~

  11. Favicon of http://Junios.net Junios 2011.12.16 09:53  댓글주소  수정/삭제  댓글쓰기

    잘보고 갑니다.

    머 다 혼자하게 되면 무의미 해지지만 인원이 충분하면 집중과 선택 그리고 빠른 사이클을 위해서 필요하지 않을까 하네요.

  12. 죠쉬 2011.12.19 12:58  댓글주소  수정/삭제  댓글쓰기

    최소한 엔진과 로직의 계층은 분명히 나눌 수 있기는 할 듯 합니다.
    그런 의미에서 일의 관점이 아니라 논리적인 계층구조의 관점에서 볼 땐 나쁘지 않은 구조일 수 도 있을 듯 합니다.

    사람만 충분하다면

    엔진개발자 - 스크립터 - 기획자

    이런 구조를 가질 수 있다면 정말 이상적인 개발 환경이 될터 인데 말이지요

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.21 14:19 신고  댓글주소  수정/삭제

      넵 저도 그 이야기를 하고 싶은겁니다. ㅎㅎ
      스크립트를 사용하는게 나쁜게 아니라, 제대로 된 계층과 역활로 충실하게 하자는거죠 ^^

  13. Favicon of https://crass.tistory.com 래스 2011.12.20 00:21 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다.

    기획자 입장에서도 사실 스크립트의 사용은 굉장히 환영하는 바입니다.

    저희 팀 같은 경우엔, 퀘스트/인던 스크립트(..빌드를 하기 때문에 스크립트라고 불러야 할지 사실 좀 모호합니다만..;)를 기획팀에서 코딩하여 외부 DLL로 빌드하고, 서버를 띄우는 형태를 취하고 있습니다.

    접근성이 굉장히 떨어져 버린다는 단점이 있긴하지만..

    1. VC로 코딩, 서버 프로세스 연결해서 브레이크포인트 잡고 돌려 볼 수 있어서 디버깅 용이/기획팀에서 디버깅 가능
    2. 신규기능이 아닌이상, 프로그램팀에 쫓아가 징징대지 않고 처리 가능.

    등의 장점이 있네요.

    사족으로는, 프로그래머분들은 튼튼한 뼈대를 만들어 주시고,
    저희는 재밌는 살점을 붙일 수 있는, 그런 해피한 프로세스가 빨리 정립되었으면 하는 바람입니다.

  14. sgpro 2011.12.20 11:09  댓글주소  수정/삭제  댓글쓰기

    알콜코더님과 같은 생각을 하시는 몇몇 분들이 있네요.

    http://jacking.tistory.com/321
    http://blog.daum.net/gdocument/47

    두분다 경험담을 적은 글이고, 제가 스크립트를 도입할 때가 되면 주변 분들에게 보여드리는 글이기도 합니다. (이제 알콜코더님에 글도 같이 보여드려야 겠네요 ^^)

    그리고, 같이 보여드리는 글이 하나 더 있습니다.

    "스크립트 남용의 해악:game programming gams 1부 ( p.40 )"입니다.

    이글에서 가장 인상 깊은 구절은
    1. 스크립트 사용에 주된 원칙 : 로직과 데이터의 분리(복잡한 로직은 코드에, 그리고 데이터는 코드 외부에 두어야 한다)

    2. 스크립트 사용에 주된 원칙 : 스크립트란 일을 편하게 하기 위한 것이지 일을 어렵게 만들기 위한 것이 아님을 명심해야 한다.

    3. 스크립트가 위험한 이유는 스크립트가 데이터의 성격과 로직의 성격을 함께 가지고 있기 때문이다. 그래서 상태의 개수가 늘어나면 스크립트를 작성하는 것과 프로그램 코드를 작성하는 것에 별다른 차이가 없어진다.

    4. 게임 디자이너나 스크립트 작성자가 게임을 프로그래밍 하도록 해서는 안된다.

    5. 단! 퀘이크 C처럼 특별한 사례에 경우, 게이머가 봇을 직접 작성할 수 있도록 하는 것은 FPS에 있어서 매우 중요한 마케팅 포인트들 중 하나이며, 따라서 스크립팅 언어를 C 수준으로 복잡하게 만드는 것이 개발 자원의 낭비라고 할 수 없다. 하지만!!!! 이것은 특별한 사례임을 명심, 명심해야 한다.

    이러한 글들을 같이 개발하는 분들에게 보여드리는 의도는 스크립트를 사용하지 말자는 것은 아니구요. ^^;

    "스크립트 환경에 대한 위험성을 인지하고 조심스럽게 사용하자~" 입니다. (소중한 경험을 날로 먹는 거죠 ㅎㅎㅎ;; 항상 감사하게 생각합니다)

    그리고, 프로그래머가 계속 스크립트 환경을 제공하면 언젠간 기본적인 스킬로 정착이 되지 않을까요? 희망을 가져봅니다~ ^^;;;

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.21 14:21 신고  댓글주소  수정/삭제

      넵. 동감입니다.
      좋은 참고자료 링크 해주셔서 감사합니다.
      저도 많이 배우네요. ^^

      스크립트가 나쁜게 아니라.. 제대로 사용되고, 사용할 수 있는 개발 구조가 된다면. 분명 강력한 무기입니다. ^^

  15. Favicon of http://www.twitter.com/BurningBottle 버들 2011.12.21 01:53  댓글주소  수정/삭제  댓글쓰기

    200% 공감되는 글 잘 보았습니다. 현재 진행 중인 프로젝트에서는 초기에 C++ 로만 작업하다가 스크립트(클래스가 지원되는 Squirrel을 사용하고 있습니다)로 엔진 부분을 제외한 컨텐츠 메인 로직을 다 뺐다가, 요즘은 다시 스크립트에서 기획자가 만지는 부분만 제외하고 모두 C++ 로 옮기고 있습니다 ㅜㅜ

    타입에서 자유롭고 컴파일도 필요없는 특성은 굉장히 좋았지만, 메인 로직이 스크립트에 있다 보니 항상 프로그래머가 스크립트를 더 많이 보게 되었고, 입사해서 퇴사할 때까지 스크립트만 만지다가 나간 프로그래머도 있을 정도였습니다. 디버깅의 불편함 때문에 까먹은 개발 기간이 지금 생각해 보면 너무나 아깝네요. 앞으로의 프로젝트에서는 스크립트를 정말 필요한 부분에만, 소극적으로 사용하고자 생각 중입니다.

    한 가지 덧붙히자면 우리 팀의 기획자 분들은 적극적으로 공부하시는 분들이라 참 복받은 것 같네요 ㅎㅎ

    • Favicon of https://gamedevforever.com 알콜코더 2011.12.21 14:22 신고  댓글주소  수정/삭제

      ㅋㅋ 저도 이전 프로젝트에서.. 전부 루아로 뽑았다가..
      결국은 다시 C++ 집어넣는 삽질을 한적이 있습니다.

      스크립트가. 명가의 보도는 아니죠. 과유불급이란 말도 여기에 해당되는 것 같습니다. ^^

      기획자 분들이 열심히 공부한다니.. 정말 부럽네요.
      잘만 활용하면, 분명 좋은 결과가 있을겁니당.

  16. Favicon of http://dalinaum-kr.tumblr.com 달리나음 2011.12.27 11:06  댓글주소  수정/삭제  댓글쓰기

    lua처럼 JIT이 성숙한 언어에서 수십배의 성능 차이가 발생할 수는 없을 겁니다.

    lua가 상대적으로 느린게 참이겠지만, 성능 상의 바틀넥이 있을만한 부분에 lua로 작성된 스크립트가 사용되기 보다는 변동 가능성 높은 정책적인 부분에 스크립트를 사용할텐데 그 경우 빨리 변경할 수 있고 빌드의 횟수도 줄이는 이점도 있을 겁니다.

    C/C++언어의 IDE의 이점을 감안해도 스크립트 언어가 제공하는 생산성을 따라오긴 어렵다고 봅니다. 해외의 프로그래밍 대회를 보시면 알겠지만 구글과 같은 기업에서 온 탑 코더 대회 출신들이 테러하는 경우가 아닌 경우에는 스크립트 언어나 함수형 언어를 쓰는 사람들의 생산성이 훨씬 높은 것을 아실 수 있습니다.

    사실 C/C++ 코드만큼 LUA가 익숙하지 않은게 문제가 아닐까 합니다. 누구에게나 편안 언어와 편하지 않는 언어가 있고 알콜코더님은 C/C++언어에 더 익숙하신 거죠. 그리고 편한 언어를 쓰는게 더 생산성이 높으신 것일테고요.

    언어의 성능차이, 글루코드를 사용하는 불편함
    언어의 익숙함과 간결한 코드를 고려한 생산성의 차이

    전자와 후자를 고려했을 때 실인지 득인지는 사람마다 다를 것 같습니다.

    • Favicon of https://gamedevforever.com 끼로 2011.12.27 11:28 신고  댓글주소  수정/삭제

      스크립트를 쓰지 말자 라는 내용이 아니라 억지로 쓰지 말자 라는 내용이니 달리나음님의 의견도 어느정도 포함하고 있는 글이라고 생각됩니다.. 물론 변동 가능성이 있는 부분들에만 스크립트를 사용하는게 당연하기에 달리나음님의 의견에도 공감을 합니다. 그런데 알콜코더님이 말씀하신 내용은 단순 변동 외에 AI같은 게임 로직을 스크립트로 옮기는 경우도 상당히 많은데 그런 부분에 있어서 '억지로' 스크립트로 빼게 되면 프로그래머가 스크립트를 만지게 되는 경우가 발생할 수 있고 그렇다면 프로그래머에게 더 익숙한 C++이 더 효율적일 수 있으니 '억지로' 스크립트로 빼는걸 하지 말자 라는 내용인것 같습니다. 아무튼 알콜코더님의 글과 달리나음님의 댓글처럼 프로그래머와 스크립트를 만질 팀원의 충분한 커뮤니케이션이 이루어져야 개발을 해나가는데 있어서 문제가 발생하지 않는것 같습니다 ㅎㅎ

  17. 코인1 2012.03.01 23:52  댓글주소  수정/삭제  댓글쓰기

    "대한 민국의 대부분의 게임 회사에서는 루아 스크립트는 바로 프로그래머가 개발하고 코딩합니다! " 그러니까 퀘스트 스크립트 코딩을 개발자가 한다는 말인가요? 그게 사실이면 그 회사들 명단 까발려야 하는거 아닌지...

    그라나도 에스파다를 예로 들면 꽤나 오래전부터 루아를 도입했는데 스크립트라 무거울 줄 알았던 서버도 잘 굴러가고 기획자들이 스크립트 직접 작성해서 지금은 여러가지 기능을 개발자 도움 없이 직접 만들 정도라고 인터뷰 본 적이 있고요

    드래곤 네스트라는 게임도 퀘스트 스크립트와 문서를 루아와 XML로 관리하고 있더군요. 퀘스트 하나마다 분량도 상당하고.. 아마 프로그래머는 루아를 C++에 붙이기만 했을테죠

    그 뿐만 아니라 구인공고 보면 UI나 기획자 요구사항에 루아 또는 액션스크립트 코딩 요구하는 부분이 많던데요, 그걸 개발자에게 넘긴다? 말씀하신 부분이 사실이라면 정말 충격이 큽니다...

  18. 나그네 2015.05.17 20:48  댓글주소  수정/삭제  댓글쓰기

    작성자 분이 본문에서 설명하는 문제 상황이 어떤 상황이냐면...
    코어 부분 (C, C++, Java 등) 개발과 스크립트 API 개발과 스크립트 작성을 결국은 모두 같은 프로그래머가 하는 경우입니다. 이 경우엔 결국 그냥 C, C++, Java 등으로만 개발하는 것만 못하는 상황이 되죠.

    물론 C, C++ 같은 딱딱한 언어는 '문법 설탕' 같은 것이 그다지 없기 때문에, 이 언어들로 로직을 작성하는 건 아주 귀찮은 일입니다. 라인 수도 많아질 테고... 하지만 아무리 그렇다고 하더라도 (어느 정도의 규모까진) 스크립트 API 를 개발하는 것보다는 쉽고 간단한 일입니다. 스크립트 API 란... 간단히 말하면 C, C++로 구현된 부분의 래퍼 API를 만드는 일입니다. 자칫하면 게임 개발보다 스크립트 API 개발에 시간을 훨씬 더 많이 잡아먹는... 배보다 배꼽이 더 큰 일이 되기 쉽상입니다. 스크립트 API를 만들어 두는 이유 중 하나가 코어 부분과 코어 언어에 대한 이해 없이도 쉽게 로직을 개발할 수 있도록 하는 것이라고도 할 수 있는데, 어차피 코어 부분을 개발한 프로그래머는 다 이해하고 있을 테니 스크립트의 필요성도 적을 테구요.

    규모가 커지면 스크립트 언어의 필요성도 같이 커지지만, '프로그래머 -> 코어개발, 레벨 에디터/기획자 -> 스크립트' 와 같이 분리가 되어 있지 않고 프로그래머 혼자 다 하는 상황이면 괜히 힘만 더 들어갈 가능성이 커집니다. 결론은 스크립트 언어의 도입은 신중히...