Teknik olarak bilgilerin nerede saklanacağına dair bir gereklilik yok. Ancak problem başka yerde:
1. Bütün yazılım yapma süreçleri önce basit başlar sonra zamanla karmaşıklaşmaya, dallanıp budaklanmaya başlar. İşin doğası böyledir. Siz yeni özellikler, işlevler ekledikçe sistemler ve sistemleri kuran kodlar karmaşıklaşır içe içe girmeye, bir birini etkilemeye ve sıkıntı çıkarmaya başlar. Bunlar ilk günlerde değil daha sonraları proje ilerledikçe ortaya çıkar. Bu sadece oyunlar için değil her türlü yazılım projesi için geçerlidir. Yani ister Amazon Web Services ister Android ister IOS olsun, ister chrome programlayın ne yaparsanız yapın doğası gereği her şey karmaşıklaşır. Bu öyle bir noktaya gelebilir ki, sonucunda o hep duyduğunuz iptal edilen oyunlar, yeni versiyonu yapılmayan programlar, daha kötüsü de çıkarıldığı halde bug ları yüzünden hiç alınmayan ürünler ortaya çıkabilir. Yazılım şirketlerinin bir numaralı düşmanı da budur. (Sonunca ya örnek MODO, Oyunlara örnek için google a bakabilirsiniz)
2. Yukarıda anlattığım şeyler yüzünden önce OOP konsepti sonra SOLID prensipleri gibi bir çok kavram ortaya çıkmıştır. İşini önemseyen programcılar bunlara 4 elle sarılırlar. Çoğu profesyonel oyun şirketine bu prensiplere uygun kod yazmıyorsanız almazlar. Kodunuz çalışsa da almazlar. Örneğin ben almıyorum. Bildiklerimden alanı da görmedim.
3. OOP ve SOLID vb. programlama konseptleri ise en başta "single responsibility" yani "tek sorumluluk" ile konuya girerler. Hatta SOLID in başında ki S bile odur. İşlerin mantıklı ve düzgünce parçalanıp sorumluluğun başka başka objelere verilmesi, sistemlerin iç içe geçmesi, birbirine minimum etki etmesi için şarttır. Ancak bu şekilde yazılımcılar artan karmaşıklıkla, projenin arap saçına dönmesiyle başa çıkabilirler. Örneğin bu sayede 10000 inci özellik eklenmesine rağmen halen Maya ayakta ve ayakta olacak, ama Modo çöküyor. Ya da çok karmaşık ve komplex oyunlar piyasaya çıkabiliyor.
4. Profesyonel dünyada alt sistemlerin hep C++ la kurulması, sadece üst sistemlerin ve sürekli değiştirelecek şeylerin BP ye bırakılmasının sebebi de büyük oranda bu. (Başka bir çok faydası da var ama burda konumuz değil)
Şimdi soruna gelecek olursak. Teknik olarak her yere her bilgiyi koyabilirsin. Bu birazda oyunun kapsamına büyüklüğüne bağlı. Bomber man gibi basit oyunlarda her yere koyabilirsin de diyebilirim, ama oyun büyüdükçe neyi nerde tuttuğun daha önem kazanır. Mantıklı yerde olmayan şeyler olayı daha da komplex leştirmeye ve yukarıda saydığım sıkıntılı şeylere götürür.
En baştan Epic Games tüm sistemi dizayn ederken, her class için farklı bir maksat düşünerek ortaya çıkarmış.
Genel olarak:
Karakter: Görsel ve Animasyon temsili, puppet, kukla
PlayerController: Oyunu oynayan kişinin ta kendisi. Bu yüzden net connection, player input, kamera vb.
PlayerState: Oyunu oynayan kişinin datası yani bilgileri. Health, Damage Power, kaç altını olduğu, hangi görevleri bitirmiş olduğu vb.
GameState: Oyuncuya ait değil de herkese ait olan data nın tutulduğu, mesela hangi takım kaç puanda, oyun başlayalı kaç dakika oldu, oyun alanında kalan altın miktarı nedir vb. (Ayrıca tüm PlayerState ler)
GameMode: Oyunun kuralları ve işleyişini yukarıdan belirleyen işlevler içeren class. Mesela Team Death Match mı, single player mı, Free for All mu. Bunlara ait işlevler ve kurallar bütünü
Oyunum komplex olacaksa PlayerState te tutarım canımı. Daha basitse ve sırf bir tane şey için playerstate oluşturmak istemiyorsam PlayerControllera. Oyunum çok çok daha basitse ve hiç bir komplexlik olmayacaksa üçüncü tercih olarak karakter de tutardım. Yani tercih sırası PlayerState -> PlayerController -> PlayerCharacter. Oyunum daha da profesyonel, uzun soluklu ve karmaşık olacaksa PlayerState içinde sırf bu bilgiler için ayrı bir obje de tasarlayabilirdim (GAS sistemindeki Attribute sınıfı gibi)
Tüm bunlar oyunun tarzına da bağlı. Bir RTS için tek bir işçinin canı karakter de durması daha mantıklı olabilir. Bir oyuncunun playerstate inde 250 askerinizin canını tutmaya çalıştığınızı düşünün. Yada karakteri değiştirebildiğimiz bir multiplayer oyunda playercharacter, playercontroller ın bu konuda önüne geçebilir. En başta anlattığım gibi, ana maksat kompleksliği azaltmak, yönetilebilir halde tutmak. Bunlar sağlandığı sürece yukarıda ki bilgiler ışığında karar vermek size kalıyor.
