Unity의 게임 개발에 대한 카오스 고블린 접근 방식

게임 개발 프로젝트를 시작할 때 가장 마비되는 감정 중 하나는 게임 잼을 위해 냅킨에 적어 놓은 몇 가지 아이디어이든 전통적인 10페이지 디자인이든 초기 게임 디자인을 마친 직후에 느끼는 감정입니다. 문서.

게임이 ROGUELITE-RTS-MMORPG가 될 것이라고 결정한 후에는 실제로 게임을 구축해야 하기 때문입니다.

그리고 가장 먼저 구축할 것이 RTS 부분이라고 결정했다고 가정해 보겠습니다. 따라서 사용자 스토리, 작업 또는 자신을 구성하는 데 사용하는 작업 단위를 적어 두세요.

그런 다음 해당 목록의 첫 번째 항목이 "스크롤 가능 지도 구현"이라고 가정해 보겠습니다.

그리고 이런! 스크롤 가능한 지도를 구현한 적이 없습니다. 하지만 귀찮게 하지 마세요. Google이 도와드리겠습니다. 그렇죠?

하지만 온라인에서 찾은 솔루션이 정확히 필요한 기능을 수행하지 못한다면 어떻게 될까요? 아니면 당신이 찾은 솔루션이 15년이나 된 것인가요? 아니면 아래에 솔루션이 얼마나 나쁜지 설명하는 수많은 댓글이 있지만 더 나은 솔루션을 지정하는 댓글은 단 하나도 없습니다[^0].

따라서 빌드하려는 항목에 대한 코드 참조를 찾을 수 없습니다. 게임 개발자는 어떤 일을 할까요?

답은 카오스 고블린 모드로 들어가는 것입니다.

카오스 고블린 모드 진입

고블린에 대해 잘 모르는 분들을 위해 설명하자면, 고블린은 여러 판타지 작품에 자주 등장하는 종족으로, 일반적으로 좀 더 진지한 오크나 홉고블린보다 작은 사촌으로 묘사됩니다. 일부 다른 속성에서는 매우 특정한 방식으로 기계적으로 능숙한 것으로 묘사됩니다. 그리고 그 방법은 신뢰할 수 없습니다. 즉, 고블린이 만드는 것들이 잘 디자인되거나 만들어졌기 때문이 아니라 순전히 독창성과 완고함 때문에 효과가 있을 때도 있다는 뜻입니다.

이것이 게임 개발에 대한 카오스 고블린 접근 방식의 핵심입니다. 이제 여기서 약간의 관심을 잃기 시작했다고 확신합니다. 다시 돌아와서 Chaos Goblin의 본질을 요약하겠습니다.

이 점을 더 자세히 설명하기 위해 Fallout 3의 Presidential Metro Head에 대해 말씀드리겠습니다( 여기에서 전체 내용을 읽을 수 있습니다). 그 요점은 플레이어가 자신이 지하철 안에 서 있다고 생각하는 게임 장면에서 플레이어의 헤드기어가 실제로 지하철 차량 모델로 교체되었으며, 지하철을 타고 움직이는 것은 플레이어 자신의 모델이라는 것입니다. 미리 정해진 트랙.

일부 플레이어는 이 내용을 읽고 개발자가 게으르다고 생각할 수도 있습니다. 하지만 문제의 진실은 개발자들이 항상 이런 종류의 일을 한다는 것입니다.

그리고 바로 이러한 종류의 관행이 카오스 고블린 모드의 교리를 형성하며, 이는 다음과 같습니다.

플레이어가 모르는 것이 플레이어에게 해를 끼칠 수는 없습니다.

게임의 일부에서 플레이어가 성 타워 안에 서서 밖으로 날아가는 용에게 화살을 발사하고 있다고 가정해 보겠습니다. 가끔 드래곤이 가까이 다가와서 창문을 통해 머리를 밀어 플레이어를 물려고 합니다.

이제 플레이어가 생각하는 한, 드래곤은 실제로 그곳으로 날아가고 있습니다. 그러나 게임 개발자로서 우리는 이러한 환상을 해소하고 상황을 최적화하기 위해 몇 가지 트릭을 사용했을 수도 있습니다.

수행할 수 있는 작업은 다음과 같습니다.

• 드래곤과 플레이어의 거리에 따라 다양한 모델을 사용하세요. 플레이어는 드래곤이 가까이 있을 때만 드래곤의 세부 사항을 볼 수 있습니다. 그렇다면 드래곤의 3D 모델을 덜 디테일하면서도 메모리 공간을 덜 차지하는 모델로 교체하는 것은 어떨까요?

  
  

• 플레이어가 드래곤을 보고 있지 않을 때 드래곤의 전원을 끄세요. 플레이어가 보고 있는 위치를 추적함으로써 3D 모델을 선택적으로 켜거나 꺼서 렌더링 비용을 절약할 수 있습니다.

  
  

• 플레이어가 완료되지 않은 작업을 보는 것을 방지합니다. 어떤 이유로든 타워 외부의 환경을 위한 예술 작품이 완성되지 않았다고 가정해 보겠습니다. 따라서 플레이어가 창문 선반 위로 나가면 아무것도 볼 수 없습니다. 이를 돕기 위해 게임 디자이너들은 창문의 선반이 즉시 죽음의 장소가 되도록 결정했습니다. 그래서 플레이어가 난간 위에 서면 3초간 용의 포효 소리가 들리고 플레이어의 화면이 어두워지기 시작합니다. 3초 사운드가 끝나면 드래곤이 플레이어를 잡아먹는 빠른 애니메이션을 재생합니다(아마도 이미 가지고 있는 애니메이션을 재사용할 수도 있습니다). 플레이어에 관한 한, 선반은 드래곤이 플레이어를 집어낼 수 있는 장소일 뿐입니다. 완료되지 않은 작업을 보지 않기 위해 작업이 완료되었다는 사실을 알 필요가 없습니다.

  
  

• 아마도 용이 창문을 통해 머리를 내밀 때 우리는 전체 용 모델을 더 작지만 더 상세한 머리 모델로 대체할 것입니다. 이를 통해 사용하지 않는 모델에서 메모리를 확보하는 동시에 플레이어에게 향상된 경험을 제공할 수 있습니다.

  
  

오랫동안 게임 업계에 몸담아왔다면 위의 내용을 표준 관행으로 인식할 것입니다. 그러나 이러한 기술이 교묘하고 매우 혁신적인 것으로 간주되던 때가 있었습니다.

플레이어가 보고 있는 것보다 훨씬 더 많은 것이 있다고 생각하도록 속이는 새로운 방법을 찾는 것은 이제 여러분에게 달려 있습니다.

가장 좋은 솔루션은 현재 작동 중인 솔루션입니다.

많은 게임 개발자는 가능한 모든 미래 시나리오를 포괄하는 솔루션을 찾으려고 노력하기 때문에 막히게 됩니다. 이러한 태도는 올바른 상황에서는 가치가 있을 수 있지만, 카오스 고블린 모드에 있을 때 목표는 무언가가 가능한 한 빨리 작동하도록 하는 것입니다.

이에 대한 부록:

결함이 있는 프로토타입은 미완성된 걸작보다 더 가치가 있습니다.

위의 요점과 유사하게, 많은 개발자들은 너무 일찍 최적화하려고 하기 때문에 기능을 구현하려고 할 때 얼어붙습니다.

개발자가 제어할 수 없는 시스템에서 프로젝트를 실행해야 할 때까지 최적화는 남겨두어야 합니다[^1].

X를 하기 전에 얼마나 알아야 합니까? 대답은, 당신이 지금 가지고 있는 지식의 양이 무엇이든 충분하다는 것입니다.

이는 많은 초보 게임 개발자가 겪는 또 다른 걸림돌입니다. 그들은 기능 구현을 연기하여 강좌를 한 개만 더 듣고, 온라인 튜토리얼을 한 개만 더 듣고, 비디오를 한 개만 더 본 다음 게임을 구현할 준비가 됩니다.

나는 특히 이것에 대해 유죄이며 그것이 얼마나 교활할 수 있는지 알고 있습니다.

좀 더 구체적인 예를 들기 위해, 탁구 게임을 처음부터 프로그래밍하는 임무를 맡았다고 가정해 보겠습니다.

알고 있는 내용과 모르는 내용에 따라 이를 위해 취할 수 있는 접근 방식이 다를 수 있습니다.

• Unity의 물리 시스템에 익숙하다면 비교적 간단한 노력입니다. 두 개의 강체와 충돌체를 사용하고, 힘과 속도를 적용하고, 공의 탄력을 위해 물리 재료를 사용하면 그게 전부입니다. 베어본 Pong 클론.

  
  

• 하지만 여러분이 Unity의 충돌 시스템에 익숙하지 않고 Unity의 변환 구성 요소를 사용하는 방법만 알고 있으므로 얻을 수 있는 것은 개체의 위치와 크기뿐입니다.

  • 하지만! 이는 Pong을 구현하기에 충분합니다. 공의 위치와 크기를 추적하고 이를 패들의 위치 및 크기와 비교하여 충돌이 있는지 확인하는 스크립트를 작성할 수 있습니다.

    
    

• 아니면 Unity를 모르고 C++와 콘솔에 인쇄하는 방법만 알고 있을 수도 있습니다.

  • 하지만 그것으로도 충분해요! 터미널 트릭을 사용하여 공, 패들 및 플레이 영역을 나타내는 기호의 행과 열을 인쇄할 수 있습니다. 이는 게임 루프의 개념과 함께 입력에 응답하는 상쾌한 UI를 프로그래밍하기에 충분합니다.

    
    

• 아니면 컴퓨터 과학을 전공하지도 않았거나 C++ 수업을 듣지도 않았고 Javascript만 알고 계십니까?

  • 괜찮아요! JS를 기본 언어로 사용하고 렌더링 및 물리 구성 요소가 모두 제공되는 Phaser를 사용할 수 있습니다.

    
    

• 프로그래밍도 못하나요? 전혀 문제 없습니다.

  • Gamemaker 는 무료 버전이 포함된 상용 게임 엔진이며 코드가 없는 옵션이 있습니다.
  • GDevelop 은 코드 없는 옵션도 포함된 무료 오픈 소스 게임 엔진입니다.

내가 이걸 가지고 어디로 가는지 알아냈죠?

실패한 프로젝트는 없습니다. 단지 재사용을 기다리는 스크랩 더미일 뿐입니다.

대부분의 게임 개발자는 대개 한두 개(또는 10,000개)의 버려진 프로젝트를 어딘가에 두고 있습니다. 낭비하는 것은 의미가 없습니다. 일시정지 시스템과 같은 코드가 있으면 재사용하세요. 같은 것을 다시 쓰는 것은 의미가 없습니다. 어떻게 쓰는지 정확히 기억하더라도 복사하세요. 적응하기 어렵다면 다음 번에 더 쉬울 수 있도록 다시 반복하세요.

아마도 재사용할 수 있는 여러 비트의 코드가 포함된 워크숍 프로젝트[^2]가 있을 수도 있습니다.

반짝이는 것 보이시나요? 반짝이는 걸 가져가세요

대화 시스템이 필요합니까? 오픈 소스를 찾아서 용도를 변경하세요. 귀하의 모든 요구 사항을 충족합니까? 아니요? 50% 이상 충족되나요? 예? 그러면 처음부터 새 것을 만드는 대신 이를 사용하는 것이 좋습니다.

인벤토리 시스템? itch.io에서 오픈 소스 게임을 찾아 시스템을 채택해보세요.

1인칭 카메라가 필요하신가요? 이를 처리하려면 사전 구축된 자산을 활용하세요[^3].

당신이나 나보다 의심할 여지 없이 더 능숙한 뛰어난 게임 개발자가 많이 있습니다.

특별한 이유가 없는 한 모든 것은 사전 구축된 시스템을 사용할 후보로 간주되어야 합니다. 그러나 다음과 같은 합리적인 예외가 존재합니다. 단순히 복사하여 붙여넣은 코드를 게임의 백본으로 사용하지 마십시오(적어도 코드를 이해하고 정리하고 댓글을 달 수 있는지 확인하세요). 10년이 된 모듈로, 저자는 아마도 열대 어딘가에서 휴식을 취하고 파파라치가 없는 천국에서 Elvis, Tupac, Marilyn Monroe와 함께 Mai Tais를 홀짝이는 것 같습니다.

의심스러우면 복사하세요

기능 구현에 대해 확신이 없다면 원하는 것과 유사한 기능을 수행한 게임을 찾아서 모방하세요.

"카피"란 아트 스타일, 스토리 또는 캐릭터보다는 컨트롤 처리, 카메라 뷰, 메커니즘과 같은 디자인 측면을 의미합니다.

예를 들어, 지금은 잊혀진 가상의 ROGUELIKE-RTS-MMORPG에서 스크롤이 얼마나 빨라야 할까요?

추측하는 대신 다른 RTS가 이를 어떻게 관리했는지 확인할 수 있습니다. Age Of Empires II(역사적으로 중요한 RTS)를 관찰하고 이를 통해 사용자가 커서 이동 속도를 제어할 수 있다는 사실을 발견했다고 가정해 보겠습니다. AoEII와 나란히 게임을 배치하고 동일하다고 느껴질 때까지 커서를 조정할 수도 있습니다. 목표를 달성하기 위해 얼마나 많은 개발자가 이처럼 단순하고 기술 수준이 낮은 솔루션에 의존하는지 보면 놀랄 것입니다.

이별의 생각

그렇다면 카오스 고블린의 장난을 마친 후에는 무엇을 해야 할까요? 자, 잠시 쉬고 차를 마시고 나중에 코드로 돌아가세요.

코드를 잠시 쉬게 한 후(날씨가 너무 건조한 경우 젖은 수건 아래) 코드를 조금 다듬어 공유해야 합니다. 예! 이상적으로는 선임 개발자, 동료, 동료 학생과 공유하거나 최악의 경우 온라인 커뮤니티[^4]와 공유하세요.

왜 공유하는 걸까요? 카오스 고블린이 되는 것은 내구성이 있거나 최적의 것을 만드는 것이 아니기 때문입니다. 그것은 작동하는 무언가를 만드는 것입니다. 완벽하게 기능하거나 아름답게 보일 필요는 없으며 작동만 하면 됩니다. 이러한 유형의 개발은 결과를 생성하지만 결과가 즉시 생산 준비가 되는 경우는 거의 없습니다. 따라서 누군가와 상의하여 피드백을 제공하는 것이 매우 중요합니다.

프로젝트 단계에 따라 이 사람의 의견을 즉시 구현할 시간이 없을 수도 있습니다. 그렇다면 최소한 코드[^5]에 해당 주석을 문서화해야 합니다.

그리고 그게 다야! 이제 귀하는 전 세계 전문 게임 개발자들이 문제 해결을 위해 사용하는 최고의 기술을 보유하게 되었습니다.

이제 두 번째 컵파를 마실 시간이라고 제안하고 싶습니다. 그렇죠?

노트

[^0] - 이는 놀라울 정도로 흔한 현상으로 '덴버 비유'라고 불립니다. 자세한 내용은 다음 학술 논문을 참조하세요.

[^1] - 이는 약간의 일반화이며 대부분의 일반화와 마찬가지로 프로젝트 요구 사항을 철저하게 분석하는 것만큼 도움이 되지 않을 수 있습니다. 그러나 실제로 필요할 때까지 최적화를 연기하는 것이 좋은 경험 법칙입니다. 요즘에는 비디오 게임을 최적화하는 것이 예전보다 훨씬 덜 어려워졌습니다. Unity와 같은 일부 게임 엔진 회사에서는 무료 상담을 통해 도움을 제공할 수도 있습니다. 결국, 귀하의 게임을 성공적으로 출시하는 것이 귀하에게 가장 큰 이익이 됩니다.

[^2] - 워크숍은 Unity에 대한 이해를 높이기 위해 제가 사용하는 카타 또는 실습 중 하나입니다. 여기에서 이에 대한 자세한 내용과 기타 기술을 읽을 수 있습니다.

[^3] - 이 기사 에서 다른 유용한 도구와 함께 정말 좋은 FPS 컨트롤러 패키지를 찾을 수 있습니다.

[^4] - 이는 온라인에서 받게 될 댓글의 약 95%가 무의미하거나, 불완전하거나, 시대에 뒤떨어진 댓글이거나, 작성자의 지극히 개인적인 신념을 반영할 수 있다는 경고를 담고 있습니다. 그러므로 항상 어느 정도 회의적인 태도로 그러한 피드백에 접근하십시오. 유용한 의견을 찾고, 나머지는 무시하거나 제거하고, 코드를 공유할 수 있는 사람을 찾기 위해 진심으로 노력하십시오.

[^5] - 팀마다 코드 문서를 유지 관리하는 위치에 관해 서로 다른 기준을 유지하므로 이를 준수해야 합니다. 그러나 일반적으로 나는 코드 문서가 코드 자체 옆에 위치하도록 옹호합니다. 이것이 가능하지 않다면 선택한 코드 버전 관리 시스템에서 git 하위 모듈 이나 이에 상응하는 모듈을 사용하는 것을 고려해 보세요. 문서가 기본 저장소에 있을 수 없다면 최소한 git 하위 모듈에 있어야 합니다.