Tek oyunculu bir motor geçersiz verileri ne kadar güçlü bir şekilde reddetmelidir?

Tek oyunculu bir oyunda, bir varlığı harici komut dosyalarında belirtilen bileşenlerden oluşturmaya çalışırken, bileşenlerden biri yanlış biçimlendirildiğinde ne olması daha fazla arzu edilir?

• Motor bu bileşeni atlamalı ve varlığın oyun dünyasında sadece iyi yazılmış bileşenlerle yaşamasına izin vermeli mi?
• Yoksa bileşenlerden biri kötü biçimlendirilmişse, varlığı dünyaya eklememeli midir?

Not, sadece varlığa ne olması gerektiği hakkında - söylemeden gelmesi gereken - hataları günlüğe kaydetmekten bahsetmiyorum.

Değiştirilebilir bir oyundan bahsediyorsanız, yukarıdaki önerilerinizden birini takip etmek isteyebilirsiniz. Ancak kendi hatalarınızı devretmekten endişe ediyorsanız, söyleme. Fail-Fast'ın savunucusu oldum . Bu bir o hata ise size bırakmadan önce oluşturduk ve zorunluluk gidermek, hata bariz yapmalıdır. Wiki sayfasının alt kısmında yer alan makale, hızlı başarısız olmanın neden iyi olduğu ve ne zaman kullanılması gerektiği ve kullanılmaması gerektiği konusunda iyi bir okuma.

Oyun geliştirmede kullanıcı ve geliştirici arasındaki ayrım her zaman net değildir. "Hızlı başarısız" gibi standart programlama teknikleri, özellikle takım boyutları büyüdükçe, her zaman avantajlı değildir.

Örneğin, teknik sanatçınız gölgelendiriciyi hedefleme anahattı için vidaladı - geri dönüşü kırdı, diyelim, bu sadece SM4 sistemlerine yükleniyor ve fark etmedi çünkü hat sisteminin bir zirvesine sahip. Bu, bazı animasyonların yüklenememesiyle sonuçlanır. Bu animasyonlara, dövüş tasarımcınızın yazdığı belirli bir büyü tarafından referans verilir. Son olarak, seviye tasarımcınız yumurtlamaları yerine koymaya çalışıyor ve bu yumurtlamaların hepsi bu büyüyü yapabiliyor - ama şimdi dünyadan hiçbirini yerleştiremiyor çünkü büyüleri geçerli değil çünkü etkileri geçerli değil Tasarımcılar her zaman en kötü bilgisayarlara sahip oldukları için gölgelendiriciler yüklenmeyeceği için geçerli değil.

Bu yüzden demo saat 2'de hazır değil ve yatırımcılarınız neden oyunda tek bir düşman bile alamayacağınızı merak ediyor ve projeniz kapanıyor.

Ya da başarısızlığı günlüğe kaydettiğiniz ancak denemeye devam ettiğiniz seçeneği seçersiniz ve oyun bazı düşmanların büyü efektlerinin görünmemesi dışında iyi oynar - ancak yatırımcılar bunların nasıl görünmesi gerektiğini bilmiyorlar, bu yüzden farkına varmak.

Bu nedenle, neredeyse her zaman ilk seçeneği savunacağım - olabildiğince varlıkların ortaya çıkması. Başarısızlık gerektiren durumlar vardır - örneğin, yapıları yapabilecek kişiler (örneğin programcılar ve teknik üreticiler) ve yükte her zaman% 100 kontrol edilen kişiler veya kesinlikle sorumlu kişinin emin olduğunuzdan emin olmamanız gibi verilerin asla düzenlenmemesi gerekiyorsa sorun editörü kullanan kişidir - ancak bunlar olağan durumlar değildir ve yatırım yapmaya hazır olamayacağınız çok fazla teknik altyapı gerektirir.

Kullanıcı içe aktaracağı varlığı önizleyebilmeli ve hata olup olmadığını önceden bilmelidir.

Hangi hataların ölümcül olması gerektiğine bir şekilde karar vermelisiniz, oyuna eklenmesini engelleyin ve hangilerinin uyarı olarak reddedilebilir .

Elbette, içe aktarılan varlık herhangi bir nedenle kayıt oyunu verilerini geri döndürülemez bir şekilde değiştirebiliyorsa, kusursuz olmasını istersiniz.

Geliştirme sırasında, geçersiz veriler hakkında gürültülü olması gerektiğini öneririm. yani her şeyi okunacak bir yere kaydedin. Ancak, motorunuz bunu yoksayabilir ve devam edebilirse, bunu yapmalıdır. Gibi bir mantığa sahip olabilirsiniz

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

Çok oyunculu bir oyunda bile, bir oyuncunun sistemi aldatmaya çalıştığını varsaymazsanız bu kabul edilebilir.

Yazılımı serbest bıraktıktan sonra, oyuncuların bu günlükleri okumayacakları varsayımıyla varsayılan olarak bu günlük kaydını kapatmak isteyebilirsiniz.