Oyun geliştirme ile uğraşırken yazılım testi farklı mıdır?


11

Ben okuyordu bu kağıt o, örneğin, genel ve oyun geliştirme yazılım geliştirme arasındaki farklar hakkında ve yazarlar işaret yazılım testleri ile ilgili bazı iyi noktaları yaptı

... oyun geliştiricileri, bu testlerin oyun tasarımcılarının yaratıcı arzularının değişmesi karşısında hızlı eskime nedeniyle otomatik testi kullanmakta tereddüt ediyorlar.

Yani, bu okuma bana, bir oyunla uğraşırken / test ederken yazılım testinde başka hangi yönleri farklı veya özel olarak düşünmeliyiz diye düşündürdü? Herkes bu konuda deneyime sahip veya bu konuda başka bir şey duydunuz mu?


Makaleyle bağlantı kurmak ister misiniz? Okumayı merak ederdim.
RubberDuck

1
Kağıt şu şekildedir : microsoft.com/en-us/research/wp-content/uploads/2016/02/… . Oh, ve sakıncası yoksa bu konuda fikrini ver. Teşekkürler. :-)
Ronnie Edson

9
Korkarım ki oyun dışı gelişimde de ortaya çıkan güçlerin değişen arzuları karşısında hızlı eskime (testlerin). Hangisi belki de oyun geliştirmenin diğer gelişimden farklı olmadığını göstermektedir?
Erik Eidt

İş yazılımı ve oyunlar arasındaki en büyük farkın, neredeyse her yerde yaygın olan "değişen gereksinimler" olmadığını, ancak performansı ve bir oyunu oluşturan yoğun kullanıcı arayüzü çalışmalarının vurgulandığını söyleyebilirim. İş yazılımlarında, veri ve mantık modelleri sunumdan ayrılma eğilimindedir ve bu da onları birim test için kolay adaylar haline getirir. Oyunların her zaman bu lüksü yoktur. Bu online oyunların sunucu tarafı kısmı vs. daha geleneksel yollarla, aynı şekilde saf oyun mantığı, canavar yumurtlama oranları, test edilemeyeceğini söylemek değildir
Dan1701

1
Farklı çok geniş bir kilisedir. Ve daha çok neyi karşılaştırdığınıza bağlı.
Robbie Dee

Yanıtlar:


10

Modern oyunlar aslında bir şirket içi veya özel oyun motoru kullanılarak geliştirilen bir ton yaratıcı sanat içeriğidir. Motorun çoğu, birim için test edilebilir (işleme, geometri, fizik, AI modülleri vb.). Benzer şekilde, geliştirilen içeriğin ayrı ayrı bölümlerine de basit testler eklenebilir. Bu, birim ve beyaz kutu testinin gerçekten mümkün ve başarılı olduğu anlamına gelir.

"Bir bütün olarak ürün" söz konusu olduğunda, bir oyun bir simülasyon. Basit bir iş programından daha üretken karmaşıklığa sahip olabilir. Sayılabilir, iyi planlanmış davranışlara sahip bir kurumsal kaynak planlayıcısına karşı sonsuz, benzersiz, prosedürü oluşturulmuş dünyaları düşünün. Basitçe söylemek gerekirse, oyunlar bağlamında bir şey yapmanın olası benzersiz yollarının sayısı, matematiksel olarak çok çok büyük olabilir. Aslında oyunlar için bir satış noktası olarak kabul edilir.

Buna ek olarak, son çıktının tamamen işitsel görsel olduğu ve bu çıktının mutlak doğruluğunun belirleyici bir standardı olmadığı gerçeğini de ekleyin. GPU yongalarının kesin hesaplamalar yapmasına gerek yoktur, bazıları kesin olmasa bile çok fazla hesaplama yapar.

Ve son olarak, asıl amaç Eğlence . Oyuncular 60+ FPS çalıştırıyorsa, harika görünüyor ve sonsuz saatler süren eğlenceli içeriğe sahipse aksaklıklarla iyi durumda.

Bu, geleneksel otomatik kara kutu test fikirlerini oyunlara uygulandığında "çok somut ve buna değmez" bir bölgeye yerleştirir.

Bununla birlikte, son zamanlarda NN'leri , etkili bir şekilde keşif, kendi kendine öğrenen maymun testi olan oyun oynamaları için eğitme girişimleri olmuştur .


2
"Ortalama işletme programı" nedir?
Ocak'ta

1
Evet ! Farklı olan etkileşim sayısı o kadar fazla değildir (birbiriyle ilişkili binlerce işlem türü ve sonsuz bir şekilde yeniden yapılandırılabilen bir süreç ortamı ile önde gelen bir ERP alın). Bir işletme yazılımının bir entegrasyon testinde kolayca doğrulanabilecek tekrarlanabilir bir davranış sağlaması beklenir. Oyunlar eğlendirmek zorunda ve tekrarlanabilir her şey sıkıcı. Bu nedenle, test aracının eğlence derecesini veya kullanıcının gördüğü sahnelerin tutarlılığını ve gerçekliğini ölçmesi zordur. Bundan 30 yıl sonra bazı yapay zeka ile olabilir ....?
Christophe

@Christophe tekrarlanabilir kapsamına bağlıdır - örneğin "karakter vurulduğunda, 5 can kaybetmelidir" mükemmel tekrarlanabilir ve mükemmel bir şekilde test edilebilir. Önemli olan, tekrarlanabilir test edilebilir mantığın, savunulması gereken daha az somut durumları olan parçalardan iyi bir şekilde soyutlanmasıdır.
Ant P

2

Gamedev yaptığımdan bu yana uzun yıllar geçti ama güzel cevabın üstünde, eklemek ve ayrıntı vermek istediğim bazı şeyler var.

Daha önce bahsedilen, çıktının sıkı "FPS-kritik" kısıtlamalarına ve hesaplama / bellek bütçelerine karşı sadece görsel ve işitsel olduğudur. Sorular daha iyi olduğunda, doğruluk fikirleri bulanıklaşıyor, "İyi görünüyor mu? Kesintisiz olarak sorunsuz çalışıyor mu? Harika görünüyor mu?" tasarımcı / geliştirici işbirlikleri her hızlı yinelemede biraz farklı görünmeye ve ses çıkarmaya neden olurken, geliştiriciler ince ayar yapıyor ve ayarlıyor ve yaklaşıyor.

Bir diğeri, testçilerin harika olabileceğidir! Onlar beri, başka bir etki Test kullanıcıları daha adanmış bir grup asla buldum istiyorumyazılımı test etmek için. Onlar eğleniyorlar. Oyun bağımlısı ve oyunun her köşesini keşfederken bilgisayarın yanında uyuyorlar. İnsanların yazılımın her köşesini pratik olarak bağımlı hale getirirken her köşesini iyice test ettikleri zaman, en belirsiz hataları bile bulmak oldukça kolay hale geliyor. Mevcut endüstrimde, test cihazlarının çalışması biraz daha zordur, çünkü birçoğu geçim kaynaklarını yazılıma bağlayan profesyoneller olduğundan, işlerini yapmak için birkaç özelliğe güvenirler ve yorucu olmakla ilgilenmezler. her kuytu ve çatlak her zaman. Doğal olarak, insan test kullanıcılarına çok fazla güvenemediğimizde, daha otomatik testlere ihtiyacımız var.

Yine bir diğeri, bir oyunun kod tabanının tipik olarak yıllar ve yıllar boyunca korunmadığı ve değiştirilmediği ve genişletilmediğidir. İlk olarak 6502 montajında ​​geliştiren Super Mario'nun geliştiricileri, oyunun gönderilmesinden çok sonra orijinal koda benzeyen herhangi bir şeyi korumak zorunda kalmışlar gibi değil. Doom 3 muhtemelen Doom 1'den sıfır kod satırı (veya yakın) kullanıyor. Devam eden bir franchise varsa, yeni oyunlar "yükseltmelerden" daha çok "devam ediyor". Çoğu oyun sadece bazı yamaları, DLC'leri gönderiyor ve serbest bırakıyor ve kod tamamlanıyor. Bu, onlarca yıldır taşınan ve sürdürülen Amiga günlerine dayanan kodları korumak için çalıştığım VFX endüstrimin büyük bir tezatıydı. Oyunlar genellikle don '

Oyun kod tabanlarının bu kısa ömürlü doğasının nedenlerinden biri, donanıma bu kadar bağlı olmalarıdır. En ileri nitelikleri ve FPS açısından kritik gereksinimleri ile birleştirildiklerinde, genellikle donanım ayrıntılarını soyutlayacak, hatta yakın bile olmayacak şekilde geliştirilemezler. Genellikle hedeflenen donanım üretimi için çok özel olarak yazılırlar ve PS3'ün yerini bir PS4 ile değiştirmesi, daha sonra artık eskimiş ve yerine bir PS5 vb. Donanım yetenekleri, oyunun tasarımında ve geliştirilmesinde çok önemli bir rol oynar, genellikle PSX için PS4 için yazılmış aynı kodun çoğunu korumaya değmez, örn. Nesiller boyu süren çoğu oyun serisi hala yeni nesil motorlarını yazıyor büyük ölçüde en yeni donanım için sıfırdan başlayarak.

Kısa ömürlü bir kod tabanı ile sınırlı bakım süresi gelir (yani, kodun değiştirilmesi gereken sınırlı bir süre). Her yükseltme ile motorun kapsamı gittikçe büyüyor ve oyunların görev açısından kritik bir yere yakın olmadığı gerçeğiyle birleştiğinde, kodun değiştirilmesi için sınırlı bir zamanla, kesinlikle böyle bir şey yok en kapsamlı birim ve entegrasyon testini uygulamak için kritik ihtiyaç. Gelecekte değişiklik yapılmayacaksa gelecekteki değişikliklerin bütünlüğünün sağlanmasında bunu yapmanın bir yararı yoktur ve eski kod tabanlarının birim testi ve yeniden düzenleme boyutu, ilk etapta "eski" değilse doğal olarak önemsizdir.

Her zaman alakalı olmayan bir diğer küçük oyun, herhangi bir masaüstü bağlantı noktası olmadan çok dar bir donanım aralığını hedefleyebileceğidir. Bu durumlarda, yazılımı radikal olarak farklı donanım ve sürücülerle çalıştıran kullanıcılar olan bu bağlamlarda öngörülemeyen büyük bir hata kaynağı ortadan kaldırılmıştır.

Bununla birlikte, en yüksek / en kaba düzeyde entegrasyon testi daha çabuk faydalı olma eğilimindedir. Örneğin, birçok oyun, "tekrarlar" için oyun durumunun zaman içinde nasıl değiştiğini kaydetmek için bir yol kullanabilir. Bu tür tekrar özellikleri, oyunun deterministik olmasını ve daha önce başka biri tarafından kaydedilmiş bir oyun oturumunu tekrar oynatmak için kendi başına bir test aracı olarak kullanılabilir.

Ayrıca, oyunları için bot yazmak gibi şeyler yapan ve botların oyunlarını maksimum hızda oynatıp bu simülasyonu çalıştıran, başlangıçta bir veya iki gün sonra belirsiz bir çökme ile karşılaşan, düzelttikten sonra küçük stüdyolarda çalışan gamedevlerle karşılaştım. simülasyonu tekrar çalıştırdı ve haftalarca çalıştırdıktan sonra bile şov durduran çökmeler kalmayana kadar tekrarladı. Dolayısıyla, gamedev'lerden yazılımlarını test etmeye kadar gördüğüm ilginç türden pragmatik yaklaşımlar var, ancak çoğu zaman en kaba entegrasyon testi seviyesine benzeyen ve oyuncuların oyunla gerçekte nasıl etkileşime girdiğine çok benzeyen şeyler.

Son olarak, bu büyük AAA oyun motorları tamamen farklı bir canavara benzemeye başlıyor: daha uzun ömürlü, donanımı biraz daha iyi bir şekilde soyutlama, daha büyük kod tabanları ve daha uzun bakım aralıkları ile seviye editörleri tam gelişmiş geliştirme ortamlarına benzemeye başlıyor. Bu büyük motorların muhtemelen daha kapsamlı bir test prosedürü gerektireceğini hayal ediyorum, özellikle kodlarının korunma süresi önemli ölçüde genişliyorsa. Hala birçok oyun stüdyosu büyük AAA oyun motorları yazmıyor: ya lisans alıyorlar ya da kapsamı oldukça küçük olan ve yıllarca korunmayacak küçük bir tescilli motor geliştiriyorlar.


1
Botlar. Evet, bu denenmiş ve test edilmiş bir yaklaşım.
SD
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.