We’ve been working with lots of OpenGL code today, so I thought I should document some of the resources we’re using. These might prove useful for others, too.
Framebuffer Object 201 – GameDev.net
Official OpenGL Documentation for glFramebufferTexture2D, which is very closely related to glFramebufferTexture2DEXT() and glFramebufferTexture2DOES() [most importantly, for iPhone OS]
Using Framebuffer Objects to Render to a Texture - iPhone Dev Center
Using a Framebuffer Object as a Texture - Mac OS X Reference Library
Forum – Render to Texture Example – Related to this Developer Forums post on how to Blit from one GL_TEXTURE_2D to another
GLPaint Dissected – Forays into iPhone OpenGL ES – Introduction
FBO direction – iDevGames – iPhone Game Developers Forum – Render to texture example
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); // notice the 'f'. is this guaranteed to fail?
rendering to an offscreen framebuffer – apple discussion forums
That’s all for now.
혹시, 문제가 되면, 바로 지우도록 하겠습니다.
Feature creep이라는 말이 있습니다. 게임 개발 뿐만 아니라 많은 소프트웨어 개발 프로젝트에서 발견할 수 있는 것들입니다.
마침 위키피디아에서 feature creep을 잘 설명한 글이 있습니다. (링크) 요약해보죠.
- 제품을 개발하다보면 사용자들이 원하는 기능과 쓸모있는 기능들을 넣고자 하는 열망이 생긴다. 그리고 그렇게 함으로 매출을 올리고자 한다. 아이러니하게도, 이것이 feature creep의 시작이다.
- feature creep이 지속되면 불필요한 기능들이 자꾸만 들어가게 되고 프로젝트의 복잡도가 증가하며 제품의 특장점과 핵심 기능이 서서히 감춰지게 된다.
- feature creep은 이미 개발된 (혹은 개발중인) 프로젝트를 유지하려는 의지가 원인이 되기도 한다.
- feature creep은 프로젝트의 개발 비용을 과다하게 증가시킬 뿐만 아니라 프로젝트를 죽여버리는 원인이 되기도 한다.
Feature creep으로 진화된 물건. 바지 주머니에 넣으려면?
feature creep은 매우 흔합니다. 당장에 여러분이 참여하고 있는 프로젝트에서도 발견할지도 모릅니다.
feature creep을 일으킬 수 있는 위험인자는 흔하게 널려있습니다. 여러분의 직장 상사, 여러분의 친인척들, 심지어 여러분 자신 및 여러분이 지금 열심히 보고 있는 책에도 있을 수 있습니다. 저 또한 많은 feature creep에서 고생해본 사람이기도 합니다.
어떤 경우에서 생기는지 보도록 하죠.
프로그래머들은 신기술이 나오면 바로 적용해보고 싶어합니다. 뭔가 엘레강스한 대단한 아키텍처(나중에 알고보니 안티패턴임을 뒤늦게 깨달을)를 적용해보고 싶어합니다. 어느날, 모노리스 코드가 만들어지고 심지어 자기 스스로도 감당하기 힘든 복잡도를 가진 괴물을 만들고 맙니다. 그리고 회사가 개발 일정과 (자금이) 나빠지면서 슬슬 구인 게시판을 뒤져보기 시작합니다. 중요한 실력과 정교한 개발보다 많은 시도를 해보고 싶어하는 (나쁘게 말해서 회사를 상대로 실험해보려는) 모험심 강한 (그러나 실력과 책임감이 그만큼 받쳐지지 못하는) 프로그래머에게서 볼 수 있습니다.
게임 기획자들은 대단한 게임을 만들고 싶은 마음에 여러가지 아이디어들을 계속 집어넣습니다. 다른 게임에서 감동한 기능들을 자꾸만 넣습니다. 뭔가 엘레강스한 완성도의 게임을 꿈꾸며 대량의 기획서를 작성합니다. 그리고 플레이를 해보니 별로 재미가 없습니다. 안되겠습니다. 뭔가를 추가해야겠다고 생각합니다. 장르도 늘어납니다. 처음에는 액션 게임이었는데 만들다보니 MMO + RPG + 전략시뮬 + 커뮤니티 + 어드벤처 + 음악댄스 + 영어교육 게임이 되어버립니다.
경영진,마케터,운영팀도 feature creep에 일조합니다. 유저들의 피드백, 시장 현황, 소문 등은 개발 방향에 자꾸만 쓸데없는 암세포를 붙이게 합니다.
횟집은 뭐니뭐니해도 회가 신선하고 맛있어야 합니다. 스끼다시와 매운탕만 잔뜩 줘봤자 회가 물러터졌으면 소용없죠. Feature Creep은 동네 음식점에서도 흔히 볼 수 있습니다.
feature creep으로 고생하는 게임 개발 프로젝트의 공통점은 다음과 같습니다.
- 프로젝트 초기에 만들려고 했던 것이 분명하게 구체화되어있지 않았습니다. 아무것도 구체화되어있지 않으면서 정작 만들고자 하는 것은 거대한 꿈 덩어리입니다.
- 현실 감각을 잊은 지나친 열정을 갖고 있습니다. 단 한개의 궁극 완성도 제품을 만들려는 열망만 가득합니다. 현실적으로, 신차를 개발해도 포니부터 시작해야 소나타도 만들고 그랜저도 만들고 궁극적으로 에쿠스도 만드는건데, 처음부터 페라리를 만들려고 합니다. 즉 프로젝트 범위의 상한선을 미리 그어놓지 않았습니다.
- 디렉터가 중간 결과물이 별로 마음에 들지 않는다는 이유로 당황합니다. 그리고 돌파구를 "더 멋진 시스템의 추가"에서 찾으려만 합니다. 그냥 버리고 완전히 새로운 것을 시작하는게 더 나을 것 같은데 말이죠.
단도직입적으로 말하죠. Feature creep은 가장 쉬우면서 무능력한 개발 방향입니다.
Feature creep이 "자꾸만 넣는다"인데 이에 반대되는 말은 "더 이상 뺄 것이 없을 때까지 빼기"입니다. 그리고 더 이상 뺄 것이 없을 때까지 빼버리고, 남은 것들에 대해서는 최고의 품질을 만들기 위해 집중을 한 제품 중에서는 시장에서 성공한 것이 많습니다. 제가 생각하는 이러한 예는 비주얼드, 광란의 수족관, 팡야(골프게임), 아이팟입니다. ProudNet을 쓰는 프로젝트 중 몇 개도 있고요.
혹시 여러분의 프로젝트에서는 알게 모르게 feature creep이 범해지고 있지 않나요?
