Oyun motoru olmadan video oyunu geliştirmek (2025)

 (noelberry.ca)
33 puan yazan GN⁺ 2025-05-21 | 5 yorum | WhatsApp'ta paylaş
  • Ticari oyun motorları olmadan da oyun geliştirmek yeterince kolay ve keyifli olabilir
  • Büyük motorların sunduğu özelliklerin çoğuna gerek yoktur; araçları kendiniz yazdığınızda esneklik ve geliştirme verimliliği artar
  • Modern C# ve açık kaynak kütüphaneler kullanıldığında, ekip büyüklüğünden bağımsız olarak yeterli bir geliştirme ortamı sağlanabilir
  • FMOD, SDL3, Dear ImGui gibi kütüphaneler ile kendi araçlarınızı birleştirerek ihtiyaçlara uygun bir pipeline kurulabilir
  • Çapraz platform geliştirme, bakım ve taşınabilirlik açısından, doğrudan inşa edilmiş hafif bir framework oldukça avantajlıdır

Önsöz: 20 yıllık bir oyun geliştiricisinin düşünceleri

  • 2025'te de hâlâ ticari oyun motorları olmadan video oyunu geliştiriyorum
  • Çevremdekiler, ticari motor kullanmıyor olmama sık sık şaşırıyor
  • Unity veya Unreal gibi büyük motorların temel işlevleri, bunları doğrudan kendim uygulamaya kıyasla tatmin edici gelmiyor ve sonuçta birçok kısmı yeniden yapmak gerekiyor
  • Ticari motor kullanırken, sık değişen iş politikaları veya güncellemelerin yol açtığı sorunlara maruz kalınıyor
  • Her projeye tam uyan küçük araçları doğrudan yazmak daha verimli ve uzun vadede de bakımı daha kolay

Oyun geliştirme için programlama dili seçimi

  • Uzun yıllardır ana dil olarak C# kullanıyorum
  • Modern C#, geçmişe göre performans, sözdizimi ve geliştirme deneyimi açısından büyük ölçüde iyileşti
  • dotnet watch gibi hot reload özellikleri sayesinde, kodu gerçek zamanlı değiştirip test etmek çok pratik
  • Geliştirici olmayan kişilerin de daha kolay yaklaşabilmesi, ekip içinde rol paylaşımını ve iş birliği verimliliğini artırıyor
  • Yerleşik reflection özelliği, editör ve araç geliştirmede güçlü avantajlar sunuyor

Çapraz platform kütüphaneleri ile render/girdi uygulaması

  • SDL3 kullanarak pencere, render, kontrolcü ve çapraz platform desteği dâhil tüm temel işlevleri uyguluyorum
  • SDL3'ün GPU abstraction yapısı sayesinde DirectX, Vulkan, Metal gibi farklı ortamlara destek vermek kolaylaşıyor
  • SDL üzerine doğrudan yazdığım C# katmanını (ör. Foster) ortak bir yardımcı araç seti olarak kullanıyorum
  • Geriye kalan son ticari ses aracı olarak FMOD kullanılıyor; bunun dışında pipeline açık kaynak temelli kurulmuş durumda
  • Geçmişte OpenGL/DirectX'i doğrudan uygulama deneyimim de oldu; bu açıdan SDL'nin sunduğu kararlılık önemli bir avantaj

Asset işleme yöntemi

  • Kendi motorunuzu kullandığınızda, oyunun ihtiyaç duyduğu dosyaları yalnızca basitçe yüklemeniz yeterlidir
  • Piksel art oyunları gibi küçük ölçekli asset'lerde, tüm dosyalar başlatma sırasında tek seferde yüklenir
  • Büyük projelerde ise yalnızca gereken asset'ler istek üzerine yüklenir ve sahne geçişlerinde bellekten çıkarılır
  • Dönüştürme gerekiyorsa, derleme sırasında otomatik çalışan bir script yazmak çoğu zaman yeterlidir

Seviye editörü ve UI araçları

  • LDtk, Tiled, Trenchbroom gibi açık kaynak seviye editörleriyle veri entegrasyonu kolaydır
  • Genelde her proje için özelleştirilmiş editörler doğrudan geliştiriyorum
  • UI'ın ana gövdesini sıfırdan yazmak yerine, Dear ImGui'nin immediate mode GUI yaklaşımından yoğun biçimde yararlanıyorum
  • C# reflection ile ImGui birleştiğinde, oyun nesnelerinin durumunu gerçek zamanlı görselleştirmek mümkün oluyor
  • Gerektiğinde amaca uygun harici araçlarla kendi araçlarımı birlikte kullanıyorum

Çapraz platform ve konsola taşıma

  • Geçmişte konsola taşıma sorunları yüzünden C++ seçmek neredeyse zorunluydu; ancak C# Native-AOT ile bu sorun büyük ölçüde çözüldü
  • FNA gibi açık kaynak framework'lerde konsol desteği aktif biçimde genişletiliyor
  • SDL3'ün sunduğu genel amaçlı abstraction katmanı kullanıldığında, çoğu sistemde aynı kod tabanı işletilebiliyor

Geliştirme ortamı: Linux merkezli açık ekosistem

  • Ana geliştirme platformumu Linux'a taşıdım; açık kaynak toolchain ile uyumu çok iyi
  • Hâlâ belirli ticari yazılımlarla bağlantılar var (ör. vscode, github), ancak açık kaynak ekosistemi büyüdükçe destek de genişliyor
  • Kişisel olarak Steam Deck gibi çeşitli Linux tabanlı platformlarda aynı çalışma ortamını kuruyorum

Ek Soru-Cevap ve örnekler

  • Godot kullanımı sorusu: Geliştirme ihtiyacı açık kaynak motor odaklıysa Godot öneriliyor; bunun dışında tercih özel araçlardan yana
  • 3D çalışma: Büyük motorların avantajları var, ancak küçük ve özel odaklı projelerde özelleştirilmiş framework yeterli olabilir
  • Yüksek performans gerektiren teknoloji ihtiyaçları: Gereksinim düzeyine göre Unreal gibi büyük motorları kullanmak da gayet uygun
  • Ekip olarak motor değiştirme: Küçük ekipler veya tek kişilik geliştirme için uygun; ayrıca orta ve büyük stüdyolarda da uzun vadeli riskten kaçınma nedeniyle özel motora geçiş örnekleri artıyor
  • Asset workflow: Aseprite dosyaları, yerleşik tag'ler ve zamanlama kullanılarak otomatik olarak animasyona dönüştürülebilir

Sonuç

  • Ticari oyun motoru olmadan oyun yapmak, tercih ve çalışma biçimine bağlı bir seçimdir
  • İhtiyaçlarınızı ve eğlenceyi önceliklendirerek size en uygun yöntemi seçebilirsiniz

İlgili okumalar

5 yorum

 
assembler 2025-05-29

Güzel bir çalışma.
Ben birinci nesil oyun geliştiricilerindendim.
Unreal çıkmadan önce elbette geliştirici şirketler için
engine geliştirmek olağandı
ve bu aynı zamanda rekabet gücüydü.
Engine geliştirmede çekirdek, kernel, rendering ve diğer girdi/çıktılar
temelinde araç geliştirme işin büyük kısmını oluşturuyordu.
Ben o zamanlar particle, sound, layer ve object araçlarından
sorumluydum; ekip 7 kişiydi ama kabaca toplandığında sayının 20'yi rahatça geçtiğini sanıyorum.

Bir noktadan sonra Unreal çıkıp seri üretim oyunlar
ortaya dökülünce artık engine geliştirmeye yatırım yapmadılar.
Sanırım o dönemde birçok kişi bağımsızlaşıp kendi şirketini kurdu.
Meğer bunun üzerinden 27 yıl geçmiş.

Ben de yaş aldım ve artık oyun değil başka işlerle uğraşıyorum.

Ekran kartına göre directx ve opengl modları için
çekirdek işleri yaptığım o buruk günler aklıma geliyor.

Gambare...
 
chanapple 2025-05-21

Son zamanlarda strateji oyunu yapmak için uzun süre bir motor arıyordum; böyle olacaksa birini doğrudan kendim yapmanın daha iyi olacağını düşünmüştüm. Bunu gerçekten uygulayıp başarılı olan bir örnek görünce insanın içine cesaret doluyor.
 
GN⁺ 2025-05-21
Hacker News görüşleri

  • 5 yıl boyunca tek başıma 2D bir oyun motoru geliştirip bununla ilgili ücretli işler yaparken, insanların pek bilmediği önemli bir noktayı anlatmak istiyorum
    Motor işin kolay kısmı
    Asıl önemli olan, motorun etrafındaki araçlar, içerik ve asset pipeline
    Farklı veri kaynakları ve formatlardan texture, ses, model dosyaları (gltf, fbx, animasyon vb.) içe aktarma
    Editör uygulamasında kesme, kopyalama, yapıştırma, geri alma, yineleme, kaydetme, silme gibi temel düzenleme işlevleri
    Geliştiricinin editörle gerçek veriyi oluşturup değiştirebilmesini sağlayan görselleştirmeler ve özellikler (entity, animasyon, scene, audio graph, scripting desteği vb.)
    Statik geometri baking, shader derleme, texture/ses yeniden örnekleme ve paketleme, oyun içeriği asset pack oluşturma gibi veri paketleme ve ön işleme süreçleri
    Bütün bunlar bittikten sonra, gerçek runtime kısmı (yani oyunun main loop'u ve alt sistemleri) tüm sistemin küçük bir bölümünü oluşturuyor
    Bu yüzden oyun stüdyolarında motorla ilgilenenlerin sayısı az, araç geliştiren programcıların sayısı ise çoktur
    detonator motoru: https://github.com/ensisoft/detonator

    • Genel amaçlı olmaktan ziyade kendi oyunuma uygun bir motor yapmaya odaklanmanın önemli olduğunu düşünüyorum
      UI, sıkıştırma gibi şeyler kütüphane ve framework'lerle çözülebilir
      OP'nin imGUI gibi küçük kütüphaneler kullanması da buna iyi bir örnek
      Tüm oyunlar için bir motor yapmadığınız için, aslında yapmanıza gerek olmayan çok şey ortadan kalkıyor

    • Motor, asset pipeline'a bağlı küçük bir runtime eklentisi gibi
      Bugünlerde shader derleyiciler bile 3D API'lerden giderek daha önemli hale geliyor
      İlginç kısım shader derleyicide yoğunlaşıyor; 3D API ise shader çalıştırma ve veri taşıma rolüne indirgeniyor

    • İnsanlar "motor" derken çoğu zaman asset pipeline'ı ve editörü de bunun içine katıyor
      Günümüzün motorları sadece main loop + 3D API fonksiyonlarından ibaret değil
      Unity gibi bir motor kullandığında yalnızca render kodu yazan geliştirici sayısı çok az
      Elbette Unity/Unreal kullanmak, hiç asset aracı kullanmayacağınız anlamına da gelmiyor

    • Yakın zamanda devam oyunu için motoru baştan yazarken buna çok katıldım
      Postmortem'de de yazdığım gibi, çoğu insan motor denince oyunun çalıştırılabilir dosyasına giren kodu düşünüyor ama pratikte oyunun kendisiyle birlikte dağıtılmayan kodun — seviye editörü, içerik pipeline'ı, hata ayıklama/profiling, geliştirme iş akışı gibi — payı çok daha büyük
      Araç geliştirme, motor geliştirmeden daha sıkıcı ve daha kolay yıpratıcı bir iş
      Bu yüzden birçok özel oyun motoru projesi yarıda kalıyor
      Postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • En baştan editör yapmak oldukça büyük bir iş
      Mümkünse mevcut editörleri kullanıyorum
      Örneğin TrenchBroom (Quake editörü) + func_godot kombinasyonu, 2D tarafında ise Tiled
      Oyun verisi yönetimi için CastleDB de vardı ama artık Hide (tam teşekküllü bir 3D editör) ile entegre durumda
      Araçları yaptıktan sonra oyunu tasarlamak ve içerik üretmek de başlı başına önemli bir aşama

  • Birkaç yıl önce SDL2 ve biraz C++ ile basit bir "sprite" sınıfı yapıp collision gibi birkaç temel özellik eklemiştim
    Buna illa motor diyeceksek, daha çok elektrikli bisiklet desteği gibi bir şeydi
    "Motor"un sık sık projeyi/oyunun tamamını yönlendiren şeye dönüşmesi önemli bir nokta
    Oyunları motorlara uydurmak zorunda kalmamak için Unity gibi büyük motorlardan hep kaçınıyorum
    Bunlar sonunda hep aynı oyun yapısını üretiyor, değişen sadece varlıklar oluyor
    Bence motor öğrenmeye zaman harcamaktansa, SDL ile çok daha kısa bir öğrenme eğrisiyle başlanabiliyor ve SDL oyun dışındaki çapraz platform projelerde de işe yarıyor
    Benim oyunum: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • Kendi motorunu yapmanın uzun sürdüğü söyleniyor ama Unreal ya da Unity'yi fikirleri doğrudan oyuna çevirebilecek kadar iyi öğrenmek de ne kadar sürüyor diye sormak lazım
    Sonuçta kendi motorumu tamamladığımda tam da o seviyede uzmanlığa sahip oluyorum, yani uzun vadede zaman kazandırıyor
    Mühendislik kariyeriniz ilerledikçe, zamanı düşününce kendiniz yapmanın avantajı artıyor
    Oyun ne kadar sıra dışı ya da nişse, kendiniz yapmanız o kadar mantıklı
    Unreal'in karmaşık arayüzünde aylar kaybedip en başta istediğiniz şeyin genel amaçlı bir motorda neredeyse imkansız olduğunu anlamak verimsiz bir deneyim
    Öte yandan, sürrealist bir open-world RPG yapıyorsanız her şeyi kendiniz üretmek iyi bir tercih değil
    Özel motorların kısıtları bazen yaratıcılığı tetikliyor ve en üst düzeyde olmasa bile daha özgün oyunlar ortaya çıkıyor

    • Kendim de bir motor yaptım
      Başta sayısız deneme-yanılma ve çıkmazla karşılaştım, yaklaşık 1 yılımı aldı
      3D rendering, uyarlanabilir UI, skeletal animation, save dosyaları, smart object'ler, pathfinding, scripting, ses, fizik gibi oyunda görebileceğiniz neredeyse tüm alt sistemleri yazdım
      Özellikle geri sarma özelliğini (Braid'deki sistem gibi) kendim uyguladım
      Böyle bir özellik motorun tüm alt sistemlerinden (script, fizik vb.) destek gerektiriyor
      Kendi motorumun her parçasını bildiğim için yeni özellik geliştirirken inanılmaz bir özgürlüğüm var
      Ama 1 yıl geliştirdikten sonra giderek tükendim ve motivasyonumu kaybettim

    • Unreal'i bilmiyorum ama Unity ile geliştirme, elle kod yazmaya kıyasla 10 kattan fazla daha hızlı olabiliyor
      Fizik özelliğini 1 dakikada ekleyebilirsiniz ama kendi motorunuzda dış kütüphane entegre etmek bile bir iki gün sürebilir
      Unreal kullanıcısı Noel'in gösterdiği dahili görselleştirme özellikleri Unity'de de yerleşik
      Bounding box düzenleme gibi şeyler de varsayılan olarak geliyor
      Motorun temel davranışı yetmiyorsa, ImGui ya da Yoga tabanlı bir CSS motoruyla kolayca genişletebilirsiniz
      Gelişmiş particle editörü, karmaşıklığı gizlenmiş shader'lar, modüler veri akışı gibi sayısız özellik sunuluyor
      Teoride hepsini kendim yapmak isterim ama pratikte önce bitirmek gerekiyor

    • Unreal ya da Unity'yi öğrenip oyun fikrini hemen hayata geçirmek için gereken süre ile, kendi motorunu yazmak için gereken süre aynı soru değil
      Küçük bir fikir verin, birkaç saat içinde oynanabilir bir prototip çıkarılabilir
      Unity'de başlangıçta sadece biraz programlama yeterli; Unreal'de ise yalnızca Blueprint ile bile neredeyse çıkışa yakın aşamaya kadar gidebilirsiniz
      10 dakikada Super Hexagon tarzı bir oyun prototipi yapan videoya bakın: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      Unity'ye özgü tek belirgin unsur prefab'lar; geri kalanı genel oyun geliştirme kavramları
      Unreal geliştiricisiyseniz, Unity'de de 1 saatten kısa sürede benzer bir prototip çıkarabilirsiniz

    • "Motor tamamlandıktan sonra" varsayımı başlı başına gerçekçi olmayabilir
      GameObject.Instantiate gibi basit görünen bir davranışı bile bir motorda kendiniz uygulamak için muazzam kaynak gerekir
      2D/3D fizik, shader'lar, platform desteği gibi karmaşıklıkları düşünün
      Hedefiniz motorsa motor yapın; amacınız oyunsa oyunu yapın görüşündeyim

    • Bir oyun motoru yazacak kadar oyun geliştirme bilginiz varsa
      Unreal ya da Unity'yi öğrenip bir prototip çıkarmak için bir gün yeter
      Tam ustalık uzun sürer ama istediğiniz oyun prototipini ortaya çıkarma süresiyle kıyas kabul etmez

  • "Her şeyi yapan" büyük motorlar olmadan da oyun yapmak daha kolay, daha eğlenceli ve bazen daha verimli
    Ama motorun belli bir özelliğine (örneğin Unreal'in inverse kinematics'i ya da animasyon blending'i) derinlemesine girmeye başlayınca, "iyi ki bunu 2-3 haftada kendim yazmak zorunda kalmamışım" diye düşünüyorsunuz
    Minimalizm ya da şişmeyi önlemek önemli ama bu motorlar ağır işi üstlendikleri için popüler

    • Eskiden ben de böyleydim
      İlk 3D oyunumu yaparken input, nesne yönetimi, culling, model yükleme, matematik kütüphanesi, grafikler, normal map, SSAA gibi her şeyi kendim yazdım ama oyunun tamamlanma oranı %0 kaldı
      Yine de hobi amaçlı 2D projelerde hâlâ sadece tarayıcı canvas'ı ile, bağımlılıksız geliştiriyorum
      Aslında burada motor görevini tarayıcının kendisi görüyor

    • "İyi ki kendim yapmamışım" görüşüne karşı
      Uzun vadede bir bağımsız geliştirici kariyerini düşünüyorsanız, birkaç hafta sürse bile konuyu derinlemesine anlamak ve kaynak kodunun %100'üne sahip olmak ve bunu tekrar kullanabilmek daha değerli

    • Benim bitirme tezim, NeXTSTEP/Objective-C tabanlı bir particle motorunu Windows 95/Visual C++ tarafına taşımakla ilgiliydi (OpenGL tabanlıydı, marching cubes örneği de vardı)
      Böyle şeyler bugün motorlarda neredeyse tek satırlık özelliklerin bir parçası haline geldi

    • Motor kullanınca proje çok daha hızlı ilerliyor ve altyapı geliştirmeye zaman harcamak gerekmiyor
      Tekerleği yeniden icat etmek çoğu insan için o kadar da eğlenceli değil

    • Inverse kinematics ya da animasyon blending gibi özellikler
      Eğer oyununuzun merkezindeyse uygulamaya değer; değilse gereksiz bir teknik tuzak

  • Lua ve Love2D ile, tamamen kendi tarzımda oyunlar yapıyorum
    Kendime bilinçli kısıtlar koymak işin eğlencesinin büyük parçası
    Geliştirme eğlenceli olmaktan çıktıysa, bu bir şeylerin yanlış gittiğinin işaretidir; o zaman daha iyi bir yöntem ararım
    Oyunum YOYOZO sadece 39KB ama Ars Technica'nın 2023'ün en iyi oyunları listesinde büyük yapımların yanında yer aldı
    https://news.ycombinator.com/item?id=38372936

    • O oyunu hatırlıyorum
      Playdate'i aldıktan yıllar sonra SDK'sıyla uğraşmaya başladım, Lua'yı da ilk kez öğreniyorum
      Güçlü tiplendirme ve dil güvenliği isterdim ama eldeki iş için yeterli
      Şimdilik yaptığım tek şey, crank'e göre sahte 3D uzayda dönen metinlerden oluşan küçük bir teknik demo
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      Bu projeyi yaparken, eski CRUD/web app kariyerim yüzünden trigonometriyi neredeyse tamamen unuttuğumu fark ettim
      Playdate geliştirmenin en güzel yanı, sabit bir canvas olması sayesinde piksel konumlarını bir kez ayarlayınca her cihazda aynen çalışması
      Önceki geliştirme kariyerimde hep responsive UI yaptığım için bu deneyim bana çok taze geldi

  • Bir oyun motoruyla (Godot, Unity, Unreal vb.) bir şey yapmaya çalıştığımda hep motorla boğuşuyormuşum gibi geliyor
    Sonunda sanki önceden belirlenmiş bir oyun biçimine asset yerleştiriyormuşsunuz gibi oluyor ve istediğim oyunu yapmak zorlaşıyor
    Web geliştirmeye benzetirsek, WordPress gibi hazır paket bir çözüm hissi veriyor
    Varsayılan yapı niyetinizle örtüşmediğinde, çok büyük hack'ler ve dolambaçlı çözümler gerekiyor

  • Yazar (Noel), Celeste adlı oyunun geliştiricisidir ve oyun 3 milyondan fazla satmıştır
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • Ben de büyük ölçüde katılıyorum ve kod odaklı bir C# oyun framework'ü geliştiriyorum (XNA/Monogame'in manevi halefi, SDL yerine Sokol kullanıyor)
    https://zinc.graphics/
    Modern C#'ın güçlü yönleri: çapraz platform, NativeAOT derleme, native hot reloading, reflection vb.
    Ben şahsen source generator desteği de ekledim
    Geçmişten gelen olumsuz algılar var ama son 5 yılda CoreCLR ve dil tarafındaki gelişim gerçekten etkileyici
    Tek dileğim Union Types; şu anda öneri aşamasında ve gelecek yıl eklenmesini umuyorum
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • Böyle bir proje için C# öğrenmeye başlamak isteyenlere yönelik kaynaklar olup olmadığını merak ediyorum
      C#'ı yalnızca Win32 ya da Unity içinde kullandım; C/C++ tarafında düşük seviye motor bilgim var ama C#'ın oyun konsolları gibi çapraz platform alanlarda mümkün olmadığını sanıyordum
      Artık bunun yanlış olduğunu fark ediyorum

  • Her tür yazılımda başlangıçta her şeyi sıfırdan yapmayı tercih ederim
    Büyük proje deneyimi olan birine bu yavaş gelebilir ama startup aşamasında aslında daha hızlıdır
    Sadece gereken minimumu uygularsınız; soyutlamalar oturduktan sonra yeni özellik ekleme hızı daha da artar
    Kurumsal ölçekte büyük yazılımla, kendi yazdığım küçük motorun üretkenliği tamamen farklı
    Kendi yazdığım kodu kesip biçmek, yeniden düzenlemek çok daha kolay olduğu için çok daha hızlı ilerliyorum
    Bu yüzden mikroservisleri ve küçük ekipleri seviyorum
    Kendiniz yaptığınızda, deneme-yanılma ve her an patlayabilecek bir mayın tarlasından geçmek zorundasınız; ayrıca dilin ya da platformun gerçek karakterini öğrenmek de yıllar alıyor
    Ama sonuçta bütün bu süreç geliştiricinin gerçek birikimine dönüşüyor
 
kissdesty 2025-06-10

Motor yerine MonoGame düzeyinde bir framework kullanmak nasıl olur diye merak ediyorum~
 
lazyhack 2025-05-23

"O sürecin kendisi en nihayetinde geliştiricinin birikimi olarak kalıyor" sözüne kesinlikle katılıyorum.