Bir web projesini çalışır hale getirmekle insanların severek kullandığı bir ürüne dönüştürmek arasında ciddi bir fark var.

Test Merkezim’i geliştirirken başlangıçtaki hedefim oldukça basitti: Kullanıcıların herhangi bir üyelik oluşturmadan zihinsel becerilerini değerlendirebileceği ve tarayıcı üzerinden zeka oyunları oynayabileceği hızlı bir platform hazırlamak.

Ancak proje büyüdükçe işin yalnızca soru göstermekten veya birkaç oyun geliştirmekten ibaret olmadığını gördüm. Kullanıcı akışı, mobil kullanım, skor güvenliği, oyun zorluğu ve sayfa performansı en az oyunların kendisi kadar önemliydi.

Bu yazıda proje boyunca karşılaştığım temel problemleri ve çıkardığım dersleri paylaşmak istiyorum.

Kullanıcıyı teste ulaştırmak mümkün olduğunca kolay olmalı

İlk tasarımda kullanıcı ana sayfadaki butona basıyor, test tanıtım sayfasına gidiyor, tekrar bir başlangıç butonuna basıyor ve ardından isim ekranında bir kez daha “Teste Başla” butonuyla karşılaşıyordu.

Teknik olarak bu akış çalışıyordu. Kullanıcı açısından ise aynı işlemi üç kez tekrarlamak anlamına geliyordu.

Bu nedenle ara tanıtım adımını kaldırdım. Kullanıcı ana sayfadan test ekranına ulaştığında isteğe bağlı olarak adını yazabiliyor ve doğrudan teste başlayabiliyor.

Bu değişiklik bana basit bir gerçeği yeniden hatırlattı:

Her ek tıklama kullanıcıya projeden vazgeçmesi için yeni bir fırsat verir.

Bir ekran gerçekten gerekli değilse onu daha güzel tasarlamak yerine tamamen kaldırmak bazen daha doğru çözüm oluyor.

Neden PHP ve Vanilla JavaScript?

Proje, paylaşımlı sunucuda çalışan hafif bir yapıya sahip. Bu nedenle büyük bir framework veya zorunlu bir derleme süreci kullanmak istemedim.

Genel yapı şu şekilde oluştu:

  • Sunucu tarafında PHP
  • Oyun mekaniklerinde Vanilla JavaScript
  • Ortak başlık, alt bilgi, ses ve liderlik bileşenleri için PHP parçaları
  • Skor ve oynanma verileri için sunucu tarafı API
  • Sayfa özelinde HTML, CSS ve JavaScript

Bu yaklaşımın en önemli avantajı dağıtım kolaylığı oldu. Güncellenen dosyalar doğrudan sunucuya aktarılabiliyor ve bağımlılık kurulumu gerekmiyor.

Dezavantajı ise ortak bileşenleri doğru ayırmadığınızda benzer kodların farklı oyunlarda tekrar etmeye başlaması. Bu nedenle yalnızca gerçekten ortaklaşan parçaları merkezi dosyalara taşıdım; oyunlara özgü mekanikleri kendi sayfalarında bıraktım.

Bir zeka oyunu aslında küçük bir durum makinesidir

Oyun geliştirirken görsel tasarıma odaklanmak kolay. Fakat asıl zorluk oyunun bütün durumlarını doğru yönetmek:

  • Oyun başlamadan önce hangi butonlar aktif?
  • Geçersiz hamle nasıl ele alınıyor?
  • Geri alma işlemi skoru veya hamle sayısını etkiliyor mu?
  • Sayfa yenilendiğinde oyuncu kaldığı yerden devam edebiliyor mu?
  • Oyun bittikten sonra yeni girişler engelleniyor mu?
  • Dokunmatik ekran ile fare aynı davranışı gösteriyor mu?

Örneğin Çizgi Bulmacası’nda oyuncunun tüm hücreleri tek kesintisiz çizgiyle doldurması ve numaralı noktaları doğru sırada toplaması gerekiyor.

Masaüstünde sürekli fare tuşunu basılı tutmak yorucu olduğu için aynı satır veya sütundaki uzak bir hücreye tıklandığında aradaki geçerli hücrelerin otomatik doldurulmasını ekledim. Kurallar değişmedi fakat kontrol biçimi daha rahat hale geldi.

Bu küçük değişiklik, oyunun zorluğunu azaltmadan kullanım sürtünmesini azalttı.

Zorluk yalnızca tahta boyutuyla belirlenmiyor

İlk yaklaşımda seviye yükseldikçe numaralı noktaların sayısını azaltıyordum. Daha az ipucunun oyunu otomatik olarak zorlaştıracağını düşünmüştüm.

Fakat fazla sayıda nokta da rotayı daha çok zorunlu kontrol noktasına bağlayabiliyor. Bu durum bazı bulmacalarda daha yoğun sayı dağılımını zorlaştırabiliyor.

Bu nedenle doğrusal sistem yerine karma bir yapı kullandım:

  • Tahta boyutu 5×5’ten başlayarak 8×8’e kadar büyüyor.
  • Aynı tahta boyutunda nokta yoğunluğu yükselip düşüyor.
  • İleri bölümlerde 3 ile 9 arasındaki yoğunluklar karıştırılıyor.
  • Her yedi bölümde bütün yoğunluklar bir kez kullanılıyor.
  • Aynı nokta sayısının arka arkaya gelmesi engelleniyor.

Böylece oyuncu bir sonraki bölümde nasıl bir yapı çıkacağını önceden kestiremiyor. Prosedürel üretimde yalnızca rastgelelik değil, kontrollü çeşitlilik kullanmak daha dengeli sonuç veriyor.

İstemciden gelen skora güvenmemek gerekiyor

Tarayıcı tabanlı oyunlarda bütün oyun mantığı kullanıcı tarafından görülebilir ve değiştirilebilir. Bu nedenle yalnızca JavaScript tarafından gönderilen skoru kabul etmek güvenli değil.

Sunucu tarafında şu kontrolleri uygulamak önemli hale geldi:

  • Oyun kimliğini beyaz listeyle doğrulamak
  • Oyuna göre izin verilen zorluk değerlerini kontrol etmek
  • Her oyun için makul skor aralıkları belirlemek
  • Gerçekçi olmayan tamamlanma sürelerini reddetmek
  • Oyuncu veya IP bazında gönderim sınırı uygulamak
  • Liderlik tablosuna yazılmadan önce girdileri temizlemek

Casual bir oyun platformunda bütün oyunları sunucuda yeniden simüle etmek gereğinden fazla karmaşık olabilir. Ancak birkaç düşük maliyetli doğrulama, otomatik skor sahteciliğinin büyük bölümünü engelleyebilir.

Buradaki temel kural oldukça net:

İstemci kullanıcı deneyimini yönetir, sunucu ise verinin kabul edilip edilmeyeceğine karar verir.

Mobil deneyim sonradan eklenen bir özellik olmamalı

Oyunların büyük kısmı telefondan oynandığı için masaüstü tasarımını küçültmek yeterli olmadı.

Mobil görünümde özellikle şunları ayrı ayrı ele almak gerekti:

  • Oyun alanının ekran genişliğine göre ölçeklenmesi
  • Kontrol butonlarının hamle ve süre göstergelerinin altında kalmaması
  • Dokunma hedeflerinin yeterince büyük olması
  • Metin ve ikonların aynı hizada durması
  • Açılır menülerin ekran dışına taşmaması
  • Kaydırma hareketiyle oyun hareketinin çakışmaması

Responsive tasarım yalnızca width: 100% kullanmak anlamına gelmiyor. İçeriğin hangi sırayla gösterileceğine ve kullanıcının parmağının nereye ulaşacağına da karar vermek gerekiyor.

Performans için her zaman büyük bir altyapı gerekmiyor

Projenin performans tarafında uyguladığım bazı basit tercihler şunlar oldu:

  • Yazı tiplerini harici servis yerine yerel sunucudan yüklemek
  • Büyük görselleri WebP formatına dönüştürmek
  • Ekranın altındaki görselleri tembel yüklemek
  • Ortak CSS dosyasını küçük tutmak
  • Gereksiz JavaScript kütüphanelerinden kaçınmak
  • Görsellere genişlik ve yükseklik değerleri vermek
  • İlk ekranda ihtiyaç duyulmayan kaynakları ertelemek

Bu optimizasyonların her biri tek başına küçük görünebilir. Ancak mobil bağlantıda toplam etkileri oldukça belirgin oluyor.

SEO ile kullanıcı deneyimi birbirinden ayrı değil

Arama motorları için içerik hazırlarken kullanıcıya aynı bilgiyi farklı kutular içinde tekrar tekrar göstermek kolay bir hata.

Benim için daha sağlıklı yaklaşım şu oldu:

  • Her sayfada tek ve açıklayıcı bir ana başlık kullanmak
  • Sayfanın arama niyetine doğrudan cevap vermek
  • Görünen içerikle yapılandırılmış veriyi eşleştirmek
  • Benzer sayfalar arasında başlık tutarlılığı sağlamak
  • Kullanıcıyı gereksiz tanıtım ekranlarında bekletmemek
  • Oyunların altında kuralları ve mekanikleri gerçekten açıklamak

Bugün gelinen noktada proje; kayıt istemeyen bir IQ testi, anında sonuç ekranı ve farklı becerilere odaklanan tarayıcı tabanlı zeka oyunları sunuyor.

Online testlerin profesyonel veya klinik değerlendirmelerin yerine geçmediğini açıkça belirtmek de güvenilir ürün iletişiminin önemli bir parçası.

Bu projeden çıkardığım temel dersler

Projeyi geliştirirken öğrendiğim en önemli noktaları şöyle özetleyebilirim:

  1. Çalışan kullanıcı akışı her zaman iyi kullanıcı akışı değildir.
  2. Rastgele üretim, kontrolsüz bırakıldığında dengeli zorluk oluşturmaz.
  3. Mobil kontroller masaüstü kontrollerinden ayrı düşünülmelidir.
  4. İstemciden gelen hiçbir skor doğrudan güvenilir kabul edilmemelidir.
  5. Küçük performans iyileştirmeleri birlikte büyük fark yaratır.
  6. SEO içeriği kullanıcıya gerçek bir cevap vermiyorsa uzun olması işe yaramaz.
  7. Oyuncuyu oyunda tutan şey yalnızca zorluk değil, sürekli değişen deneyimdir.

Proje geliştikçe yeni oyun mekanikleri, daha dengeli skor sistemleri ve daha iyi erişilebilirlik seçenekleri üzerinde çalışmaya devam edeceğim.

Siz tarayıcı tabanlı oyunlarda oyun durumunu ve prosedürel zorluğu nasıl yönetiyorsunuz? Benzer projelerde kullandığınız yaklaşımları yorumlarda duymak isterim.