Prolog ile Oyun Programlama

 (thingspool.net)
1 puan yazan GN⁺ 2024-10-12 | 1 yorum | WhatsApp'ta paylaş
  • Bir oyunun temel mekaniklerini fonksiyonlar, sınıflar ve durum değişkenleri yerine mantıksal ilişkiler ve yüklemler ile tasarlamaya yönelik bir yaklaşımı ele alıyor
  • Prolog’un LISP’ten daha yabancı gelmesinin nedeni sözdiziminden çok, veri yapılarını ve algoritmaları matematiksel ilişkiler merkezli ele alması
  • İlişkisel veritabanındaki satırları, dijital devrelerin giriş/çıkışlarını ve oyun nesnelerini n-li ilişkiler olarak görünce Prolog’un bildirime dayalı modeli ile veri odaklı tasarım bağlantı kuruyor
  • Grafik, ses, fizik ve basit I/O’ya kadar her şeyi Prolog ile uygulamak zor olsa da oynanış mekanikleri için uygulanabilirliği var
    1. bölüm, world ve actor temelinde etiketler ile actor’lar arasındaki ilişkileri Prolog yüklemleriyle ifade ediyor; zaman içindeki değişim ve oyun döngüsü ise sonraki bölüme bırakılıyor

Prolog’u oyun mekaniklerine uygulamaya dair problem bilinci

  • LISP ve Prolog, C# ve Java gibi yaygın nesne yönelimli dillerden farklı programlama paradigmalarına aittir
  • LISP, fonksiyonel programlama ve meta-dilsel örüntülerde güçlüdür; Prolog ise mantıksal programlamanın temsilcisi bir dil olarak ele alınır
  • LISP’e, C#’taki lambda ifadeleri ve higher-order function gibi kavramlar ile elektrik mühendisliği ve sinyal işleme geçmişi sayesinde beklenenden daha kolay yaklaşılabildi
  • Buna karşılık Prolog’un sözdizimi basit görünse de veri yapılarını ve algoritmaları matematiksel ilişkiler olarak ele alma biçimi büyük bir zorluktu
  • Prolog’un yaklaşımı çeşitli mühendislik modelleriyle temas eder
    • İlişkisel veritabanındaki her satır, Prolog sözdiziminde n-li yüklem olarak görülebilir
    • Dijital devre bileşenlerinin giriş/çıkış davranışı, giriş ve çıkış portlarını birleştiren n-li bir ilişki olarak uygulanabilir
    • Donanım parçaları veya bellekteki saf veri gibi nesneler de mantıksal programlamada ilişkilerle tanımlanabilir
  • Fonksiyonel programlamada nesnelere fonksiyon gibi bakılabildiği gibi, mantıksal programlamada da nesnelere ilişki olarak bakılabilir

Oyunun temel mekanikleri ve bildirime dayalı tasarım

  • Mantıksal programlama, video oyunlarının temel oynanış mekanikleri gibi karmaşık sistemleri tasarlamak ve uygulamak için kullanılabilir
  • Tüm oyunu Prolog ile uygulamak, deneysel bir amaç yoksa sıradan bir oyun geliştiricisi için büyük bir meydan okumadır
  • Oyunun tüm bileşenleri Prolog’a iyi uymaz
    • Basit I/O modülleri
    • Grafik modülleri
    • Ses modülleri
    • Fizik modülleri
  • Uygulama alanı, oyunun tamamından çok temel mekaniklere daha yakındır
  • Oynanış sistemini bildirime dayalı cümleler kümesi olarak kurmak, emirsel sistemlere göre daha sağlam ve modüler olabilir; race condition gibi kafa karıştırıcı edge case’lerden de daha özgür olabilir
  • Bu metodolojide sistem yalnızca mantıksal ilişkiler ve yüklemlerle tasarlanmalıdır
    • Fonksiyon yok
    • struct yok
    • class yok
    • interface yok
    • durum değişkeni yok

World ve Actor modeli

  • Prolog tabanlı oyun programlamanın özü, elektrik devrelerindeki direnç, transistör, kondansatör ve indüktör gibi ilişkileri en ilkel yapı taşı olarak kullanmaktır
  • Oyun genel olarak world ve actor olarak ikiye ayrılır
    • world, her şeyin gerçekleştiği sahnedir
    • actor, world’e ait bir nesnedir
  • actor, player, enemy, obstacle, item gibi adı ve özellikleri olan tekil entity’leri ifade eder
  • actor’lar birbirleriyle veya kendileriyle etkileşime girebilir ve bu süreçte çeşitli event’ler ortaya çıkar
  • Oynanış, bu event’lerin zinciri olarak görülebilir
  • Bu modelde world birden çok actor içerir; her actor’ın kendi durumu ve davranışı vardır

Etiketleri tekli yüklem olarak ifade etmek

  • Her actor benzersiz bir adla tanımlanır
    • Örnekte actor1 ve actor2, birinci ve ikinci actor’ı temsil eder
  • Etiket, actor’a eklenen bir anahtar sözcüktür ve actor’ın ne olduğunu gösterir
  • bread(actor1). ve bread(actor2)., actor1 ve actor2nin ikisinin de ekmek olduğu anlamına gelir
bread(actor1).
bread(actor2).
  • Prolog’da bread tekli bir ilişkidir; bread(actor1) ve bread(actor2) ise bu ilişkinin tekil örnekleridir
  • Bir actor birden fazla etikete sahip olabilir
  • Tüm ekmeklerin flammable ve decomposable olması gerekiyorsa her actor’a etiketi elle ekleme yöntemi zahmetli ve hataya açıktır
  • Horn clause kullanıldığında bread(X) doğruysa flammable(X) ve decomposable(X) otomatik olarak geçerli olur
flammable(X) :- bread(X).
decomposable(X) :- bread(X).
  • Bu Horn clause’lar oyunun konfigürasyon verisi gibi davranır
    • Teknik tasarım dokümanlarında veya elektronik tablolarda yer alan character type, skill type, mission type özellik tanımlarına benzer
    • bread adlı type-specifier’ın flammable ve decomposable özelliklerini içerdiği bir yapıdır
  • Unity benzetmesiyle, Bread prefab’ına Flammable ve Decomposable component’lerini eklemeye benzer
  • Nesne yönelimli ortamda Bread sınıfının IFlammable ve IDecomposable interface’lerini implemente etmesine benzer
  • Prolog’un Horn clause’u bu bağlamda veri tipi tanımı rolü görür

Tekil actor’lara eklenen özel etiketler

  • Önceden tanımlı etiketlerden ayrı olarak yalnızca belirli bir actor’a özel etiket eklenebilir
  • Örnekte bir büyücü ikinci ekmek olan actor2ye büyü yaptığı için enchanted etiketi gerekir
enchanted(actor2).
  • flammable ve decomposable, tüm ekmeklere ait özelliklerdir
  • enchanted, yalnızca büyülenmiş özel ekmeğe eklenen bir özelliktir

Actor’lar arası ilişkileri ikili yüklem olarak ifade etmek

  • Oynanış sistemi, tekil actor’ların özelliklerinin yanı sıra actor’lar arasındaki ilişkileri de ifade etmelidir
  • İlişki örnekleri şöyledir
    • Ekosistemde predator, prey’i kovalar; prey ise predator’dan kaçar
    • dating simulator’da erkek kadına flirt etmeye çalışır, kadın ise reddeder
    • The Sims gibi social simulator’larda insanlar birbirlerinin arkadaşı, düşmanı ya da ikisinin arasında bir şeydir
    • Satrançta bishop, rook’u çaprazdan alır; rook ise bishop’ı dikey/yatay yönde alır
  • Prolog’da tekli yüklem bir actor’ın özelliğini gösterdiği gibi ikili yüklem de iki actor arasındaki ilişkiyi gösterebilir
  • Horn clause kullanılarak gerekli koşullar kümesinden ilişkiler dinamik olarak çıkarımlanabilir

canEat ve canSpoil örnekleri

  • actor3 bir insansa ve insanlar ekmek yiyebiliyorsa, “X human ve Y bread ise X, Y’yi yiyebilir” ilişkisi tanımlanabilir
human(actor3).
canEat(X, Y) :- human(X), bread(Y).
  • Burada canEat(X, Y), X ile Y arasında geçerli olan bir ilişkidir
  • actor4 fungus ise ve ekmek decomposable ise fungus, decomposable bir actor’ı spoil edebilir
fungus(actor4).
canSpoil(X, Y) :- fungus(X), decomposable(Y).
  • canSpoil(X, Y), “X fungus ve Y decomposable ise X, Y’yi spoil edebilir” ilişkisidir
  • decomposable(Y), daha önce bread(Y)den Horn clause ile çıkarımlanabilir

Hâlâ kalan sorun: zaman içindeki değişim ve oyun döngüsü

  • Buraya kadarki örnekler actor’ların özelliklerini ve ilişkilerini ifade etse de hepsi statiktir
  • Oyun, sabit bir manzara değil; zaman geçtikçe actor’ların hareket edip etkileşime girmesi gereken bir şeydir
  • Prolog’un bildirime dayalı doğası tek başına, zaman geçtikçe özelliklerin değişmesi sorununu kolayca çözebilecek gibi görünmez
  • Oyun döngüsünün Prolog’da nasıl kavramsallaştırılacağı Part 2 içinde devam ediyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-12
Hacker News yorumları

  • Genelde yalnızca Part 1’i olup orada kalan yazılara düşük gözle bakarım, ama bu yazının gerçekten devam bölümleri gelmeye devam etmiş
    https://thingspool.net/morsels/page-11.html (part 2)
    https://thingspool.net/morsels/page-12.html (part 3)
    https://thingspool.net/morsels/page-13.html (part 4)
    https://thingspool.net/morsels/page-14.html (part 5)
    Ve devam ediyor

    • Part 13’e kadar süreceği belirtilmiş. Hepsini okumak zaman alacak ama gerçekten hoşuma gitti; Rust ile yazılmış Scryer Prolog olan https://github.com/mthom/scryer-prolog’u takip etmeyi düşünüyorum
      Bu teknikleri Rust ile oyun programlamaya taşıyabilecek gibi görünüyorum
    • Bağlantıyı içindekiler sayfasıyla değiştirmek daha iyi olabilir: https://thingspool.net/morsels/list.html
    • Aslında yazarın web sitesini öne çıkarmak ve yazmaya devam etmesini sağlamak istiyorsak tam tersini yapmak gerekebilir

  • Breath of the Wild’ın oyun tasarımında kimya motoru denen bir kavram var. Genelde oyun motorlarında nesnelerin hareket açısından nasıl etkileştiğini hesaplayan bir fizik motoru bulunur; kimya motoru ise malzemelerin simyasal anlamda nasıl etkileştiğini ele alır.
    Kural tabanlı bir motor gibi farklı maddelerin etkileşimlerini hesaplayarak, okun ahşap malzemeden yapıldığı için ateş alabilmesi gibi şaşırtıcı etkileşimler ortaya çıkar.
    YouTube bağlantısı: https://www.youtube.com/watch?v=QyMsF31NdNc&t=2354s
    Oyunların kural tabanlı öğeleri genellikle nispeten basit olur ve genel amaçlı olmaları gerekmez; bu yüzden elle kodlanıyor gibi görünüyor. Baba is You’nun geliştiricisine bir Datalog motoru uygulayıp uygulamadığını sorduğumda da hayır demişti; Breath of the Wild’ın da benzer olduğunu sanıyorum.
    Yine de böyle bir kimya motorunun, hızlı denemeler için Prolog veya Datalog gibi mantıksal dillerle uygulanmasının en iyi yol olup olmadığını sık sık düşünüyorum. SQL de sorgu esnekliğini korumak için kullanılmaya başlanıp sonunda olduğu gibi dağıtılır hale geldi; geçmişte SQL sorgularının yavaş olduğundan çok şikâyet edilmiş olsa gerek, ama bu esneklik yeterince faydalı olduğu için onu hızlandırmaya sayısız saat harcandı. Günümüzde neredeyse kimse “bu sorgudan daha hızlı imperatif kodu kendim yazabilirim” diye düşünmüyor.

    • Noita, piksel düzeyinde kimya motoru kavramı etrafında kurulu bir oyun ve C++ ile yazılmış kendi kural motorunu kullanıyor.
      Şimdiye kadar oynadığım oyunlar arasında oldukça ilginç olanlardan biri.
      https://store.steampowered.com/app/881100/Noita/
      https://www.youtube.com/watch?v=prXuyMCgbTc
    • O nesne sistemi aslında ZMachine’in tasarımıyla aynı. Nesneler özelliklere sahip olabiliyor ve nesne yönelimli programlamadaki nesneler ve metotlar gibi davranıyor.
      MUD’lar da muhtemelen benzerdir.
      Grafik oyunların yenilikçi biçimde yapmaya çalıştığı şeyler, 40 yıl önce metin oyunlarında, özellikle de etkileşimli kurmacada zaten yapılmıştı. Bu, Infocom’un ilk işlerinden ziyade 90’lardaki Curses, Jigsaw, Anchorhead, Devours, Spider and Web gibi müthiş amatör oyunların rönesansında daha belirgindi; NetHack/Slash'EM gibi roguelike’larda, CDDA: Bright Nights’ta ve yalnızca fantezi değil, siberpunk ya da bilimkurgu ortamlarında tuhaf malzemeler ve etkileşimler ele alan çevrimiçi MUD’larda da öyleydi.
      Warren Spector gibi en iyi oyun yapımcıları da özgür yazılım oyunları, bağımsız oyunlar ve acayip oyunlar oynayıp buralardan yeni oynanış fikirleri almış olmalı.
      Orijinal Deus Ex’teki NetHack göndermesinin basit bir easter egg değil, muhtemelen NetHack’ten esinlenen beliren oynanışa bir saygı duruşu olduğunu düşünüyorum.
      Deus Ex’in güçlü yanı grafikleri ya da dünya kurgusu değil, oyun içinde neler yapabildiğinizdi; FPS’in doğrusal yapısını kırarken bunu System Shock 1 ve 2’den daha erişilebilir hale getirmiş olmasıydı. System Shock tarafında zorluk ayarı ve oynanışın son hâline getirilmesi konusunda başarısız olunan yönler vardı. Arx Fatalis (şimdiki Libertatis) ve Ultima Underworld de benzer.
    • Aklıma Dwarf Fortress geliyor. Gümüş çekiç, gümüş daha ağır olduğu için daha fazla hasar verir; ahşap mobilyalar yanar. Yağmur ya da kan yüzünden giysilere sıvı bulaşır ve bunu içmek de mümkündür.
      Basit kurallardan gerçekten ilginç pek çok karmaşıklık doğuyor.
    • Orijinal metni henüz okumadığım varsayımıyla, birkaç yıldır oyun motorlarında ilişkisel programlama kullanma fikrine kapılmış durumdaydım. Sonunda tüm oyunu genel amaçlı bir ilişkisel dille yapmak yerine motoru C++ ile yazmanın ve ilişkisel olarak ele almak istediğim bazı yönler için özel çözücüler kullanmanın daha iyi olduğu sonucuna vardım.
      Genel amaçlı mantıksal/ilişkisel dillerin uyguladığı çözüm algoritmaları tek seçenek değil; ayrıca bir dil ne kadar genel amaçlıysa, oyun motorunun verimli biçimde çözmesi gereken problemler için o kadar verimsiz olabilir. Tersine, mantıksal dili bu tür özelliklerle yerel olarak genişletirseniz, basitleştirici varsayımları bozmanız ya da değerlendirme sırasını değiştirmeniz gerekir; bu da dili basit ve verimli biçimde uygulamayı zorlaştırabilir.
      Örneğin mantıksal ilişkileri doğrusal kısıtlarla birlikte kullanmak istiyordum. A <= (B-10.0) .OR. B <= (A-10.0) gibi bir ifadeyle, genişliği 10.0 olan iki oyun nesnesinin merkez konumlarını, sınırları çakışmayacak şekilde kısıtlayıp hangisinin önde olduğuyla ilgilenmemek gibi. Bu tür ifadelerle sahneleri ya da karmaşık oyun nesnelerini niteliksel olarak kurabilir, kesin koordinatları ise doğrusal kısıt çözücüsünün seçmesini sağlayabilirsiniz.
      Sorun şu ki f(A) <= g(B) gibi bir doğrusal kısıtı çözmek, ilgili tüm değişkenleri etkileyebilir. A veya B’nin C, D, E, F ile de kısıtları olabileceğinden, prop(X) .OR. prop(Y) mantıksal ifadesinin sol ya da sağ tarafını seçer seçmez çalıştırmak, önceden kesinleştirilmiş başka önermeleri geçersiz kılabilir.
      Bu yüzden doğrusal değişkenlerdeki <= işaretini boolean sonuç üreten bir test olarak yorumlamak yerine, genel doğrusal kısıt deposuna f(A) <= g(B) ekleyen bir komut olarak yorumlayıp daha sonra tüm doğrusal değişken matrisi üzerinde çözücüyü çalıştırmak daha iyi olur.
      O zaman dilin kısıt eklemenin ne zaman bittiğini ve çözme zamanının geldiğini nasıl bileceği, gerçekten değeri test etmesi gereken ve kısıt koymaması gereken mantık cümleleriyle ne yapılacağı gibi tasarım soruları ortaya çıkar. Ama esas nokta şu: oyun motoru bağlamında hem doğrusal kısıt çözmede hem de mantıksal programlamada, uzun hesaplamaların ne zaman çalıştırılacağı ve ne kadar süre çalıştırılacağı üzerinde daha fazla denetime ihtiyaç var.
      Yani mantık dili açısından genişletme özelliğini iyi çalışacak şekilde tasarlasanız bile, dış sistem açısından mantıksal programın bir bölümünü çözmeye yönelik arama süresi aniden patlayabilir ve programcının bunun nerede, ne zaman olacağını her zaman öngörmesi zor kalır. Bu anlamda elle yazılmış imperatif kodun daha hızlı olması bile gerekmez; yavaş olsa da öngörülebilir olması yeterlidir.
      Aslında her şeyi mutlaka baştan elle yazmak da gerekmiyor. Asıl mesele, kural motorunun imperatif oyun kodunun dışarıdan çalıştırıp kesebildiği bir çözücü mü olduğu, yoksa tüm oyunun çözücünün, yani ilişkisel dilin içinde mi çalıştığıdır. Tüm oyun ilişkisel olsaydı neler yapılabileceğini hayal etmek çekici; ama bu teknolojiyi oyunun tamamına uygulamak için gerçekte var olmayan, sihirli gibi bir ilişkisel çözücüye ihtiyaç var.

  • Prolog ile oyun programlamaya giriş niteliğinde olmasına rağmen doğrudan aksiyon oyunlarına geçmesi ilginç. Gerçek zaman, zaman çizelgesi, 3D, ECS ve olay boyutlarını ele alıyor.
    Genelde Prolog ile oyun geliştirmeye giriş kitapları macera oyunlarından, özellikle de klasik metin tabanlı maceralardan başlar. Çünkü labirentler ve envanter bulmacaları Prolog’un olguları ve kurallarıyla, DSL’lerle doğrudan örtüşür.
    Kart oyunlarında ya da masa oyunlarında da kuralları Prolog ile çok rahat ifade edebilirsiniz; robotik, lojistik, finans ve sanayi gibi alanlarda kullanılan Prolog planlayıcılarına benzer şekilde, temel kombinatoryal genel amaçlı oyun rakiplerini de neredeyse kolayca genişletebilirsiniz.

  • Yapay zeka dersi aldığımda ilk öğrendiğimiz şey Prolog’du ve ödev olarak hepimiz adventure/colossal cave tarzı bir oyun yazmak zorundaydık. Prolog bu işe iyi uyuyordu ve derste ortaya çıkan basit oyunların çeşitliliği şaşırtıcıydı.
    Diğer öğrencilerin yaptığı oyunların hepsini bir araya getirmiş olmayı isterdim. Birkaç hafta işledikten sonra CLIPS ve Lisp gibi başka konulara geçmiştik.
    Kendi ödevimde Bureaucratic Maze [1]’i yapmıştım; bu da Prolog’da oldukça sezgiseldi.
    [1]. http://logicmazes.com/bureau/index.htm

    • Common Lisp’te Land of Lisp kitabında başlangıç alıştırması olarak gerçekten böyle bir oyun yazılıyor.
      Ancak Inform6’da, oyun tasarımına uygulanan nesne yönelimlilik ve ZMachine gibi oyun içi nesnelerin ilişkilerini doğrudan ele alan yaklaşım sayesinde zorluk ciddi biçimde düşüyor, neredeyse sıradanlaşıyor.
    • https://amzi.com/AdventureInProlog/ da Prolog’u aynı yöntemle öğretiyor.
    • macOS’un güncel Chrome/Firefox sürümlerinde, üst sayfadan bağlantı verilen bulmacalar terminalde JavaScript hatası veriyor. Gerçekten çalıştığını görmek güzel olurdu.
      http://logicmazes.com/alice.html
      alice.html:353 Uncaught TypeError: Cannot read properties of undefined (reading 'play')
      at playSound (alice.html:353:30)
      at finalize2 (alice.html:347:1)
      at :1:1

  • 12 yazıya göz attım; Prolog kullanımına giriş olarak iyi görünüyor ama bunun oyun programlama ile ilgili olduğunu söylemek için şimdilik biraz erken gibi.
    İleride gelişebilir ama 12. derse kadar içerik çoğunlukla Prolog’da bazı nesne yönelimli kavramları modellemeye çalışmakla ilgiliydi.
    Bir şeyi kaçırıp kaçırmadığımı bilmiyorum ama oyunun önkoşulu gibi görünen kullanıcı etkileşimi henüz ele alınmamıştı. Mesaj göndermeye kısaca değinilen bir bölüm vardı; belki de kastedilen oydu.

  • Benzer bağlamda, Prolog yerine CLIPS kullanan mantıksal programlama odaklı bir oyun programlama kitabını keyifle okumuştum.
    Adventures in Rule-Based Programming: A CLIPS Tutorial https://a.co/d/7wVOcZp

    • Ben de o kitaptan bahsedecektim. İş yerinde bir sistemde CLIPS ya da benzeri bir şey kullanma olasılığını araştırırken ücretsiz belgeleri gözden geçirip satın almıştım; okuması keyifli bir kitaptı.
      https://www.clipsrules.net/
    • https://ryjo.codes/ üzerinde CLIPS ile ilgili pek çok iyi kaynak var.
    • İlginç görünüyor. Kindle sürümünün iyi olup olmadığını merak ediyorum.
      Programlama kitapları Kindle’da çoğu zaman berbat oluyor ama Fire tabletle bakınca idare edebilir.

  • Oyun durumunu olgular ve ilişkiler kümesi olarak görme bakışı (Prolog) ile ECS’nin özündeki “bu bir veritabanıdır”[1] fikri arasında ilginç bir örtüşme var.
    Kişisel olarak Datascript’i oyun durumu veritabanı olarak deniyorum ama başarılı olup olmayacağını söylemek için henüz erken. Bu öğreticideki fikirlerin bu bakış açısıyla bire bir eşleştiğini görmek güzel.

    1. https://www.gamedevs.org/uploads/data-driven-game-object-sys...
    • İlginç nokta, mantıksal programlamadaki kurallar ile oyun kurallarının örtüşmesi. Stanford’un mantıksal programlama tabanlı Game Description Language [1] çalışmasından ilham alarak dün Datascript ile tik tak toe uyguladım: https://github.com/kasbah/datascript-games/blob/e06a37025bf9...
      Yazdıklarımdan daha kısa bir kural tanımı yapmanın mümkün olup olmadığından hâlâ emin değilim. Stanford makalesinde kurallar (<= (column ?n ?x) ...) gibi yazılabiliyor; Datascript’te ise veriyi taşımaya yönelik çevresel işler çok daha fazla oluyor.
      Bunun Datascript/Datomic Datalog’un bir sınırından mı kaynaklandığını, yoksa benim anlayışımın eksikliğinden mi olduğunu bilmiyorum.
      Deneyine nasıl yaklaştığını merak ediyorum. Paylaşabileceğin bir çalışma ya da şu an benim izlediğim yöntem hakkında bir önerin varsa çok ilgimi çeker.
      [1]: https://www.cs.uic.edu/~hinrichs/papers/love2006general.pdf
    • Henüz görmediysen, bir sonraki kareyi türetmek için DataScript kurallarını zincirleyen şu yaklaşım ilgini çekebilir: https://frankiesardo.github.io/minikusari/#!/minikusari.tuto...

  • Çok mantık içeren oyunlarda, örneğin şehir simülasyonlarında durum makinesi sorununu ele alma biçimi olarak ferahlatıcı. Prolog’u bu şekilde kullanmayı hiç düşünmemiştim.

  • Nedensellik ve görelilik tartışmalarında gerçekten harika şeyler yapılabilecek gibi görünüyor. Örneğin bir NPC ile rastgele bir karşılaşma üretirken, geçmişte oyuncunun başlattığı nedensel zinciri içeren o NPC’nin olay geçmişini oluşturmak mümkün
    Her şey bir ilişki olduğundan ve NPC’nin şu anda var olduğu gerçeğiyle birlikte gözlemlenen tüm dünya durumları ve eylem geçmişi bulunduğundan, önceden simülasyon yapmadan geriye doğru iz sürüp NPC’ye tamamen tutarlı bir geçmiş vermek mümkün

  • Yaygın actor-world/entity-trait modelinin Prolog’un ilişkisel yaklaşımıyla iyi örtüştüğünü hiç düşünmemiştim
    Ancak öngörülebilir ve verimli çalışma süresi de önemli. Prolog genelde bir sorguyu tatmin etmek için terimleri eşleştirerek kaba kuvvet araması yapma eğiliminde. Serinin tamamını henüz okumadım; bu sorunu ele alıp almadığını merak ediyorum

    • Kaba kuvvet araması, çözümü bulmanın yalnızca saf bir yöntemidir. SQL tablolarına indeks eklenebildiği gibi, Prolog yüklemlerine de indeks eklenerek performans artırılabilir
    • Acemi bir soru ama kaba kuvvet aramasının miktarı kullanılan çözücüye bağlı değil mi? Sonlu alan kısıtları gibi şeyleri kabaca biliyorum; Prolog’un kod tabanının farklı bölümlerinde farklı çözücüler kullanılmasına ne kadar imkân verdiğini merak ediyorum
      İlk tahminim, çözüme dair bilinen kısıtları bir tür “tip bildirimi” gibi yazmak şeklinde olacağı yönünde