코드를 뛰어 넘기 전에 계획을 세우는 것이 가치가 있습니까?

나는 항상 계획이 게임에 중요하다고 생각했습니다. 그러나 나는 어느 시점에 있는지 모른다. 일부는 계획 대신 코드를 알려주는 것이지만 코드에있을 때 다음에 무엇을 해야하는지 쉽게 알 수 있기 때문에 여전히 중요하다고 생각합니다. 현재 콘텐츠가 많은 게임을 개발 중이므로 해당 콘텐츠를 소개하는 디자인 문서를 시작하기로 결정했으며 측면에서 개념 증명을 수행하여 수행 할 수 있는지 확인하고 있습니다. 각 개념 증명의 일부는 실제 게임에서 나중에 사용할 수 있습니다.

편집 : 나는이 프로젝트에서 혼자 일하고 있습니다.

내 질문은 : 코드에서 뛰어 들기 전에 계획을 세우는 것이 가치가 있습니까? 나는 아직도 다른 사람들이 이것에 대해 무엇을 말해야하는지 알고 싶어합니다. 왜 내가 생각하는 대신 코딩해야한다고 말하는 사람들이 여전히 있습니다. 그래서 이것에 대해 어떻게 생각하십니까?

당신은 당신의 질문에 두 가지 똑똑한 것을 말했습니다.

1. "생각하는 대신 코드"-이것을 설명하는 전체 철학이 있습니다 : http://gettingreal.37signals.com/toc.php
2. "완료 될 수 있는지 확인하는 개념 증명"-나는 거의 끝났을 때 불가능하거나 극단적으로 만들기 어려운 많은 아이디어를 보았습니다. 때로는 프로그래밍 환경 (언어, 라이브러리, 하드웨어 성능)이 제한되어 있기 때문에 예측할 수없는 경우가 있습니다.

이것이 내가 말하는 이유입니다.

• 재미 있고 프로그래밍에서 벗어나지 않는 한 공동 작업 자나 투자자를 찾고 있지 않다면 큰 디자인 문서를 만들지 마십시오.
• 항상 달성하고자하는 것을 명심하십시오. 모든 모듈에는 설계된 입력 및 출력이 있어야합니다. 그렇게하면 모듈을 쉽게 테스트 할 수 있고 안개 속에서 방황하는 느낌이 없습니다.
• 코드를 입력하는 데 소요되는 시간은 약 5 % (최소한 최종 코드 입력)이므로 대부분의 시간을 설계해야합니다.
• 프로그래밍은 이론적 인 과학이 아니며 종이에 무언가가 작동하는지 확인하는 대신 코드를 작성하고 시도 할 수 있습니다. 최종 제품은 사용자 입력을 완벽하게하고 GUI를 멋지게 보이며 특수한 경우를 다루는 것에 관한 것입니다.
• 아이디어를 잊는 것을 두려워하는 경우 할 일 목록을 작성하십시오.
• 덜 열정적이며 현장에서 더 많은 경험을 가질 수 있기 때문에 친구들과 아이디어에 대해 이야기하십시오. 일단 전략적 게임에서 단위 매개 변수를 비밀로 유지하려는 아이디어가 있었지만 친구는 이와 같은 게임을하면서 끔찍한 사용자 경험이라는 나쁜 아이디어라고 말했습니다.

예,하지만 약간만 .

게임 프로그래밍, 특히 게임 플레이 프로그래밍의 경우 코드를 작성하기 전에 좋은 사용 사례 가 있어야합니다 . 예를 들어 플레이어가해야 할 일, 어디로 가야하는지, 어떻게, 어떻게 세상과 상호 작용할 수 있는지 등. 이것은 종이에 스케치 된 스토리 보드이거나 동료와의 토론에서 나올 수 있습니다 ... 게임 디자인의 일부이며 , 게임이 어떻게 진행 될지에 대한 대략적인 생각없이 코딩을 시작하는 것은 어리석은 일입니다.

그러나 게임은 반복적 으로 만들어야 합니다. 당신은 당신의 게임에 대한 큰 스펙을 만들 수 없으며 그것이 재미있게되기를 바랍니다. 효과가있는 것과 그렇지 않은 것을 알아 내고 계속 반복하려면 정기적 인 플레이 테스팅이 필요합니다. 실행 파일이 가장 빠를수록 게임 디자인을 가장 빨리 테스트 할 수 있으며 게임이 끝날 때 가장 잘됩니다. 따라서 비공식적 인 게임 디자인에서 최대한 빨리 코딩을 시작하고 결과를보고 계속 진행하는 것이 좋습니다.

한 가지 확실한 것은, 혼자서 코딩 할 때 멋진 소프트웨어 디자인 문서 나 방법론이 필요하지 않다는 것입니다. 소스 코드는 디자인입니다.

일부는 생각하는 대신 코딩해야한다고 말하는가? 코드를 작성하려면 만들고 싶은 것을 알아야하고, 만들려는 것을 알아야합니다. 먼저 원하는 것을 생각해야합니다. 코딩하기 전에 먼저 생각해야합니다.;).

그리고 진지하게, 당신은 아마도 처음에 자세한 계획이 필요하지 않을 수도 있지만 개요 및 / 또는 이정표를 갖는 것은 항상 유익합니다. 작업.

코딩과 계획이 모두 필요합니다. 먼저 계획하고 코드를 작성하지만 모든 것을 한 번에 계획하지는 마십시오. 핵심을 계획하고 코딩하고 필요에 따라 계획을 업데이트 한 다음 재생성, 그래픽, 사운드, 스프라이트 등을 추가 할 수있는 기능을 계획하면 제작중인 게임이 더 좋아 보이고 전반적으로 기분이 좋아집니다. 분명히 그러한주기를 두 번 이상 실행할 수 있으며 필요에 따라 업 스케일링을 지원할 의사 결정을 내리는 것이 좋습니다.

코드를 작성하기 전에 어디로 가고 있는지 알고 있어야하며, 작성 / 도화는 달성하고자하는 것을 구체화하는 좋은 방법이 될 수 있습니다. 나는 말 그리기 다이어그램, 스케치 등을 그리기도 당신에게 많은 도움이 될 수 있기 때문이다. Word 나 다른 것으로 만든 멋진 문서를 만들 필요가 없습니다. 연필과 종이 한 장 (종이 조각?)을 가져 가서 생각 나는 모든 것을 쓰십시오.

필자는 연필과 종이를 사용하는 것이 좋으며 아이디어를 구체화하는 데 도움이되며 어디를 가든지 목표를 고칠 수 있도록 가고 싶은 곳을 설정합니다. 그것은 반사가 필요한 모든 것에 효과적입니다. 그리고 많은 영역에서 실제 작업을 수행하기 전에 적어 두는 것이 분명합니다.

당신을 위해 일하는 것은 무엇이든하십시오. 개인적으로, 나는 사물을 조금 계획하고 있지만, 코딩을 시작하기 전에 디자인 문서가 극히 세부적인 계획은 없습니다. 특히 혼자 일하기 때문에 가장 생산적인 일을하십시오.

(질문은 게임 디자인이 아닌 코드 디자인 / 아키텍처 관점에서 이루어 졌다고 가정하지만 적어도 어느 정도의 대답은 두 가지 모두에 적용됩니다.)

이미 말했듯이 둘 다 필요하며 균형을 맞출 필요가 있습니다. 코드 흐름 / 구조를 과도하게 설계하고 저조하게 설계하면 문제가 발생할 수 있습니다. 올바른 균형이 무엇인지 말하기는 어렵지만 일반적으로 코드의 나머지 부분이 현재 프로그래밍중인 항목과 어떻게 결합하고 가능한 문제에 대해 생각하는지 모호한 아이디어가 있어야합니다. 그렇지 않으면 나는 "나 자신을 막 다른 길로 코딩하는"경향이있다. "알았어. 이제는이 문제를 어떻게 해결했는지에 따라 이전의 모든 해결책을 만들어내는 새로운 문제를 만들었지. ) 헛된 ".

일반적으로 제 생각에는 "나중에 (지금 사용하는 것과 비슷한 패러다임으로 모든 것이 완전히 구현 된 경우)"에서와 같이 "만약"시나리오에 대해 올바른 균형을 가지고 있는지 대략적으로 판단 할 수 있습니다. 그 부분 A는 약간 다르게 작동해야하는데, 이는 변경 사항을 수용하는 부분 B를 완전히 재 작업해야한다는 것을 의미합니다. " 한 부품의 구조적 변경으로 인해 하나 또는 두 개의 다른 부품을 변경하지 않아도되며 변경 사항이 계단식으로 표시되지 않는 경우 (부품 B와 연결되는 다음 부품도 변경해야 함) 코드 등은 비교적 좋은 방식으로 구획화됩니다.

그러나 실제로 이것은 약간의 경험을 얻은 후에 느낄 수있는 것입니다. 이것이 모든 사람들이 처음으로 gamedevs에게 알려지고 쉬운 것 (브레이크 아웃 / 테트리스 / 스네이크)을 코딩하고 모든 메뉴, 사운드, 효과, 완전히 완성 된 게임을 만들기 위해 모든 것을 완료하도록 조언하는 이유입니다. 소규모 프로젝트를 망쳐 놓는 것 (좋은 방식이든 나쁜 방식이든)을 수행하면 다양한 건축 결정의 영향이 얼마나 멀리 있는지 느낄 수 있습니다.