개인 게임 프로젝트를 빠르게 코딩 할 수있는 실질적인 이점

나는 몇 가지 프로그래머들이 보통 "Y 형 시간에 X 형 게임 쓰기"또는 "각각 Y 시간 만주는 X 개의 게임 쓰기"영역에서 스스로 시간에 민감한 과제를 설정하는 것을 보았습니다. 이러한 방식으로 워크 플로를 설정하여 한동안 속도를 단축 할 수있는 실질적인 이점은 무엇입니까? 빠른 작업을 수행하기 위해 효율적인 코드를 사용하지 않는 것 같습니다. 그리고 나는 이러한 도전에서 최종 연마 층을 추가하는 것이 우선 순위가 높지 않기 때문에 프로그래머를 사용하는 것이 좋습니다.

몇 년 전에 간단한 2D 스크롤 슈팅 게임과 퍼즐 게임을 만들었고 어리 석음으로 대부분의 코드를 삭제했습니다. 이제 속도 코딩 방식을 사용하여 몇 가지 간단한 작업을 다시 수행하고 게임 로직에 더 관심을 갖기를 원합니다.

적어도 내 경험상, 특정 종류의 프로그래머는 때때로 건축 우주 비행사 라고 불립니다 .

특정 방식으로 모든 것을 추상화해야하거나 코드를 리팩토링하려고 끊임없이 노력하는 사람이라면 최종 제품에 집중하는 세션을 갖는 것이 매우 좋습니다. . 때로는 더 간단한 솔루션이 더 빨리 게임을 할 수 있다는 사실을 강조 할 수 있으므로 큰 디자인을 미리 한 경우보다 더 빠른 반복 루프에 빠질 수 있습니다.

당신이 카우보이 프로그래머 라면 건축 우주 비행사와는 달리 ,이 정기 연습은 아마도 중복 될 것입니다.

나는 그런 식으로 나 자신을 위해 기한을 정한 적이 없지만, 일을 빨리 할 때 중요한 일을하는 것이 중요하다.

빠른 작업을 수행하기 위해 효율적인 코드를 교환 해야하는 것처럼 느껴집니다.

직접 게임을 작성할 때 효율적인 코드는 문제가되지 않습니다. 문제는 종종 동기를 유지합니다. 최적의 효율이 아니더라도 작동하는 것을 얻는 것은 계속 진행하고 끝내기에 충분한 동기가 될 수 있습니다 . 좋은 결과가 나오면 언제든지 나중에 다시 리팩토링 할 수 있습니다. 처음부터 모든 것을 올바르게 시도하면 끝나지 않을 수 있습니다.

나는 일 년에 몇 번 이렇게한다. 게임을 디자인하고 구현하고 출시하는 데 일주일이 걸립니다.

내가 완벽 주의자이기 때문에 나는 그것을한다. 내 선택에 따라, 나는 게임에서 영원히 일할 것이다. 어려운 마감일 (사전에 게시)은 실제로 개발을 중단하고 일정에 따라 게임을 출시하도록 강요합니다. 이 연습에 들어가는 나의 개인적인 규칙은 마감일이 지난 후에는이 게임들 중 어떤 것도 수정할 수 없다는 것입니다. 또한 그것은 나에게 미래 프로젝트에 집중하고 더 오래된 프로젝트를 수정한다는 생각에 산만 해지지 않습니다.