최흥배 멘토님 소개
게임 리뷰
게임리뷰 진행
피드백
인디게임 대회에 내면 좋을 것 같다.
국내 인디게임 대회도 있고, 해외 인디게임 대회도 있다.
명확한 목표를 가지고 인디게임 대회를 참여해봐라!
Q) 그래픽 라이브러리는 어떤 것을 사용하고 있나?
→ 우선은 42에서 정해준 mlx라는 라이브러리를 사용중이다.
SDL이라는 라이브러리가 있다. 이걸 사용하면, 지금 사용하는 코드를 재사용할 수 있다.
2D 크로스플랫폼 라이브러리가 있다.
C, C++ 지원해준다.
게임을 계속 만들고 싶다면 유니티를 사용해라
대신 유니티를 사용하면 전부 다시 코딩해야한다.
Q) map은 어떻게 만들었나?
→ 지금은 0101 로 파싱해서 쓰고있다.
지금 방식도 좋지만 map tool을 만들어서 하는게 좋을 것 같다.
map tool이 하는 역할이 text파일로 만들어내서 그 파일을 읽는 것.(시간이 많이 걸릴 수 있다)
txt 파일로 따로 뺄것(data <-> code 분리), 맵툴 만들것, 유니티에서 맵툴 제공해줌
보통 아티스트, 기획자, 개발자가 함께 작업하는데
map tool이 있으면 기획자, 아티스트만 작업해서 map 디자인을 넣을 수 있다.
하지만 unity는 map tool을 제공한다!
map tool을 만드는 것은 학습 목적이고, 실용적이라고 할 순 없다!
코드리뷰
Q) scene으로 나뉜 것
→ unity 에서 경험한 것을 토대로 만들어봤다.
Q) script파일은 ??
→ 코드 파일내에서 캐릭터,
lua라는 언어를 사용한다.
script언어 안에 로직을 넣는다.
보통 사용 게임들은 프로그래머는 게임 틀만 잡아주고 기획자들이 스크립트 언어를 조정한다.
프로그래머의 1차 목표는 로직
게임의 재미는 기획자 분들이 결정한다.
로직 수정할때마다 프로그래머가 수정해줘야하니까 비효율적이다 → 스크립트를 씀
기획자도 script파일을 어느정도 다룰 수 있다.
모든 회사가 같은 방향으로 진행하지는 않는다.
스크립트 언어를 적용해야 프로그래머, 기획자의 자율성이 올라간다.
패키지 게임은 대부분 스크립트 언어를 지원한다.
대표적인 예가 World of warcraft!
유저마다 UI가 다르게 나올 수 있다.
일반적인 script 폴더에는 위와같은 lua script언어파일들이 들어있다.
unity입장에서는 C#이 script언어로 받아들인다.
알게 모르게 script언어를 많이 쓴다.
게임 개발을 한다면 script언어는 꼭 만나게 될 것 같다!
다시 코드리뷰!
코드를 보니 구조는 잘 잡혀있는 것 같다!
asset, engine으로 나눈 것은 좋은 것 같다.
보기 좋은 코드가 무조건 좋은 코드이다.
그래서 if 문은 무조건 중괄호를 치는 것이 좋아보인다!
중괄호가 없으면 한눈에 코드가 들어오지 않는다.
관계 없는 코드는 엔터로 띄워 두는 것이 좋다!
관계 있는 코드끼리 붙여두는 것이 가독성이 좋다.
가장 중요한 것은 코드의 일관성이다!
어떤 곳에선 중괄호를 작성하고, 어떤 곳에서는 중괄호를 작성하지 않으면 보는 사람은 이해하기 어렵다.
깔끔한 코드는 몇달 뒤에 봐도 이해할 수 있다.
필요한 부분은 주석도 중요하다.
주석이 없는 코드가 가장 좋은 코드이긴 하다!
하지만 아직 그정도 실력이 안되기 때문에 주석을 열심히 달자!
변수나 함수 이름을 봤을 때, 무슨 일을 하는지 알 수 있으면 가장 좋다.
→ header 파일은 어떻게 나누는게 맞는지 고민이 많이 된다.
A) 원칙은 .c하나당 .h하나를 만들어야 한다. 없으면 제 3자가 보면 고민에 빠지게 된다.
보통은 1:1로 맞추게 되는데 그러면 헤더가 길어지니까 header.h 파일을 만들어서 해당 파일에 모든 .h파일을 넣어두긴한다.
하지만 단점은 하나만 바꿨을 때, 엮인 모든 파일이 재컴파일 되는 상황이 생길 수 있다.
팀마다 다르기 때문에 컨벤션을 맞추면 될 것 같다.
콘솔게임 (C++)등은 한번 빌드할 때, 2시간씩 걸리기도 한다. 보통 퇴근할 때 빌드하고 가기도 한다.
분산빌드 인크리드빌드 or 빌드 파일 다 나눠서
클라이언트 개발은 유니티, 언리얼을 하면 된다.
하지만 바로 유니티, 언리얼을 하면 엔진을 자동으로 해주기 때문에 내부 로직을 알기 어렵다.
신입 개발자 채용을 할 때, 로직에 대한 질문을 많이 한다.
unity만 해본 사람은 대부분 잘 모른다.
새로운 기술로 넘어갈 때에는 근본 원리를 아는 사람과 모르는 사람은 차이가 무조건 있다.
예를 들어서 시야에 벗어난 것은 화면에 출력하지 않아도 되는데 이런 것들을 어떻게 처리하는지 질문을 한다.
Q) 직업적인 프로그래머에 대해서 어떻게 생각하나?
→ 이것저것 해보면서 공부하는 중이다.
다 잘하면 좋지만, 하나를 정해서 하면 좋다.
→ 프로그래머와 기획자가 어느정도 나누어져 있는지 궁금하다.
A) 회사, 팀마다 다르다.
철저히 분리된 회사도 있고, 같이 하는 회사도 있다. 대부분 큰 회사들은 분업이 철저히 나누어져 있다.
작은 회사들은 대부분 같이 하는 경우가 많다. 큰 회사에서도 같이 하는 경우도 있다.
팀마다 다르다. 기획에 참여하고 싶으면 작은 회사가 확률적으로 높긴 하다.
그래도 평가는 할 수 있다. 실제로 구현해봐야 알 수 있는 것들이 많다.
시장조사는 해보는게 좋다
Q) 네트워크가 생각보다 불안정하다
•
액션게임은 클라이언트도 잘해줘야댐 (유저가 봤을때 그럴듯하기만 하면 된다)
◦
센스있게 적당한 지연은 숨긴다
•
네트워크 불안정한건 어쩔 수 없음
•
데이터 계산은 서버에서 한다 + 클라이언트한테 시키기도한다.
◦
해킹의 위험이 있다.
◦
데디케이티드 서버
▪
서버 → gui 출력 안함
▪
클라이언트 → 그대로 출력
•
한국은 다 온라인 게임 or 인디 패키지 게임
◦
패키지 하고 싶으면 외국(미국, 일본)으로...
◦
한국에서 클라이언트 경력 쌓고 해외로 이직하는것도 나쁘지 않다.
Q) 클라우드를 쓰는지?
•
자체 클라우드를 쓰기도함 openstack으로
•
aws azure gcp
◦
aws가 압도적
▪
사람들이 많이 쓴다, 편하다, 배우기 쉽다. 책/유투브 굿
▪
azure 랑 gcp는 docs를 읽어도 모른다
◦
구글/마소가 싸게 해준다 그래서 씀 + mssql 이나 window 쓰니까 azure 쓴다.
◦
게임 서버는 window os 를 많이씀
•
클라우드 장점 : 머신을 마음것 금방 고를수있다.
Q) 도커 쿠버네티스?를 쓰나요?
•
웹쪽은 표준에 가깝게 쓰이고 있다.
•
게임쪽은 아직까지는 아니지만 점점 쓰는 추세다
◦
게임서버는 window 이다보니까 도커를 쓰지는 않는다.
◦
애니팡 → 웹서버 방식 이런건 도커/쿠버네티스 가능하다
◦
but 온라인 게임은 실시간 통신이 많다. tcp, udp 통신해야되는데 도커 쿠버네티스 장점 살리기어렵다
◦
실시간은 서버 죽이고 살리고가 마음대로 못한다
◦
도커까지는 그래도 할만한거같은데 쿠버네티스까지는 좀.. 학습하기 복잡하다
Q) 왜 window os를 쓰나요?
•
한국은 PC 게임으로 시작하는데 이떄는 윈도우였다
•
그래서 계속 윈도우로 개발하는게 내려오고있다.
•
리눅스 쓸수있어도 윈도우 쓴다. os단에서 문제생기면 윈도우 노하우가 있기때문에 윈도우를 쓴다.
•
윈도우 : 유료 ← 매우 작은 비용
•
한국 : 특히 실시간은 윈도우를 씀
•
해외 : 케바케 + 리눅스 서버
•
클라이언트 : 언리얼/유니티 써서 대부분 모바일
Q) 준비해두면 좋을것
•
서버 / 클라이언트 둘중 고르기
•
서버
◦
C++ : 소켓 서버
◦
C# :
◦
golang 도 괜찮다 → 실제 회사에서 이거 쓸 확률은 굉장히 낮다
◦
웹방식의 api 서버 만들어보기
◦
소켓 서버 만들어보기
▪
채팅 서버 (실제 게임 서버랑 거의 비슷하다)
▪
오히려 어려운걸 하지말고 간단한 채팅 서버가 낫다
▪
채팅 아니면 클라이언트 까지 만들어야해서 난감하다
•
서버코드가 난잡해진다.
◦
OS 기능을 잘 사용해야한다 (운영체제론에 대해서 잘 알아야함)
▪
window의 api를 잘 써야한다
◦
네트워크 기초는 필수!
◦
데이터베이스
▪
sql 기본 사용법
▪
테이블 정규화
▪
인덱스 원리 / 종류
▪
사실 게임쪽은 db 많은 기능 쓰지 않음
▪
그래서 mysql 많이 씀 가끔 mssql
▪
성능이 중요하기 때문에 데이터 중복하더라도 join 을 거의 안함
◦
서버 죽으면 진짜 큰일
▪
대부분 메모리에 올려놓고 성능 올림 but 죽으면 큰일
▪
그래서 적당한 빈도로 백업을한다.
▪
이전 데이터가 남아있으면 그나마 낫다
▪
어떻게 피해를 최소화할지
◦
redis 이거 진짜 대부분 씀 알아두면 편할듯
◦
조심할 버그 : 돈/아이템 복사가 제일 문제
▪
운영이 개판이라는 얘기 들음..
▪
유저가 화를 안내는 한도안에서 해야한다
▪
유저가 게임머니 조금만 잃어도 난리난다
▪
소멸되는 데이터 진짜 조심 돈/아이템은 바로 저장
•
클라이언트
◦
게임 프로그래밍 기본 알고리즘을 배우는게 좋다.
▪
알고리즘 기초 지식 알아야함 (진짜 수학을 잘해야함)
▪
3D 에서 물체를 클릭하는걸 어떻게 표시할것이냐
▪
Ray로 3D 공간상에서 객체를 선택하는 알고리즘
▪
앞으로 계속 일을 시킬거니까 이런 지식이 필요하다
▪
언리얼이나 유니티를 안 쓸 수 도있으니까
◦
요즘 대부분 3d 게임이라서 3d할줄 알아야한다
▪
directX vulkan? 을 쓸줄 아는거 3d로 오브젝트 표현/ 애니메이션 정도는 알고있으면 좋다.
◦
가끔 언리얼/유니티 만 할줄 아는지 물어보기도함
▪
근데 안가는게 좋다
▪
당장 일 시키려고 하는거다
◦
게임 포트폴리오가 필수로 있어야한다
▪
이론만 알고있는지,
▪
실제로 구현이 가능한지 확인해야함
▪
온라인 게임이 아니여도 상관없다.
◦
수학 싫어하면 클라이언트 쪽은 아니다... (근데 고등학교 수학 정도만 알아도 괜찮다)
◦
클라이언트는 C++ 가 필수다.
•
게임 개발자 단점
◦
게임의 성공의실패 : 유저가 좋아하면 돈번다
◦
엔터테인먼트 : 성공을 가늠할 수 없다.
◦
게임이 잘 될거라는 보장이 없다.. 성공 확률이 10%도 안되는듯
◦
구글 플레이 순위 50등 안에 들기만해도 억단위 버니까 성공으로 본다
◦
프로젝트 참가할때 개발자들도 게임의 성공을 고민하게 된다.
◦
처음에는 기획이 있는데 실체화하기전까지는 어떻게 될지 모른다 → 마지막 결과물이 이상하게 나온다
◦
게임이 재밌어야하니까 처음 기획이랑 다르게된다
◦
재밌게 하려다보니까 점점 다른 게임을 모방하게 된다.
◦
진짜 게임을 좋아해야 의욕이 생긴다 → 게임이 망하더라도 버틸만하면 좋다
◦
헛짓했다 이런 생각없이 앞으로 또 재밌게 하자 이런 마인드
•
게임 개발자 장점
◦
IT 쪽이라서 분위기가 부드럽다
◦
유투브보면서하거나 쉴떄 같이 게임하고
◦
새로운 프로젝트 할때마다 새로운 기술을 빠르게 배우고 적용하고 할 수 있다.
