우리는 여러 가지 상태가 될 것입니다. 대부분의 예제에서 상태를 기반으로 제어 가능한 문자로 switch 문을 봅니다. 이것은 대부분의 게임에서 일이 이루어지는 표준 방식입니까? 또는 해당 상태의 애니메이션과 논리를 처리하는 상태 집합을 만드는 것이 더 좋습니다. 후자가 필요하지 않을 수도 있지만 더 많은 유연성을 가질 수있는 많은 수업을 만드는 것처럼 보입니다. case 문은 코드를 더 복잡하게 만들지 만 전반적인 파일은 적습니다. AI 유형 함수의 경우 상태 모델을 사용하는 것이 좋습니다. 나는 내가 뭘하고있는 것 같아요, 내가 'walkleft', 'walkright'와 같은 간단한 것들에 대한 상태 객체를 만들어야할까요? 아니면 실종 된 일을하는 더 좋은 방법이 있습니까?상태 및 제어 할 수있는 게임 개체
감사합니다. 충분히 명확하길 바랍니다.
모두 스위치 설명문의 크기에 따라 다릅니다. 저는 개인적으로 여러 가지 상태의 물건을 만드는 것에 의지합니다. 당신이 그 때문에 많은 파일을 가지고 있다면 결국 그렇게 될 것입니다. 아마도 각 코드는 다른 코드가 간섭을 일으킬 가능성이 적은 모듈이기 때문에 코드를 더 쉽게 이해할 수 있습니다. 당신이 국가의 행동에 대해 추론하려 할 때, 당신을 혼란스럽게하는 잡다한 코드는 줄어들 것입니다.
가능한 한 코드를 작성하고 독립 실행 형 모듈로 테스트 할 수 있도록 디자인을 작은 조각으로 나누는 것이 좋습니다. 이렇게하면 디버깅이 훨씬 쉬워집니다. 모든 것을 모듈화 할 필요는 없지만 몇 개의 거친 클래스 대신 많은 클래스를 사용합니다.
불필요한 것들을 만드는 데 조심해야합니다. 유연성이 너무 높으면 유지 관리가 어려워집니다. 현재 문제를 해결할만큼 유연하게 만드십시오. 가상의 장래의 필요를 해결하는 데 너무 많은 노력을 기울이지 마십시오. 지금 필요한 것에 집중하십시오. 많은 사례가있는 커다란 switch 문이 코드를 지저분하게 만들 것입니다. 나는 그것이 바로 당신에게 당신의 대답을 줄 것이라고 생각합니다. 작은 기능과 작은 클래스로 간단한 코드로 기울여보십시오. 물론 당신은 그것들을 많이 가지고있을 것이지만, 얼마나 많은 작은 함수들이 서로 잘 어울리는지를 이해하는 것이 훨씬 쉽습니다. 거대한 함수 안에서 무수히 많은 명령문들이 서로 겹치게되는 것보다 훨씬 쉽습니다.
단순 케이스 문과 본격적인 상태 시스템 사이의 중간 지점으로 점프 테이블 (요즘 분기 테이블 또는 기능 또는 방법 테이블 일 가능성이 있음)을 사용하는 것이 좋습니다.