PlayerPrefs Ne İçin Uygundur, Ne İçin Değildir?

Konu, Amaç ve Beklenen Sonuç

Kalıcı veri ile runtime veri aynı şey değildir. PlayerPrefs küçük kullanıcı tercihlerine uygundur ancak hassas/ekonomik veriyi güvenli saklama sistemi değildir. JSON dosyası yapılandırılmış yerel save için kullanılabilir; dosya yolu, şema sürümü ve bozuk kayıt senaryosu yönetilmelidir. DontDestroyOnLoad ise yalnız nesnenin sahne yüklemelerinde yok edilmemesini sağlar; save sistemi değildir.

Adım Adım Uygulama

1. Adım

1. Veriyi tercih, ilerleme, ekonomi ve geçici oturum verisi olarak sınıflandır; her sınıf için saklama ömrünü belirle.

2. Adım

2. Ses seviyesi veya dil gibi basit tercihleri PlayerPrefs’te tut; coin/ödeme/rekabetçi skor gibi manipülasyona duyarlı veriyi sunucu doğrulaması olmadan güvenilir sayma.

3. Adım

3. JSON save kullanıyorsan seri hale getirilecek DTO/modeli açık tanımla; schemaVersion alanı ekleyerek ileride migration planla.

4. Adım

4. Dosyayı Application.persistentDataPath altında yönet; yazma sırasında yarım dosya riskine karşı geçici dosya + replace gibi atomik yaklaşımları değerlendir.

5. Adım

5. DontDestroyOnLoad manager kullanıyorsan singleton duplicate kontrolü yap; sahnede yeni kopya doğduğunda hangisinin korunacağını açık belirle.

6. Adım

6. Daily Reward gibi tarihe bağlı ekonomide yalnız cihaz saatine güvenmenin saat değiştirme hilesine açık olduğunu kabul et; çevrimiçi sistemde güvenilir sunucu zamanı tercih et.

7. Adım

7. Yeni sürüm, bozuk JSON, eksik alan, ilk kurulum ve uygulama kaldırma/yeniden kurma senaryolarını test et.

Uygulamalı Örnek

Örneğin SettingsSave yalnız musicVolume, sfxVolume ve language tutabilir. ProgressSave ayrı dosyada level/XP bilgisi taşır. Daily Reward çevrimiçiyse backend’in UTC zamanına göre lastClaim kontrolü yapılır; çevrimdışı mod varsa bunun güvenlik sınırlaması kullanıcı deneyimi kararına dahil edilir. Bu örneği kendi projenize uyarlarken değerleri ezberlemek yerine “PlayerPrefs Ne İçin Uygundur, Ne İçin Değildir?” konusundaki aynı neden-sonuç ilişkisini koruyun.

Yaygın Hatalar ve Nedenleri

1. PlayerPrefs’i şifreli ve hileye dayanıklı veritabanı sanmak.

2. DontDestroyOnLoad’u save sistemi sanmak.

3. JSON şema sürümünü hiç planlamamak.

4. Tek dosyayı doğrudan yazarken yarım yazma riskini düşünmemek.

5. Daily Reward’da cihaz saatini tek doğruluk kaynağı yapmak.

Son Kontrol ve Doğrulama

1. Bozuk save dosyasında uygulamanın kontrollü fallback yaptığını dene. Sonuç “PlayerPrefs Ne İçin Uygundur, Ne İçin Değildir?” için somut kabul ölçütü olarak kullanılmalıdır.

2. Eski schemaVersion kaydını yeni sürümde aç.

3. Sahneye geri dönünce duplicate manager oluşmuyor mu kontrol et.

4. Cihaz saatini ileri/geri alarak offline tarih mantığını test et.

5. Ses/dil tercihinin uygulama yeniden açıldığında doğru yüklendiğini doğrula.

Kısa Sonuç

PlayerPrefs Ne İçin Uygundur, Ne İçin Değildir? için kaliteli sonuç, aracı veya ayarı bir kez kullanmaktan değil; doğru sorumluluğu seçip uygulamayı gerçek koşulda doğrulamaktan gelir.

Kaynaklar

Bu makaledeki teknik kavramları doğrulamak ve sürüme bağlı ayrıntıları kontrol etmek için aşağıdaki birincil/resmî kaynaklar kullanılmıştır. Yazılım arayüzleri ve platform gereksinimleri zamanla değişebileceği için özellikle yayın/build/SEO gibi güncel konularda son sürüm dokümantasyonunu kontrol edin.

1. Unity 6 Manual: https://docs.unity3d.com/6000.0/Documentation/Manual/index.html

2. Unity Scripting API: https://docs.unity3d.com/6000.0/Documentation/ScriptReference/index.html

3. MonoBehaviour API: https://docs.unity3d.com/6000.0/Documentation/ScriptReference/MonoBehaviour.html

4. Prefabs – Unity Manual: https://docs.unity3d.com/kr/current/Manual/Prefabs.html

5. ScriptableObject – Unity Manual: https://docs.unity3d.com/kr/current/Manual/class-ScriptableObject.html

6. Profiler Window – Unity Manual: https://docs.unity3d.com/cn/current/Manual/ProfilerWindow.html