1주차 요약: Flame을 사용해보기
지난 1주차에는 기존 게임 엔진들과 Flame의 특징을 비교해보고, Flame에 대해 알아보면서 간단한 예제 코드를 작성하여 가장 기본적인 형태의 게임을 만들어 보았습니다. 이 과정에서 보통의 Flutter 앱에 Flame의 위젯을 넣고 사용하는 방법과, Flutter 위젯과는 다른 Flame의 위젯의 생애 주기를 학습했습니다.
2주차: 주제 정하기
이번 2주차에는 어떠한 게임을 만들 것인지 주제를 정했습니다.
우선 Flame은 모바일(및 웹) 2D 엔진이기 때문에 이에 맞는 게임을 생각해보았습니다.
- 옛날 플래시 게임 초등학교 중학교 시절 컴퓨터실에서 하던 플래시 게임들입니다. 우리에게 이미 익숙하고 게임 방식도 단순하여 개발하는 데 큰 어려움은 없을 것이라 생각했습니다. 하지만 저작권 문제로 실제로 게임을 출시하려고 하면 문제가 생길 수 있고, 에셋도 구하기 힘들기 때문에 우리가 이미 알고 있는 게임을 개발하는 것은 힘들 것이라고 생각했습니다.
- 틀린 그림 찾기 보통의 틀린 그림 찾기와는 다르게 틀린 그림 찾기를 여러 플레이어가 같이 플레이하는 형태의 게임입니다. 기존에 존재하지 않는 독창적인 방식인데다, 멀티 플레이 방식만 학습하여 구현하면 개발의 난이도도 어렵지 않을 것이라 생각했습니다. 하지만 가장 중요한 부분인 “틀린 그림” 에셋을 어디서 구하느냐가 문제가 되었습니다. 이미 있는 그림은 구하기도 쉽지 않고, 구한다고 해도 출시 목적이면 사용을 할 수 없습니다. 직접 그리는 건 쉽지 않고, 디자이너를 구하는 것은 비용 문제로 현실적으로 불가능하다고 생각 되었습니다. 가장 현실적으로 생성형 AI를 사용해서 틀린 그림 찾기에 사용 할 그림을 제작하기로 하였습니다. 하지만 그림을 그려줄 수 있는 상용 AI 툴들의 경우 특유의 AI 그림체를 지우기 힘들 뿐만 아니라 틀린 그림이 들어간 서로 다른 이미지를 만들어도 우리가 생각하는 틀린 그림 찾기와는 다른 모습으로 나와 현실적으로 AI로 그림을 만드는 것도 불가능하다고 생각했습니다.
자체 에셋
스터디를 시작할 때 게임의 퀄리티가 괜찮으면 출시까지 하기로 했기 떄문에 에셋을 구하는 게 가장 큰 문제였습니다. 스터디원 셋 다 개발자인 것도 이유 중 한 가지이고, 게임 에셋을 만드는 것 자체가 쉬운 일이 아니기 때문입니다.
그래서 웹이나 앱 게임 중에, 에셋이 없거나 굉장히 간단한 게임을 생각해봤습니다.
Agar.io를 필두로 한 다양한 io 게임들이 대부분 에셋이라고 할만한 게 거의 없고, 웹 및 앱 기반입니다. 거기에 다양한 io 게임들이 나오는 것을 보아 게임 내 여러가지 요소를 추가해 재미를 추구할 수 있는 부분이 많이 존재할 것으로 생각합니다.
최종 주제
io 게임의 에셋 디자인에서 발전 시켜 몇 가지 사항들을 결정하였습니다.
- 3가지 구황 작물 (감자 ☻고구마 ☻옥수수 ☻)가 싸우는 컨셉의 게임
- 1대 1 게임이며, 각 플레이어는 3가지 중 원하는 캐릭터를 고를 수 있음
- 각 캐릭터는 고유한 스킬을 가지고 있으며, 이 스킬은 성장할수록 발전시킬 수 있음
- 이 발전 방향 또한 플레이어가 자유롭게 조절 가능
- 플레이 타임 약 10분
이 외의 세부 사항들은 개발을 진행해 가면서 회의를 통해 발전시킬 예정입니다.
멀티 플레이
게임을 하게 되면 필히 서버와의 통신이 필요합니다. 또한 다른 플레이어와의 상호작용도 처리해야 합니다. 보통의 pc 게임들은 한 번에 수많은 사람들이 접속하기 때문에 Server - Client 구조가 필수적입니다. 하지만 우리가 만들 게임은 두 명의 플레이어, 즉 클라이언트가 서로 게임을 진행해야 합니다. 플레이어 수가 많아지게 되면 어떻게 될지 모르겠지만 일단은 두 명의 플레이어가 게임을 진행하는 데에 서버까지 필요할까 라는 의문이 생겼습니다. 그래서 보통의 게임들은 멀티 플레이어를 어떻게 처리하는지 알아보았습니다.
Server-Client
기본적인 구조입니다. 중앙에 서버를 두고 클라이언트가 여기에 연결되어 통신하는 방식입니다. 이 방식도 두 가지 세부 방식이 나눠집니다.
- 서버 처리 방식 클라이언트가 서버에 입력 값을 보내면, 서버에서 이벤트를 처리하고, 다시 클라이언트에 보내는 방식입니다. 모든 정보가 서버에서 모이고, 모든 처리를 서버에서 합니다.
- 장점
- 많은 플레이어가 동시에 상호작용이 가능합니다.
- 모든 이벤트가 서버에서 처리되기 때문에, 클라이언트 단에서 조작이 불가능합니다. (핵 사용 불가)
- 같은 원리로, 동기화가 편리합니다.
- 단점
- 서버에서 모든 걸 처리하기 때문에, 서버에 부하가 많이 걸립니다.
- 서버 비용이 많이 들어갑니다.
- 즉각적인 반응이 힘듭니다.
- 서버 동기화 방식 클라이언트에서 입력 값에 의한 이벤트를 처리하고, 이 결과 값을 서버에 보내면, 서버는 이를 다른 클라이언트들과 공유만 하는 방식입니다.
- 장점
- 많은 플레이어가 동시에 상호작용이 가능합니다.
- 속도가 빠릅니다.
- 단점
- 클라이언트에서 이벤트를 처리하기 때문에, 잘못된 처리를 서버에서 검증하지 않으면 조작이 가능합니다. (핵 사용 가능)
Peer To Peer(P2P)
게임을 플레이하는 플레이어간 연결을 통해 게임을 진행하는 방식입니다. 플레이어간 직접 연결이기 때문에 적은 인원의 게임에 주로 사용됩니다.
- 장점
- 직접 상대방에 메시지를 전달하므로 속도가 빠르고, 서버의 부담이 최소화됩니다.
- 클라이언트가 직접 모든 걸 처리하기 때문에, 클라이언트의 성능이 좋을 경우 게임의 성능도 좋아집니다.
- 단점
- 서버를 거치지 않기 때문에, 잘못된 처리를 막을 수 없습니다. (핵 사용 가능)
- 여러 클라이언트 간의 동기화가 힘듭니다.
이러한 단점을 막기 위해, 클라이언트 하나가 사실상 서버의 역할인 HOST가 되고, 나머지 클라이언트들이 여기 접속해서 게임을 플레이하는 Super Peer 방식도 존재합니다.
Supabase
우리가 만들 게임은 P2P 방식이 적당해 보이지만, 그렇다면 P2P 방식의 통신도 구현해야해서 어떤 식으로 구현할지 찾아보다가, Flame 개발자들을 위해 게임 서버를 제공하는 패키지를 찾았습니다.
‣
유저가 많아지면 유료 요금제를 사용해야 하지만, 유저가 적을 때는 무료 요금제로 사용할 수 있기 때문에, 우선 개발 과정에서는 Supabase를 사용하고, 이후 유저가 많아지면 다시 고민해보기로 했습니다.
3주차 계획
3주차 계획은 다음과 같습니다.
- supabase를 설치
- 멀티 플레이 접속
- latency 체크
그리고 지연시간이 멀티 플레이에 적합하다고 판단되면, 앞으로 지속적으로 supabase를 사용하면서 latency가 늘어나지 않는 방향으로 개발할 예정입니다.