더 복잡한 능력 시스템이지만 더 원활한 Gamedev 작업 흐름 – 어떻게?

안녕하세요! 저는 War Robots 프로젝트의 클라이언트 개발자 Vladimir Popov입니다. 이 글을 쓰는 시점에서 War Robot은 몇 년 동안 존재해 왔으며 이 기간 동안 수십 개의 새로운 기계가 게임에 등장했습니다. 당연히 로봇의 다양한 능력이 중요합니다. 왜냐하면 로봇이 없으면 로봇은 게임을 더욱 흥미롭게 만드는 고유성을 잃어버리기 때문입니다.

이번 포스팅에서는 게임플레이 능력 시스템이 게임에서 어떻게 작동하는지, 그리고 어떻게 발전해왔는지 공유하겠습니다. 그리고 좀 더 쉽게 접근할 수 있도록 기술적인 세부 사항을 너무 많이 넣지 않고 간단한 용어로 설명하겠습니다.

능력을 구현하는 방법

먼저, 프로젝트 기록을 자세히 살펴보고 더 이상 사용되지 않는 이전 구현을 살펴보겠습니다.

이전에는 능력이 매우 사소한 방식으로 설계되었습니다. 즉, 로봇에 하나의 구성 요소가 부착되어 있었습니다. 이는 프로그래머가 능력의 작동 방식, 즉 흐름과 다른 능력과 상호 작용하는 방식을 완전히 설명하는 구성이었습니다. 모든 로직은 하나의 구성요소 내에 설명되어 있으며, 게임 디자이너는 이를 로봇에 연결하고 필요에 따라 매개변수를 구성하기만 하면 됩니다. 능력의 흐름을 바꾸는 것은 불가능하다는 점을 언급할 가치가 있습니다. 게임 디자이너는 매개변수와 타이밍만 변경할 수 있었습니다.

기존 능력은 활성 및 비활성의 두 가지 상태로만 존재할 수 있으며 각 상태에는 해당 작업이 할당될 수 있습니다.

로봇 '스토커'가 이전에 보유했던 '재머' 능력의 예를 살펴보겠습니다. 그것은 다음과 같이 작동했습니다 :

1. 능력이 활성화되면 애니메이션이 표시되고 로봇은 방해 전파 상태에 들어갑니다. 이 상태에서는 다른 사람이 능력을 활성화하는 로봇을 겨냥할 수 없습니다.
2. 능력이 비활성화되면 아무 일도 일어나지 않습니다.
3. 능력을 활성화하려고 할 때 마지막 활성화 이후 n 초 이상 경과했는지 확인했습니다.
4. m 초 후에 자동으로 비활성화가 발생했습니다.

오랫동안 이 기능은 우리에게 충분했지만 시간이 지남에 따라 게임 디자이너와 프로그래머 모두 더 이상 이 접근 방식에 만족하지 않았습니다. 코드가 괴물처럼 변했기 때문에 프로그래머가 이러한 기능을 지원하기가 어려웠습니다. 여기에는 모든 상황을 설명해야 하는 매우 긴 레거시 체인이 포함되었습니다. 또한 게임 디자이너에게는 유연성이 부족했습니다. 능력을 변경하려면 인접한 능력이 동일한 기능을 가지고 있더라도 프로그래머에게 수정을 주문해야 했습니다.

새로운 능력 시스템을 입력하세요

그래서 우리는 뭔가 변화가 필요하다는 것을 깨달았습니다. 따라서 우리는 각 능력이 여러 관련 개체의 집합으로 표현되는 새로운 시스템을 개발했습니다. 기능은 상태 능력과 상태 구성요소로 나누어졌습니다.

어떻게 작동하나요? 모든 능력에는 주요 목표가 있습니다. 이 중앙 개체는 다른 능력 개체를 외부 세계와 연결하며 그 반대도 마찬가지입니다. 또한 모든 주요 결정을 내립니다.

상태는 얼마든지 있을 수 있습니다. 본질적으로 이 반복의 상태는 이전 버전의 활성/비활성 상태와 크게 다르지 않지만 이제 상태는 얼마든지 있을 수 있으며 그 목적은 더욱 추상적이 되었습니다. 능력은 한 번에 하나의 상태만 활성화할 수 있다는 점에 유의하세요.

이전 시스템과 비교했을 때 주요 혁신은 구성 요소였습니다. 구성 요소는 일부 작업을 설명하고 각 상태에는 원하는 수의 구성 요소가 있을 수 있습니다.

새로운 능력은 어떻게 작동하나요? 능력은 상태 중 하나에만 있을 수 있습니다. 주요 개체는 전환을 담당합니다. 상태에 연결되는 구성 요소는 상태의 활성화/비활성화에 반응하며 이에 따라 일부 작업을 수행하기 시작하거나 수행을 중지할 수 있습니다.

모든 개체를 사용자 정의할 수 있습니다. 게임 디자이너는 원하는 대로 상태와 구성 요소를 혼합하여 사전 설치된 블록에서 새로운 기능을 구성할 수 있습니다. 이제 프로그래머는 새로운 구성 요소나 상태를 만들기 위해 그림을 입력하기만 하면 되므로 코드 작성이 훨씬 쉬워집니다. 그들은 작은 개체로 작업하고 몇 가지 간단한 요소를 설명하며 더 이상 스스로 기능을 구축하지 않습니다. 이제 게임 디자이너가 이 작업을 수행합니다.

흐름은 다음과 같이 되었습니다.

1. 주 개체는 첫 번째 상태를 활성화합니다.
2. 상태는 모든 구성요소를 활성화합니다.
3. 상태는 능력이 다른 상태로 전환되는 순간을 결정합니다.
4. 주 개체는 이전 상태를 비활성화합니다.
5. 이전 상태는 해당 구성 요소를 비활성화합니다.
6. 주요 객체는 새로운 상태를 활성화합니다
7. 새로운 상태는 해당 구성요소를 활성화합니다.

그 후, 이 절차가 계속해서 반복됩니다. 사용 편의성을 위해 상태는 구성 요소 컨테이너 역할을 할 뿐만 아니라 언제 다른 상태로 전환할지 결정하고 기본 개체에 전환을 요청합니다. 시간이 지남에 따라 이것은 여전히 우리에게 충분하지 않은 것으로 판명되었으며 능력 다이어그램은 다음과 같이 변환되었습니다.

기본 개체, 상태 및 구성 요소는 그대로 유지되었지만 새로운 요소도 추가되었습니다.

가장 먼저 눈에 띄는 것은 각 상태와 구성 요소에 조건을 추가했다는 것입니다. 상태의 경우 이는 상태를 떠나기 위한 추가 요구 사항을 정의합니다. 구성 요소의 경우 구성 요소가 작업을 수행할 수 있는지 여부를 결정합니다.

충전 컨테이너에는 요금이 포함되어 재충전되며, 필요한 경우 충전을 중지하고 주에서 사용할 요금을 제공합니다.

타이머는 여러 상태가 공통 실행 시간을 가져야 하지만 자체 실행 시간이 정의되지 않은 경우에 사용됩니다.

모든 능력 개체는 선택 사항이라는 점에 유의하는 것이 중요합니다. 기술적으로 작업 기능을 위해서는 주 개체와 하나의 상태만 필요합니다.

이제 실제로 프로그래머의 개입 없이 완전히 구축된 기능은 많지 않지만, 일반적으로 개발 비용이 눈에 띄게 저렴해졌습니다. 이제 프로그래머는 아주 작은 것(예: 하나의 새로운 상태 또는 두 개의 구성 요소)만 작성하면 되기 때문입니다. 재사용됩니다.

우리 능력의 구성 요소를 요약해 보겠습니다.

• 주 개체는 상태 기계의 기능을 수행합니다. 상태와 구성 요소에 세계에 대한 정보를 제공하고 세계에 능력에 대한 정보를 제공합니다. 주요 개체는 상태, 구성 요소 및 기능의 서비스 부분(충전 및 외부 타이머) 사이의 링크 역할을 합니다.

  
  

• 상태는 기본 개체의 활성화 및 비활성화 명령을 수신하여 그에 따라 구성 요소를 활성화 및 비활성화하고 기본 개체에 다른 상태로 전환하도록 요청합니다. 상태는 다음 상태로 전환해야 하는 시기를 결정합니다. 이를 위해 내부 조건(플레이어가 능력 버튼을 클릭했는지 여부, 상태 활성화 이후 특정 시간이 지났는지 여부 등) 및 상태에 연결된 외부 조건을 사용합니다.

  
  

• 구성 요소는 상태로부터 활성화 및 비활성화 명령을 수신하고 개별 작업 또는 장기간 작업을 수행합니다. 행동은 완전히 다를 수 있습니다. 피해를 입히고, 아군을 치료하고, 애니메이션을 켜는 등의 작업을 할 수 있습니다.

  
  

• 조건은 원하는 요소가 어떤 상태인지 확인하고 이를 상태나 구성 요소에 보고합니다. 조건은 복잡할 수 있습니다. 조건이 충족되지 않으면 상태는 다른 상태로의 전환을 요청하지 않습니다. 또한 조건이 충족되지 않으면 구성요소는 작업을 수행하지 않습니다. 조건은 선택적 엔터티입니다. 모든 능력이 그런 것은 아닙니다.

  
  

• 충전 컨테이너는 요금을 보관하고 재충전하며 필요한 경우 충전을 중지하고 국가에 요금을 제공합니다. 플레이어가 여러 번 사용할 수 있도록 허용해야 하는 경우 다중 충전 능력에 사용되지만 연속으로 n 회를 초과할 수는 없습니다.

  
  

• 타이머는 여러 상태가 공통 지속 시간을 가지지만 각 상태가 얼마나 오래 지속되는지 알 수 없는 경우에 사용됩니다. 모든 상태는 n 초 동안 타이머를 시작할 수 있습니다. 모든 관련 상태는 타이머 종료 이벤트를 구독하고 종료 시 작업을 수행합니다.

이제 능력 도표로 돌아가 보겠습니다. 기능이 어떻게 바뀌었나요?

1. 게임 시작 시 메인 객체는 첫 번째 상태를 선택하고 활성화합니다.
2. 상태는 모든 구성요소를 활성화합니다.
3. 구성 요소는 조건이 충족되었는지 확인한 다음 작업을 수행합니다.
4. 상태는 다른 상태로의 전환 조건을 확인하기 시작합니다.
5. 조건이 만족되고 그에 연결된 추가 조건이 만족되면 상태는 주 객체에게 다른 상태로 이동을 요청합니다.
6. 주 개체는 이 상태를 비활성화하고 다른 상태를 활성화합니다.
7. 전체 과정이 반복됩니다

주에서는 추가 전환 조건으로 요금을 사용할 수 있습니다. 이러한 전환이 발생하면 충전 횟수가 감소합니다. 상태에서는 공통 타이머를 사용할 수도 있습니다. 이 경우 총 실행 시간은 타이머에 의해 결정되며 각 상태는 개별적으로 언제든지 지속될 수 있습니다.

능력 UI

우리는 새로운 능력 UI를 위해 바퀴를 완전히 재창조하지 않았습니다.

기본 개체에는 자체 UI가 있습니다. 항상 UI에 있어야 하고 현재 활성 상태에 의존하지 않는 일부 요소를 정의합니다.

각 상태는 UI에 고유한 쌍을 가지며 상태 UI는 해당 상태가 활성일 때만 표시됩니다. 상태에 대한 데이터를 수신하고 이를 어떤 방식으로든 표시할 수 있습니다. 예를 들어 기간 상태에는 일반적으로 UI에 남은 시간을 표시하는 막대와 텍스트가 있습니다.

상태가 능력을 계속하기 위해 외부 명령을 기다리고 있는 경우, UI에 버튼이 표시되고, 버튼을 누르면 해당 상태로 명령이 전송됩니다.

능력의 예

구체적인 예를 사용하여 능력이 어떻게 작동하는지 살펴보겠습니다. 먼저 '인퀴지터'라는 로봇을 살펴보자. 서로 이어지는 네 가지 상태가 있습니다. 상태 위에는 UI에서 표시되는 내용을 볼 수 있습니다. 그 중 두 가지에 대해서는 해당 구성요소도 표시됩니다. 다른 두 상태에는 단순히 구성 요소가 없습니다.

능력의 흐름은 다음과 같습니다.

1. 모든 것은 "WaitForClick" 상태로 시작됩니다. 현재 이 능력은 아무 일도 하지 않습니다. 단지 명령을 기다릴 뿐입니다.

   
   

2. 이러한 명령이 수신되자마자 주 개체의 상태가 전환됩니다. 다음 활성 상태는 "WaitForGrounded"입니다.

   
   

3. 이 상태에는 몇 가지 구성요소가 있으므로 활성화되면 로봇이 점프하고 소리와 애니메이션을 재생합니다. 무엇보다도 상태가 활성화된 동안 로봇은 로봇 조준을 금지하는 방해 전파 효과의 영향을 받습니다.

   
   

4. 로봇이 착지하면 능력이 다음 상태로 이동합니다.

   
   

5. 이 상태에는 세 가지 구성요소가 있습니다. 이미 익숙한 소리 및 방해 전파, 그리고 n 반경 내의 모든 플레이어에 대해 카메라가 흔들리게 하는 흔들기입니다.

   
   

6. 이 상태에는 Duration이 있으므로 n 초 동안 작동한 후 능력이 다음 상태로 이동합니다.

   
   

7. 마지막 상태에도 지속 시간이 있지만 구성 요소가 없습니다. 즉, 일반 재사용 대기 시간이 적용됩니다.

   
   

8. 완료되면 능력이 첫 번째 상태로 돌아갑니다.

   
   

또 다른 예는 '팬텀(Phantom)'이다. Inquisitor와 매우 유사하지만 몇 가지 뉘앙스가 있습니다.

1. WaitForClick부터 시작합니다.

   
   

2. 그러면 텔레포트가 설치된 Duration에 따라 메크의 능력치가 변경되고, 사운드와 애니메이션이 재생됩니다.

   
   

3. 그 후: 기계의 능력치가 변경되는 DurationOrClick, 애니메이션 및 FX가 재생됩니다.

   
   

4. 클릭이 이루어지면 기계 순간 이동, 통계 변경, 애니메이션, FX 및 사운드가 재생되는 다른 기간으로 이동합니다.

   
   

5. 이 상태 이후(또는 DurationOrClick의 시간이 만료된 이후) Duration으로 이동합니다.

여기서 주요 차이점은 분기가 있는 상태를 본다는 것입니다. DurationOrClick은 지정된 시간이 지나면 상태 A로 이동하고, 플레이어가 이전에 능력 버튼을 누른 경우 상태 B로 이동합니다.

결론

우리 시스템이 단순한 것에서 꽤 복잡한 것으로 진화한 것처럼 보이지만, 이러한 변화는 프로그래머와 게임 디자이너 모두의 삶을 단순화시켰습니다. 이제 작은 구성 요소를 추가할 때 프로그래머의 지원이 주로 필요한 반면, 후자의 팀 구성원 그룹은 더 큰 자율성을 얻었으며 이제 기존 상태 및 구성 요소에서 새로운 기능을 독립적으로 조립할 수 있습니다. 동시에 또 다른 보너스로 플레이어는 기계의 더욱 다양하고 복잡한 능력을 통해 이익을 얻었습니다.