게임 시스템 개발 노트(4)-게임 프로그램 소개

게임 프로그램이든 다른 어떤 기능의 프로그램이든 개발자의 입장에서 볼 때 차이가 크지 않다.진정으로 차이가 비교적 큰 부분은 제품 디자인에 있어야 한다.
 
그러나 게임은 소프트웨어 세계에서 가장 대형과 복잡한 응용 중의 하나로 코드 규모는 기본적으로 백만행이라는 수량급에 있다.그래서 실현하려면 구조상의 정성스러운 디자인과 프로그램 언어와 프로그래밍 기교에 대한 유연한 운용이 필요하다. 그렇지 않으면 개발 과정에서 전설적인 소프트웨어 위기의 신마가 나타나기 쉽다.상용 소프트웨어에 대해 말하자면 먼저 타당성 문제를 해결해야 하고 그 다음에 해결해야 할 원가 문제를 해결해야 한다. 소프트웨어 기술은 이곳에 와서 가용성과 개발 효율의 균형을 이루는 예술이 된다.
 
물론 간단하게 말하자면 인터넷 게임의 프로그램은 단순한 C/S 구조 소프트웨어일 뿐이다. 바로 기본적인 인터넷 통신 기능을 바탕으로 클라이언트가 인터페이스 논리를 추가하고 서비스 측에서 게임 논리를 추가한 다음에 모든 클라이언트가 서비스에 요청을 해서 다른 클라이언트와 상호작용을 한다.
 
다음은 프로그램 구조에서 간단하게 인터넷 게임을 소개한다.
 
내가 본 프로그램은 주로 두 종류인데 하나는 기능형으로 특정한 문제를 해결하는 데 전문적으로 쓰인다. 일반적인 구조는 다음과 같다.
INPUT -> ALGORITHM -> OUTPUT는 기본적으로 순수한 알고리즘의 물건이다
 
또한 여러 모듈의 기능을 구현하고 오버헤드 문제도 함께 고려하도록 설계된 단일 애플리케이션 유형도 있습니다.

WHILE(COND) DO



   DO STH.



END

 
이 소프트웨어를 정상적으로 보이기 위해서, 순환 내부에서는 보통 막힌 조작 (예를 들어read) 이나 슬립 마운트 라인을 직접 호출해서 쓸데없는 성능 비용을 줄일 수 있다.
게임 프로그램은 자연히 두 번째 종류를 사용하는데, 우리는 게임 루프라고 부른다.
 
확장하면 간단한 게임 서버의 차이가 많지 않다.

 
  
GameInit();  //         



while(GameState != GAME_EXIT)

{

   

  FLUSH_NET_EVENT(); //      

  FLUSH_TICK_EVENT();  //      

  GAME_SLEEP(); //          ，      sleep  ，                   。

}



Release();  //   、     
  
  
일부 전형적인 게임 기능의 예, 예를 들어 캐릭터가 이동하는 과정은 프로그램에서 대체적으로 이렇게 몇 단계로 나뉜다.
1. A 유저 클라이언트는 버튼 메시지를 받고 게임 세계 좌표에서 이동하는 목표점으로 전환하여 서비스 측에 보낸다
2. 서버가 메시지를 받은 후 먼저 네트워크 메시지 대기열에 쌓여 처리를 기다린다(이때 현재 프레임이 네트워크 메시지를 처리했을 수도 있지만 다음 논리 프레임은 아직 시작하지 않았다)
3. 서버 pop 대기열과 이 이동 메시지 처리를 시작합니다(FLUSH NET EVENT)
4. 서비스 측이 검증을 거친 후에 서비스 측의 역할 위치 정보를 바꾸고 이동 메시지를 보내면 클라이언트가 이동에 동의한다.
5. 서비스 측에서 이동 메시지를 다른 클라이언트에게 전송하고 다른 클라이언트의'A유저'가 목표 지점으로 이동하도록 통지한다.
6. 다른 클라이언트가 서버에서 보낸'지시'를 받은 후 이동하는 이미지 효과를 나타낸다
  
물론 실제 게임에서 장애물, 길찾기, 위치 동기화, 지연된 느낌, 동기화된 데이터 양 등 더 많은 것을 고려해야 하기 때문에 상술한 과정에서 최적화를 해야 한다.
  
그리고 예를 들어 한 유저가 몬스터를 치는 과정:
1. 유저 클라이언트가 몬스터를 클릭하면 클라이언트는 마우스 클릭 위치(또는 캐릭터 위치)에 따라 유저가 어떤 조작을 하는지 판단한다.
2. 서비스 측에 메시지를 보내서 내가 몬스터를 칠 거라고 알려라
3、서버 등 FLASHNET_EVENT 
4. 서비스 측에서 이 요청을 검증하고 타격 조건이 있는지 판단한다.
5. 서비스 측에서 유저 클라이언트와 다른 유저 클라이언트에게 몬스터 처치를 하도록 통지한다.
6、서비스 측은 유저의 스킬 정보에 따라 이 몬스터에게 데미지를 판단하고 결산합니다
7. 클라이언트가'몬스터 처치 지시'를 받은 후에 몬스터 처치 애니메이션을 표현한다.
  
구체적으로 실시하는 것도 최적화된 부분이 있다. 상술한 이런 절차는 사실상 서비스 측에 의존하는 방법이다. 일부 게임 동작 요소가 강하기 때문에 이렇게 하면 지연 문제를 가져올 수 있고 더 많은 일을 클라이언트 자신에게 맡겨야 한다.이렇게 하는 주요 문제는 여러 클라이언트가 비교적 좋은 동기화 효과를 얻기 어렵고 외부 연결을 일으키기 쉽다는 것이다.
  
이러한 절차를 밟는 과정에서 일부 조작이 정해진 시간에 실행되어야 할 수도 있다. 그러면 정해진 시간에 이벤트를 등록하고 시간이 요구를 충족시킨 논리 프레임에서 그것을 가져와 실행한다.
  
물론 지금은 온라인 이동과 전투일 뿐 게임이라고 부르기 어려울 만큼 내용이 풍부한 게임 방법, 도구, NPC 시스템 등이 필요하다.그 중에서 대다수의 기능을 이 절차에 넣는 것은 사실 모두 특수성이 없기 때문에 끊임없이 누적된 코드만 있으면 할 수 있다.
  
특히 게임 제품은 데이터에 대한 의존성이 매우 크다. 간단한 스크린 게임을 하더라도 많은 관문, 서로 다른 총알이 서로 다른 외형, 비행 속도, 살상력, BOSS의 혈액량 등을 설계해야 한다.이 물건들을 모두 코드에 비벼 넣는 것은 매우 비현실적이며, 반드시 방법에 따라 논리와 데이터를 분리하여 간단한 방식으로 관련시켜야 한다.
  
그래서 현재 대형 게임에는 많은 데이터 테이블이 있는데 어떤 디자인 장비, 어떤 디자인 도구, 어떤 디자인 기능, 어떤 디자인 NPC, 어떤 디자인 수치, 임무 등이 있다.앞에서 묘사한 분업에 따르면 일반적으로 절차와 기획은 쌍방이 모두 받아들일 수 있는 방식(사실은 절차가 기획에 타협하는 것)으로 데이터 표를 작성하고 절차도 이 규범에 따라 데이터 파일을 분석한다.이렇게 하면 게임 프로그램이 시작되자마자 이 데이터를 메모리에 불러오고 해석을 통해 프로그램이 쉽게 사용할 수 있는 데이터 구조를 형성한 후에 개발하면 훨씬 수월해질 것이다.