LLM olmadan oyun yapmak 3 ay, LLM ile 3 gün
(marianogappa.github.io)- 15 yıllık deneyime sahip bir yazılım mühendisi, çocukluğundan kalan bir kart oyununu Go diliyle geliştirme deneyimini paylaşıyor
- LLM (büyük dil modeli) olmadan “Truco” geliştirirken UI tasarımı ve sunucusuz dağıtım gibi tüm sorunları elle çözerek 3 ay harcadı
- “Escoba”yı yaparken LLM’den yararlanarak backend kod dönüşümü ve uygulama hızını büyük ölçüde kısalttı; tek bir promptla çoğu şeyin çalışması sağlandı
- Yazının ikinci yarısında Tic-Tac-Toe örneğiyle Go backend, WASM dönüşümü ve React entegrasyonu üzerinden herkesin oyun yapabilmesi için adım adım bir rehber sunuluyor
- Ancak React frontend’i ve WASM tabanlı oyun durumu yönetimi hâlâ doğrudan debug edilip elde uygulanmayı gerektiriyor
Giriş
- 15 yıllık deneyime sahip bir yazılım mühendisi, aslında hiç gerçekten bir oyun yapıp dağıtmadığını fark ediyor
- Çocukluğunda Arjantin’de arkadaşlarıyla oynadığı kart oyunlarından birini Go diliyle geliştirmeye karar veriyor
Truco: LLM olmadan 3 ay
- 18 Haziran 2024’te Truco adlı kart oyununu Go backend ile geliştirmeye başlıyor. React konusunda yalnızca asgari bilgiyle frontend’i yazıyor
- En büyük zorluk UI geliştirme oldu; sunucu barındırmamak için TinyGo kullanarak WASM (WebAssembly) olarak transpile edip statik dosyaları GitHub Pages üzerinde yayımladı
- LLM’in olmadığı bu süreçte, tüm ayrıntıları kendisi araştırıp deneme-yanılmayla ilerleyerek yaklaşık 3 ayda tamamladı
- Amaç reklam ya da gelir değil, yalnızca oyunu tamamlamaktı; çıkışının üzerinden 1 yıl geçmesine rağmen hâlâ düzenli olarak oynanıyor
- Truco oyna: https://marianogappa.github.io/truco-argentino
- Backend (Golang): https://github.com/marianogappa/truco
- Frontend (React): https://github.com/marianogappa/truco-argentino
Escoba: LLM ile 3 gün
- 1 yıl sonra, ailesini görmek için Arjantin’i ziyaret ederken yeğenine en popüler ikinci kart oyunu olan Escobayı öğretiyor
- Bu kez LLM (Claude) kullanarak Truco’nun backend’ini kopyalıyor, ardından promptta Escoba’nın kurallarını açıklayıp kodun refactor edilmesini istiyor
- İlk promptta neredeyse kusursuz bir uygulama ortaya çıkıyor; yalnızca küçük bug’lar ve birkaç ek özellik elle tamamlanıyor
- Frontend içinse birkaç gün boyunca doğrudan geliştirme ve debug gerekti. LLM’in sınırları, React becerisi ve oyun durumunun WASM içinde yönetildiği alışılmadık ortamın tümü birer zorluktu
- Escoba oyna: https://marianogappa.github.io/escoba-de-15
- Backend (Golang): https://github.com/marianogappa/escoba
- Frontend (React): https://github.com/marianogappa/escoba-de-15
Adım adım: Kendi oyununuzu nasıl yaparsınız
- Birinin doğrudan oyun geliştirmeyi deneyebilmesi için asgari düzeyde uygulamalı rehber ve örnek kod sunuluyor
- Başlangıç için fork edilebilecek bir Tic-Tac-Toe örnek deposu veriliyor
Backend geliştirme
- Sıra tabanlı bir backend’de işlevler net biçimde tasarlanabiliyor
- Sunucusuz yapıyı korumak için, ticari bir sunucu yoksa insanların birbirine karşı oynadığı bir yapıyı tercih etmemek daha gerçekçi bir seçim
Frontend geliştirme
- Frontend’de şu işler gerekiyor
- Backend’den yeni bir
GameStateoluşturmasını istemek - Durumu UI’da göstermek
- Geçerli hamlelerin seçilebileceği bir arayüz sağlamak
- Bir hamle uygulandığında backend’e komut göndermek
- Sıra bottaysa backend’den işlem yapmasını istemek
- Backend’den yeni bir
Backend’i WASM’e dönüştürme
- Go kodunu WASM olarak derlemek için
GOARCH=wasm GOOS=js go buildkullanılıyor - İkili dosya boyutu büyük olabileceğinden, boyutu azaltmak için TinyGo kullanılıyor
- Frontend’le bağlanacak fonksiyonları dışa aktarmak için Go tarafında ayrı bir entry point (ör.
main_wasm.go) yazılıp build sırasında dallanma yapılıyor - Programın hemen kapanmaması için main fonksiyonunda
select {}ile bloklama yapmak gerekiyor
Backend-frontend veri entegrasyonu
- Go’daki serbest biçimli
structyapıları, örneğinGameState, WASM içinde doğrudan serialize/deserialize edilemiyor - Bu nedenle tüm verilerin JSON formatında değiştokuş edilmesi gerekiyor
- TinyGo dokümantasyonuna başvurularak hem giriş hem çıkışta JSON serileştirme kullanılıyor
Frontend-backend arayüzü
- Frontend, backend fonksiyonlarını doğrudan çağırıyor
GameStateyalnızca WASM içinde yönetiliyor ve frontend bunu mutate edemiyor; her zaman doğruluğun tek kaynağı backend- WASM yeniden derlendikten sonra dosyanın değiştirilmesi gerekiyor; bunun için bir Makefile otomasyon örneği veriliyor
WASM çalışma ortamı
- Çalıştırmak için
wasm_exec.jsdosyasının head içine eklenmesi gerekiyor; ardından bu script kullanılarak instance oluşturulup çalıştırılıyor
Sonuç
- Oyun yapmak keyifli bir deneyimdi ve Go + WASM + React kombinasyonu herkesin deneyebileceği bir yaklaşım sunuyor
- LLM desteği üretkenliği ciddi biçimde artırsa da frontend yetkinliği ve debug deneyimi hâlâ büyük önem taşıyor
- Bu yapıyla herkes kendi oyununu geliştirmeyi deneyebilir; denemeye değer
4 yorum
React'te
document.getElementByIdkullanan bir kod üretildiyse, acaba hangi LLM kullanılmıştır....Neredeyse başlık oltalama amaçlı clickbait gibi hissettiriyor..
"Sıfırdan yaparsan 3 ay, benzer bir şeyi tekrar yaparsan 3 gün"
Sanırım asıl yazar, kendisinin normalde ne yaptığını bilmeyen biri.
Hacker News görüşleri
Bu gönderide sevdiğim şey, birçok geliştiricinin gözden kaçırdığı bir noktaya parmak basması. Oyun geliştirmede darboğaz çoğu zaman kod yazmanın kendisi olmadı. Tek başına çalışan biri de AI olmadan mekanikleri hızlıca yapabilir. Asıl zor kısım, yukarıdaki görünmez katmanlar; örneğin oyun döngüsü dengesi, zorluk ayarı, sırıtmayan asset üretimi, kullanıcının ilgisini 5 dakikadan uzun süre koruyacak polish seviyesi gibi şeyler. Steam'in LLM'lerden sonra neden harika oyunlarla dolup taşmadığının sebebi de bu. Teknoloji bir engeli azalttı ama daha büyük engeller yerinde duruyor. 2010'larda Unity yükselirken de durum aynıydı. Motorlar oyun geliştirmeyi demokratikleştirdi ama iyi oyunlarda patlama yaratmadı; sadece deneme sayısını artırdı. LLM'ler kod tarafında, görsel modeller de sanat tarafında aynı etkiyi yaratıyor ama hangi oyunun gerçekten eğlenceli olduğunu bu araçlar söyleyemiyor. Bana ilginç gelen soru şu: AI yalnızca uygulamayı değil, playtest sürecini de yaparsa ne olur? Yani binlerce kez döngü çalıştırıp hangi mekaniğin simüle oyuncuyu elde tuttuğunu söyleyecek noktaya gelirse, verimlilik hilesinin ötesine geçip bir tasarım partnerine dönüşebilir. Henüz o aşamada değiliz ama bu yazı bana o yöne giden erken bir veri noktası gibi geliyor
AI yalnızca uygulamayı değil playtest'i de yapıp binlerce döngü çalıştırarak oyuncuyu ne kadar daha içine çektiğini anlayabilirse nasıl bir gelecek olacağı merakına karşılık, AI'ın oyuncuyu nasıl simüle edebileceği ve neden gerçek insanların neye bağlanacağını doğru değerlendirebileceği konusunda şüphe duyuyorum
Unity'nin 2010'lardaki yükselişi örneğinde gerçekten çok iyi oyun sayısının az olduğu iddiasına itiraz etmek istiyorum. Aslında XBLA dönemiyle kıyaslayınca, bugün sahip olduğumuz muazzam oyun hacmi Unity, Godot, Gamemaker, Renpy, RPG Maker gibi araçlar olmadan mümkün olmazdı. Yani sadece nitelikte değil, nicelikte de açıkça sıçrama yaşandı
Benim için üretken AI'ın turnusol testi, 2D pixel art aksiyon oyunu için tam bir spritesheet üretebilmesi. Örneğin bir tankın ya da ana karakterin hareketlerini bile kusursuz çıkarabilmesi hedefim olurdu ama şimdiye kadar buna dair başarılı bir örnek görmedim
"AI oyununuzun gerçekten eğlenceli olup olmadığını size söyleyemez" tespiti bence asıl içgörü. AI, bir insanın oyunu gerçekten deneyimlediği düzeyde, ya da başka herhangi bir şeyi insan gibi deneyimleyemez. En fazla benzer oyunlara dair insan değerlendirme verilerine bakarak bir miktar tahmin üretebilir. Yani AI oyununuzdan keyif alamaz. Bu özün, AI çağında insanların rolünü tanımlayacağını düşünüyorum. AI belgeleri ya da kodu geçmiş veriye dayanarak bir ölçüde insan gibi üretebilir ama yalnızca gerçek insanların yapabildiği anlamlı sentez ve deneyimler vardır. İnsanlara özgü, ikame edilemez bir değer noktası var; sadece o değere nasıl baktığımızı farklı ele almalıyız
Bu desen oyun geliştirmenin dışındaki alanlar için de geçerli. Herkesin beklediği gibi agent tabanlı kodlamada da muazzam potansiyel var ama sadece bazı görevleri ezici şekilde hızlandırıyor; hızlı web uygulaması demoları, küçük kütüphane entegrasyonları gibi. Gerçek büyük ölçekli yazılımda ise hâlâ yetersiz. Modellerin eğitilme biçimi de, onları kullanma konusundaki birikimimiz de henüz yeterli değil. Bu şaşırtıcı değil. git de ortaya çıktıktan sonraki ilk 5 yıl ancak elit şirketlerde düzgün benimsendi, ardından yaygınlaşması için 5 yıl daha gerekti. Sonuçta artık ona çok alıştık ama bence LLM'leri gerçekten düzgün kullanmak git'ten bile zor. Eğer her ürün, OSS ve blog yazısında "artık bitti, her şey devrim geçirdi" türü abartılar biraz daha az olsaydı belki daha hızlı ilerlerdik. Hâlâ deneme-yanılma ve deney aşamasındayız, bu zaman alır. Çok hızlı hüküm vermemek gerek. Eğer gerçekten her şey çözülmüş olsaydı en azından çok daha iyi yazılımların içinde boğuluyor olmamız gerekirdi ama şu an ancak dengeyi kurmaya çalışıyoruz. Yine de yeni bir teknolojinin ortaya çıkışından 1-2 yıl sonra bu kadarı oldukça etkileyici
LLM'in 3 aylık bir avantajı vardı: kod, önceki oyunu şablon olarak kullanmak ve en önemlisi elde kod yazarken birikmiş tüm deneyim ve hatalar
Başta bunun sansasyonel bir başlık olacağını düşünmüştüm ama aslında "Truco backend'ini kopyalayıp Claude'a Escoba kurallarını uzun uzun anlattıktan sonra kodu refactor ettirdim" kısmı şaşırtıcıydı. Bir insan bunu doğrudan refactor etse ne kadar sürerdi diye merak ediyorum. 3 günden fazla da sürebilir, sürmeyebilir de
Bir başka nokta da şu oyunun katılımcının ilk oyunu olması. Yani ilk denemede çok sayıda bilinmezle uğraşmak zorundasınız ama aynı işe bir kez edindiğiniz içgörü ve bilgi birikimiyle yeniden başlarsanız, LLM olmadan bile 3 aydan çok daha kısa sürede yapabilirsiniz
Aslında aynı projeyi iki, üç kez tekrar ettiğinizde ilk seferde aylar süren şeyin sonraki seferde yaklaşık üçte bire düştüğünü bizzat yaşadım
<i>öksürük</i> bunu 24 saat içinde geliştirdiğim bile oldu, örnekler için nordicgamejam.com var. LLM'nin, GenAI'ın ve Unity'nin olmadığı dönemde Microsoft XNA ile C# elimizdeki en iyi seçenekti demek istiyorum. Sanat tarafı da çoğunlukla Paint'te çizilmiş el yapımı şeylerdi. Yine de her yıl yeterince eğlenceli oyun çıkıyordu; Baba is You ve Braid gibi geniş kitlece bilinen örnekler de vardı. Darboğaz kodlama değildi; bana göre asıl bottleneck ekip üyeleri arasındaki iletişimdi
Bu yorum zincirine bakınca oyun geliştirme deneyimi olmayan çok yazı var gibi görünüyor. Aslında LLM'in kullanıldığı proje türü eğitim verisinde bolca bulunan bir tür. Örneğin programlamaya giriş derslerinde işlenen bir proje tipi ve Güney Avrupa ülkelerinde bu blogdaki kart oyununa çok benzeyen oyunlar gerçekten çok yaygın. Ben de üniversitenin ilk yılında hiç deneyimim yokken Moon Patrol'u Python'da sıfırdan yapmıştım; 2-3 ay sürdü ve haftada 3 gece sabahlayarak kodladım. Kart oyunu yapmak bundan daha bile kolay. LLM'in kesinlikle faydalı olduğu yerler var ama bu tür basit örnekler, LLM'in kodlama verimliliğini ya da kullanışlılığını benchmark etmek için uygun değil
LLM ile birkaç güne yayarak şöyle bir şey yaptım: stacky. Gerçekte yaklaşık iki gün çalışmış oldum. Başta sıfırdan geliştirdim, sonra brownfield tarzında devam ettim ve çok ciddi biçimde bitirme niyetim de yoktu. Ama detay ve özellik ekledikçe aklıma yeni fikirler gelmeye başladı; super rotation, DAS vb. Hâlâ tamamlanmadı, oyunun ancak %10-20'si kadar. WebGL sürümü de çalışıyor. Ama nihai Tetris'i yapmaya fazla yaklaşsam dava edilirim diye korktum ve öyle bir lisans ücretini de karşılayamam, o yüzden durdum. Sonuçta kazandığım şey özgüven ve deneyim oldu. Yakın zamanda HN'de parametrik fonksiyonlarla ilgili bir bağlantı görünce 1-2 saat içinde graphy adlı bir playground da yaptım. Yine detaylara gereğinden fazla zaman gitmeye devam ediyor. Ne istediğiniz netse, LLM ile böyle işler yapmak oldukça keyifli olabiliyor
Belirli bir seviyenin üzerinde hobi amaçlı oyun geliştirmeyi uzun süredir sürdürüyorum ve birkaç oyunu da bitirdim. Ama bu yorum zincirinin genelinde gerçek oyun geliştirme deneyimi çok yok gibi. Oyun geliştirmede kodlamanın kolay olduğu iddiasına katılamıyorum. Taze fikirler ya da türü dönüştüren mekanikler bulmak nispeten kolay; asıl zor olan bunları gerçekten koda dökmek. Örneğin multiplayer Vampire Survivors'a battlemech özelleştirmesi eklemeyi hayal etmek kolaydır ama bunu yalnızca LLM ile uygulamak neredeyse imkânsızdır. Bu örnekteyse zaten tamamen bilinen bir kart oyunu kural seti var, yani yılan oyunu kadar basit. Bunu yazarı eleştirmek için söylemiyorum; sadece birçok kişinin gerçek oyun geliştirme deneyimi olmadan bu alanı değerlendirdiğini belirtmek istiyorum
Kodlamanın oyun geliştirmenin zor kısmı olduğu iddiasına katılmıyorum. Elbette zor olabilir ama asıl zor olan yeni ve eğlenceli fikirler bulmak. İyi bir fikriniz varsa onu küçük parçalara bölüp yineleyerek sonunda uygulayabilirsiniz. Asıl duvar, bomboş bir sayfadan ne yapacağınıza karar verdiğiniz andır. Yürüyüşe çıkmak, olmadık şeyler denemek; bu sanatın binlerce yıldır tekrar ettiği problem. Kodlama ise sonuçta mühendislik işi. Ben de son dönemde oyun geliştirmeyi öğrenirken matematik de çalışıyorum ama vektör matematiği ya da quaternion öğrenmek, "ben nasıl bir oyun yapmak istiyorum?" sorusuna karar vermekten çok daha kolaydı
Genel olarak katılıyorum ama benim için tersine, yeni fikir üretmek ya da yaratıcı denemeler yapmak her zaman daha zor oldu. Neredeyse her oyun mekaniğini kodlayabilirim ama yazma/yaratıcılık kısmı gerçekten zor. Eğer bu taraf size kolay geliyorsa gerçekten şanslısınız. Herkes için doğal bir şey değil
Tamamen client-side bir oyun yapmaya çalışıyorsa neden "backend" gerektiği şekilde yazdığını, ayrıca neden tüm uygulama yerine sadece backend için ayrı bir teknoloji kullandığını merak ediyorum
Yazılım sektöründe fikirlerin kolay ve hızlı biçimde hayata geçtiği alanların neredeyse kalmadığını hissediyorum. Rekabet artık öyle yoğun ki, ne kadar küçük bir pazarı hedeflerseniz hedefleyin doğrudan küresel VC'lerle ve küresel AI ile yarışıyorsunuz. Eskiden en azından büyük şirketlerin umursamadığı bir niş bulunabiliyordu. Şimdi ister büyük VC pazarı olsun ister niş, her durumda tüm dünyayla rekabet etmek zorundasınız; geriye ya aşırı karmaşık teknoloji gerektiren küçük pazarlar ya da kârlılığı düşük, başarısızlık olasılığı yüksek ve yaşam döngüsü kısa alanlar kalıyor ki oyunların çoğu tam burada. İlk durumda kapı kapı dolaşıp ürünü anlatacak kadar yoğun pazarlama gerekiyor. Oyun sektöründeki deneyimime göre, geliştirme aşamasına girmeden önceki en büyük başarı hikâyesi bile "bir milyon görüntülenme alıp 6 ay sonra tamamen sönmek" düzeyinde kalıyor. Tekrarlayan gelir neredeyse hiç olmayınca başlamak bile fazlasıyla moral bozucu. Minecraft gibi bir oyun yapmak neredeyse piyango gibi. Ama oyun sektörü, en azından diğer yazılım alanlarına göre daha meritokratik. Kalite ve eğlence düzeyi benimsenmeyle bir ölçüde bağlantılı. Diğer sektörler ise regülasyon, ağ etkisi kaynaklı tekeller ya da devlet kontrolüyle tam bir labirent. Keşke devlet en baştan "bu alanı zaten şu şirket domine edecek, startup kurma başka yere bak" diyebilse de insanlar 1 yılını boşa harcamasa
Ne zaman greenfield, yani tamamen yeni projelerin agent coding becerisini benchmark etmek için en kötü senaryo olduğunun farkına varılacağını merak ediyorum
LLM'leri sevmemin nedeni, kodu zihnimde programları soyutladığım biçime daha yakın şekilde ele almamı sağlaması. Kodu okurken onu adeta bir AST gibi düşünüyorum; fonksiyonları ve çağrıları, girdiler ve çıktılar olarak soyut düğümlere dönüştürerek anlıyorum. LLM sayesinde bunu tersine çevirip koda dökmek inanılmaz kolaylaştı. Artık fikrime uygun örnek kod aramak ya da hafızamı yoklamak zorunda kalmıyorum; LLM'e WiFi başlatma gibi tekrarlı kodları yazmasını söylemem yetiyor. Sonuç olarak programları Lego blokları gibi birleştirebiliyorum. LLM'den önce de bu mümkündü ama çok daha fazla emek istiyordu. Bu sayede bugünlerde farklı diller arasında kolayca geliştiriyorum. Dillerin iç yapısını ya da sözdizimini çok öğrenmiyorum ama zaten mesele de bu. Dil ve sözdizimi, programın mantıksal akışıyla ilgisiz ikincil ayrıntılar. Sonuçta makine dilinden assembly'ye, C'ye ve giderek daha yüksek seviyeli dillere evrildiysek, şimdi de kodlamaya değil doğrudan 'programlama'ya yaklaşıyoruz. Son hâlinin ne olacağını kimse bilmiyor ama yazmaya harcadığımız zamandan çok programlamaya odaklandığımız zamanın giderek artacağı açık