Pong – Devlog 1: Projeye Başlama

JAG (Just Another Game) serisi aslında bir kaç yıldır aklımda olan bir projeydi. Bu proje ile oyunlarda karşımıza çıkan temel özellikleri (features) kodlayabilecek, meraklılarına bu kodları rehber olarak paylaşacaktım. Fakat hem yoğunluk hem de başka projeler nedeniyle sürekli erteledim durdum. Geçtiğimiz hafta artık bu beklemeye bir dur dedim. Önce proje konseptlerini belirledim, bir iş planı hazırladım. Ardından serinin ilk projesinin startını verdim: Pong.

Arkadaşım Tolga’yı aradığımda proje hakkında, kafamdaki taşlar yerine oturmuştu. Pong oyun dünyasındaki en ikonik oyunlardan biriydi. Böyle bir öğrenim/paylaşım sürecinde de benim amacıma fazlasıyla hizmet ediyordu.

Proje bir kere piyasadaki diğer kodlama rehberlerinden farklı olmalıydı. O yüzden piyasada olan tonlarca kodlama rehberlerinde en çok rahatsız olduğum şeyi yapmamaya karar verdim: Basit bir oyun versiyonu ya da oyunun bir parçasını yapmak yerine içimin sineceği ve tamamlanmış bir oyun yapmak istedim. Meraklılarına da bu süreci bütün yönleriyle anlatmak istedim.

Pong oyunu binlerce kere yapılmıştı zaten. Onun için kendimden bir şeyler katmak da istedim. Bunun için aşağıdaki özellikleri de ekledim:

1. Oyun bir kere 3D olacak,
2. Oyunda birden fazla bölüm olacak ve her bölümün ayrı bir özelliği olacak,
3. Oyuncular power-uplar kazanabilecek ve bunu oyunda kullanabilecek,
4. Aynı anda birden fazla kişi oynayabilecek (Projeyi basit tutmak adına network özelliği koymadım. Sadece tek klavyede aynı anda iki kişi oynayabilecek)
5. Oyun sonuçları leaderboardda kaydedilebilecek.

Yukarıda bahsettiğim özellikler konsept aşamasının aslında ilk basamağı. Bu ortaya çıktığında, proje ekibi fikirleri net bir şekilde tartışabilir. Bunun aksi “abi bir fikrim var” kuru gültüsünden başka bir şey değil. Lütfen sen de bu kalabalıktan biri olma.

Konsept aşamasında ikinci bir konu ise istediğin özelliklerin gerçekçiliği. Burada 4. maddeye dikkatini çekmek istiyorum. Network tabanlı bir multiplayer bu proje için makul bir özellik değil – en azından benim açımdan. Niye diye sorarsan?

1. Ben çok fazla (dürüst olalım 20’den fazla) kişinin bu oyunu oynamasını beklemiyorum, herhangi bir gelir getirmeyecek bu projede hosting maliyetini yüklenmek mantıklı değil.
2. İkincisi bu projede temel oyun özelliklerine odaklanarak kapsamını düşük tutmak istiyorum. Burada aslında benlik önemli bir faktör var: Ben 5 hafta içinde bu oyuna 30 saatten daha fazla vakit ayırabileceğimden emin değilim. O yüzden yarım yamalak bir feature creep oyun olması yerine yapmak istediği şeyi iyi bir şekilde yapan bir oyun yapmak benim için daha değerli.
3. Kısıtlı zamanda power-up ve çoklu bölüm tasarımları benim için daha önemli özellilkler.

Konsept aşaması için 3 – 5 kelam ettikten sonra artık proje planlamasına geçebiliriz. Yalnız buraya kadar geldiysen okuyucu senden bir ricam olacak. Lütfen yaptığım işleri eleştir ve kendimi geliştirmem noktasında yanımda ol. “Ellerine sağlık, güzel olmuş” yorum ve maillerindense acımasız da olsa bir eleştiri benim bu süreçteki en büyük yardımcım olacaktır. En azından neyi düzeltmem gerektiğini göreceğim. Kısaca eleştirini benden esirgeme, hakaret olmadığı sürece hepsi başımın tacıdır.

Proje Ekibi ve Yönetimi

Proje ekibimiz küçük, iki kişilik: Ben ve Tolga. Benim 3 yıllık bir Unity ve C# tecrübem olmasına rağmen bugüne kadar hep ekip üyesi olarak projelerde bulundum. Bu benim ilk yönettiğim (Konsept aşamasında beklettiğimiz bir RTS oyununu saymazsam) proje olacak – aslında basit bir konsept seçmemdeki en önemli gerekçe bu. Tolga ise PHP odaklı pek çok proje dışında öncesinde Unity tecrübesi var. Bu projede de bana destek olacak.

Proje yönetimi açısından çok temel bir yaklaşım sergilemeyi planlıyorum. Projede Agile Scrum metodolojisinin modifiye/sade bir metodunu burada kullanacağım. Kısaca:

1. Yapılacak her şey önem ve yapılma sırasına göre listelenecek,
   • İş kalemleri, tahmini yapılma süresi ile eklenecek
   • İş kalemlerinin ufak bir özeti/açıklaması eklenecek
2. Proje ekibi iş listesinden bir/bir kaç kalemi üzerine alıp hafta sonuna kadar tamamlayacak,
3. Çarşamba günü iş durumu için ekip arkadaşları takip edilecek,
4. Cumartesi günü yapılan katkılar incelenecek
   • Onaylanan işler “Yapılacak İş Listesi”nden çıkarılacak
   • Düzeltme gereken işlerin açıklaması güncellenerek “Yapılacak İş Listesi”ne eklenecek
5. Pazar günü iş listesi güncellenecek ve devlog yazılacak.

Normalde Scrum metodolojisi müşteri, ürün sahibi, scrum uzmanı, scrum ekibi gibi pek çok paydaştan ve çok daha kompleks bir yapıdan oluşuyor. Burada sadece ikimiz olduğu için oradaki süreçlerin pek çoğunu iptal ettik. İhtiyaçlarımızı karşılamak adına da proje takibi için Trello’yu, kodların paylaşımı için Unity Teams’i kullanacağız.

Trello Sayfasına ulaşmak için linke tıklayınız.

GDD Belgesi

GDD, yani namı diğer Oyun Tasarım Dökümanı… Tüm oyun fikirlerinin tartışıldığı ve planlama aşaması yapıldığında ilk hazırlanan belgedir. Normalde büyük oyunlarda yüzlerce sayfadan oluşan bu dokümanı proje disiplinini sağlamak için bu projede kullanmak istedim. Bir kaç sayfalık bir belge bizim işimizi fazlasıyla görecektir.

Bu belgenin nasıl hazırlanacağını anlatan uzun rehberler internette mevcut. Belki birgün türkçe bir rehber yazabilirim bu konu hakkında (konuya yeterince hakim olduğuma ikna olursam eğer). Oyun tarzına göre yapısı çok değişen bu belgede biz aşağıdaki başlıkları dolduracağım:

1. Giriş
   1. Genre
   2. Hedef Kitle(ler)
   3. Hedef Platform(lar)
   4. Tema
   5. Teknik Altyapı
   6. Oyun Özeti
2. Genel Değerlendirme
   1. Referans Oyunlar
   2. Temel Oyun Mekanikleri
      1. İnput Sistemi
      2. Oyun Fiziği
      3. Yapay Zeka
      4. Leaderboard
      5. Power-up
      6. Çoklu Bölüm
      7. Çoklu Oyuncu
   3. Temel Oyun Döngüsü
   4. Kod Mimarisi
   5. Alternatif Mekanikler
3. Kullanıcı Ara Yüzü / Ekranlar Tasarımı
4. Bölüm Tasarımı
5. Asset Listesi
   1. Oyun Objeleri
   2. Material
   3. Grafik Ara Yüz
   4. Partikül FX
   5. Sesler

GDD belgesine ulaşmak için linke tıklayınız.

Oyunun Miro sayfasına ulaşmak için linke tıklayınız.