3D Unity Game3B Unity Oyunu

Multiplayer Space Shooter GameÇok Oyunculu Uzay Savaş Oyunu

A 3D multiplayer game where you control a space ship in a procedurally generated star system to capture hostile space stations orbiting planets.Prosedürel üretilen bir yıldız sisteminde uzay gemisi kullandığınız ve gezegenlerin yörüngesindeki düşman istasyonlarını ele geçirdiğiniz çok oyunculu bir oyun.

Building a Multiplayer Space Shooter With Procedural Systems and AI Agents

This project was my senior project, developed as a multiplayer space shooter game in Unity. The idea was to combine several systems I was interested in: procedural generation, real-time multiplayer architecture, spaceship controls, and reinforcement learning agents.

The game takes place in a procedurally generated star system where two factions fight over control of a Dyson Sphere. Players can freely travel through the system, encounter enemies, capture hostile space bases, upgrade their ships, and eventually attack the Dyson Sphere to win the game.

Starting With the Game Concept

The core idea was to create a space action game where players could explore a different star system each time they played. I wanted the game to include both structured objectives and open movement, so the player would not only fight enemies but also move through a larger generated world.

The main gameplay loop was built around:

  • Exploring the star system
  • Encountering enemy ships
  • Fighting or escaping from battles
  • Collecting ship parts
  • Capturing space bases
  • Upgrading the player ship
  • Attacking and defending the Dyson Sphere

This gave the project a larger structure than a simple combat prototype. It needed a map system, events, player progression, multiplayer synchronization, and enemy behavior.

Game loop state diagram

Procedural Star System

The map was generated before players entered the game. Instead of using a fixed level, the game created a random star system from configuration values.

The system could generate planets, orbits, asteroid areas, space bases, and the central Dyson Sphere objective. Planet and asteroid meshes were created procedurally by generating a sphere and then modifying its surface with Perlin Noise. This helped create more natural-looking planets and asteroid shapes instead of using only simple geometric primitives.

General structure diagram

Multiplayer Architecture

A major part of the project was the multiplayer system. We chose a server-authoritative architecture, where the server controls the main game state and clients send player inputs to it.

This was important because multiplayer games need consistency. If every client decides the game state independently, cheating and desynchronization become much easier. In a server-authoritative setup, the server becomes the trusted source for movement, actions, events, and updates.

To organize the system, we divided the game into manager classes:

  • Game Manager for general game state
  • Map Manager for generated map data
  • CTF Manager for capture events
  • Event Manager for encounters and asteroid events
  • AI Manager for computer-controlled ships
  • Upgrade Manager for player ship upgrades
  • Player objects for controlled ships

This helped separate responsibilities and made the project easier to reason about as it grew.

General structure diagram

Capture Events and Game Objectives

One of the main gameplay systems was a capture-the-flag-style event structure. There were two types of capture zones: hostile space bases around planets and the Dyson Sphere at the center of the system.

When players entered a capture zone, enemy ships would try to prevent them from staying inside the area long enough. If players captured a space base, they could land there and upgrade their ships. If they attacked the Dyson Sphere, they had to survive a larger endgame-style objective.

This gave the game a clearer sense of progression. The player was not only flying and shooting, but also fighting for control of important locations in the star system.

Spaceship Controls and Combat

The player controlled a spaceship using keyboard and mouse input. The controls were designed to create a space-flight feeling, with movement, rolling, aiming, and shooting separated into different inputs.

One feature I liked was the camera mode switch. Since aiming while flying can be difficult, the game included both a drive mode and an aim mode. In aim mode, the camera moved closer and allowed the player to aim weapons more carefully while the ship rotation was locked.

We also built the ship models ourselves using Unity ProBuilder, because available free assets did not match the needs of the project. Particle systems were used for thrusters and projectiles because they were more efficient and visually readable for weapon effects.

Training AI Agents With PPO

The AI part of the project focused on training enemy ships using reinforcement learning. We used Unity ML-Agents and the PPO algorithm to train intelligent agents for space combat.

The AI problem was divided into two parts:

  1. Weapon agent Responsible for aiming the weapon and deciding when to shoot.

  2. Movement agent Responsible for moving the ship into a useful combat position while keeping a safe distance from the target.

Splitting the problem made it more manageable. Instead of expecting one agent to learn everything at once, each agent had a clearer responsibility.

Weapon Agent Experiments

The weapon agent was trained to rotate toward a target and fire accurately. I experimented with two different targeting approaches.

The first version controlled the weapon by changing yaw and pitch values directly. It improved over time, but it struggled when the correct target direction was far away because the agent had to learn how to rotate gradually toward it.

The second version worked differently. Instead of rotating the gun step by step, the agent selected a point on a camera view, and the system converted that point into a target direction. This made the action space more natural for aiming.

After training, the second approach performed much better. In the training environment, the weapon agent was able to hit randomly appearing moving targets at a strong level.

General structure diagram

Movement Agent

The movement agent was trained to keep a useful combat position. Its goal was to stay at a safe distance from the target while turning the ship in a way that gave the weapon agent a better shooting angle.

The agent learned to navigate around the target and orient the ship properly, but it still had limitations. It was not trained to dodge projectiles or perform highly mobile chase-and-escape behavior. That made it promising as a prototype, but not yet a complete combat pilot.

Training vs. Real Gameplay

One of the biggest lessons came from moving the trained agents from the training scene into the real game environment.

The weapon agent worked well in the controlled training environment, but its performance dropped in the full game. The main reason was scale. In the training setup, targets appeared within a smaller range. In the game environment, battles could happen over much larger distances, which changed the conditions the agent had learned from.

This taught me that training an agent is not only about getting good results in a test scene. The training environment has to match the real gameplay situation closely enough, or the agent may fail to generalize.

What I Learned

This project helped me understand how different game systems connect inside a larger Unity project. It was not only about gameplay, AI, networking, or procedural generation separately. The difficult part was making all of them work together.

I learned more about:

  • Designing a multiplayer game around server authority
  • Structuring gameplay systems with managers
  • Creating procedural planets and asteroid events
  • Building spaceship controls and camera modes
  • Training Unity ML-Agents with PPO
  • Separating AI behavior into smaller learning problems
  • Evaluating the gap between training performance and gameplay performance

Final Thoughts

This project was one of my most ambitious student projects because it combined many technical areas at once. Some systems worked better than others, and the AI agents still had clear limitations, but the project gave me a much stronger understanding of how complex game prototypes are built.

Looking back, the most valuable part was seeing how procedural generation, multiplayer architecture, and machine learning can all exist inside the same playable game. It showed me the kind of technical game development problems I enjoy working on: systems that are interactive, visual, and difficult enough to require experimentation.

Prosedürel Sistemler ve Yapay Zeka Ajanlarıyla Çok Oyunculu Bir Uzay Savaş Oyunu Geliştirmek

Bu proje, Unity ile iki kişi geliştirdiğimiz çok oyunculu bir uzay savaş oyunu ve aynı zamanda bitirme projemizdi. Amacımız; prosedürel üretim, gerçek zamanlı çok oyunculu mimari, uzay gemisi kontrolleri ve pekiştirmeli öğrenme ajanları gibi ilgilendiğim çeşitli sistemleri tek bir projede bir araya getirmekti.

Oyun, tasarımımıza göre iki grubun bir Dyson Küresi’nin kontrolü için savaştığı prosedürel olarak oluşturulan bir yıldız sisteminde geçiyordu. Oyuncular sistem içinde serbestçe hareket edebiliyor, düşmanlarla karşılaşabiliyor, düşman uzay üslerini ele geçirebiliyor, gemilerini geliştirebiliyor ve sonunda oyunu kazanmak için Dyson Küresi’ne saldırabiliyordu.

Oyun Konsepti

Temel fikir, oyuncuların her oynayışta farklı bir yıldız sistemini keşfedebileceği bir uzay aksiyon oyunu oluşturmaktı. Oyunda hem belirli hedeflerin hem de serbest hareket imkanının bulunmasını istiyordum. Böylece oyuncu yalnızca düşmanlarla savaşmayacak, aynı zamanda daha büyük ve prosedürel olarak oluşturulan bir dünyada hareket edecekti.

Ana oynanış döngüsü şu adımlardan oluşuyordu:

  • Yıldız sistemini keşfetmek
  • Düşman gemileriyle karşılaşmak
  • Savaşmak veya çatışmalardan kaçmak
  • Gemi parçaları toplamak
  • Uzay üslerini ele geçirmek
  • Oyuncunun gemisini geliştirmek
  • Dyson Küresi’ne saldırmak ve onu savunmak

Bu yapı bize, harita, yıldız sistemindeki olaylar, oyuncu gelişimi, çok oyunculu senkronizasyon ve düşman davranışları için ayrı sistemler geliştirmemiz gerektiğini gösterdi.

Oynanış döngüsü durum diyagramı

Prosedürel Yıldız Sistemi

Harita, oyuncular oyuna girmeden önce oluşturuluyordu. Önceden hazırlanmış, sabit bir harita kullanmak yerine oyun, belirlenen konfigürasyon değerlerine göre rastgele bir yıldız sistemi üretiyordu.

Geliştirdiğim harita üretim sistemi; farklı gezegenler, yörüngeler, asteroit bölgeleri, uzay üsleri ve merkezde bulunan Dyson Küresi hedefini oluşturabiliyordu. Gezegen ve asteroit mesh’leri, önce bir küre üretilip ardından yüzeyi Perlin Noise ile değiştirilerek prosedürel olarak hazırlanıyordu. Böylece yalnızca basit geometrik şekiller kullanmak yerine daha doğal görünen gezegenler ve asteroitler elde edilebiliyordu.

Prosedürel yıldız sistemi görünümü

Çok Oyunculu Mimari

Projenin önemli bölümlerinden biri çok oyunculu sistemdi. Ana oyun durumunun sunucu tarafından kontrol edildiği ve istemcilerin oyuncu girdilerini sunucuya gönderdiği, sunucu otoriteli bir mimari kullanmayı tercih ettik.

Bu yaklaşım, çok oyunculu oyunlarda tutarlılığın korunması açısından önemliydi. Her istemci oyun durumuna bağımsız olarak karar verdiğinde hile yapmak ve oyuncular arasında senkronizasyon sorunları oluşması çok daha kolay hale gelir. Sunucu otoriteli bir sistemde ise hareketler, eylemler, olaylar ve durum güncellemeleri için güvenilir kaynak sunucudur.

Sistemi düzenlemek için oyunu farklı yönetici sınıflarına ayırdık:

  • Genel oyun durumu için Game Manager
  • Oluşturulan harita verileri için Map Manager
  • Ele geçirme etkinlikleri için CTF Manager
  • Düşman ile karşılaşmalar ve asteroit olayları için Event Manager
  • Bilgisayar kontrollü gemiler için AI Manager
  • Oyuncu gemisi geliştirmeleri için Upgrade Manager
  • Kontrol edilen gemileri temsil eden Player nesneleri

Bu yapı sorumlulukların ayrılmasını sağladı ve proje büyüdükçe sistemi anlamayı ve yönetmeyi kolaylaştırdı.

Oyunun genel sistem yapısı

Ele Geçirme Etkinlikleri ve Oyun Hedefleri

Oyunun temel sistemlerinden biri, bayrak kapmaca benzeri bir ele geçirme yapısıydı. Tasarımda iki tür ele geçirme bölgesi bulunuyordu: gezegenlerin çevresindeki düşman uzay üsleri ve sistemin merkezindeki Dyson Küresi.

Oyuncular bir ele geçirme bölgesine girdiğinde düşman gemileri, yeterince uzun süre bölgede kalmalarını engellemeye çalışıyordu. Bir uzay üssü ele geçirildiğinde oyuncular üsse inerek gemilerini geliştirebiliyordu. Dyson Küresi’ne saldırdıklarında ise oyun sonuna benzer, daha büyük çaplı bir hedef sırasında hayatta kalmaları gerekiyordu.

Bu sistem oyuna daha belirgin bir ilerleme hissi kazandırdı. Oyuncu yıldız sistemindeki önemli bölgelerin kontrolü için savaşıyordu.

Uzay Gemisi Kontrolleri ve Savaş Sistemi

Oyuncu, uzay gemisini klavye ve fare aracılığıyla kontrol ediyordu. Kontroller; hareket, dönüş, nişan alma ve ateş etme eylemlerini farklı girdilere ayırarak uzay uçuşu hissi verecek şekilde tasarlanmıştı.

Beğendiğim özelliklerden biri kamera modu geçişiydi. Uçuş sırasında nişan almak zor olabildiği için oyunda hem sürüş modu hem de nişan alma modu bulunuyordu. Nişan alma modunda kamera gemiye yaklaşıyor, geminin dönüşü kilitleniyor ve oyuncu silahlarını daha hassas şekilde hedefleyebiliyordu.

Projeye uygun ücretsiz modeller bulamadığımız için gemi modellerini Unity ProBuilder kullanarak kendimiz oluşturduk. İtici motor ve mermi efektlerinde ise hem daha verimli hem de görsel açıdan daha anlaşılır oldukları için parçacık sistemlerinden yararlandık.

PPO ile Yapay Zeka Ajanlarını Eğitmek

Projenin yapay zeka bölümü, düşman gemilerinin pekiştirmeli öğrenme kullanılarak eğitilmesine odaklanıyordu. Uzay savaşlarında görev alacak akıllı ajanları eğitmek için Unity ML-Agents kütüphanesini ve PPO algoritmasını kullandık.

Yapay zeka problemini iki parçaya ayırdık:

  1. Silah ajanı Silahı hedefe çevirmekten ve ne zaman ateş edileceğine karar vermekten sorumluydu.

  2. Hareket ajanı Hedefle güvenli bir mesafeyi korurken gemiyi uygun bir savaş konumuna taşımaktan sorumluydu.

Problemi bu şekilde ayırmak eğitim sürecini daha yönetilebilir hâle getirdi. Tek bir ajanın tüm davranışları aynı anda öğrenmesini beklemek yerine her ajana daha belirgin bir sorumluluk verdik.

Silah Ajanı Deneyleri

Silah ajanı, hedefe doğru dönmek ve isabetli şekilde ateş etmek üzere eğitildi. Hedefleme sistemi için iki farklı yaklaşım denedim.

İlk sürümde ajan, yaw ve pitch değerlerini doğrudan değiştirerek silahı kontrol ediyordu. Zaman içinde gelişme gösterse de doğru hedef yönü uzakta olduğunda zorlanıyordu. Bunun nedeni, hedefe ulaşabilmek için silahı adım adım nasıl döndürmesi gerektiğini öğrenmek zorunda olmasıydı.

İkinci sürüm farklı bir şekilde çalışıyordu. Ajan, silahı aşamalı olarak döndürmek yerine kamera görüntüsü üzerinde bir nokta seçiyor, sistem de bu noktayı bir hedef yönüne dönüştürüyordu. Bu yaklaşım, nişan alma işlemi için daha doğal bir eylem uzayı oluşturdu.

Eğitimden sonra ikinci yaklaşım çok daha iyi sonuç verdi. Silah ajanı, eğitim ortamında rastgele beliren hareketli hedeflere yüksek isabet oranıyla ateş edebiliyordu.

Silah ajanının eğitim ortamı

Hareket Ajanı

Hareket ajanı, savaş sırasında avantajlı bir konumu korumak üzere eğitildi. Amacı, hedefle güvenli bir mesafede kalırken silah ajanına daha iyi bir atış açısı sağlayacak şekilde gemiyi yönlendirmekti.

Ajan, hedefin çevresinde hareket etmeyi ve gemiyi uygun şekilde yönlendirmeyi öğrendi ancak bazı sınırlamalara sahipti. Mermilerden kaçmak veya hızlı takip ve geri çekilme manevraları yapmak üzere eğitilmemişti. Bu nedenle prototip olarak umut verici olsa da eksiksiz bir savaş pilotu gibi değildi.

Eğitim Ortamı ve Gerçek Oynanış Arasındaki Fark

En önemli deneyimlerden biri, eğitilen ajanları eğitim sahnesinden gerçek oyun ortamına taşırken ortaya çıktı.

Silah ajanı kontrollü eğitim ortamında iyi çalışıyordu ancak tam oyun ortamındaki performansı düştü. Bunun temel nedeni ölçek farkıydı. Eğitim ortamında hedefler daha dar bir mesafe aralığında ortaya çıkıyordu. Gerçek oyunda ise savaşlar çok daha uzak mesafelerde gerçekleşebiliyor ve bu durum ajanın öğrendiği koşulları değiştiriyordu.

Bu deneyim, bir ajanı eğitmenin yalnızca test sahnesinde iyi sonuçlar almaktan ibaret olmadığını gösterdi. Ajanın öğrendiklerini gerçek oyuna aktarabilmesi için eğitim ortamının gerçek oynanış koşullarına yeterince yakın olması gerekiyordu.

Öğrendiklerim

Bu proje, farklı oyun sistemlerinin daha büyük bir Unity projesi içinde nasıl bir araya geldiğini anlamama yardımcı oldu. Zorluk yalnızca oynanış, yapay zekâ, ağ sistemi veya prosedürel üretim üzerinde ayrı ayrı çalışmak değil, tüm bu sistemlerin birlikte çalışmasını sağlamaktı.

Bu süreçte şu konularda deneyim kazandım:

  • Çok oyunculu bir oyunu sunucu otoritesi etrafında tasarlamak
  • Oynanış sistemlerini yönetici sınıflarıyla yapılandırmak
  • Prosedürel gezegenler ve asteroit etkinlikleri oluşturmak
  • Uzay gemisi kontrolleri ve farklı kamera modları geliştirmek
  • Unity ML-Agents ve PPO ile ajan eğitmek
  • Yapay zekâ davranışlarını daha küçük öğrenme problemlerine ayırmak
  • Eğitim performansıyla gerçek oyun performansı arasındaki farkı değerlendirmek

Son Düşünceler

Bu proje, birçok teknik alanı aynı anda bir araya getirdiği için öğrencilik dönemimde geliştirdiğim en kapsamlı çalışmalardan biriydi. Bazı sistemler diğerlerinden daha iyi sonuç verdi ve yapay zeka ajanlarının belirgin sınırlamaları vardı. Buna rağmen proje, karmaşık oyun prototiplerinin nasıl geliştirildiğine dair çok daha güçlü bir anlayış kazanmamı sağladı.

Geriye dönüp baktığımda en değerli tarafı; prosedürel üretim, çok oyunculu mimari ve makine öğrenmesinin aynı oynanabilir oyun içinde birlikte çalışabildiğini görmekti. Bu proje, üzerinde çalışmaktan keyif aldığım teknik oyun geliştirme problemlerini daha iyi anlamamı sağladı.