“조기 최적화하지 않는다”는 것이 “가장 최악의 일을하는 방법을 선택”을 의미하지는 않습니다. 프로토 타입을 작성하지 않는 한 여전히 성능에 미치는 영향을 고려해야합니다. 요점은 융통성, 신뢰성 등과 같이 개발의 그 시점에서 다른 더 중요한 것들을 무너 뜨리지 않는 것입니다. 간단하고 안전한 최적화를 선택하십시오. 비용을 추적하십시오. 강력한 타이핑을 사용해야합니까? 대부분의 게임은 잘 작동했습니다. gamemplay에 대한 유연성의 흥미로운 사용법을 발견 한 경우이를 제거하는 데 얼마나 많은 비용이 듭니까?

최적화 된 코드, 특히 “스마트”코드를 수정하는 것이 훨씬 어렵습니다. 그것은 항상 어떤 것을 더 좋게 만들고 다른 것은 더 나쁘게 만드는 선택입니다 (예를 들어, 메모리 사용을 위해 CPU 시간을 거래 할 수 있습니다). 그 선택을 할 때, 당신은 모든 의미를 알고 있어야합니다. 그것들은 비참 할 수도 있지만 도움이 될 수도 있습니다.

예를 들어 Keen, Wolfenstein 및 Doom 사령관은 각각 최적화 된 렌더링 엔진 위에 구축되었습니다. 각 게임에는 “트릭”이있어서 게임을 처음부터 사용할 수있었습니다 (각각 시간이 지남에 따라 추가 최적화가 있었지만 여기서는 중요하지 않습니다). 괜찮습니다 . 게임의 핵심, 게임을 가능하게하는 생각을 크게 최적화해도 괜찮습니다. 특히이 최적화 된 기능을 통해 새로운 영역을 탐색하는 경우 많이 탐색하지 않은 게임 디자인을 고려할 수 있습니다. 최적화가 도입 한 제한은 흥미로운 게임 플레이를 제공 할 수도 있습니다 (예 : RTS 게임의 단위 수 제한은 성능을 개선하기위한 방법으로 시작되었지만 게임 플레이 효과도 있습니다).

그러나 이러한 각 예에서 게임은 최적화 없이는 존재할 수 없었습니다. 그들은 “완전히 최적화 된”엔진으로 시작하지 않았습니다. 그들은 맨 필요로 시작하여 일을 시작했습니다. 그들은 새로운 기술을 개발하고 재미있는 게임을 만드는 데 사용했습니다. 그리고 엔진 트릭은 가능한 한 코드베이스의 작은 부분으로 제한되었습니다. 더 무거운 최적화는 게임 플레이가 대부분 수행되었을 때 또는 흥미로운 새로운 기능이 등장 할 때만 도입되었습니다.

이제 만들고 싶은 게임을 생각해보십시오. 그 게임을 만들거나 깨는 기술 기적이 실제로 있습니까? 아마도 당신은 무한한 세상에서 열린 세계 게임을 상상하고있을 것입니다. 즉 정말 게임의 중앙 조각? 게임이 없으면 단순히 작동하지 않습니까? 어쩌면 당신은 현실적인 지질학 등으로 지형이 제한없이 변형 될 수있는 게임에 대해 생각하고있을 것입니다. 더 작은 범위에서 작동하게 할 수 있습니까? 3D 대신 2D로 작동합니까? 최적화로 인해 기존 코드의 큰 덩어리를 재 작업해야 할 경우에도 가치가있을 수 있습니다. 더 큰 물건을 만들어도 게임이 더 나아지는 것은 아니라는 것을 깨달을 수도 있습니다.

많은 최적화가 적용된 최근 게임의 예로서, Factorio를 지적하겠습니다. 게임의 중요한 부분 중 하나는 벨트입니다. 수천 개가 있으며 공장 주변에 많은 개별 재료를 운반합니다. 게임이 최적화 된 벨트 엔진으로 시작 되었습니까? 아니! 사실, 원래 벨트 디자인은 최적화하기가 거의 불가능했습니다. 벨트에있는 항목을 물리적으로 시뮬레이션 한 결과 흥미로운 일이 생겼습니다 (이것은 “긴급한”게임 플레이를 얻는 방식입니다-놀라운 게임 플레이입니다). 디자이너), 그러나 벨트의 모든 단일 항목을 시뮬레이션해야 함을 의미했습니다. 수천 개의 벨트를 사용하면 수만 개의 물리적으로 시뮬레이션 된 항목을 얻을 수 있습니다. 심지어이를 제거하고 벨트로 작업을 수행하면 관련 CPU 시간을 95-99 % 줄일 수 있습니다. 메모리 로컬 리티와 같은 것을 고려하지 않아도 그러나 실제로 해당 한계에 도달 할 때만 유용합니다.

벨트와 관련이있는 거의 모든 것이 벨트가 최적화되도록 벨트를 다시 만들어야했습니다. 대형 공장에는 많은 벨트가 필요했으며 대형 공장이 게임의 매력 중 하나이기 때문에 벨트를 최적화해야했습니다. 결국, 큰 공장을 가질 수 없다면 왜 무한한 세상을 가지고 있습니까? 재밌게 물어봐야한다-초기 버전 은 그렇지 않았다 🙂 게임이 재 작업되어 현재 위치를 찾기 위해 여러 번 재 형성되었다. 이 같은 게임을하고 C ++로 전환했습니다. 그리고 Factorio에게는 훌륭하게 작동했습니다 (아직도 프로젝트에서 최적화되지 않은 것이 좋지만-특히 취미 프로젝트로 관심이 없기 때문에 실패했을 수도 있습니다).

그러나 일이있다 있습니다제한된 범위의 공장에서 할 수있는 많은 일들이 있습니다. 많은 게임들이 그 사실을 보여주었습니다. 한계는 자유보다 재미를 더 강화할 수 있습니다. “지도”가 무한하다면 Spacechem이 더 재미 있을까요? 많이 최적화 된 “벨트”로 시작했다면 거의 그렇게해야합니다. 물리 시뮬레이션 컨베이어 벨트로 수행 할 수있는 흥미로운 작업을 확인하는 등 다른 설계 방향을 탐색 할 수 없었습니다. 잠재적 인 디자인 공간을 제한하고 있습니다. 완료되지 않은 게임이 많이 보이지 않기 때문에 어려운 부분이 재미를 얻습니다. 재미있는 게임마다 수백 가지가있을 수 있습니다. 끔찍한 혼란으로 풀려 나갔습니다). 최적화가 도움이된다면 계속하십시오. 그렇지 않으면 … 아마도 조기 일 것입니다. 일부 게임 플레이 메커니즘이 훌륭하게 작동한다고 생각하지만 진정으로 빛을 발하기 위해서는 최적화가 필요합니다. 흥미로운 역학이 없다면최적화하지 마십시오 . 재미를 먼저 찾으십시오-대부분의 최적화가 도움이되지 않으며 종종 해 롭습니다.

마지막으로, 당신은 훌륭하고 재미있는 게임이 있습니다. 지금 최적화하는 것이 이치에 맞 습니까? 하아! 생각만큼 명확하지 않습니다. 재미 있나요대신 할 수 있습니까? 시간이 여전히 제한되어 있음을 잊지 마십시오. 모든 것이 노력이 필요하며, 그 노력을 가장 중요한 부분에 집중하려고합니다. 예, “무료 게임”또는 “오픈 소스”게임을 만드는 경우에도 마찬가지입니다. 게임이 어떻게 진행되는지보십시오. 성능에 병목 현상이 발생하는 위치를 확인하십시오. 그 장소를 최적화하면 더 큰 즐거움을 얻을 수 있습니까? 더 많은 플레이어를 유치 할 수 있습니까 (예 : 컴퓨터가 약하거나 다른 플랫폼에서)? 항상 우선 순위를 정해야합니다. 비율을 산출하는 노력을 찾으십시오. 게임을하고 다른 사람들이 게임을하는 것을 보는 것만으로도 낮은 성과를 거둘 수 있습니다. 그러나 중요한 부분을 참고하십시오-거기에 가려면 게임이 필요합니다 . 그것에 집중하십시오.

체리로서 최적화는 결코 끝나지 않는다는 것을 고려하십시오. 작은 확인 표시가있는 작업이 아니라 다른 작업으로 넘어갑니다. 항상 “한 번 더 최적화”할 수 있으며, 개발의 큰 부분은 우선 순위를 이해하는 것입니다. 최적화를 위해 최적화를 수행하지 마십시오. 특정 목표를 달성하기 위해 수행합니다 (예 : “333 MHz Pentium에서 한 번에 200 개의 화면을 표시하는 것이 좋습니다”). 더 이상 터미널 목표의 전제 조건이 아닐 수도있는 중간 목표에 너무 집중하여 터미널 목표를 추적하지 마십시오.

답변