• 소개
  • 저서목록
  • 모든글
  • cat:개발
  • cat:음악
  • cat:개인
  • 네 저도 환생한 사람입니다.

    쉐이더 강좌 올려놓은거에 달린 너무나 진지한 댓글에 내가 단 답변…

    • 2012-02-29
    • 셰이더강좌 농담
  • 꽃미남 게임개발자로 널리 알려진 포프입니다

    얼마 전에 게임개발포에버에 글을 쓸 때 처음 여는 인사가 이거였습니다.

    • 2012-02-28
    • 농담
  • 그래픽 프로그래밍 팀장이 될 뻔 했었다....

    난 매우 직선적인 성격이다.. 특히 회사에서 일할 땐…. 말도 안되는 개소리는 개소리라고 말해주고… 실력이 없는 놈이 정치를 하려고하면 쌍욕도 잘해준다… 사실 주변에서는 이러면 적만 만들다가 회사 짤리니 조심하란 이야길 하는데… 내 자세는 언제나..

    • 2012-02-07
    • 개발일지
  • 거짓말로 버티고 사는 개발자...

    최근에 회사를 떠나야 했던 떠난 개발자가 있다. 뭐 짧게 짧게 여러 회사를 옮겨다녀야 하는 인간 중 하나인데…. (뭐, 그래야 하는 이유는 대충 다들 알테고)…. 어쩌다 오늘 그 인간의 블로그를 보게 되었는데 본인이 회사를 떠나게 된 이유를 설명하고 있었다. 나를 비롯한 많은 울 회사 직원들이 이 글을 아주 즐겁게 봤는데… 이게 세계 최고의 판타지 소설 '반지의 제왕'을 연상시키기 때문이라지….?

    • 2012-02-07
    • 게임업계 인생조언 개발일지
  • 여태까지 내가 출시한 게임들...

    조만간 어떤 책에 내 직군 인터뷰가 실릴 예정인데 거기에 들어갈 그림을 좀 찾다가 여태까지 내가 만든 게임의 패키지 박스 사진들을 모아보면 어떨까해서 대충 뚝딱 만들어봤더니 여태까지 출시된 놈이 총 13개….. (Collector's Edition박스는 제외하고.. 이놈은 그냥 포장만 멋지게 한거라…)

    • 2012-01-02
  • 게임 출시전 개발자가 갖춰야할 마음가짐

    아시는 분들은 아시겠지만 제가 2011년 9월에 스페이스 마린이란 게임을 출시했습니다. 다음은 이 게임을 마무리하는 도중 느꼈던 점을 아주 간단히 길게 정리해 놓은 글입니다. 게임을 마무리 지을 때 가져야할 프로그래머의 마음가짐, 아주 당연한 거라고 생각해왔는데 모르는 분들도 좀 계시더군요.게임 출시전에 가져야 할 마음가짐이란 간단히 말해 조홀라~ 조심하는 겁니다. 아무래도 코드를 수정 할 때마다 새로운 버그를 만들 확률이 높아지거든요. '뭐~ 버그 좀 만드는 거야 어떻다고... 나중에 고치면 되지~' 하시는 분들도 있을텐데요. 이런 마음가짐은 게임 마무리 단계에서는 먹히지 않습니다. 게임 출시 직전에 모든 것을 테스트할 시간이 굉장히 부족하거든요. 특히 몇 년 동안 제대로 작동하던 기능들을 전부 다 테스트할 수 있는 여력은 없지요.저는 주로 Xbox 360 및 PS3용 콘솔 게임을 개발합니다. 콘솔게임이 시중에 나오려면 반드시 콘솔 제작자(마이크로소프트 및 소니)가 정해 놓은 기술 테스트를 통과해야 하죠. 이 테스트를 신청한 시기부터 그 결과를 들을 때까지 걸리는 기간이 대략 1달입니다. 근데 만약 부주의하게 만든 버그 때문에 이 테스트에 실패하면 어떻게 될까요? 뭐, 버그 고쳐서 다시 테스트 신청을 합니다. 또 1달 기다리죠. 여러 번 버그를 만들면 어쩌죠? 뭐, 출시일이 지연되겠죠. 마케팅 하시는 분들 이미 돈 다 퍼다 부었는데....... 근데 이게 전부일까요? 아뇨... 테스트를 신청할 때마다 돈도 내야합니다. 얼마냐고요? 별로 안비쌉니다.  한 번에 몇 천만원 정도... -_- 왠만한 프로그래머 연봉 한 번에 날라가는 건 쉽죠. 자, 이제 문제점을 아셨나요? 출시날짜를 놓쳐서 돈 날리고 테스트 신청 하느라 또 돈 몇 번 날립니다. 이래도 별 문제가 아니라고 생각하신다면 여러분이 만든 버그때문에 테스트 실패할 때마다 봉급에서 몇 천 만원씩 까면......이제, '뭐~ 어떻다고?'하고 생각하시는 분은 없겠죠? -_-그럼 제가 이번에 느꼈던 경험을 바탕으로 게임출시 전에 반드시 해야할 일과 하면 안되는 짓거리(?)를 간단히 설명드리겠습니다.고장난 것만 고친다: 위에서도 말씀드렸듯이 코드를 수정할 때마다 새로운 버그가 생길 확률이 높아집니다. 게임 출시직전에 제대로 작동하고 있는 코드를 괜히 쓸데없이 만져서 프로젝트 전체를 망칠 위험을 감수하는 건 바보같은 짓입니다.타인의 코딩 스타일을 자기 기호에 맞게 바꾸지 않는다: 코드를 이리 저리 옮기는 것, 빈 칸 4개를 탭 하나로 바꾸는 것, 한 줄로 길게 쓰인 코드를 보기 좋게 여러 줄로 나누는 것 등... 뭐 다 좋은 일인데... 이런 짓을 하다가 버그를 만드시는 분들이 꽤 됩니다. 아무리 훌륭한 프로그래머도 인간인지라 실수는 하기 마련입니다. (본인을 절대 실수 안한다고 생각하시는 분들 계시나요? 당신은 무지할 뿐입니다... -_-) 각 프로그래머가 1달에 한 번만 실수해서 버그 만들어도 프로그래머 30명을 가진 팀에서는 하루에 하나씩 버그가 나옵니다. 남의 코딩 스타일, 이딴 게 맘에 걸리시더라도 그걸 굳이 게임 출시전에 고칠 필요는 없습니다. 그냥 노트에 적어놨다가 다음 게임을 만들 때 고치세요. 또 한가지 말씀 드리고 싶은 것은 개인적으로 정말 맘에 안드는 코딩 스타일이 있는데 사내 코드베이스에 그런 스타일이 만연해 있으면 그건 사내 프로그래머들이 동의한 코딩 스탠다드일 가능성이 높습니다. 이거 맘에 안든다고 자기 맘대로 바꾸기 전에 본인이 사회부적응자는 아닌지 한 번 진지하게 고민해주는 센스... ㅇㅇ?게이머(또는 테스터)를 만족시킬 수 있는 것만 고친다. 프로그래머의 자기만족은 무시한다: 수학적으로 옳지 않은 게 보인다고요? 최종 사용자(게이머)가 신경 쓸만한 것이이 아니면 고치지 마세요. 그 흔히 쓰는 포토샵의 레이어 블렌딩조차 수학적으론 틀리다는 거 아시나요? 하지만 포토샵을 사용하는 아티스트들은 별로 신경도 안쓰죠. 마찬가지로 게이머들도 수학공식에는 크게 신경 않씁니다. (오히려 수학공식 매우 싫어할껄요? -_-) 수학적으로 옳아보겠다고 프로그래머 맘대로 뭔가를 수정하면 이로 인해 피해를 보는건 동료 개발자들 뿐입니다. 다음과 같은 상황을 생각해 보죠. "아티스트 아찌들~ 울 게임에서 수학적으로 틀린 게 있었어요. 그래서 제가 이렇게 올바르게 고쳤거든요.. 무핫핫~ 그래서 최종 조명 결과가 좀 달라보일테니... 아트들을 다 고쳐주세요! 지난 2년 동안 만들어 왔던 아트들 다 고칠 시간 있죠?..... 뭐 마감이라서 없다구요?!? 하... 하지만 이게 수학적으로 맞는건데... 좀 해욧!" 이딴 식의 주장을 하는 본인을 발견하신다면... 우선 남들의 업무를 존중하는 법부터 배우세요. 본인 만족을 위해서 수학공식 파는 것도 좋고 제가 상관하고픈 바도 아닌데... 남들에게 불합리한 피해를 끼친다면 그냥 퇴사하고 절에 들어가서 홀로 게임 만드시라고 권해 드리겠습니다.그래도 반드시 고쳐야할 것이 있다면 그로 인해 조금이나마 영향을 받을만한 다른 개발자들 모두의 허락을 받는다: 본인이 고쳐야한다고 생각하는 것과 동료 개발자들이 고쳐야 한다고 생각하는 것에는 차이가 있을 수도 있습니다. 그들이 고쳐야한다고 생각하는 것이 더 중요할 수도 있지요. 만약 그렇다면 다른 개발자들의 업무부담을 늘리는 버그수정은 차라리 안하고 넘어가는게 납니다.이 위에 적은 이야기들... 사실 게임을 하나라도 출시해 본 프로그래머라면 다들 알고 있을 법한 상식이라 생각했습니다. 특히 콘솔게임을 출시해봤다면. 그런데 스페이스 마린을 마무리 하는 도중 이런 믿음이 깨진 일이 있었죠. 자칭 경력많은 콘솔 게임 프로그래머라고 하는 작자가 하루가 멀다하고 무수한 버그를 만들어 냈고, 제가 그걸 디버깅할 특권(?)을 부여받았더라죠. 근데...... 이 모든 버그들이 발생한 이유가 바로 이 몰상식한 놈이 게임 출시전에 갖춰야할 마음가짐을 몰랐기 때문이라지요..... 써글... -_-제발 프로그래머 아찌들 부탁인데... 게임을 출시할 때만큼은 좀 책임감있게 코딩합시다... 네?

    • 2011-12-16
  • 사진: KGC에서 발표하는 포프

    KGC에서 보내준 사진 중 잘나온 놈 몇장~

    • 2011-12-01
    • 발표
  • 이번 주의 바보짓 - Multiply 혼합 "연산"

    I absolutely love my darn stupidity. :)이번 주에 회사에서 multiply 혼합 연산을 사용해야할 일이 생겼다. UI 아티스트가 메쉬별로 글로우(glow) 효과를 입히고 싶어했고, 게임 스크린샷을 찍어다가 그 위에 포토샵 레이어를 입혀서 '이렇게 하자.'라고 보여줬는데...... 불행히도 그 PSD 파일을 이미 지워버렸단다 -_-;그래서 additive 블렌드 레이어를 썼다는 그 아티스트의 말만 믿고...  똑같은 메쉬를 두 번 그려서 additive 혼합 효과를 내봤는데 (처음 그릴 땐 일반적으로.. 두번째 그릴땐 그냥 단색만 출력하면서 blend op을 additive로 했음) 결과가 다르다.... 그럴수밖에....포토샵에는 additive란 이름의 블렌드 레이어조차 없거든 -_-;;;;; 왜 이걸 까먹었었을까.. 멍청한 나.....좀더 이미지를 자세히 관찰한 결과 Multiply 블렌드 레이어를 쓴 거 같았다. 그래서 '그럼 간단히 D3D에서 혼합연산을 multiply로 바꿔주면 되겠군.' 이라 생각했는데.. 어라 왠 걸? D3DBLENDOP_MULTIPLY란 놈이 없더군... '이상하다 분명히 예전에 본적이 있는거 같은데.. PC가 아니라 Xbox360하고 PS3였나?' 하고 포기할려는 찰라.... 블렌드옵이 아니라 소스블렌드 알파에 dest color를 사용해주면 그런 효과를 낼 수 있다고 조언해주는 울 팀장님... 쿨럭 -_-; 초보실수... 쿨럭쿨럭 -_-;;;; 이렇게 알고 있던 것도 아주 까맣게 까먹는 나를 보면....... 으음... 역시 멍청한 나...인생은 그런 거지.. 룰루랄라~ ^^ (절대 배우지 않는 자세... 보너스 + 2만점 -_-)참고로 아래는 포토샵에서 지원하는 레이어 블렌드 모드:

    • 2011-01-15
    • 포토샵 그래픽
  • 내가 생각하는 조명벡터의 방향

    빛의 벡터를 그리는 방법에는 사실 두가지가 있다.정점를 밑둥으로 하여 빛의 위치를 가리키는 벡터빛의 위치를 밑둥으로 하여 정점을 가리키는 벡터난 개인적으로 빛의 위치를 밑둥으로 두는 걸 선호하는데 그게 상식적으로 맞아서 일뿐 특별한 이유는 없다. 정점을 밑둥으로 하면 난반사광(diffuse lighting) 계산을 할 때 부호를 뒤집어 줄 필요가 없으니 속도가 빨라질 수도 있다는 주장도 있는데.. 쉐이더에선 아마 거의 차이가 없을거고.. CPU에서 차이가 있더라도 거의 미미한 수준... 이런 자잘한 최적화 때문에 상식을 깨는걸 별로 안좋아하기에 난 여전히 빛의 위치를 밑둥으로 밀고 나갈 예정..이걸 그림으로 표현하면(벡터 반사를 보여주긴 하지만) 대충 이런 그림...(출처 위키피디아)

    • 2011-01-10
    • 그래픽 수학 shader
  • 쉐이더 입문 책을 쓰고 있습니다.

    예전에 북미취업 시리즈 쓸 때, 잠깐 언급했었죠. 쉐이더 입문 책.... 현재 쓰고 있습니다. 이미 출판사와 계약은 마쳤구요. 지금은 열심히 쓰고 있습니다. 지난 몇주간 밤낮으로 썼더니 절반 이상은 쓴 것 같군요. (초고만요)일단 제가 지난 3년간 캐나다의 Art Institute 대학에서 쉐이더 강의를 했던 내용을 책에 담는 것을 목표로 하고 있습니다. AI 대학의 게임프로그래밍 학과에서 몇년 동안이나 가장 훌륭한 과목으로 손꼽혔을 정도니 아무래도 쉐이더 초보/입문자들에게 크게 도움이 될 거라 생각합니다.제가 생각하는 대상 독자는프로그래머인 경우: C++, DirectX를 마친 프로그래머, 3D 수학을 마친 프로그래머.테크니컬 아티스트: 특별한 사전 요구사항 없음제가 이 책을 내는 이유는 아직 이런 책이 시중에 없어서입니다. 강의를 하면서도 적당한 책이 없어서 아예 교재 없이 강의를 했다죠. 그렇게 하다가 이 자료를 개발한 것이고요. 시중에 나와있는 대부분의 책은 중급/고급자를 위한 겁니다. 따라서 초보자가 그대로 보면 뭔소리진 몰라서 그냥 포기하고 말죠. 초보자 내용이 간간히 DirectX 책에 소개되는 경우가 있지만 그 중에서도 마땅히 된 책이 없다고 생각하는 이유가너무 수박 겉핥기 식이다.또는 너무 이론이나 문법에만 치우쳐져 있다.또는 실무에서 그다지 도움이 안 되는 내용만 너무 많이 담고 있다. (따라서 지면수가 많다. 책값도 쓸데없이 비싸다.)등 입니다.따라서 이 책은 쉐이더 프로그래밍에만 초점을 맞추고, 정말 실무에 써먹을 수 있는, 아니면 실무에서 다른 기법을 써먹는데 기반이 되는 내용만을 다룹니다. 아무래도 테크니컬 아티스트와 쉐이더 입문에 입문하는 프로그래머가 모두 볼 수 있도록 하다보니 ShaderX나 GPU PRO등에서 볼 수 있는 고급기법들은 들어있지 않습니다. 저 책들하고 경쟁할 생각도 없습니다. 제 책은 순수히 입문자를 위한 책이고, 제 책을 읽고 쉐이더에 재미가 붙으신 독자분들이 ShaderX 등의 책을 즐겁게 보실 수 있다면 전 행복합니다. 그리고 쓸데없이 지면수를 늘리지 않으려는 것도(따라서 책값도 줄이는게) 제 목적 중 하나입니다.모든 내용을 한 권에 담은 무거운 책들이 난무하는 상황에서 어찌보면 모험을 거는 건죠. 그래도 출판사 측에서 흔쾌히 그러자고 해줘서 한 숨 놓았습니다.현재 제가 써놓은 초고를 따라하시면서 테스트를 해 주시는 프로그래머 분들이 두 분 계십니다. 한 분은 경력이 꽤 있는 게임프로그래머지만 HLSL 쉐이더 프로그래밍을 해보진 않으신 분이고, 다른 분은 경력이 거의 없으신 분이죠. 두 분다 이 책의 내용에 흡족해 하시고 있으니 기대를 좀 해보셔도 좋을 듯 합니다. (그리고 현재는 이분들이 주시는 피드백을 기초로 모자란 부분을 계속 더해가는 중입니다).몇 주만 더 밤낮으로 일하면 초고는 다 끝납니다. -_-;업데이트(2010년 12월 31일):한글판으로 나옵니다. (물으시는 분들이 많으셔서)업데이트(2011년 11월 18일):그냥 인터넷에 공개합니다. (출판사 사정으로 출판이 애매해져서)

    • 2010-12-30
    • 도서 그래픽 shader
    • 이전
    • 1
    • 2
    • 3
    • 4
    • 다음
Copyright © 2010 - 2023. Pope Kim
English