Roblox, Oyun Oluşturma Sürecini Nasıl Değerlendiriyor?

Yeni mobil öncelikli içerik oluşturma aracımız Build, Roblox kullanıcılarının metin komutlarını kullanarak oyun oluşturmasına ve bunları dünyanın dört bir yanındaki oyunculara yayınlamasına olanak tanır. Bütünsel bir oyun oluşturmak, oyun üretimi için uçtan uca bir ajan sistemini gerektirir: kod, görsel varlıklar, oyun sistemleri, kullanıcı arayüzü ve kontrolleri tek bir bileşik yapıda koordine eden bir sistem. Bu sistem, oyuncu girdileri ve çok oyunculu etkileşimlerle ortaya çıkan çeşitli senaryoları sağlam bir şekilde yönetmelidir. Yeni Zelanda’daki alfa sürümünün piyasaya sürülmesinden bu yana, 100.000’den fazla oyuncu Build’i kullanarak oyun oluşturmayı denedi ve yaklaşık 9.000 Build oyunu yayınlandı.¹ Build’i oyun oluşturmak için kullanan binlerce kişiden %71’i daha önce Roblox Studio’yu hiç kullanmamıştı,¹ bu da onların Build ile yeni bir şey denediklerini gösteriyor.

Ancak içerik oluşturucular, bu yeni aracı ancak kullanımı kolaysa ve ürettiği oyunların kalitesi üzerine geliştirme yapılabilecek düzeyde yüksekse kullanacaktır. Build ile oluşturulan oyunların kalitesini anlamak için, baştan sona tüm içerik oluşturma sürecini değerlendiriyor ve bu değerlendirmelerin yanı sıra içerik oluşturucuların geri bildirimlerini de ürünü iyileştirmek için kullanıyoruz. Değerlendirme (eval) çerçevemiz, niyet anlayışını, 3D oynanabilirliği ve oyunun son rötuşlarını önceliklendirmemize ve iyileştirmemize yardımcı oldu. Build’in Yeni Zelanda’da alfa sürümünün piyasaya sürülmesinden bu yana, içerik oluşturucuların memnuniyeti %10 arttı, istenmeyen çıktılar %18’den %3’e düştü ve yönlendirilmiş oturumların yaklaşık %14’ü ile oyun testlerinin %19’u yayınlandı^.² Bunlar, ilerlemeye ilişkin açıklayıcı göstergelerdir; yalnızca değerlendirmenin etkisine dair nedensel tahminler değildir.

Oyun Oluşturmayı Değerlendirmenin Neden Farklı Olduğu

Oyunlar, uygulamalar, videolar ve dünya modelleri gibi bileşik eserler üreten diğer sistemlerde de görülen bazı değerlendirme zorluklarını paylaşır. Örneğin, kalite, birden fazla bileşenin birbiriyle nasıl çalıştığına bağlıdır ve tek bir bileşen puanı sonucu tam olarak tanımlayamaz. 

Oyunları diğerlerinden ayıran özellik, ürünün oyuncular tarafından yönlendirilen, çalıştırılabilir, gerçek zamanlı bir sistem olmasıdır. Tepki verme, etki, ilerleme ve oyun hissi gibi özellikler etkileşim yoluyla ortaya çıkar ve yalnızca kod veya varlıkları inceleyerek tam olarak değerlendirilemez. Bu nedenle bir oyun, hem düşük seviyeli doğruluk (hatasız ve oynanabilir) hem de yüksek seviyeli oyuncu deneyimi (prototip değil, tamamlanmış hissi veren bir oyun) açısından benzersiz derecede yüksek bir çıtayı aşmak zorundadır. 

Değerlendirme yoluyla yanıtlamaya çalıştığımız soru, herhangi bir parçanın doğru olup olmadığı değil, bütünsel yapının yaratıcının niyetine uyup uymadığı ve oyuncuların tüm deneyimi sonuna kadar oynayabilip oynayamayacağıdır. Bu soruyu yanıtlamak için tek bir ölçüt yetmez.

Dört İşaret, Tek Çerçeve

Build yaratım değerlendirme çerçevemiz dört göstergeyi birleştirir. Her biri farklı bir soruyu yanıtlar, farklı bir hata türünü tespit eder ve somut bir nicel puan verir:

1. Oyun spesifikasyon kalitesi (0 - 100 puan): Build, uçtan uca bir oluşturma aracıdır: Yaratıcının talimatını bir spesifikasyona dönüştürür, ardından bunu kullanarak oyunu oluşturur. Değerlendirici, spesifikasyonun önemli kararları açıkça alıp almadığını, yaratıcının niyetini koruyup korumadığını, Roblox'un çalışma zamanı içindeki uygulanabilirliği dikkate alıp almadığını ve hiç ifade edilmemiş gereksinimleri uydurmaktan kaçınıp kaçınmadığını değerlendirir.

2. Statik oyun kalitesi (0 - 100 puan): Statik değerlendirme aşamasında, değerlendirici oluşturulan oyunu Roblox Studio düzenleme modunda inceler. Bu inceleme, oyun yapısını, komut dosyalarını, varlıkları, özellikleri, bağlantıları ve istemci/sunucu sınırlarını içerir. Bu aşamada iki soruya yanıt arıyoruz. Birincisi, oyunun doğru bir şekilde oluşturulup oluşturulmadığıdır: gerekli sistemlerin uygulanması, motor API’si ve ağ seçimleri, beklenen kontrol ve kullanıcı arayüzü bileşenlerinin varlığı, oyun mimarisinin sağlamlığı ve tutarlılığı. 

İkincisi ise oyunun eğlenceli olacak şekilde tasarlanıp tasarlanmadığıdır: temel döngü derinliği, içerik çeşitliliği ve zorluk artışı, ilerleme, tekrar oynanabilirlik ve türün standartlarının ötesinde yenilikçilik. Bir oyun mimari açıdan kusursuz olabilir ancak içerik derinliği olmayabilir ya da fikirlerle dolu ancak kötü bir şekilde kurgulanmış olabilir. 

Bu iki bakış açısını birbirinden ayırıp en iyi uygulamalarla karşılaştırarak, oyunun hangi noktalarda yetersiz kaldığına dair daha ayrıntılı bir fikir edinebiliriz.

3. Oynanabilirlik Testi (%0 - %100 başarı oranı): Oynanabilirlik testi değerlendiricisi oyunu çalıştırır ve koddan olayları tetiklemek yerine, dokunmalar, tıklamalar, tuş vuruşları ve gezinme gibi gerçek oyuncu benzeri girdilerle bir test planını uygular. Durum bazlı bir test planı, oyunun başlatılmasını, yanıt vermesini, ilerlemesini, hatalardan kurtulmasını ve çalışma zamanı hataları içermemesini kontrol eder. Her bir öğe, basit bir “oynanabilir/oynanamaz” değerlendirmesinin yanı sıra, kademeli ağırlıklı bir başarı oranı olarak raporlanan ikili (geçti/kalmadı) bir sonuçtur. Tutarlılığı ölçmek için testleri tekrar ederiz.

4. Görsel ve deneyimsel kalite (0 - 100 puan): Bir oyunun görünümü ve hissi açısından en önemli unsurların bazıları koddan okunamaz; bu nedenle görsel değerlendirici, farklı cihazları temsil eden görüntü pencerelerinde yakalanan oyun görüntülerini kullanarak sunumu bağımsız olarak puanlar. Bu değerlendirme ölçeği, varlıkların işlenişi, kullanıcı arayüzünün bitirme kalitesi, hareket, ışıklandırma ve sese dayalı olarak oyunun sadece nasıl göründüğüne ve seslendiğine odaklanır. Temel soru şudur: Oyun, piyasaya sürülebilir bir ürün gibi mi yoksa bir prototip gibi mi görünüyor? Görselleri mekaniklerden ayrı tutmak, “kod çalışıyor” ve “oyun bitmiş görünüyor” gibi unsurların tek bir yanıltıcı puan olarak ortalamasının alınmaması anlamına gelir.

Puanlanan sinyallerin yanı sıra, her çalıştırmada token kullanımı, araç çağrıları, tetiklenen beceriler ve gecikme süresi gibi yalnızca bilgilendirme amaçlı metrikler de yakalanır. Bu metrikler değerlendirme puanını etkilemez, ancak bir sonucun nasıl ortaya çıktığını açıklayabilir ve aynı oyun için iki kat daha pahalı hale gelen bir derleme gibi değerlendirme kriterlerinin gözden kaçırdığı gerilemeleri tespit edebilir.

Sinyaller, tespit ettikleri hatalarla eşleştirilir:

Yönlendirmeli 3D Obby Parkurunda Yürüyüş

Sinyaller, gerçek bir talimatta en kolay şekilde görülür. Örneğin, “Başlangıç platformu, hareketli engeller, kontrol noktaları ve bitiş çizgisi bulunan gerçek bir 3D obby oyunu.” Obby'ler, Roblox'ta popüler bir platform oyunu türüdür. Her uygulama detayını belirtmese bile, yaratıcının niyeti açıktır. Yapımcı, makul varsayımlarla detayları doldurmalıdır.

Plan ve Spesifikasyon

Build, Skyforge Ascent adlı yeni bir oyun için, kontrol noktaları ve üç tür tehlike içeren beş bölümlük bir parkuru ayrıntılı olarak anlatan bir teknik özellik belgesi hazırladı. Bu belge, temel döngüyü, zorluk eğrisini, sanat yönünü, ekranları, üst katmanları ve kontrolleri tanımladı. Teknik özellik değerlendirmesi, belgeye 91/100 puan verdi; belge, eksiksizlik, talimatlara uyum, uygulanabilirlik ve iç tutarlılık açısından tam puan aldı. Puan kesintisi, iki belirli boyuttan kaynaklandı: uygulama ayrıntıları ve kabul kriterlerinin kapsamı. 

Spesifikasyon, dönme hızları, kayma mesafeleri, karo zamanlamaları, platform boyutları veya sıfırlama düzlemi yüksekliği gibi sayısal sabitleri hiçbir zaman kesin olarak belirlemedi; bu nedenle bir mühendisin bunları hala belirlemesi gerekiyor. Ayrıca, birkaç kabul kriteri (“yaklaşık 24 platform” veya “göksel demirhane paleti” gibi) kesin olarak yanlışlanamaz niteliktedir. Yüksek bir spesifikasyon puanı, yalnızca belgenin geliştirmeye hazır olduğunu kanıtlar. Bu taahhütlerin gerçek oyun geliştirme sürecinde geçerliliğini koruyup korumayacağı ise sonraki üç aşamada ölçülecektir.

Statik Denetimler: Kod Kalitesi ve İçerik Kalitesi

Sanal yargıç, Skyforge Ascent'in placefile'ını oyunu oynamadan inceledi ve iki değerlendirme merceği farklı sonuçlara ulaştı.

Aynı yer dosyasını inceleyen mühendislik mercek, oyuna 98/100 puan verdi. Beş bölüm ve üç hareketli tehlike içeren örnek niteliğinde bir yapı tespit etti; sunucu yetkili sıralı kontrol noktaları, düşme-sıfırlama sistemleri ve StyleSheet çerçevesine dayalı bir kullanıcı arayüzü kullanılarak yaratıcının niyetini tam olarak karşıladı. Spesifikasyonda belirtilen her şey yerine getirilmişti. Tek sorun, kullanılmayan iki yardımcı işlev dışa aktarımdı.

Tasarım bakış açısı ise oyuna 31/100 puan verdi. Her şey çalışıyordu, ancak oyun ilerleme, tekrar oynanabilirlik, oyuncu inisiyatifi ve özgün çekicilik açısından sıfır puan aldı. Temel döngü basit ve doğrusal idi — her kontrol noktasına ulaş, bitiş çizgisini geç — ve her denemede çok az çeşitlilik vardı; ikinci kez oynamak için bir neden yoktu. Bu, obby türünün klasiklerinden biriydi, kendine özgü bir çekiciliği olan bir oyun değildi.

İşte bu fark, araştırmanın ortaya koyduğu bulgudur. Kod kalitesi ile içerik kalitesi temelde farklı boyutlardır ve bir sürüm, birinde neredeyse mükemmelken diğerinde başarısız olabilir. Tek bir karma kalite puanı, bu iki unsuru ortalamaya indirgeyerek anlamsız bir sonuç verirdi.

Oyun testi

Oyun testi ajanı, gerçek bir oyuncu gibi girişler yaparak koşu oyununu oynadı ve test planındaki dokuz maddenin tümünü başarıyla tamamladı: başlangıç platformunda bir karakter oluşturma, boşluklar arasında 3D geometriyle gezinme, tehlikeli darbeler alma, kontrol noktalarını tetikleme ve otomatik düşme kurtarma, koşuyu tamamlama ve yeniden başlatma; bunların hepsi sıfır çalışma zamanı hatasıyla gerçekleştirildi. Bu özel koşuda, Skyforge Ascent oyun testinde 100/100 puan aldı.

Mükemmel bir oyun testi puanı, sadece mekaniklerin çalıştığını ve oyunun baştan sona teknik olarak oynanabilir olduğunu kanıtlar. Oyunun gerçekten ilgi çekici veya eğlenceli olup olmadığına dair hiçbir şey söylemez—bu ayrım, tasarım açısından oyuna 31 puan verilmesinin tam da nedenidir.

Görsel Kalite

Son olarak, değerlendirme sistemi, görsel sunum açısından kaydedilen oturumu telefon boyutunda bir görüntü alanında puanladı. Skyforge Ascent, 86/100 puan aldı: temiz, tutarlı ve tipik bir engelli koşu oyununun görsellerine rahatlıkla uyan; okunabilir platform geometrisi; anlaşılır tehlikeler; ve modern, göze batmayan bir HUD. Küçük görsel sınırlamalar oyunun mükemmelliğe ulaşmasını engelliyor, ancak bozuk hiçbir şey yok ve oyuncunun kaydırmayı durdurmasına neden olacak hiçbir şey de yok.

İzleme Metrikleri

Aynı oyun seansı, süreç metriklerini de kaydetti. Oyunun derlenmesi yaklaşık sekiz dakika sürdü, sıfır araç hatası vardı ve Build, 3D, kullanıcı arayüzü, komut dosyası düzenleme, varlık ekleme ve oyun sesi becerilerini kullandı. Bu metrikler değerlendirme puanını doğrudan etkilemese de, oyunun nasıl yapıldığını bize gösterir ve gelecekte hiçbir kazanç sağlamadan daha yavaş veya daha pahalı hale gelen bir derlemeyi işaret eder.

Beş aşamada Skyforge Ascent, oyun özellikleri, kod kalitesi, içerik kalitesi, oyun testi ve görsel kalite açısından farklı puanlar aldı. Bu boyutlardan dördü, Build’in tek bir komutla eksiksiz, hatasız, oynanabilir ve sunuma hazır bir Roblox deneyimi yaratabileceğini gösteriyor. Bir boyut ise, bu oyunun kimsenin ikinci kez oynamayı tercih edeceği bir oyun olmadığını belirtiyor. Bu farkı ortalamaya çekmek yerine ölçmek, Build değerlendirmesinin asıl amacıdır.

Erken Değerlendirme, Build’i Nasıl Geliştirdi? 

Değerlendirme sonuçları sadece puanlar üretmekle kalmaz, aynı zamanda ürün iyileştirmeleri için eyleme geçirilebilir yönlendirmeler de sağlar. Tek tek bileşenlerin hata ayıklamasını bütünsel sistem düzeyinde testlerle birleştirerek, standartlaştırılmış komut dizileri üzerinden yapılan çevrimdışı toplu değerlendirmeler, Build’in geliştirilmesini doğrudan şekillendirmiştir. 

1. Alfa sürümündeki yaratıcıların sorunlarını hızla çözme: Yeni Zelanda’daki alfa lansmanımızda, kullanıcılar bize, 3D oyun istedikleri halde Build’in bazen 2D oyun oluşturduğuna dair geri bildirimde bulundular. Değerlendirme çerçevesi, ekibimizin Build’in 3D yeteneklerini hızla geliştirmesine yardımcı oldu. İki hafta içinde, kullanıcılar bunu açıkça belirtmeseler bile, bir 3D oyun oluşturma niyetini anlama konusunda Build’in yeteneğini geliştirdik. Ayrıca, nesne konumlandırma, aydınlatma vb. ile ilgili yaygın sorunları gidererek 3D oynanabilirliğini ve görsel kalitesini iyileştirdik. O zamandan beri, tüm şikayetler arasında “istediğim gibi değil” şikayetleri %18’den %3’e düştü; oyun testinden sonra genel memnuniyetsizlik oranı 10 puan azaldı. Ayrıca, çerçevenin kendisinde yineleme yaparken de birçok ders çıkardık. 
2. Modeller ve mimariler arasında karşılaştırmalı performans değerlendirmesi: Değerlendirme çerçevemizi kullanarak, Build sistemi yapılandırmalarını standartlaştırılmış komut dizileriyle karşılaştırmalı olarak titizlikle değerlendiriyoruz. Değişiklikleri üretime göndermeden önce, çevrimdışı A/B değerlendirme raporları, aday sürümleri dört boyutun tamamında üretim temel değerlerimizle karşılaştırır: 

Örneğin, bu çevrimdışı fark analizleri, çeşitli model yükseltmelerinin ve ajan yönlendirme kararlarının bireysel kalite sinyallerini nasıl etkilediğini belirlememize olanak tanır:

• Temel model performansı: Temel modelimizi yükseltmek, her sinyalde tutarlı kazançlar sağladı; bu da ilk denemede daha az hatalı derleme, üstün görsel kalite ve daha derin oyun içeriği ile sonuçlandı.
• Ajan yönlendirme mimarisi: Buna karşılık, çift ajan kurulumunda belirli alt görevleri hafif bir modele devretmek, içeriğin derinliğini ve çeşitliliğini korudu, ancak oynanabilirlik ve görsel kalitede keskin gerilemelere neden oldu.

1. Oluşturma paradigmaları genelinde kalite referans noktalarının izlenmesi: Ayrıca, en uygun değerlendirme seti ile farklı zamanlarda mevcut yapı kalitesini anlamak için bu çerçeveyi kullanıyoruz. Bu setler, giderek daha geniş ve karmaşık hale gelen oluşturma görevlerinin anlık görüntülerini sunar.
   En eski set, nispeten basit mekanizmalara sahip tamamen 2D oyunlardan oluşur. Oyun mantığını oluşturmak kolaydı, bu nedenle oyun testi puanı genellikle daha yüksekti; öte yandan, tam da aynı nedenden dolayı içerik puanı düşük kaldı.
   Odak noktamızı 3D oyunlara kaydırdıkça, puan dağılımı doğal olarak değişir: Hatasız oyun daha zor hale gelir ve bu da oyun testi puanlarını düşürür. Görsel puanlar, varlıkların yeterince işlenmemiş olması nedeniyle sabit kalır ve oyunlara bir prototip havası verir. 3D oyunlar daha derin olma potansiyeline sahip olduğundan içerik puanları daha yüksektir; ancak tek turlu komutlar içerik genişletme için sınırlı bir alan sunduğundan genel puanlar düşük kalma eğilimindedir.

1. Türlere özgü darboğazların ortaya çıkarılması: Değerlendirme verileri, türler arasında önemli performans farklılıklarını da vurgulamaktadır. Oyun mekanizmasının ağırlıklı olduğu türler (ör. RPG'ler, nişancılık oyunları, yarış oyunları) daha fazla oynanabilirlik sorunuyla karşılaşma eğilimindedir. Nispeten basit mantığa sahip türler (örn. hayatta kalma ve tycoon oyunları) genellikle oyun testlerinde daha iyi performans gösterir; bu da görsel cilalama ve kullanıcı arayüzü tasarımını çözülmesi gereken bir sonraki aşama haline getirir. Türler arasındaki farkı bilmek, Build oyunları genelinde daha dengeli bir örnekleme ile değerlendirme setimizi genişletmemiz için bize motivasyon sağlar.
2. Değerlendirme donanım tasarımı konusunda öğrenilen dersler: Çerçevenin kendisi üzerinde yapılan yinelemeler, donanım güvenilirliği konusunda bize önemli dersler verdi:

• Sistem metrikleri ve bileşen metrikleri: Temiz kod yapısı veya API kullanımı, oyunun oynanabilirliğini garanti etmez. Düzeltilebilir hataların gizlenmesini önlemek için doğruluk, tasarım ve sunumu birbirinden ayrı tutarız.
• Değerlendirme sisteminin zayıf yönleri ve insan tarafından yapılan kalibrasyon: Statik kontroller, oyunun çökmesine neden olan çalışma zamanı engellerini gözden kaçırabilirken, otomatik oyun testleri karmaşık fizik hesaplamalarıyla başa çıkmakta zorlanır. Sanal hakemler, profesyonel oyun geliştiricileri ve deneyimli topluluk yorumcuları ile karşılaştırılarak sürekli olarak kalibre edilir.
• Çok turlu ve gerçek trafiğe genişletme: Gerçek içerik oluşturucular sürekli olarak yineleme yaptıkları için (sistemler ekleyerek, zorluk seviyesini ayarlayarak, hataları düzelterek), çok turlu düzenlemeleri ve gerçek dünyadaki komut dağıtımlarını değerlendirmek üzere değerlendirme sistemimizi genişletiyoruz.

Sırada Ne Var

Şu anda Build içerik oluşturma değerlendirme sistemimizi beş yönde genişletmeye odaklanıyoruz:

1. Türler, 2D/2,5D/3D deneyimleri, çok oyunculu senaryolar ve karmaşıklık seviyeleri genelinde daha geniş kapsam
2. Çok turlu düzenlemeler için daha güçlü destek
3. Daha güvenilir oyun testi, ekran görüntüsü, video ve ses kanıtları
4. Büyük ölçekte insan değerlendirmeleriyle ve içerik oluşturucuların belirlediği referans vakalarla kalibrasyon
5. Çevrimdışı değerlendirme, çevrimiçi ürün sinyalleri ve regresyon testleri arasında daha iyi entegrasyon

Uzun vadeli hedefimiz, yaratıcıların önem verdiği düzeyde, yani yaratıcıların oluşturabileceği, test edebileceği, paylaşabileceği ve geliştirmeye devam edebileceği deneyimlerin kalitesini ölçen, şeffaf ve sürekli gelişen bir değerlendirme sistemidir. Bugün, bu sinyaller Build tarafından oluşturulan oyunları değerlendirmek için kullanılmaktadır. Zamanla, bunları insan yargısına göre daha da iyileştirip kalibre ettikçe, diğer içerik oluşturma iş akışlarına da genelleştirilebilir ve daha geniş Roblox ekosisteminde oyun kalitesini anlamak için ortak bir dil sağlanmasına yardımcı olabilir.

Roblox Assistant için ajansal sistemlerin değerlendirilmesine ilişkin daha fazla bilgi için “Roblox Studio için Ajansal AI Asistanlarını Karşılaştırmalı Değerlendirmede OpenGameEval’ın Kullanımı” başlıklı makaleye bakabilirsiniz.