출처 - 김주복님의 M2 아키텍처 리뷰
그래도 일단 완벽하진 않더라도 MMORPG 설계! 도전~!
도전은 도전이고.. 무엇을 목표로 도전?! '완벽'이란 무엇인가..
출처 - 김주복님의 M2 아키텍처 리뷰
오오미.. 이게 뭐시당가.. 완벽의 길은 멀고도 험란한 것이로군요..
아무튼 무엇을 목표로 할 것인지 김주복님의 개인적인 사견을 참고하여 하나하나 생각해 봅시다.
출처 - 김주복님의 M2 아키텍처 리뷰
먼저 성능!! 게임은 무조건 내 컴퓨터에서만큼은 원활한 플레이가 가능해야 한다!
최대한 최적화가 가능하도록 코드를 작성하는 습관을 들이고
구조적으로 최적화가 될 수 있도록 설계하는것이 첫번째 목표!
출처 - 김주복님의 M2 아키텍처 리뷰
나는 프로그래머다! 적어도 부끄럽지 않는 코드를 작성해야 하지 않을까?!
잘못된 설계는 문제있는 코드를 만들어내고, 문제 있는 코드는 프로그램의 품질을 저하시킵니다.
두번째 목표는 설계의 원칙을 준수하고 설계에 철학을 담는다!
철학이란 지식을 추구하는 과정이라고 합니다. 지식이란 알려고 하는 욕구이며, 알려고 하는 이유는 더 나은 삶을 살기 위함이라고 합니다. 이런 의미로 볼 때 소프트웨어의 철학이라고 한다면 소프트웨어를 만드는데 있어 더 나은 품질의 소프트웨어를 만들기 위해 필요한 과정으로 볼 수 있겠지요. 바꾸어서 이야기하자면 철학이 있는 소프트웨어와 그렇지 않은 소프트웨어는 품질에도 차이가 있을 것입니다. 거창하지 않더라도 소프트웨어를 작성할 때 목표가 있고 그 목표를 달성하기 위한 과정에 일관된 행위가 적용된다면 철학이 있다고 할 수 있겠습니다.
출처 - 김주복님의 M2 아키텍처 리뷰
우리 모두 라이브의 뼈아픈 경험이 있지 않는가.. (저희팀 프로그래머들은 모두 3년 이상의 라이브 경험이 있습니다..)
물론 모든 문제를 생각하고 만들수는 없지만, 적어도 예상되는 문제들은 생각해야 합니다.
간단한 시스템 하나를 추가해도 여기저기서 문제가 터지고..
하나의 새로운 기능 추가는 두 개 이상의 버그를 만들어내니..
그래도 최대한 구조적으로 간결하게! 의존성을 최소화하고! 기능의 모듈화! 데이터화!
출처 - 김주복님의 M2 아키텍처 리뷰
최대한 만들어놓은것을 나중에 사용할 수 있도록 한다!
코딩을 하다보면 가끔씩 느끼는 것이 있죠.. "아 이거 옛날에도 비슷한거 했는데.."
그렇다면 옛날에 만든것을 사용할 수 있으면 되는것 아닌가?!
출처 - 김주복님의 M2 아키텍처 리뷰
내가 작성한 코드, 하지만 나 혼자 작업하는것이 아니다!
지금 내 옆에 있는 프로그래머야 대화가 가능하니 다행이지만..
내가 얼굴을 보지 못할 프로그래머도 있을테니..
그렇다면 김주복님의 PT엔 무엇이 담겨져있을까?
출처 - 김주복님의 M2 아키텍처 리뷰
오오미.. 이건 또 뭐시당가.. 당신은 날 힘들게 하는군요..
하지만 최대한 노력해보겠습니다! (털썩.. Orz)
자 그럼 목표는 대충 정해진것 같고.. 이 목표를 어떻게 수행을 해야하지?
출처 - 김주복님의 M2 아키텍처 리뷰
일단 시작은 우리도 프레임워크 레이어링!
출처 - 김주복님의 M2 아키텍처 리뷰
그냥 무조건 김주복님 PT에 있으니 따라한다? 레이어 아키텍처의 장점이 무엇인지도 모른채? 그럼 안되지..
출처 - 김주복님의 M2 아키텍처 리뷰
시스템의 추상화, 구조의 의존성 최소화, 기능별로 나눠진 레이어 덕분에 이해가 쉽고..
사용 목적이 명확해지고, 의존성이 적기 때문에 확장도 용이하고..
레이어 아키텍처, 녀석 참 달달한 녀석이로군요..
크게는 Generic, Module, Application, Execution 으로 나누고
세부적으로 Core / Graphic, Network, Input, Sound / GameSystme, Application / 실행파일들 형태로 나눴습니다.
먼저 Generic!
Generic에는 Core와 Core.Net이 존재하고
Core와 Core.Net은 각각 C++과 C# 환경에서의 기본적인 기능들과 유틸리티를 가지고 있는 프로젝트들이죠.
두번째는 Module!
Module은 각각 Graphic, Network, Input, Sound로 구성되어 있으며,
각각 모듈의 인터페이스들을 구현한 프로젝트들로 구성되어있습니다.
어떤 모듈이 어떤 구현을 사용할 것인지는 Application 레이어에서 설정 가능!
(자세한 내용은 나중에 따로..)
GraphicModule과 GamebryoWrapper의 관계
GamebryoWrapper에서는 Gamebryo를 이용하여 각 인터페이스클래스의 실제 구현부를 만듭니다.
각 모듈들은 인터페이스 클래스인 소스들과 실제로 사용될 오브젝트들과 매니저로 구성됩니다.
소스의 역활은 실제 해당 기능이 실행되도록 하는 가장 원시적인 객체이고,
오브젝트는 이 소스를 사용하여 여러가지 추가적인 작업을 하는 형태이죠.
여기에서 모듈별로 필요하면 멀티코어를 활용할 수 있도록 하는것이 목표!
출처 - 김주복님의 M2 아키텍처 리뷰
멀티코어에 대한 고민은 코어의 수가 늘어나기 시작한 몇 년 전부터 항상 고민거리였습니다.
그렇다면 우리 프로젝트에서는 어떤식으로 멀티 코어를 지원하지?!
네뷸라3를 참고하여 Application 레이어에서 Object를 사용할때 각 기능에 맞게 여러가지 명령을 하게 되면
그 명령들을 쌓아두었다가 적당한 때에 Source에 입력해주는 형태는 어떨까?!
예를 들면 위치값을 가진다고 했을때, Object 따로 Source 따로 각자 가지고 있고,
한번의 Lock을 통해 동기화 하는 형태로 말이죠.
(가능하면 데이터를 쓰는 부분과 읽는 부분을 잘 정리하여 Lock없이도 가능하면 더 좋을듯..)
세번째는 Application!
Application 레이어에서는 게임 시스템과 사용하는 모듈들을 관리합니다.
GameBaseSystem에서는 서버와 클라이언트가 공통으로 사용하는 기능이 들어가고,
ClientSystem과 ServerSystem에서 각각 클라이언트와 서버에 맞는 시스템 구현을 하는 형태입니다.
그리고 ClientApplication과 ServerApplication에서는 어떤 모듈을 어떤 구현을 사용하여 실행할 것인지등을 설정하고
각 시스템들을 실행시키고 관리하는 프로젝트이죠.
게임 객체 설계는 상태 의존적인 컴포넌트 기반 게임 객체 간략 정리 를 참고..
마지막으로 Execution!
Execution 레이어에서는 실제 실행파일의 프로젝트들이 들어갑니다.
각 실행파일의 형태에 따라 클라이언트, 툴 등 형태에 맞게 구현!
아직 이 도전은 끝나지 않았습니다..
덧글