Praxion ile oynayarak beceri öğrenen bir Minecraft ajanı geliştirmek

Rust ile oyun kontrolü, Python ile karar alma ve modelin yazdığı kuralları gerçek Minecraft dünyalarında sınayan bir kabul hattı

Fatih Serbest · 12 Kasım 2026

Şekil 1. Praxion’un erken oyun prototipinin gözlemci kaydından bir kare. Görüntü, ajan için bir model girdisi olarak kullanılmadı.

Bir Minecraft fırını yapmak için sekiz kırık taş ve erişilebilir bir çalışma masası gerekir. Tarif bu kadar kısa olsa da ajan için iş daha uzundur. Önce taş bulması, uygun kazmayı edinmesi, blokları kırması ve düşen eşyaları toplaması gerekir. Çalışma masası geride kaldıysa yeniden bir masa bulmalı ya da kurmalıdır. Bu işlerin herhangi biri başarısız olduğunda, bir sonraki adım dünyanın o anda hangi durumda olduğuna bağlıdır.

Praxion’un üçüncü otonom koşusunda fırın hedefi geldiğinde kütüphanede bu işi uçtan uca yapan bir beceri yoktu. Ajan, elindeki alt becerileri birleştiren bir kural dosyası üretti. Dosya dört deneme dünyasında kabul koşullarını sağladı. Ardından canlı gövde yeni komutu unknown_skill hatasıyla reddetti. Beceri dosyası diskteydi, çalışan süreç ise kütüphaneyi yalnızca açılışta okumuştu. Bir sonraki koşuda yeniden yükleme yolu devreye girdi ve aynı beceri başka bir dünyada fırın üretti.

Bu iki koşu, projedeki “öğrenme” sözcüğünün somut karşılığını veriyor. Model bir hedef için bir program taslağı çıkarıyor. Oyun motoruyla etkileşen ayrı bir katman onu çalıştırıyor, test düzeneği sonucunu ölçüyor ve kabul edilen program sonraki oturumlarda yeniden kullanılabiliyor. Kalıcı değişiklik, model ağırlıkları yerine beceri kütüphanesinde gerçekleşiyor.

Minecraft neden iyi bir sınama ortamı?

Minecraft’ta başlangıç koşulları tohuma bağlıdır. Bir dünyada doğduğun noktadan hem ağacı hem yüzey taşını görürsün. Başka bir dünyada ağaç bir yamaçtadır, taş toprağın altında kalır veya ulaşılabilir bir patika görüş alanının dışındadır. Üstelik zaman ilerler. Kaynak aramak açlık, gece ve düşman riskiyle aynı anda yürür. Tarif bilgisinin doğru olması, onu uygulayacak hareket dizisinin de doğru olacağını garanti etmez.

MineDojo, açık uçlu görevleri ve Minecraft bilgisini bir araştırma ortamında bir araya getirdi. Voyager ise otomatik hedef üretimini, çalıştırılabilir bir beceri kütüphanesini ve oyun geri bildirimiyle program düzeltmeyi aynı döngüde kullandı. Praxion, beceriyi kod olarak saklama fikrini dar bir kural diliyle uygular. Buradaki mühendislik sorusu, bu koda hangi gözlemlerin ve eylemlerin açılacağı ve tekrar kullanılabilmesi için hangi oyun kanıtının aranacağıdır. Projelerin ölçüm düzenekleri farklıdır. Bu yazıdaki deneyler Praxion’un kendi geliştirme kayıtlarından gelir. MineDojo (Fan ve ark., 2022) · Voyager (Wang ve ark., 2023)

İki süreç, iki zaman ölçeği

Rust tarafına gövde, Python tarafına beyin deniyor. Gövde oyun protokolünü takip eder, yerel durumunu günceller ve hareketi yönetir. Beyin bir hedef önerir, mevcut becerilerle eşleştirir veya yeni bir aday yazdırır. Minecraft normal hızda saniyede yaklaşık 20 oyun adımı işler. Bir hedef önerisi veya beceri yazımı ise ağ çağrısı ve model yanıtı bekler. İki süreç arasındaki sınır, bu beklemeyi hareket döngüsünün dışına çıkarır.

Şekil 2. Gövde canlı oyun oturumuyla konuşur. Beyin hedef ve beceri seçer. Adayın kabulü ayrı dünyalarda sınanır.

Gövde, Minecraft Java Edition’a grafik arayüzü açmadan bağlanan bir istemci olarak çalışır. Projede Minecraft sürümü, protokol numarası ve kullanılan Azalea kaynak kodu sürüm manifestinde sabitlenir. Azalea, Minecraft istemcileri ve botları için Rust bileşenleri sağlar. Paket biçimindeki bir değişiklik, gövdenin dünya modeline doğrudan yansıyabildiği için istemci, sunucu ve ayrıştırıcı sürümlerini birlikte izlemek önemlidir. Örneğin patlama paketinin ayrıştırılmasıyla ilgili bir uyumsuzluk, bir geliştirme koşusunda durum eşzamanını bozdu. Gövdenin böyle bir durumda yürütmeyi durdurması ve hatayı görünür kılması, yanlış durum üzerinden yeni hareketler üretmesini önler. Praxion kaynak deposu · Azalea

İki süreç yerel TCP bağlantısı üzerinden uzunluk önekli JSON mesajları paylaşır. Gövde anlık durum, olay ve eylem sonucu yollar. Beyin ise kimliği, parametreleri ve süre sınırı olan bir beceri isteği gönderir. Sıra numaraları olay akışını izlemeyi sağlar. Olay türleri filtrelendiği için sıra numaralarında boşluk olması olağandır. Kuyruk taştığında gövde düşen mesaj sayısını bildirir ve güncel bir durum görüntüsü gönderir. Python tarafında bağlantıyı okuyan iş parçacığı, model çağrısı sürerken de mesajları ve canlılık sinyalini işler.

Gövdenin hakemi, hangi davranışın o anda eylem üretebildiğini belirler. Bir refleks tehlikeye müdahale ederken sıradaki blok kırma kuralı yeni bir hareket başlatmaz. Operatör bir hedefi durdurduğunda da paneldeki tıklama ile oyundaki iptal iki ayrı olaydır. Python döngüsü çalışan komuta iptal isteği gönderir ve hedef kaydını gövdenin cancelled sonucundan sonra kapatır. Böylece panel, henüz gerçekleşmemiş bir durum değişikliğini olmuş gibi göstermez.

Sunucunun bildiği dünya ve ajanın gördüğü dünya

Minecraft istemcisi yakın çevrenin blok verisini alır. Bu veri, istemcinin çarpışmaları ve sahneyi hesaplayabilmesi için gereklidir. Aynı veriyi doğrudan hedef aramaya açarsan ajan toprağın arkasındaki blokları tarayabilir. Praxion’da hareket fiziği ile oyun kararları farklı veri erişim yolları kullanır. Fizik katmanı çarpışmayı hesaplayabilir. Beceri, olgu ve refleks katmanları dünya hakkında algı arayüzü üzerinden soru sorar.

Görüş sorguları göz konumundan blok veya varlığa ışın testi yapar ve oyun adımı başına bir bütçeye tabidir. Daha önce görülen bilgi, kaynağı ve yaşıyla taşınabilir. Ajanın kendi envanteri ve konumu ise doğrudan takip edilen durumdur. Ekrandaki oyuncunun o an baktığı yönü taklit etmek bu prototipin görüş modelinin bir şartı değildir. Bu nedenle kullanılan algı, yalnızca ekran pikselleriyle oynayan bir sistemin algısından farklıdır.

Kural dili için özellikle önemli bir ayrım, bilinmeyen ile yanlış arasındadır. Bir blok görüş dışındaysa, sorgu o bloğun orada bulunmadığını kanıtlamaz. Üç değerli mantıkta bilinmeyen bir önermenin değili de bilinmeyendir. Bir kural ancak koşulu doğru olduğunda seçilebilir. Böylece bir görüş sorgusu cevap üretemediğinde yorumlayıcı, bu sonucu kesin yokluk gibi kullanmak zorunda kalmaz. Örneğin near, bilinen bloklar arasında eşleşme yoksa yanlış dönebilir. Bu sonuç, haritada o bloğun hiç bulunmadığını göstermez. not near koşulu aramayı başlatabilir ve keşif becerisi ulaşılabilir konumlardan yeni alanları gözlemler.

Gövdenin kendi koyduğu bloklar da algı modeline bir soru ekledi. Örneğin yüksek bir kütüğe yetişmek için altına bir kütük koyan ajan, sonra bu bloğu yeni bir odun kaynağı olarak görebilir. Bunun önüne geçmek için doğrulanmış iskele blokları algı katmanında işaretlenir. Yakınlık sorgusu, kazma ve keşif aynı işarete bakar. Blok yerleştirme isteği gönderildiği anda kayıt açılmaz. Sunucu değişikliği doğruladığında açılır ve hücre daha sonra boş görülürse kaldırılır.

Bir becerinin içi

Beceri dosyası sıralı koşul ve eylem kuralları içerir. Bir eylem craft gibi gövdede kayıtlı bir ilkel işlem, do ile çağrılan bir alt beceri veya done gibi bir bitiş sonucu olabilir. Dosya, örneğin bir Minecraft paketinin nasıl yazılacağını ya da hangi açıyla yürüneceğini tarif etmez. Bu işlerin tanımı Rust gövdesindedir. Aşağıdaki kaynak, daha sonraki bir macOS denemesinde üretilen gerçek fırın adayından. Kuralları gösteren bu örnek, aşağıda anlatılan tarihsel başarı kaydından ayrı bir denemeye ait.

skill get_furnace()
  doc "Get at least one furnace."
  rules:
    count(furnace) >= 1 -> done
    count(cobblestone) >= 8 and near(crafting_table, 4) -> craft(furnace)
    count(cobblestone) < 8 -> do get_cobblestone(8)
    true -> do get_crafting_table_near()

Kurallar yukarıdan aşağıya değerlendirilir. Envanterde fırın varsa beceri hemen tamamlanır. Taş ve masa hazırsa üretim denenir. Taş eksikse görev bir alt beceriye bırakılır. Son satır, yeterli taş bulunduğunda masayı erişilebilir hâle getirir. Bir alt beceri tamamlandığında yorumlayıcı ilk koşuldan başlayarak yeni durumu yeniden değerlendirir. Böylece aynı dosya boş envanterle başlayan bir dünyada da, taş ve masanın hazır olduğu bir durumda da yürütülebilir.

Alt beceriler çağrı yığınında tutulur. Bir alt beceri başarısız olduğunda onu çağıran kural kısa süreliğine elenir. Bu, sıradaki uygun kuralın denenebilmesini sağlar. Örneğin kırık taş toplama becerisi, görünür taş bulmak için arama yapar. Arama sonuç vermezse bir sonraki kural merdiven biçiminde aşağı kazmayı deneyebilir. Süre ve tekrar sınırları, arama ile kazmanın ilerleme olmadan birbirini çağırıp durmasını sınırlar. Devam eden ayrık bir işlem de kendi sonucunu bekler. Blok kırma isteği gönderilmişken her oyun adımında yeni bir kazma hedefi seçilmez.

Bu yapı yeni becerinin ifade gücünü mevcut ilkel işlemlerle sınırlar. Fırın dosyası taş toplamayı tarif eden başka bir program çağırabilir. Gövde bir yamaçta ağaca erişemiyorsa veya taş arayışı yanlış yerde takılıyorsa, aynı çağrıyı yeniden sıralamak temel sorunu gidermeyebilir. Bu sınır, kabul hattında hata kaynağını ayırmanın da nedenidir.

Bir komutun sonucunu nasıl biliyoruz?

Bir eylemi göndermek ve eylemin sonucunu gözlemek farklı aşamalardır. Bir kazma denemesi, hedef blok havaya dönüştüğünde doğrulanabilir. Bir üretim isteği için beklenen kanıt, ilgili eşyanın envanterde görünmesidir. Hareket ve bakışta ise düzeltme gelmemesine dayanan daha zayıf bir sinyal kullanılabilir. Bu sinyallerin her biri, ilgili ilkel işlemin başarı sözleşmesine bağlıdır.

Get Fatih’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Gövde eylemlere sonuç kaydı, yani receipt, üretir. İsteğin başladığı oyun adımı ve eyleme özgü ilişkilendirme bilgisi, sonradan gelen değişikliğin doğru isteğe bağlanmasına yardımcı olur. Kanıt penceresi kapanırsa işlem doğrulanmamış olarak sonuçlanabilir. Geç gelen bir sinyal kayıt altına alınabilir, fakat kapanmış sonucu yeniden açmaz. Aynı hücreyi veya envanter yuvasını ilgilendiren ardışık işlemlerde bu ayrım önemlidir.

Beceri düzeyinde de ek bir kontrol var. Deneme dünyasının hakemi, sunucuya RCON üzerinden envanter sorgusu gönderir ve hedef eşyanın adedini sayar. Denemenin sonucu bu sayının hedefe ulaşıp ulaşmadığına göre belirlenir. Örneğin adayın done demesi ve hakemin fırın sayısını sıfır görmesi, goal_not_met olarak kaydedilir. Bu okuma test düzeneğinde kalır. Ajan canlı oyunda hedef ararken hakemin ayrıcalıklı okumasını kullanmaz.

Hedeften beceriye, beceriden kütüphaneye

Python döngüsü eldeki durumu kısa bir özete dönüştürür. Kullanıcının hedefi varsa sıradaki seçimde öncelik alır. Otonom akışta hedef önerisi envanter, yakın geçmiş ve ilerleme basamakları gibi bilgilerle sınırlandırılır. Bir hedef, mümkün olduğunda count(furnace) >= 1 gibi kodla kontrol edilebilen bir koşulla temsil edilir. Jev yönlendirmesi ve kod tarafındaki katalog denetimleri, mevcut bir becerinin kullanılabildiği durumları yazım gerektiren boşluklardan ayırır.

Bir boşluk bulunduğunda yazar modele mevcut beceriler, ilkel işlemler ve kural dili sözleşmesi verilir. Model bir beceri adı ve kaynak metni üretir. Statik kontrol dosyanın sözdizimini, tanıdığı çağrıları ve yürütme sınırlarını inceler. Örneğin katalogda bulunmayan bir ilkel işlem, gerçek bir test dünyası açılmadan elenebilir. Bu aşamadan geçen aday, gerçek başsız gövdeyle ayrı sunucu süreçlerinde, yaratıkların etkisini azaltan Peaceful zorluk ayarıyla denenir.

Varsayılan deneyde üç geliştirme tohumu ve ayrı bir kontrol tohumu vardır. Aşağıdaki kısa örnek, uygulamadaki kabul koşulunu gösteriyor. training_passes model eğitimi sayacı değildir. Geliştirme tohumlarında kabul edilen deneme sonuçlarını sayar.

training_passes = sum(1 for seed in passed_seeds if seed != held_out)
admission_ready = held_out_passed and training_passes >= required_passes

Hatanın türü bir sonraki adımı belirler. Adayın kendi kuralı bulunamadıysa veya hakem tamamlanma iddiasını çürüttüyse, kısa olay izi önceki kaynakla birlikte yazara dönebilir. Kırık bir ilkel işlem, ölüm veya gövde başlangıç hatası başka bir tür kanıttır. Kod bu durumlarda yedek tohum deneyebilir ya da inconclusive_body sonucunu verebilir. Bu sınıflandırma sezgisel kurallara dayanır. Örneğin son on kural seçiminin tamamının aday becerilere ait olması ve ilk seçimden koşu sonuna kadar hiçbir ilkel işlemin doğrulanmaması, zaman aşımının adaydan kaynaklandığına işaret edebilir.

Kabul tamamlandığında dosya etkin beceri dizinine alınır. Canlı gövde bu dizindeki değişiklikleri daha sonra alabilir. Yazım ve deneme hattı arka planda çalışabildiği için gövde bu sırada hayatta kalma davranışlarını ve uygun mevcut işleri sürdürebilir. Bütçe sınırı devreye girerse model çağrıları kapanabilir ve sabit ilerleme basamaklarıyla çalışmak mümkündür. Bu kip, hareket ve çekirdek becerileri model yanıtlarının değişkenliğinden bağımsız incelemeyi de kolaylaştırır.

Fırın deneyi ve dört rastgele dünya

Tarihli koşu notlarına göre ilk başarılı fırın kabulünde 101, 202 ve 303 numaralı geliştirme tohumları ile 404 numaralı kontrol tohumu geçti. Üçüncü otonom koşu yeni dosyayı üretti ve kabul etti, fakat çalışan gövde henüz onu yeniden okuyamıyordu. Dördüncü koşu 404 tohumu üzerinde odun, çalışma masası, tahta kazma, kırık taş, taş kazma ve taş kılıç adımlarından geçti. Ardından daha önce yazılmış fırın becerisini çağırdı ve kayıt, bu hedefin 313 oyun adımında tamamlandığını gösterdi. 404, bu otonom koşu için yeni bir dünya kurulumu olsa da kabul sırasında kullanılmış bir tohumdu. Sonraki macOS denemelerinden birinde üç geliştirme tohumu geçti, fakat 404 üzerinde needs_table gövde hatası kaydedildi ve rapor inconclusive_body sonucunu verdi. Yedek tohumdaki başarı, zorunlu kontrol tohumu sonucunun yerine sayılmadı.

Kabul deneyleri ile serbest Survival ilerleyişi farklı sorulara cevap verir. İlkinde belirli bir beceri, tanımlı başlangıç koşulları ve ölçülebilir bir hedefle sınanır. İkincisinde ajan, birbirine bağımlı hedefleri rastgele bir doğuş konumundan ve gerçek oyun riskleri altında tamamlamaya çalışır. 11 Kasım’da dört rastgele tohumda, her tohuma yaklaşık 240 saniye verilen ve model çağrıları kapalı tutulan ayrı bir Survival denemesi yapıldı. Ölçüt, örneklenen hakem envanteri veya tamamlanan hedefle kanıtlanan en yüksek basamaktı.

• Bir koşu taş kılıca kadar ilerledi. Koşu içinde bir ölüm kaydedildi.
• İki koşu tahta kazmada kaldı. Bunlardan birinde kırık taş toplama hedefi no_block ile iki kez başarısız oldu.
• Bir koşuda odun basamağına ulaşılamadı. İki odun hedefi unreachable ile sonuçlandı.

Her tohumda tek bir doğuş sınandı. Dört gözlem, genel bir başarı oranı hesaplamak veya tüm başlangıç konumlarına genelleme yapmak için yetersizdir. Yine de bulgu uygulamayı yönlendiriyor. Ajanın bir hedef için ayrı ayrı ölçülmeli. Özellikle not_found, no_block ve out_of_reach sonuçları, ilerlemeyi hangi arama ve erişim davranışlarının sınırladığını incelemek için başlangıç noktaları sundu.

Konsol bir deneyi nasıl okunur hâle getiriyor?

Şekil 3. Yerel konsolun test envanteriyle alınmış ekran görüntüsü. Ekrandaki elmaslar ve demir külçeleri, otonom ilerleme deneyinin sonucu değildir.

Yerel web konsolu, canlı Minecraft istemcisinin göstermediği bilgileri görünür kılar. Oyun görüntüsünden ajanın yürüdüğü anlaşılır. Konsoldan hangi hedefin etkin olduğu, hangi becerinin seçildiği, envanter bilgisinin yaşı ve neden bir sonraki hedefe geçildiği incelenebilir. Karar akışı model çağrılarının amacı, token kullanımı ve maliyetiyle ilişkilendirilebilir. Aday becerilerin kabul sonuçları da hangi aşamada takıldıklarını gösterir. Bu bilgiler, aynı anda birkaç sürecin günlüğünü açmadan bir koşuyu incelemeyi mümkün kılar.

Yönetilen konsolun güncel geliştirme sürümü, sunucu ve bot yaşam döngülerini ayrı kontrol eder. Sunucu hazır olduğunda gözlemci oyuna girebilir. Bot daha sonra aynı dünyaya bağlanabilir. Botu durdurma işlemi sunucuyu açık bırakacak şekilde tasarlanmıştır, böylece aynı dünyada yeni bir bot denemesi başlatılabilir. Envanter paneli Minecraft’ın depolama, hızlı erişim, zırh ve ikinci el yuvalarını yansıtır. Simgeler yerel Minecraft istemcisinin dosyalarından okunur. Grafik istemcisini ilk açılışta etkileyebilen bir takılma ayrıca geliştirme kaydında açık duruyor.

Prototipin ulaştığı nokta

Fırın örneği, hedef seçimi, eksik becerinin yazılması, ayrı dünyalarda doğrulama ve canlı oturumda kullanım zincirinin bir örnekte kapanabildiğini gösteriyor. Rastgele dünyalar ise zincirin tabanındaki keşif, erişim ve kaynak toplama davranışlarının hâlâ sonuca yön verdiğini gösterdi. Burada sonraki teknik ölçüm, aynı işi farklı tohumlarda ve farklı doğuş konumlarında tekrar gözlemlemekle ilgili.

Praxion’un uzun vadeli hedefi, Windows’ta gerçek Minecraft istemcisini kullanabilmek ve oyuncunun kontrolü anında geri alabilmesi. Bu yazıda anlatılan koşular başsız protokol gövdesine aittir. Tam oyuncu devralma akışı, araziye uyarlanan yapı inşası ve ileri Survival basamaklarının tekrarlanabilir biçimde doğrulanması ayrı geliştirme işleridir. Fırın, bu uzun vadeli hedefler geliştirilirken aynı kabul zincirini yeniden sınamak için küçük ve ölçülebilir bir örnek sunuyor.

Kaynaklar

• Fatih Serbest. Praxion kaynak deposu ve proje belgeleri. GitHub
• Azalea contributors. Azalea: Rust crates for making Minecraft bots, clients, and tools. GitHub
• Fan, L., ve ark. (2022). MineDojo: Building Open-Ended Embodied Agents with Internet-Scale Knowledge. arXiv:2206.08853
• Wang, G., ve ark. (2023). Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291
• Praxion geliştirme kayıtları. Fırın becerisi kabul raporu, otonom koşu 3–4 notları ve 11 Kasım 2026 tarihli dört tohumlu Survival deneyi. Yerel deney kayıtları.

Yazım notu. Makalenin hazırlanmasında yapay zekâ desteği kullanıldı. Teknik ayrıntılar proje kodu ve deney kayıtlarından kontrol edildi.