Tramway SDK – Half-Life ve Morrowind motorlarının saygısız birleşimi

• Tramway SDK, son 3 yılda geliştirilen bir grafik paketi/framework/oyun motoru; ana akım motorların yüksek sistem gereksinimlerine ve monolitik editör akışına karşı hafif bir motor olmayı hedefliyor
• Unity ve Godot gibi ana akım motorların basit low-poly oyunlar için bile aşırı donanım istediğini savunuyor; hedef çalışma ortamı olarak son 15 yıl içindeki donanımları ve hatta yazılımsal rasterizasyonu kapsıyor
• Üretim yaklaşımı, node tabanlı GUI ile kod arasında gidip gelmek yerine Entity sınıfını kalıtım alarak kod yazmak ve yalnızca gerekli editörleri seçip kullanmak üzerine kurulu
• Seviye üretimi, Quake tarzı brush iş akışını temel alıyor; .map dönüştürücüsü, lightmap, Gouraud shading ve Source benzeri giriş/çıkış sistemi kullanıyor
• Açık dünya streaming ve 3D RPG Maker’a yakın bir RPG framework’ü hedefliyor; ancak hâlâ erken geliştirme aşamasında olduğu için kararsız API’ler ve henüz tamamlanmamış bileşenler göz önünde bulundurulmalı

---

Tramway SDK'nın hedef aldığı sorun

• Tramway SDK, bir grafik paketi, framework ve oyun motoru; ayrıca “T̈ra̦m̊ẅa̦ÿ SD̈K” biçimindeki heavy metal tarzı yazımı da kullanıyor
• Ana akım motorlara yönelik eleştirisi Turbobloat üzerinde yoğunlaşıyor
  • Unity'nin çok güçlü donanım ve yüksek enerji tüketimi gerektirdiğini savunuyor
  • Godot'nun Unity'den biraz daha iyi olduğunu, ama yine de görece güçlü donanıma ihtiyaç duyduğunu düşünüyor
  • Low-poly korku roguelite deckbuilder simülatörü gibi oyunların 15 yıllık donanımda bile rahatça çalışabilmesi gerektiğini savunuyor
• Tramway SDK, Turbobloat içermediği için son 15 yıl içindeki neredeyse tüm donanımlarda çalışabildiğini öne sürüyor
  • Ekran kartı olmadan da çalışması için yazılımsal rasterizasyona geçebiliyor
  • Hatta toaster ya da buzdolabı gibi cihazlarda grafik göstermeyi örnek veriyor
• “Daha iyi bir bilgisayar alırsın olur biter” itirazına üç gerekçeyle karşı çıkıyor
  • Pek çok insanın güçlü donanım almaya gücünün yetmemesi nedeniyle erişilebilirlik/satın alınabilirlik sorunu
  • Bilgisayar çipi üretiminin çevreye zarar vermesi ve yazılım şişkin değilse yeni donanımın ancak mevcut cihaz bozulup onarılamaz hale geldiğinde alınması gerektiği yönündeki e-atık sorunu
  • Zaten iyi çalışan bir bilgisayar varken başkasının Turbobloat'u yüzünden yeni bilgisayar alma zorunluluğu olmaması gerektiği görüşü

Üretim yaklaşımı ve özellikler

• Node tabanlı üretim yaklaşımı, “tek bir şey gibi görünen birçok şeyi” yönetmek zorunda bırakması ve node GUI ile kod arasında gidip gelmeyi gerektirmesi nedeniyle eleştiriliyor
• Tramway SDK'da Entity sınıfını kalıtım alarak kod yazıp ardından seviye editörüyle seviyeyi oluşturmak yeterli
  • Node kullanmadan, entity merkezli bir yapı benimsiyor
  • Kod ile node GUI arasında gidip gelen akıştan kaçınıyor
• Ana akım motorların monolitik editörleri de sorunlu görülüyor
  • Kullanılmayacak özellikler dâhil tüm editörün yüklenmesini beklemek gerektiği söyleniyor
  • Tramway SDK'nın editörlerinin tamamı isteğe bağlı
  • Yalnızca framework olarak kullanmak isteyenler sadece C++ runtime'ı kullanabiliyor
  • Sadece seviye üretimi gerekiyorsa yalnızca seviye editörü kullanılabiliyor
  • Veri dosyaları boşlukla ayrılmış değer biçiminde olduğundan, editör olmadan elle de düzenlenebiliyor
• Grafik tarafında yalnızca lightmap ve Gouraud shading ile bile örnek görseller üretilebildiği belirtiliyor
  • Verilen örneklerin Direct3D 7 seviyesi ekran kartlarının fixed-function pipeline'ında da render edilebildiği söyleniyor
• Seviye üretimi, Quake ailesinden gelen brush tabanlı iş akışını destekliyor
  • Tramway SDK, .map dosyası dönüştürücüsü sunuyor ve brush'ları üçgen mesh'lere çeviriyor
  • Trenchbroom'da seviye oluşturup ayarları Tramway SDK seviye editöründe tamamlama akışı gösteriliyor
  • Motor içinde lightmap uygulanmış seviyeler render ediliyor
  • Source'a benzer bir giriş/çıkış sistemi ile seviye içindeki entity'ler arasındaki etkileşimler tanımlanabiliyor
  • İleride Source logic entity sisteminin tamamını uygulayarak seviye editörü içinde visual scripting sağlama planı bulunuyor
• RPG tarafında, RPG Maker benzeri araçlar ile Morrowind tabanlı mod ve total conversion'ların pek çok şeyi veri değişikliğiyle üretebilmesi ilginç bir örnek olarak görülüyor
  • Tramway SDK içinde, 3D için RPG Maker'a yakın bir RPG framework genişletmesi yer alıyor
  • Motor, en baştan seviye streaming desteğiyle tasarlandığı için açık dünya RPG tarzı oyunları hızlı ve kolay üretmeyi amaçlıyor
• Özetle Tramway SDK, Quake/Source tarzı entity tabanlı bir oyun motoru ve açık dünya streaming ile RPG framework gibi isteğe bağlı genişletmeler sunuyor
• Geliştirme durumu hâlâ çok erken aşamada
  • API kararsız
  • Özellikler bozuk olabilir ya da çalışmayabilir
  • Henüz uygulanmamış birçok bileşen var
  • Yine de hızlı biçimde geliştirildiği belirtiliyor
• GitHub deposu: racenis/tram-sdk

[GN⁺]

Hacker News yorumları

• “Sadece daha iyi bir bilgisayar al” diyenler de olabilir, ama bu yüzden daha iyi bilgisayar almanın kötü olduğu konusunda tamamen katılıyorum. Pek çok kişinin, özellikle de gelişmekte olan ülkelerdeki insanların Turbobloat çalıştıracak donanımı almaya gücü yetmiyor; çip üretiminin de çevre üzerinde olumsuz etkisi büyük.
  Modern yazılımlar bu kadar şişkin olmasaydı, yeni donanımı ancak mevcut donanım bozulup tamir edilemez hâle geldiğinde alırdık. Gayet düzgün çalışan bir bilgisayar varken başkasının şişkin yazılımı yüzünden yeni bilgisayar almaya gerek yok; o parayla 1000 kutu Dr. Pepper da alınabilir. Gerçekten iyi bir proje, ilerleyişi paylaşmaya devam etmelerini isterim.

  • “320x200’den 800x600’e kadar ekran çözünürlükleri” deniyor ama daha yüksek çözünürlükler yalnızca Turbobloat yüzünden icat edilmiş değil.
  • Bunu söylerken motor sanki OpenGL 4 GPU istiyor gibi görünüyor; oysa grafikler Voodoo kartıyla bile mümkün olabilecek düzeyde.
  • Turbobloatın ne olduğunu bilmiyorum. Bağlama bakınca “sevmediğim grafik teknolojileri” gibi okunuyor ama Turbobloat’ın nerede başlayıp bittiği net değil.
  • Yeni bir bilgisayar üretip göndermek uzun vadede değerli olabilir. Çünkü performans ve enerji verimliliğindeki iyileşmeler zamanla çevresel etkiyi telafi edebilir.
    Elbette konu eğlence amaçlı kullanım olunca karar vermek zor; eski bir Game Boy, 1000W’lık modern bir oyun PC’sinden daha eğlenceli olabilir.

• “Bir, bir olmalıdır. Bir gibi davranan çok şey olmamalıdır. Node’ları kullanınca, birden fazla şeyin toplamını bir gibi davranmaya zorlamış olursun” cümlesi gerçekten Terry Pratchett tarzı ve harika.
  Sam Vimes’ın karmaşık bir soruşturma sırasında aklına getireceği türden bir cümle gibi olduğu için hoşuma gitti; umarım gelişmeye devam eder. Henüz kendim denemedim ama yapay zeka projemde kullanabileceğim bir fikir var.

  • O cümleyi tek başına alınca, aksine açıkça yanlış değil mi diye düşünüyorum. Biz zaten sürekli birçok şeyin toplamını tek bir şey olarak düşünürüz.
    İnsan, vücut parçalarının toplamıdır; vücut parçaları kimyasalların toplamıdır; kimyasallar moleküllerin toplamıdır; moleküller atomların toplamıdır, ama her aşamada onları tek bir şey olarak görürüz. Bunu yapmayı engellemek mantıklı değil. Yine de proje havalı görünüyor.
  • Sam Vimes böyle bir şey söyledikten sonra, Sybil yüzünden sancılı bir gelişim süreci yaşayıp istemeye istemeye “bazen bir, sadece birden fazla şey olmak zorunda kalabilir” diye kabul ederdi sanki.
    Ve Vetinari’nin entity component system’ı karmaşık görünse de düzgün çalışır, lanet şehrin işlemesini sağlar.
  • Bu ifade, başka çözümleri deneyip sevmemiş kişileri hedefliyor gibi; ama hiç oyun motoru kullanmamış biri olarak node’ların “birden fazla şeyin toplamını bir gibi göstermesi” ile nasıl bağlantılı olduğunu basitçe açıklasalar iyi olurdu.
    Node editörünün kullanıcı deneyimi, Finger’lardan oluşan Vector gibi şeylere özellikler ve ilişkiler atamaya teşvik ediyor; ama sonuçta Vector yalnızca “şeylerin toplamı”, kendi davranışı olan bir “tür” değil, bu yüzden ona kod bağlamak zor mu demek istiyorlar acaba.
    “Her şey Entity’dir, sadece kod yazın” demek, Vector yerine Fingers’ları içeren, kendi durumu ve davranışı olan bir Hand sınıfı oluşturmaya yönelmek anlamına mı geliyor, merak ediyorum. Ya da belirli statik değerleri ve ilişki üyelerini önceden bir araya getiren node örnekleri oluşturmak yerine, Entity alt sınıflarını yeniden türeterek daha da özelleştirmek gerektiği anlamına mı geliyor?
  • Hemen sonraki paragraf ilginç: “Node’larla bir şey yaparken sürekli node GUI’si ile kod arasında gidip gelmek zorundasın.”
    Godot’nun Node/GDScript yapısı bu iddiaya bir tür yanıt olarak görülebilir. $ operatörü ve otomatik tamamlama gibi şeylerle bu “gidip gelmeyi” olabildiğince pürüzsüz ve bütünleşik hâle getirmeye çalışıyor. Yine de sonuçta oyunu yayımlamak gerekiyor; bu yüzden “bir, birdir” düşüncesinin eninde sonunda kazanacağını düşünüyorum.
  • Ne yazık ki her şey, tekmiş gibi davranan şeylerin toplamıdır; tekil şeyler bile öyle. Yapabileceğimiz en iyi şey ya öyle davranmak ya da yakalanmadan bundan kaçınmaktır.

• Zaman geçtikçe oyun motoru kalitesini düşüren dışsal bir güç varmış gibi geliyor. Teknoloji genelinde yaygınlaşan şeyler genellikle müfredat hazırlaması kolay olanlar oluyor.
  Unity gibi düğüm tabanlı editörler, birden fazla ders boyunca anlatmaya çok uygun bir yapıya sahip. Buna karşılık raylib gibi bir motor bir öğleden sonra anlaşılabildiği için üniversite düzeyinde bir raylib dersi pek mümkün olmuyor. Böylece bootcamp tarzı okullardan yalnızca Unity/Unreal bilen amatör geliştiriciler çıkıyor, şirketler Unity/Unreal bilen kişileri işe alıyor, üniversiteler de tekrar bunu öğretiyor; bir döngü oluşuyor. Java’nın popüler olmasına da benziyor.
  Ayrıca her şirketin Unity projesinden beklentisi farklı olduğundan Unity, şikâyetçi tek bir programcı değil, müşterilerle uğraşan kâr amaçlı bir şirket olarak motoru sürekli uyarlamak zorunda kalıyor ve sonunda Turbobloat hâline geliyor. Half-Life ve Morrowind motorları, tutkulu programcıların havalı olduğunu düşündükleri şeyleri geliştirmeleri için para aldığı benzersiz bir durumdu; bu yüzden profesyonel oyun geliştiricilere uygun, asgari düzeyde bir motor ve harika teknoloji ortaya çıktı.
  Bu proje raylib ile Unity arasında bir yerde duruyor gibi görünüyor. Amatör programcılara hitap etmek için yetersiz kalmasından, küçük bir motor isteyen programcılar içinse fazla iş yapıyor olmasından endişeleniyorum. Umarım yanılıyorumdur; performansı ve tamamlanmışlık düzeyi iyi görünüyor. Unity’den bıkmış geliştiriciler kesinlikle var ve nostalji döngüsü 2000’lere kaydıkça Half-Life 2’den grafiksel olarak daha karmaşık olmayan oyunları oynamak ve yapmak isteyen gerçek bir talep de var. Web tasarımı ve dokümantasyon tonu da iyi.

  • Oyun ile motor birlikte yapıldığında birbirlerine uyum sağlayabilmeleri de önemli. Doom’da bir zeminin üstüne başka bir zemin koyamıyordunuz; bu, CPU kısıtlarından kaynaklanan bir motor sınırlamasıydı ve seviye tasarımcıları öyle görünmesini sağlayacak hileler geliştirmişti.
    İkisini birlikte tasarlarsanız eklediğiniz özellikleri aktif biçimde kullanabilir, iyi yapamadığı özelliklerden kaçınabilir ya da sanat tarzını doğrudan motora uydurabilirsiniz. Minecraft’ın pikselli, köşeli mob’ları motorla iyi uyum sağlıyor; ama daha ayrıntılı yapmaya başladığınızda, yeterli poligonla iyi render edilene kadar Minecraft’tan bile daha eski ve garip görünen tekinsiz vadiye düşüyor.
  • Bioshock’ta çalışmış birinin, muhtemelen baş tasarımcının, bir röportajda şöyle dediğini hatırlıyorum: “Şirkette yeni bir fikri denemek için ekip kurmanız ve elinizle dokunabileceğiniz bir şey çıkana kadar en az bir ay harcamanız gerekir. Oysa evde tek bir akşamda bütün bir Doom kampanyası yapabilirim.”
  • raylib veya libgdx gibi kütüphane tabanlı oyun geliştirmeyi seviyorum, ama Slay the Spire gibi bir oyunun devam oyununda Unity’den geçip Godot’ya gitmesinin bir nedeni var.
    İnsanların karmaşıklığı seven hocalardan yanlış öğrendikleri için Unity kullandığını düşünmüyorum.
  • Eski oyunlar gerçekten netti; günümüz oyunları ise berbat çalışıyor, çöküyor, indirmek için 150 GB istiyor ve açılması 150 yıl sürüyor. Oyunları grafikler için oynuyor olsaydık en popüler MMO’lardan biri 2002 tarihli bir tarayıcı oyununa dayanıyor olmazdı; hatta en başta oyun değil, gerçekliği oynardık.
    Epic Games’in Fortnite’a ne yaptığına bakmak yeterli. Akıcı çalışan, rekabet sahnesi odaklı bir oyunu Turbobloat grafikleri ve skin’ler yüzünden öldürdü.
  • “Yalnızca Unity/Unreal bilen programcılar çıkıyor, şirketler Unity/Unreal bilenleri işe alıyor, üniversiteler de tekrar bunu öğretiyor” olgusu ArcGIS’te de benzer şekilde görülüyor.

• Turbo şişkinleşme sorununa tamamen katılıyorum. Günümüz makineleri çok daha güçlü olmasına rağmen çoğu program eskisinden daha yavaş hissettiriyor.
  Proje de çok havalı, web sitesi tasarımı ise A+.

  • “Çoğu program eskisinden daha yavaş” ifadesi, bence yalnızca belli bir dönemde şans eseri biraz gereğinden güçlü donanım kullanmış kişiler için geçerli.
    Windows 98/2000/XP döneminde sıradan donanım kullanan biri olarak, SSD’li ucuz bir modern dizüstünde Windows 10/11/KDE/Gnome vb. çalıştırmak, vscode veya Slack gibi şişkin kabul edilen web uygulamalarını çalıştırırken bile çok daha tepkisel.
  • Turbobloat terimini anlayamadım. Oyun yaptım ama hiç duymadım; yazar da tanımlamamış, Kagi’de aratınca yalnızca gönderi çıkıyor, Google’da da ilgili sonuç yok.
    Sadece “çok şişkin” anlamına mı geliyor merak ediyorum. Siteyi biraz daha okuyunca “hipergerçekçi fizik simülasyonu” gibi ifadeler de gördüm; sonuçta “çok şişkinlik” anlamına geliyor gibi.

• “Unity oyunlarının çoğu, gösterişli shader’lar, normal mapping ve başka teknikler kullansa bile çok kötü görünür” görüşü belli bir kuşak arasında giderek yaygınlaşıyor gibi
  Belli türden bir texture mapping tekniğinin ortadan kaybolduğu kesin. Ikaruga’nın arka planları gerekenden fazla iyi; özellikle başlardaki basit orman efekti. PS2 dönemindeki bazı tren simülatörleri de bunu başarmıştı.
  Ancak güneş gibi güçlü yönlü bir ışık kaynağı parlak nesneleri aydınlatıp oyuncu hareket ettiğinde bu yöntem dağılıyor. Ortam kapalı havalıysa ve hiç dinamik nesne yoksa modern hilelerin epeyce etrafından dolaşılabilir

  • Doğru. Sorun şu ki bazı modern oyunlar kapalı havalı ve dinamik aydınlatmaları da yokken ille de Lumen kullanıyor. Silent Hill remake’i böyleydi; çok yavaş çalışıyor, PS5 Pro’da daha da kötü görünüyor, çimleri de eski oyunlardan daha kötü duruyor
    Aslında Silent Hill’in kurgusu optimizasyon hilelerini meşrulaştırmak için yaratılmıştı. Ekrandaki nesne yönetimini kolaylaştırmak için “sis mekânı” denen, sürekli sisli bir alan vardı; remake ise doğaüstü görünen sis yerine gerçekçi sis yapmaya çalışırken muazzam işlem gücü harcıyor
  • Unity ile yapılmış güzel oyunlar “Unity oyunu gibi” görünmediği için insanlar “Unity oyunu nasıl görünür” örneği olarak onları aklına getirmiyor. Bu yüzden Unity oyunlarının tipik imajı hâlâ “epey kaba” olarak kalıyor
    İyi görünmesini sağlayan sanat becerileri hiç kaybolmadı; sadece dağılımı çok eşitsiz. İyi modelci, texture artist, animatör ve görsel programlama yetkinliğine sahip bir ekip, Unreal da kullansa Unity de kullansa kendi motorunu da kullansa harika görünen işler çıkarır
  • Yalnızca malzemelerle yetersiz texture’ların ve normal mapping’in üstesinden gelinebileceği yönünde bir inat var. Bu doğru değil; Unreal Engine gibi şeylerin pazarlama metinlerinin yanlış anlaşılması ya da çarpıtılmasının sonucu
    Super Mario Sunshine’da GameCube’ün render edemediği “keskin” gölgeler için aslında düz mesh’ler kullanılmıştı. Delfino Plaza’da Shine Gate yakınındaki tentenin altındaki gölge texture değil, mesh. Buna karşılık o mesh gölgenin düştüğü karo meydanın iyi görünmesinin nedeni devasa tek bir texture değil, onlarca 128x128 px texture’ın düzgün UV mapping ile kullanılması.
    Modern bir oyun olsa iki tuğla texture’ı ve bunları karıştıran bir noise pattern kullanırdı; üçü de 2048x2048 px olurdu, gölge de ray tracing ile keskin kenarlar üretirdi. İronik biçimde VRAM ve bus hızı artmışken daha fazla texture yerine daha büyük texture’ları seçtik. Normal mapping’de de benzer şekilde, daha ayrıntılı modellere eşlik etmek için kullanmak yerine normal map’in eski moda olduğunu ve tüm ayrıntıları gerçekten modellemenin teknik olarak daha ileri yol olduğunu sanıyoruz. Daha az köşeli bir küre tamam, ama kürenin üzerindeki her çatlağı ve çizikleri gerçekten modellemek aptalca ve hesaplama israfı
  • Unity gibi bir şeyle çalışan bir şeyi oldukça hızlı yapabilirsiniz, ama gerçekten harika görünmesi için ayrı beceriler ve cilalama gerekir
    Factorio gibi “2D” oyunlarda bile ilk çıkış, 1.0 ve güncel sürüm arasında cilalama farkı muazzam. Modlu oyunlarda da bu fark açıkça görülür; mod varlıkları genelde “kullanılabilir” olur ama ana oyun kadar cilalı görünmez

• Yakın zamanda Half-Life 2’yi tekrar oynadım; yüksek çözünürlüklü texture paketi olmadan bile bugün hâlâ ne kadar harika göründüğüne şaşırdım

  • Bunun, oyunun sanat tarzını son derece zekice seçmiş olmasından kaynaklandığını düşünüyorum. Aydınlatmayı önceden bake etmenin iyi işlediği çok sayıda difüz yüzey var; kapalı gökyüzü de açıya bağımlı shading ve keskin, yüksek kontrastlı gölge konturları dayatan yönlü ışık yerine yayılmış ambient light kullanımına izin veriyor
    Parlak yüzeylerin çoğunun aşırı parlak olmaması da yardımcı oluyor. Bu seçimler eskimiş, işgal edilmiş, aşırı distopik bir dünyaya iyi uyduğu için inandırıcı; sakin renk paletli texture’lar da bütünü bir arada tutuyor
  • Bu yüzden gerçekten iyi art direction’ın her zaman saf grafik gücünü yeneceğini düşünüyorum. Source o dönemde de etkileyiciydi, ama kalıcı olan kısmı ortamların ve modellerin ne kadar özenle tasarlanmış olduğu
    Valve kaynaklarını teknik kısıtlar içinde ayrıntı eklemeye ve en fazlasını çıkarmaya odakladı; 20 yıl sonra bile bütünlüklü ve iyi tasarlanmış görünmeye devam ediyor
  • Half-Life 2, çıkışından sonra shading ve detay seviyesi konusunda birkaç güncelleme aldı; bu yüzden çıkıştaki hâlinden biraz daha iyi görünüyor. Yine de çıktığı anda da görsel olarak etkileyici bir oyundu
  • Bir haftadan kısa süre önce Half-Life 2’yi tekrar oynadım ve “seviyeler modern oyunlar kadar ayrıntıyla dolu olmasa da grafiklerin ve level design’ın sanatsal yönü, daha büyük bütçelere sahip birçok modern tasarımcıdan daha iyi” diye düşündüm
  • HL1’in HL2 motoruyla yapılmış remake’i Black Mesa da keyifli. Pandemi sırasında oynamıştım, pişman olmadım

• Godot ile low-poly oyun yapan küçük bir ekipte çalışan biri olarak bu harika
  “Node’larla bir şey yaparken sürekli node GUI’si ile kod arasında gidip gelmek zorundasınız”, “ana akım motorlarda tek bir dev oyun editörü var ve hangi özelliği kullanırsanız kullanın hepsinin yüklenmesi için 10 dakika beklemeniz gerekiyor” sözleri bana çok tanıdık geldi. Godot’ta bile gösterişli özellikleri neredeyse hiç kullanmıyorum ama debug döngüsü, başka ortamlarda programlama yaparken olduğundan çok daha yavaş geliyor.
  Tek bir veri dosyası belirtimi etrafında birden fazla editörün birlikte çalışması fikri de güzel. Entegre IDE’ler birden fazla geliştiricinin merge conflict yaratmasını kolaylaştırıyor; daha belirli amaçlara yönelik editörler ise role göre çalışan geliştiricilerin değişiklik kapsamını ve niteliğini sınırlamasına da yardımcı olabilir. Motorun nasıl gelişeceğini merakla bekliyorum

  • Geçen ayki hackathon’da Unity’yi açmadan C# modüllerini test odaklı geliştirme yolunu bulduğum için epey gurur duydum
    Düşük performanslı bir netbook’la bile kendi payıma katkı verebildim. Daha önce tek satır C# yazmamıştım ama komut satırında TDD’den vazgeçmeye niyetim yoktu. Bunun mümkün olduğunu öğrendim ve sonunda çalışır hâle getirdim. Herkes delirdiğimi düşündü; sponsorların geliştirici ilişkileri sorumluları da hiç yardımcı olmadı.
    O hafta sonu en büyük sürtünme hâlâ en iyi bilgisayarın lanet Unity IDE’sini açıp yeniden açmak için sonsuz zaman harcamak zorunda kalmasıydı. İnsanların katlandığı prangalar şaşırtıcı

• “Turbobloat” ve motorun “şişkin” olduğu ifadeleri kullanılıyor; bir ölçüde doğru. Ama bunun kendisi için ne anlama geldiğini, hangi özellikleri şişkinlik olarak gördüğünü ve Tramway projesinden neleri çıkardığını açıklamaya değer
  Örneğin bazıları için RPG framework’ünün dâhil edilmesi bile şişkinlik sayılabilir; Tramway’de bu var

  • Bu yüzden onu isteğe bağlı uzantı olarak koydum. Daha büyük motor projesinin bir parçası olsa da tamamen isteğe bağlı
    C++’ın “yalnızca kullandığın şeyin bedelini ödersin” ilkesini seviyorum

• “C++’tan korkan ya da sadece beceremeyen yeni başlayanlar için framework kullanımı” denmiş; ben ikinci gruptayım ve Getting Started sayfası için minnettarım.
  Çaydanlık belirdi ve anlayamayacağımı sandığım şeyleri anladım. Şu an öğle arasında sadece 30 dakikam olduğu için öğreticiyi bitirecek vaktim yok, ama devam etmek istemem bile bu belgenin ne kadar eğlenceli ve erişilebilir olduğunu iyi gösteriyor.

• Design Patterns sayfasını bulan var mı? Hedefi %100 olan bir skor tablosu gibi, çok hoşuma gitti.

  • Ana sayfada bağlantısı var: “Kullanılan tasarım kalıpları %82. Tüm kalıpları kullanınca projeyi silip Rust ile yeniden yazacağım. Nesne yönelimi olmadan.”
  • Epey aradım ama hâlâ bulamadım.