답변:
경험이 적을수록 초기 설계로 더 많은 시간을 낭비합니다. 좋은 디자인을 만드는 것은 디자인을하고 나서 그 방법을보고 평가함으로써 배울 것입니다. 일부 결정은 아직까지 도달했지만 의미가 모호합니다. 일부 게임 후에는 초기 디자인을 상당히 견고하게 만들 수 있으며이 단계에 더 많은 시간을 투자하면 돈을 지불하게됩니다.
나의 좌우명 : 처음부터 작업을 수행하되, 상식을 사용하여 다른 구성 요소보다 더 중요한 구성 요소를 감지하고 제한 시간 내에 구성 요소를 잘 설계하십시오. 예를 들어 AI가 게임에 중요한 경우 나중에 쉽게 확장 / 변경할 수 있는지 확인하십시오. 또는 모든 게임에서 사용할 구성 요소를 작성하려는 경우 재사용 성을 위해 디자인하십시오. 시간을 추적하고 디자인에 열중하지 마십시오. 디자인 마감일을 정한 후 릴리스 마감일을 얻기 위해 모든 것을 해킹하기 시작하십시오. 그러나 나중에 리팩토링 / 재 설계가 필요한 포인트를 확인하고 다음 게임을 시작하기 전에 어느 시점에서 계산하여 그 점을 개선하여 다시 물지 않도록하십시오!
좋은 조언 : 두 가지 옵션 중 하나를 선택해야하는 경우 세부 정보에 너무 오래 머 무르지 마십시오. 대부분의 경우 "좋은"또는 "나쁜"이 없습니다. 어떤 상황에서는 A가 더 좋을 것이고, 어떤 경우에는 B가 더 좋을 것이고, 전반적으로 둘 사이의 차이가 항상 시간 가치가있는 것은 아닙니다.
소프트웨어 나 게임을 디자인 할 때 많은 경험이 있으므로 연구에 시간을 투자하십시오 (예 : 디자인에 관한 책 읽기, 다른 경험에 대한 읽기, 동료 프로그래머와 디자인에 대한 이야기 등). ).
사람들은 미래를 예측하는 데 끔찍합니다. 요구 사항이 매일 바뀔 수있는 게임의 경우 특히 그렇습니다.
YAGNI 라는 원리가 있는데 , "You Are n't Gonna Need It"(일명 "You Are n't Gonna Need It")이 있는데, 기본적으로 필요한 것을 알기 전까지는 구현해서는 안된다고 말합니다 .
사람들이 필요하다고 생각한 기능들이 결코 사용 되려고하지 않았기 때문에 실제로 사용하지 않는 구조적 강성으로 인해 많은 시스템들이 혼란에 빠지는 것을 보았습니다.
나의 개인적인 철학은 아마도 가장 효과가있는 일을하는 것 입니다. 즉, Get It Done과 Hacking Shit Together는 차이가 있습니다. 목적으로 코드를 작성한다고해서 모든 것을 공개하는 것, 모든 것을하는 BLOB 클래스를 갖는 것, 또는 "나쁜"코드를 의미하는 수십 개의 다른 것들과 같이 "코드 냄새"를 발생시키는 것을해서는 안됩니다.
이것은 오늘날 내 마음가짐에서 참으로 평가됩니다.
저는 소프트웨어 빠른 프로토 타이핑의 친구입니다. 특히 게임 개발 중. 빠른 학습, 테스트 및 사용에 좋습니다. 하드웨어 프로그래밍에 가깝거나 복잡한 알고리즘이 가장 좋은 방법입니다.
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();내 Rapid Prototype 버전에는 적절한 프로토 타입 크러스트가 있어야합니다.
장점 :
당신이 잘한다면 당신은 결국 제품의 실제 디버그 / 학습 버전을 가질 수 있습니다.
우리는 프로젝트에서 그것을 사용하고 있으며 행복합니다.
민첩한 소프트웨어 개발을 살펴보십시오 . 그것은 총알이 아니지만 두 가지를 모두 목표로합니다 (완성 하고 견고한 소프트웨어 디자인).