라인게임즈

게임개발자를 위한 클론코딩

✅ 잘못된 클론 코딩 게임 업계에서 개발자들의 포트폴리오로 자주 나오는 요소는 클론 코딩입니다. 본인이 좋아하는 게임을 만들어보기도 하고, 지원하는 회사와 가장 밀접한 프로젝트를 만들어서 제출하기도 합니다. 물론 아주 잘 만든 분들도 있지만, 대부분은 제출한 클론 코드가 안 좋은 결과를 만드는 경우가 많습니다. 어떤 경우일까요? 제가 경험한 사례를 좀 공유해보려고 합니다. ❇️사례 1. 스크린샷뿐인 모작 3년 전쯤 마인크래프트 모작을 제출한 분이 있었습니다. 마치 마인크래프트처럼 보이는 월드와 블록들이 있는 스크린샷이 있었습니다. 정말 똑같다(?)는 생각이 들 정도로 잘 구성된 스샷이었습니다. 그리고, 내용에는 이 모작을 만드는데 몇 주가 걸렸고, 만들 때 어떤 엔진을 사용했는지 기입해 두셨습니다. 당연히 이분은 탈락했습니다. 모작을 할 때 중요한 것은, 이게 얼마나 걸렸고, 무슨 엔진을 썼는지보다, 어떻게 구현했는지가 가장 중요합니다. 그런 관점에서 비슷해 보이는 단편적인 스크린샷은 오히려 전혀 매력적이지 않습니다. 오히려, 블록이 2개밖에 없더라도, 혹은 블록이 화이트 박스 형태더라도, 절차적으로 생성되는 월드나 직접 배치하는 샌드박스가 있다면, 훨씬 높은 점수를 줄 것 같습니다. ❇️사례 2. 핵심을 벗어난 모작 두 번째 사례는 캔디크러시 사가와 같은 매치3 퍼즐 게임 모작을 제출한 분이었습니다. 데모도 같이 보내주셨고, 본인이 작성한 핵심 소스 코드도 제출해 주셨습니다. 허나 아쉽게도 이분도 탈락했습니다. 가장 큰 이유는 데모를 플레이할 때 연쇄가 잘 되지 않는 점이었습니다. 3-매치 게임의 핵심은 레벨 디자인도 중요하지만, 한번 매치가 되어 블록이 사라지면 그 자리를 다른 블록들이 채우면서 발생하는 연쇄작용에 있습니다. 그 연쇄작용하는 코드가 미완성 상태였고, 실제로 제출된 코드에서 연쇄 구현이 제대로 되지 않았음을 볼 수 있었습니다. 비슷한 사례로, 간혹 액션 게임 쪽에서 채용을 할 때 마영전 모작이나 리니지 모작도 자주 볼 수 있는데, 거의 대부분 탈락 처리됩니다. 우선, 마영전 모작의 경우 클라이언트-서버 구조를 굉장히 강조하는 분들이 많습니다. 사실 왜 그걸 강조하는지 잘 모르겠습니다. (어쩌면 학원에서 그렇게 시켰을 수도 있겠죠.) 마영전의 핵심은 멀티플레이 논타겟 액션입니다. 제가 본 마영전 모작 중에서는 아쉽게도 마영전의 논타겟 액션 동기화를 본인만의 방식으로 만들어서 설명해주신 분이 없었습니다. 리니지 모작도 마찬가지입니다. MMO 서버-클라이언트 구조라고 강조하는 분들을 많이 봅니다. 정말 놀랍게도, 만드는데 2주밖에 안 걸렸다는 분도 있었는데… 어필 포인트가 너무 어긋나서 할 말을 잃었던 것 같습니다. 실제로 그런 분들 중에서 MMO의 핵심 요소 중 하나인 월드 채널링이나 MMO에서 퀘스트와 같은 콘텐츠를 본인만의 방식으로 만들어서 설명해주신 분들은 없었습니다. ✅클론 코딩을 포트폴리오로 만드는 방법 위의 잘못된 클론 코딩 사례가 거의 포트폴리오에 있는 클론 코딩의 90%를 차지하기 때문에, 클론 코딩을 포트폴리오로 만드는 방법은 생각보다 쉽습니다. 바로 안티패턴을 피하는 것이죠. 우선, 클론할 게임의 핵심을 아는 것부터 시작해야 합니다. 마인크래프트, 오버워치, 3-매치, 마영전, 리니지 등 다양한 게임들의 핵심은 모두 다릅니다. 그리고 주니어 개발자 입장에서 이런 핵심을 관통하기란 쉽지 않은 것도 사실입니다. 그러나 조금만 검색해보면 나오는 것도 맞습니다. 두 번째는 핵심 기믹만 모작하는 것도 가치가 있다는 것입니다. 예를들면, 포탈2의 들어가는 포탈/나가는 포탈은 다양한 기술적 챌린지(렌더링, 공간 이동)가 있습니다. 총게임들의 Netcode(예측, 보간)들도 꽤 좋은 챌린지가 됩니다. 그래서 이런 기믹들은 만들어서 포트폴리오에 넣으면 게임플레이 프로그래머로 홍보하기 좋습니다. 개인적으로 이런 핵심 요소를 클론한 유튜브 하나를 추천해드리면, Mix and Jam 이 있습니다. 제가 생각했을 때 클론코딩의 모범사례에 가깝고, 클론 코딩에 대한 좋은 예를 보실 수 있습니다. ✅마무리하며, 클론 코딩은 분명히 개발자로서의 역량을 보여줄 수 있는 좋은 방법입니다. 하지만 그 과정에서 중요한 것은 단순히 게임을 흉내 내는 것이 아니라, 게임의 핵심 메커니즘을 이해하고 그것을 구현하는 능력을 보여주는 것입니다. 단순히 비슷해 보이는 결과물을 만드는 것보다, 그 안에 숨겨진 원리를 이해하고 자신만의 방식으로 풀어내는 것이 더 중요합니다. ✅더불어 이벤트 홍보(?) 그래서, 이번에 저와 함께 클론 코딩을 도전해볼 사람을 찾습니다!! :) [챌린지 개요] 😀현직 개발자 멘토와 함께 4주 동안 클론코딩 챌린지 도전할 사람 찾습니다! 각 분야별 유데미 멘토들과 함께 클론코딩부터 코드리뷰까지 할 수 있는 기회! 💪이번 챌린지는 [프론트엔드 / 백엔드 / 게임개발] 진행 됩니다 :) 유데미 개발 챌린지에서 개발자 커리어를 시작해보세요! 🥇챌린지 참여 혜택 무엇이 있나요? * 현직 개발자와 라이브 특강 * 주차별 미션 제공 * 멘토와 1:1 커피챗 (미션 과제 우수자 선정자) * 참가 혜택 : 유데미 개발 강의 할인 쿠폰팩, 지난 챌린지 특강 제공 💌챌린지 자세히 보러가기 : https://udemy.wjtb.co.kr/event/id/272 🌞친구와 함께 신청하면 배민 상품권 제공! https://forms.gle/2fxpfmh68ioELCwG8 모집/신청 기간 : 2024년 8월 19일(월) ~ 9월 22일(일) 챌린지 진행 기간 : 2024년 9월 23일(월) ~ 10월 18일(금) 제가 맡은 게임 개발 챌린지 주제는 “뱀파이어 서바이벌(뱀서류) 클론코딩"으로, 라이브 특강에서 포트폴리오가 되는 모작 만들기, 현업에서 사용하는 게임 프로그래밍 디자인 패턴과 테크닉, 수강생 코드리뷰까지 함께 다뤄볼 예정입니다. 많은 관심과 참여 부탁 드립니다. 감사합니다.

더 나은 코드를 작성하기 위한 가이드북 《읽기 쉬운 코드》

✅ 모범적인 코드는 무엇일까? 프로그래머로 일을 하다보면 개발자들끼리 모범적인 코드에 대해 논쟁 하게 되는 경우가 더러 있습니다. ‘어떤 구조가 더 좋다.’ 혹은 ‘이건 실제로 내가 해본 경험이 있다‘등의 다양한 이유로 시작해서 누군가가 내 코드가 더 좋은 코드라고 주장을 한다거나, 당신이 작성한 코드가 모범적이지 않다고 하는 경우, 혹은 서로의 구조를 주장하다가 기분이 상하는 경우도 있습니다. 그래서 많은 코드리뷰 책이나 개발 문화 관련 책에서 “ 비자아적 프로그래밍 (감정을 배제하고)을 해라”, “ 지속 가능하게 코드 를 짜라"등의 이야기를 하곤 합니다. 허나, 실제로 경험해보면 우리가 사람인 이상, 이런 가이드는 유니콘을 찾아 떠나는 것처럼 실질적인 도움이 되지 않습니다. (실제로 비자아적 프로그래밍을 문화로 만들어보려고 했으나 3개월만에 포기했습니다. 다들 너무 많이 상처를 받았거든요.) 그렇다면 모범적인 코드는 무엇일까요? 이번에 제가 길벗으로 부터 지원 받은 “읽기 쉬운 코드"라는 책에서 모범적인 코드에 대한 힌트를 얻을 수 있었습니다. 바로 인간이 읽기 쉬운 코드 = 모범적인 코드 입니다. “읽기 쉬운 코드"와 더불어 리팩토링의 저자 마틴 파울러가 하는 핵심은 이렇습니다. “컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다.” ✅ 읽기 쉬운 코드 오늘 소개시켜 드릴 읽기 쉬운 코드 는 책 전반에 걸쳐, 어떻게 하면 인간이 읽기 쉬우면서 내 머리에 적합한 코드를 작성하는 가에 대한 팁들로 가득차 있습니다. 교양과 같은 책인 줄 알았는데, 확실하게 이야기드리면 “실용서"에 가깝습니다. 이 정도까지 디테일해도 되나? 싶은 느낌이 많이 들었던 책은 간만이였습니다. 제가 주로 다루는 C#을 기반으로 책이 작성되어 있어서, 저 같은 경우엔 책을 읽으면서 현재 본업에서 몇가지는 적용도 해보게 되었습니다. 특히, 9장 팀워크 는 엔지니어링 리드나 팀장을 맡고 계시다면 꼭 추천해드리는 챕터 중 하나입니다. 지속적인 통합(CI)라던가 작고 많이 커밋하기, 그리고 코드의 공동 소유 개념과 코드 리뷰등 정말 알찬 팁들이 가득했습니다. ✅ 책은 모범적 코드에 대한 답을 알려주는가? 책은 전반에 걸쳐 “모범적 코드란 무엇이다!“를 제시하기 보다는 모범적인 코드로 나아가는 방법 경험에 기반해서 제시하고, 읽는 이로 하여금 답을 찾게 해줍니다. 그래서 책의 저자도 그렇고, 추천서를 쓴 마틴도 그렇고, 모든 것의 전제는 소프트 웨어는 어렵다 에서 시작합니다. 그래서 섣불리 모범을 제시하기 보단, 기동성과 더 나은 코드 를 작성하기 위한 실용적인 방법이라던가, 어떻게 코드를 내 머릿속에서 정리하고, 팀에게 잘 전파하는지 등과 같은 코드를 “읽기 쉬운 방향"으로 보내는 방법들에 대해 경험적으로 풀어 나가고 있습니다. 대표적인 예를 들면 테스트를 작성하는 방법이나 테스트 코드를 위해 관심사 분리의 개념에 대한 팁을 이야기하면서 동시에 테스트가 너무나 많아져서 생기는 퇴행에 대해서도 다루는게 이 책의 핵심입니다. 그래서 재밌게도 마틴이 쓴 책 추천서를 보면 이런 내용이 나옵니다. 책을 읽으면서 동의하지 않는 부분을 찾아 내는 것이 얼마나 재밌을지 생각 했습니다. 그리고 정확히 그런일이 발생했습니다. (중략) 하지만 이건 중요하지 않습니다. 요점은 소프트웨어가 어렵다는 것이고, 지난 70년 동안 소프트웨어를 조금이라도 쉽게 만들 수 있는 방법을 찾기 위해 노력해왔다는 것입니다. 저도 이 책을 보면서 “이렇게 까지 해야하나?” 싶은 동의하지 않는 내용도 있었고, “와 이건 실용적이다"라는 것들도 있었습니다. 허나 천천히 음미해보면 전체적인 구성이나 내용들이 실용적인 내용으로 가득차 있고, 간만에 성장한 느낌을 받았습니다. 만약에 여러분이 소프트웨어 개발의 통찰력과, 더 나은 코드를 위한 통찰력을 얻고 싶으시다면 읽어보길 추천드립니다.