기능 크리프를 사용할 수 있습니까? [닫은]

기능 크리프 를 사용할 수 있습니까 ?

게임 프로토 타입을 만들 때마다 기능이 실수로 추가됩니다. 이것은 우연의 일치를 통해 발생하거나 기존 컨텐츠를 기반으로 쉽게 추가 할 수 있습니다.

게임의 장르를 알고 있다면 기본 메커니즘을 만들기 시작하고 기능이 명확 해지면 기능을 추가 할 수 있습니까?

예를 들어, 6 개월 동안 2d 플랫 포머를 만들고 싶다면 달리기, 점프, 촬영 등을 시작하고 실수로 핵심 메커니즘을 추가 할 수 있습니까? 아니면 미리 정해진 계획이없는 시간 투자의 위험성이 너무 높습니까?

이것에 대한 나의 논리는 디자인이 벅에 더 강할 것이라는 것이다. 디자인 선택은 쉽게 할 수있는 것 (시간에 따라)을 중심으로보다 쉽게 ​​구축 될 수 있습니다.

요약하면, 게임 을 디자인 하기 전에 게임을 만드는 데 문제가 있습니까?

흥미로운 질문입니다. 주로 응답하면 회색 음영과 흑백 대 딜레마가 증가하기 때문입니다.

게임을 디자인하기 전에 게임을 만드는 데 문제가 있습니까?

해당 질문을 예 또는 아니오 유형으로 생각하면 대답은 다음과 같습니다. 대답을 더 미묘하게 할 수 있으면 변경됩니다. 이유 : 당신이 전에 게임을 건설해서는 안 일부 설계. 그러나 나중에 디자인의 일부 를 저장할 수 있습니다 .

그것은 당신이 겪고있는 문제를하지 말아야한다고 생각하지 않는다는 것을 의미합니다. 오히려, 그것은 당신이 학위로 생각해야 할 것입니다. 기능 개발은 게임 개발과 관련하여 모든 악의 두 번째 근원 일 수 있습니다 (첫 번째는 Donald Knuth가 우리에게 잘 알고 있듯이 "미숙 한 최적화는 모든 악의 근원"입니다 ). 그러나 내 경험상 주요 기능을 생각하지 않고, 즉 기본 역학으로 가고 싶은 곳의 기본 디자인을 가지고 있지 않은 것도 좋은 생각이 아닙니다.

첫 번째 주된 이유는 자원으로 (자원으로 시간을 포함하여) 도움을 줄 계획을 세우는 것이 도움이되기 때문입니다. 과도한 시도 및 오류로 인해 항상 막 다른 길에 도달하는 것은 낭비 일 수 있습니다. 예기치 않은 기능을 포함해야하는 리소스

게임 디자인 측면에서 두 번째 주요 이유는 일관성입니다. 좋은 게임 디자인은 개념적 일관성 또는 원한다면 일관성이 있습니다. 즉, 전체 게임 플레이, 기록, 구현, 심지어 그래픽까지 가능한 한 부드럽게 맞아야합니다. 주요 기능이 이동 중에 발견되면 게임 디자인이 이와 같은 것을 달성 할 가능성은 거의 없습니다. 이동 중에는 임의성이 많기 때문에 다른 작업을 수행하지 않는 경우 : 개발 프로세스에서 찾은 시점에 따라 수행 할 작업이 매우 다른 영향을 미칠 수 있습니다 .

당신이 말한 것을 전혀하지 말아야한다는 말은 아닙니다. 나는 당신이 약간의 균형을 찾아야한다고 주장하고 있습니다.

예를 들어, 6 개월 동안 2d 플랫 포머를 만들고 싶다면 달리기, 점프, 촬영 등을 시작하고 실수로 핵심 메커니즘을 추가 할 수 있습니까? 아니면 미리 정해진 계획이없는 시간 투자의 위험성이 너무 높습니까?

먼저 문장을 약간 수정하여 시작하겠습니다. 달리기, 점프, 사격 등을 통해 이미 핵심 역학을 구현하고 있습니다. 예제에서 이동 중에 추가 할 것은 특정 게임 플레이 기능입니다.

게임이 2D 플랫폼이 될 것임을 알기 때문이 아니며, 달리기, 점프 또는 촬영은 게임 디자인에 따라 다를 수 없습니다. 플레이어가 벽에서 달릴 수 있습니까? 점프 할 때 플레이어가 공중에 뜰 수 있습니까? 심지어 달리는 동안 플레이어가 촬영할 수 있습니까? 플레이어는 선형 방향이나 포물선을 통해서만 사격합니까? 이러한 결정은 게임 기능에 따라 크게 달라질 수 있습니다.

그러나 나는 당신의 요점을 알 수 있습니다.이 역학에는 종종 약간의 부분이 다릅니다. 당신이 경우에 따라서 일부 게임 디자인을 다소 있는지, 점프, 촬영을 실행하는 방법 수만큼 같은 기본 기능을 결정, 등 시작의 그 작동합니다. 그런 다음 이러한 역학을 찾아서 계속 발전시킬 수 있습니다.

물론 나중에 기본 기능에 관계없이 이러한 메커니즘을 변경해야하는 새로운 기능을 계속 찾을 수 있습니다. 그러나 여기서 핵심은 확률입니다. 적어도 당신이 게임에 대한 기본 아이디어에 대한 달리기, 슈팅, 점프 등의 결과에 대해 약간의 생각을했다면 이것이 너무 자주 일어날 확률은 더 작아 질 것입니다.

마지막으로, 그 길을 가고 싶다면 다음을 제안합니다. 그것을 반복적 인 과정으로 생각하십시오. 초기의 광범위한 디자인 사고를합니다. 게임 내에서 기본적이고 "보편적 인"것처럼 보이는 것을 구현하면 성공할 수 있습니다. 그런 다음 좀 더 디자인을 생각하고 구현 한 내용을 다시 평가하여 더 많은 구현을 수행하십시오.

게임과 같은 복잡한 프로젝트를 수행 할 때 시간 / 돈이 부족하거나 예상대로 좋지 않은 결과로 인해 원하는 기능을 모두 사용할 수없는 경우가 종종 있습니다. 이것을 기능 크리프라고합니다. 그러나 이것에는 반대 점이 있습니다. 필요하지 않다고 생각되는 기능도 찾을 수 있지만 프로젝트가 구체화됨에 따라 요구 사항이 명확 해집니다.

이것이 사람들이 프로토 타입을 제작하는 이유입니다. 따라서 작동하는 것과 작동하지 않는 것을 배울 수 있으므로 작동하지 않는 기능을 잘라낼 수있을 뿐만 아니라 멋진 새로운 기능을 찾을 수도 있습니다 . 배우지 않는 것들 중 하나를 수행 하지 않으면 잘못한 것입니다.

이것은 기본적으로 Chris Hecker와 Chaim Gingold의 Advanced Prototyping 이라는 대화에 표현 된 감정입니다 . 여기에는 Spore 연구 결과의 많은 예가 포함되어 있습니다. 프로토 타입 피드백 기반 시스템.

또 다른 예는 Left 4 Dead 의 설계 프로세스입니다 . 처음에는 게임에 기본 좀비 만 있었지만 숙련 된 플레이어와의 플레이 테스트를 통해 디자이너는 플레이어가 효과적으로 붙어 있고 게임이 너무 쉽다는 것을 알았으므로 팀을 분리하고 게임을 흥미롭게 유지하기 위해 특수 좀비를 추가했습니다.

물론 이것이 사전 디자인없이 게임을 빌드해야한다는 의미는 아닙니다 . 진행하기 전에 게임의 핵심이 재미 있어야합니다. 게임을 만드는 데있어 가장 어려운 부분이기 때문입니다.

나는 그렇다고 말할 것이다. 그러나 각각의 새로운 구성 요소 사이에 약간의 응집력을 갖도록 몇 가지 일반적인 기능 / 클래스를 미리 계획하십시오.

Unity는 게임 개발에 대한 컴포넌트 접근 방식으로 잘 알려져 있으며 이러한 형태의 개발을 쉽게 할 수 있습니다. Unity를 사용하지 않는 경우 세미 컴포넌트 방식을 복제 할 수 있습니다. 다른 게임 엔진에 익숙하지 않습니다.

유니티 게임 오브젝트에는 모두 변형 컴포넌트가 있습니다. 개체의 위치, 회전 및 배율을 나타냅니다. 따라서 일반적인 'transform'클래스를 만들어이 값을 유지하고 실제 게임 오브젝트에 대한 참조를 추가하십시오.

예를 들어 '점프'구성 요소를 사용하십시오. 모든 논리가 게임 오브젝트의 변형 클래스와 함께 작동하여 위치를 조작하게하십시오. (또는 엔진에 이미 비슷한 클래스가 내장되어있을 것입니다.)이 '점프'클래스를 모든 객체에 첨부 할 수 있으며 액션이 트리거 될 때 클래스가 변환 위치에 애니메이션을 적용합니다 (Jump.PerformJump () 또는 기타). Jump 클래스는 소유자 (또는 최소한 최소한의 정보)에 대해 아무 것도 알 필요가 없습니다.

이제 많은 구성 요소를 만든 다음 게임 개체에 연결하고 하나의 개체에 결합하는 등의 재미를 가질 수 있습니다. 예 : Run, Jump, Crouch, MovingTile, FireWeapon ( 'bullet'스프라이트 지정 및 동작 일반 구성 요소 등)

여러 용도 / 변형이 가능하도록 각 구성 요소를 가능한 한 일반적으로 만드십시오. FireWeapon의 경우, 총알 스프라이트, 속도, 손상 등을 지정할 수 있습니다. 속도와 손상이 0과 1 사이로 지정되도록 속성을 정규화하려고 할 수 있습니다. 그런 다음 게임의 최대 값으로 조정합니다. 이렇게하면 무기 간의 상대적인 차이 만 걱정할 수 있습니다. 또한 난이도가 높을수록 최대 데미지가 높은 난이도와 같은 전역 설정에 적용됩니다.

알기 전에 플러그인 할 구성 요소가 많으므로 이제 모든 게임 유형에 맞게 빠르게 개발할 수 있습니다.

요약 : 대부분의 경우 단일 코딩 단계 다음에 단일 설계 단계를 수행 할 수 없습니다. 대체해야합니다. 일반적으로 이미 코딩 된 것이 아니라 이미 설계된 것을 존중하십시오.

초기 디자인이없는 경우 (스케치 또는 정신적 이미지 만) 디자인이없는 경우 디자인이없는 것입니다. 당신은 하나와 함께 뭔가를해야합니다. 그러나 당신이 하나를 만들기 시작하면 그것을 존중하려고 노력하고 매번 새로운 것을 오지 마십시오.

실험을 수행하고 임의의 기능을 사용하면 유해하거나 유해하지 않을 수 있습니다. 심지어 유익하거나 피할 수 없을 수도 있습니다. 예를 들어, 점프를 지원하려는 것을 알고 있습니다 (많은 3D / 2D RPG는 점프를 허용하지 않습니다). 당신은 그것을 어떻게 압니까? 장애물을 정렬하기 위해 점프해야하는 게임 맵을 상상했기 때문에? 따라서 점프 구현은 플레이어가 장애물을 정렬하거나 도달 가능한 최대 고도와 같은 특정 특성을 준수 해야하는 한 충분합니다.지도의 항목이나 게임 오브젝트에 의해 향상 될 수 있으며 물리에는 가속 또는 바운스가 포함되어야합니다 ( 마리오가 적에게 뛰어들 때 그는 다시 상승하라는 충동을 얻습니다. 이것이 게임 플레이에 매우 중요합니다)?

이미 이러한 질문에 대답 할 수 있다면 설계 문서 (상상 또는 실제)가 매우 완전합니다. 대답을 할 수 없으면 디자인이 불완전한 것입니다. 이 경우 설계 작업을 수행하거나 간격을 메우기 위해 실험을 다시 수행해야합니다. 기회는 매우 개방적이거나 매우 제한적일 수 있습니다. 게임 레벨 중 일부에 장애물이 있고 점프해야하는 경우 최대 도달 가능한 고도 또는 속도를 결정할 수있는 많은 자유가있을 수 있습니다. 물리적 엔진이 점프 애니메이션의 시각 효과를 향상 시키지만 다른 용도로는 필요하지 않습니다. (많은 2D RPG 게임에서 원할 때 점프 할 수 없지만 맵에 단일 타일 구멍이있는 한, 들어 가려고하면 구멍 타일 옆의 바닥 타일로 자동으로 점프합니다.)

이미 결정한 사항을 존중하는 한 완전한 디자인없이 코드를 작성하는 것이 좋습니다. 또한 게임 우주는 다양한 사고 과정에서 구축 될 수 있기 때문에 불가피 할 수 있습니다. 예를 들어, 카드 게임 : 나는 주어진 시간에 테이블에 특정 수의 카드를 공격 및 방어하기를 원하며 자신의 차례 동안 플레이어는 어떤 카드로 어떤 카드를 공격할지 선택할 수 있다는 것을 알고 있습니다. 일부는 이미 완전한 디자인으로 보일지 모르지만 게임의 균형이 이루어지며 많은 시뮬레이션을 통해서만 가능합니다. 많은 시뮬레이션을 거친 후 Attack 10 카드가 압도되었다고 판단하고 게임에서 간단히 삭제할 수는 있지만 너무 좋아서 다른 일을 할 것입니다. 플레이어가 그러한 카드로 공격하면 그 턴 동안 다른 카드로 공격 할 수 없다는 새로운 규칙을 만들 것입니다. 이제는 게임 메커니즘을 강화하는 새로운 규칙이 있지만 단일 카드에 적용하면 (더러운 해킹처럼) 이상하게 보입니다. 이상하게 보인다는 것을 알게 된 다음 숫자가 많은 새 카드 세트를 만들기로 결정합니다. 새로운 제한 규칙이 적용됩니다. 이제 나는 더 단순한 게임 메커니즘보다 더 복잡한 게임 메커니즘을 가지고 있습니다. 제 생각에는 더 나은 게임을 만들기 위해 유리하게 전환했습니다.

이제 마지막 예에서 제안 된 카드 게임 예에서 새 카드는 새로운 자산 (비용 증가, 시간 증가)을 초래할 수 있습니다. 그러나 코딩이 디자인 결정에 좋은 방식으로 영향을 줄 때만 볼 수있는 기회가 좋은 예라고 생각합니다.

우리가하는 대부분의 게임이 코딩 전에 완벽하게 설계된 것은 아니라고 생각합니다.

다른 사람이 모든 것을 지불하면 설명하고 협상하십시오.