Akış durumu nedir?

Akış sırasında oyuncunun dikkati tek bir hedefe yönelir. Kontroller düşünülmeden uygulanır, kararlar hızlı alınır ve başarısızlık bile oyunu bırakma isteği yerine yeniden deneme dürtüsü yaratır. Ancak bu deneyim, yalnızca oyunu “eğlenceli” yapmakla oluşmaz. Oyuncuya açık hedefler, hızlı geri bildirim ve becerisine uygun mücadele sunulmalıdır.

Temel ilişki basitçe şöyle modellenebilir:

Burada $F$ akış potansiyelini, $C$ oyunun sunduğu zorluğu, $S$ ise oyuncunun beceri seviyesini temsil eder. $C$ ile $S$ birbirine yaklaştıkça akış ihtimali yükselir. Bu, kesin bir psikoloji yasası değil, tasarım mantığını görünür kılan pratik bir modeldir.

Zorluk neden sürekli artmamalı?

Oyuncu geliştikçe zorluk da artmalıdır; fakat bu artış dümdüz bir rampa olmamalıdır. Aralıksız yükselen baskı zihinsel yorgunluk yaratır. İyi oyunlar genellikle gerilim ve rahatlama döngüsü kurar: zor bir çatışmanın ardından güvenli alan, bulmacanın ardından keşif veya bölüm sonu canavarından sonra ödül ekranı gelir.

Bu yapı egzersize benzer. Kaslar dinlenmeden sürekli çalıştırılırsa performans düşer; oyuncunun dikkat kapasitesi de aynı şekilde molaya ihtiyaç duyar. Dolayısıyla akış, kesintisiz stres değil, kontrollü yoğunluktur.

Dinamik zorluk ayarlaması

Her oyuncunun refleksi, deneyimi ve öğrenme hızı farklıdır. Dinamik zorluk sistemleri performansı gözlemleyerek düşman dayanıklılığı, kaynak miktarı veya ipucu sıklığı gibi değişkenleri ayarlayabilir. Basit bir yaklaşım şöyle yazılabilir:

def zorluk_hesapla(basari_orani, mevcut_zorluk):
    hedef = 0.70  # Oyuncunun yaklaşık %70 başarı göstermesi amaçlanıyor
    fark = basari_orani - hedef

    # Küçük adımlar, değişimin yapay ve cezalandırıcı hissedilmesini önler.
    yeni_zorluk = mevcut_zorluk + fark * 0.15
    return max(0.1, min(yeni_zorluk, 1.0))

Bu kod, oyuncu hedeflenen başarı oranının üzerindeyse zorluğu biraz artırır; altındaysa azaltır. min ve max kullanımı değeri güvenli sınırlar içinde tutar. Yine de sistem gizli çalışırken dikkatli olunmalıdır. Oyuncu, oyun tarafından kasıtlı olarak engellendiğini fark ederse başarı duygusu zedelenebilir.

Adalet, öğrenme ve geri bildirim

Zor bir oyun mutlaka bunaltıcı değildir. Oyuncu neden kaybettiğini anlayabiliyor ve bir sonraki denemede farklı davranabiliyorsa başarısızlık, öğrenme aracına dönüşür. Tehlikeden önce verilen ses, düşmanın okunabilir animasyonu veya doğru anda gösterilen kısa ipucu, adalet algısını güçlendirir.

Sonuç olarak iyi zorluk tasarımı, oyuncuyu sürekli yenmek değil, onu gelişebileceğine ikna etmektir. Akışın sihri tam burada ortaya çıkar: Oyun ne çocuk oyuncağıdır ne de klavyeyi pencereden attıracak kadar acımasızdır. Her yeni engel, oyuncuya sessizce “Bunu henüz yapamıyorsun, ama birazdan yapabilirsin” der.

Bir multiplayer maçına giriyorsunuz: Takım arkadaşınız yanlış koridora gidiyor, biri mikrofonu sonuna kadar açıyor ve henüz ikinci dakika dolmadan sohbet kutusunda küçük çaplı bir iç savaş başlıyor. Bu davranışlar yalnızca “kötü oyunculuk kültürü” değildir. Anonimlik, rekabet, grup kimliği ve sosyal mühendislik aynı dijital arenada buluştuğunda insanların yüz yüze ortamda sergilemeyeceği davranışlar ortaya çıkabilir. ``

Anonimlik neden freni gevşetir?

Sosyal psikolojide çevrimiçi disinhibisyon etkisi, kişinin dijital ortamda daha dürtüsel davranmasını açıklar. Oyuncu gerçek adını, yüzünü ve sosyal çevresini göstermediğinde davranışlarının kişisel itibarına zarar verme ihtimali azalır. “Ben” yerine geçici bir kullanıcı adı öne çıkar.

Bu durumu basitleştirilmiş bir davranış modeliyle gösterebiliriz:

Burada $T$ toksik davranış olasılığını, $A$ anonimlik düzeyini, $R$ rekabet baskısını, $G$ grup kutuplaşmasını, $H$ hesap verebilirliği ve $C$ davranışın algılanan maliyetini temsil eder. Bu bilimsel bir teşhis formülü değil, ilişkileri anlamayı kolaylaştıran kavramsal bir modeldir. Anonimlik ve rekabet yükselirken yaptırım ihtimali düşerse toksisite için elverişli bir ortam oluşur.

Rekabet, grup kimliği ve günah keçileri

Dereceli maçlarda puan kaybetmek, yalnızca sanal bir sayı kaybı gibi görünmeyebilir. Oyuncunun beceri algısı ve grup içindeki statüsü de tehdit edilir. İnsanlar böyle anlarda başarısızlığı kendi kararları yerine takım arkadaşlarına bağlamaya eğilimlidir. Bu, kendine hizmet eden yanlılık olarak bilinir.

Takımlar ayrıca hızlı biçimde “biz” ve “onlar” ayrımı üretir. Rakip insan olmaktan çıkıp engel gibi algılandığında empati azalabilir. Takım içinde çoğunluğun bir oyuncuyu suçlaması ise sorumluluğun dağılmasına yol açar: Herkes hakarete katıldığı için kimse kendisini asıl fail olarak görmez.

Sosyal mühendislik oyuna nasıl sızar?

Sosyal mühendislik, teknik açık yerine güven, korku, merak veya otorite algısını hedefler. Saldırgan; takım arkadaşı, turnuva yöneticisi ya da destek görevlisi gibi davranarak bağlantıya tıklatmaya, hesap bilgisini almaya veya oyuncuyu başka platforma taşımaya çalışabilir. “Hemen doğrulamazsan hesabın kapanacak” mesajı, zaman baskısıyla eleştirel düşünmeyi devre dışı bırakmayı amaçlar.

Toksik atmosfer saldırgana avantaj sağlar. Öfkeli veya panik hâlindeki oyuncu, normalde sorgulayacağı bir isteğe daha hızlı tepki verebilir. Bu nedenle güvenliğin ilk kuralı basittir: Şifre, doğrulama kodu ve kurtarma anahtarı sohbet üzerinden paylaşılmaz.

Yazılımla erken uyarı mümkün mü?

Moderasyon sistemleri mesajları yalnızca yasaklı kelimelerle değil; tekrar, tehdit, büyük harf kullanımı ve rapor geçmişi gibi sinyallerle değerlendirebilir. Aşağıdaki örnek, açıklanabilir basit bir risk puanı üretir:

def risk_puani(mesaj, tekrar, gecmis_rapor):
    tehditler = ["hesabını kapatırım", "adresini bulurum"]
    puan = sum(ifade in mesaj.lower() for ifade in tehditler) * 3
    puan += min(tekrar, 4)
    puan += min(gecmis_rapor, 5) * 0.5
    puan += 1 if mesaj.isupper() and len(mesaj) > 12 else 0
    return puan

Bu kod otomatik ceza vermek yerine inceleme sırası oluşturabilir. Dil, mizah ve bağlam değiştiği için insan denetimi gereklidir; aksi hâlde yanlış pozitifler ve kültürel önyargılar oluşabilir.

Daha sağlıklı bir arena

Etkili çözüm yalnızca oyuncuları susturmak değildir. Hızlı raporlama, davranış geri bildirimi, kademeli yaptırım, pozitif takım ödülleri ve iki faktörlü kimlik doğrulama birlikte kullanılmalıdır. Oyuncular da öfkeliyken yanıt vermemeli, şüpheli bağlantıları açmamalı ve saldırganı engelleyip kanıtları platforma iletmelidir. İyi tasarlanmış sistemler insan doğasını değiştirmez; fakat kötü davranışın ödülünü azaltıp iş birliğini daha görünür ve değerli hâle getirebilir.

``

Ortak teorik temel

Bir şablonu, türleri parametre olarak alan bir üretim kuralı gibi düşünebiliriz. $T$ bir tür ve $G$ bir şablon olsun. Derleyici uygun kullanım gördüğünde somut bir örnek üretir:

Bu süreç örnekleme olarak adlandırılır. Fakat bir şablonun gerçekten kullanılabilir olması için gövdesindeki işlemlerin seçilen tür üzerinde geçerli olması gerekir. Örneğin a + b ifadesi kullanılıyorsa $T$ türü toplama işlemini desteklemelidir. Modern C++’ta bu gereksinimler concept ile açıkça belirtilebilir.

Fonksiyon şablonlarının temel kısıtları

Fonksiyon şablonlarının en büyük avantajı, tür çıkarımıdır. Derleyici parametrelerden T türünü bulabilir:

#include <concepts>

template<typename T>
requires std::totally_ordered<T>
const T& buyuk(const T& a, const T& b) {
    return a < b ? b : a;
}

Buradaki requires, fonksiyonun yalnızca tam sıralama ilişkisi sunan türlerle kullanılacağını anlatır. Böylece anlamsız kullanımlar, şablon gövdesindeki karmaşık hatalar yerine arayüz seviyesinde reddedilir.

Bununla birlikte çıkarım, dönüş türünden yapılmaz. T sonuc = uret(); ifadesindeki hedef tür, klasik fonksiyon şablonu çıkarımını tek başına yönlendiremez. Ayrıca fonksiyon şablonlarında kısmi özelleştirme bulunmaz. Belirli bir tür ailesine farklı davranış vermek için aşırı yükleme, if constexpr, yardımcı sınıf şablonu veya concept tabanlı overload kullanmak gerekir.

template<typename T>
void yazdir(const T& deger) {
    // Genel davranış
}

template<typename T>
void yazdir(T* adres) {
    // İşaretçiler için overload
}

İkinci fonksiyon kısmi özelleştirme değil, ayrı bir aşırı yüklemedir. Bu ayrım overload çözümleme kurallarını etkilediği için önemlidir.

Sınıf şablonlarının temel kısıtları

Sınıf şablonları veri üyeleriyle birlikte tür politikası, sahiplik ve yaşam süresi tasarlamaya uygundur:

#include <cstddef>
#include <stdexcept>

template<typename T, std::size_t N>
class SabitTampon {
    T veri[N]{};

public:
    T& getir(std::size_t i) {
        if (i >= N) throw std::out_of_range("indeks");
        return veri[i];
    }
};

Burada hem tür hem de derleme zamanı kapasitesi sınıf kimliğinin parçasıdır. Dolayısıyla SabitTampon<int, 8> ile SabitTampon<int, 16> tamamen farklı türlerdir. Genel olarak iki örnek ancak tüm şablon argümanları aynıysa aynı türdür:

Sınıf şablonlarının önemli üstünlüğü kısmi özelleştirmedir. Örneğin Depo<T*>, bütün işaretçi türleri için farklı sahiplik kuralları uygulayabilir. Ancak bu güç, tekrar eden kod ve özelleştirmeler arasında tutarsız arayüz riski doğurur. Genel sürümde bulunan bir üyenin özelleştirilmiş sürümde unutulması şaşırtıcı derleme hatalarına yol açabilir.

Hangisini ne zaman seçmeli?

Tek bir işlem, argümanlardan çıkarılabilen türler ve doğal overload davranışı gerekiyorsa fonksiyon şablonu seçilmelidir. Durum saklama, politika birleştirme, tür ailesi oluşturma veya kısmi özelleştirme gerekiyorsa sınıf şablonu daha uygundur. İyi bir generic tasarım yalnızca “her türle çalışmak” değildir; desteklenen işlemleri mümkün olduğunca erken, açık ve anlaşılır biçimde sınırlandırmaktır. concept kullanımı da bu sınırların üzerindeki nazik ama kararlı güvenlik görevlisidir.

C# ile geliştirdiğimiz özel sınıflar, varsayılan olarak +, -, >, == gibi operatörlerin ne anlama geldiğini bilmez. Örneğin iki vektörü vektor1 + vektor2 biçiminde toplamak istersek derleyici doğal olarak şaşırır. Operatör aşırı yükleme, bu sembollere kendi nesnelerimiz için anlam kazandırmamızı sağlar. Böylece kod hem matematiksel gösterime yaklaşır hem de daha okunabilir hâle gelir.

``

Operatör aşırı yükleme nedir?

Operatör aşırı yükleme, mevcut bir operatörün özel bir tür üzerindeki davranışını tanımlamaktır. Burada yeni bir operatör icat etmeyiz; C# tarafından desteklenen operatörlerden birini yeniden anlamlandırırız.

Örneğin iki boyutlu bir vektörümüz şu şekilde gösterilsin:

İki vektörün toplamı ise bileşenlerin ayrı ayrı toplanmasıyla bulunur:

Bu matematiksel kuralı C# sınıfına taşıyarak + operatörünü programlayabiliriz.

Temel söz dizimi

Aşırı yüklenen operatörler public ve static olarak tanımlanmalıdır. Metot adı yerine operator anahtar sözcüğü ve ilgili sembol kullanılır.

public class Vektor
{
    public double X { get; }
    public double Y { get; }

    public Vektor(double x, double y)
    {
        X = x;
        Y = y;
    }

    public static Vektor operator +(Vektor sol, Vektor sag)
    {
        return new Vektor(sol.X + sag.X, sol.Y + sag.Y);
    }

    public override string ToString()
    {
        return $"({X}, {Y})";
    }
}

Bu metot iki Vektor nesnesini alır ve toplamı temsil eden yeni bir nesne döndürür. Mevcut nesneleri değiştirmemek, özellikle matematiksel değer türlerinde daha güvenli ve tahmin edilebilir bir tasarımdır.

var a = new Vektor(2, 3);
var b = new Vektor(4, 1);
var toplam = a + b;

Console.WriteLine(toplam); // (6, 4)

Normalde Vektor.Topla(a, b) gibi bir metot yazılabilirdi. Ancak a + b, işlemin niyetini çok daha hızlı anlatır.

\vert Yaklaşım \vert Kullanım \vert Okunabilirlik \vert Matematiksel uyum \vert \vert —\vert —\vert —:\vert —:\vert \vert Normal metot \vert Vektor.Topla(a, b) \vert Orta \vert Düşük \vert \vert Operatör \vert a + b \vert Yüksek \vert Yüksek \vert \vert Elle hesaplama \vert new Vektor(a.X+b.X, a.Y+b.Y) \vert Düşük \vert Orta \vert

İlişkisel operatörleri yüklemek

Vektörleri büyüklüklerine göre karşılaştırabiliriz. Bir vektörün uzunluğu Pisagor bağıntısıyla hesaplanır:

Karşılaştırma sırasında karekök almaya gerek yoktur. Çünkü pozitif değerlerde $a^2 > b^2$ ise $a > b$ olur.

public double UzunlukKaresi => X * X + Y * Y;

public static bool operator >(Vektor sol, Vektor sag)
{
    return sol.UzunlukKaresi > sag.UzunlukKaresi;
}

public static bool operator <(Vektor sol, Vektor sag)
{
    return sol.UzunlukKaresi < sag.UzunlukKaresi;
}

C# bazı operatörlerin çiftler hâlinde tanımlanmasını ister. < ekleniyorsa >, <= ekleniyorsa >=, == ekleniyorsa != de tanımlanmalıdır. Derleyici bu konuda “Birini çağırdıysan arkadaşını da getir!” yaklaşımındadır.

Eşitlikte dikkat edilmesi gerekenler

== operatörü yüklendiğinde Equals ve GetHashCode metotları da uyumlu biçimde ezilmelidir. Aksi hâlde operatöre göre eşit olan iki nesne, bir Dictionary veya HashSet içinde farklı kabul edilebilir. Eşitlik tanımı uygulamanın her noktasında aynı mantığı izlemelidir.

Operatör aşırı yükleme güçlüdür; fakat yalnızca operatörün anlamı kullanıcı için doğal olduğunda tercih edilmelidir. Bir Musteri nesnesini başka bir müşteriyle toplamak belirsizken, para, tarih aralığı, karmaşık sayı veya vektörleri toplamak oldukça anlaşılırdır. Ayrıca operatörün önceliği ve operand sayısı değiştirilemez. Doğru kullanıldığında bu özellik, C++’taki benzer yaklaşım gibi özel nesneleri dilin doğal parçalarıymış gibi kullanmamızı sağlar.

``

Bilinçli hareketten otomatik tepkiye

Yeni başlayan bir speedcuber, karşısındaki deseni tanımaya ve uygun algoritmayı hatırlamaya çalışır. Deneyimli biri ise deseni gördüğü anda ellerini harekete geçirir. Benzer biçimde acemi bir oyuncu hangi tuşa basacağını düşünürken deneyimli oyuncu saldırıdan kaçıp karşı hamle yapabilir.

Bu gelişim motor hafızası olarak adlandırılır. Ancak kasların kendi başına bilgi depoladığı düşünülmemelidir. Öğrenme; beyin, sinir sistemi, görsel algı ve kas koordinasyonu arasında kurulan bağlantıların güçlenmesidir. Bir hareket dizisi tekrarlandıkça karar verme maliyeti azalır ve işlem otomatikleşir.

Basitleştirilmiş bir öğrenme modeli şöyle gösterilebilir:

Burada $T(n)$, $n$ tekrar sonrasındaki uygulama süresi; $T_0$ başlangıç süresi; $T_{min}$ ulaşılabilecek yaklaşık alt sınır; $k$ ise öğrenme hızıdır. İlk tekrarlar büyük gelişmeler sağlarken ilerleyen aşamalarda her küçük iyileştirme daha fazla emek ister. Yani 60 saniyeden 30 saniyeye düşmek, 12 saniyeden 11 saniyeye düşmekten çoğu zaman daha kolaydır.

İki dünyanın ortak mekanikleri

Her iki alanda da uzmanlık yalnızca “daha hızlı hareket etmek” değildir. Asıl kazanç, gereksiz kararları ve hareketleri ortadan kaldırmaktır. Speedcubing’de buna düşük hamle sayısı, akıcı dönüşler ve iyi look-ahead eşlik eder. Oyunlarda ise doğru rota, uygun zamanlama ve minimum girdiyle maksimum sonuç önem kazanır.

Tekrar var, tekrar var

Aynı diziyi düşünmeden yüz kez yapmak her zaman verimli değildir. Hatalı hareket tekrarlandığında beyin o hatayı da otomatikleştirebilir. Bu nedenle bilinçli pratik, rastgele tekrardan daha değerlidir.

Örneğin bir speedcuber yalnızca zorlandığı algoritmayı çalışabilir. Bir oyuncu da tüm bölümü yeniden oynamak yerine problemli sıçramayı, komboyu veya nişan geçişini ayrı bir antrenman ortamında tekrarlayabilir.

Gelişimi veriye dönüştürmek

Aşağıdaki küçük Python kodu, pratik sürelerinin ortalamasını ve tutarlılığını ölçer:

from statistics import mean, pstdev

sureler = [18.4, 17.9, 18.1, 17.6, 17.8]

print('Ortalama:', round(mean(sureler), 2))
print('Sapma:', round(pstdev(sureler), 2))

Ortalama süre genel performansı, standart sapma ise denemeler arasındaki değişkenliği gösterir. Daha düşük ortalama hızlanmayı; daha düşük sapma ise becerinin güvenilir biçimde otomatikleştiğini anlatır. Aynı yaklaşım küp çözme sürelerine, bölüm tamamlama kayıtlarına veya hedef vurma testlerine uygulanabilir.

Sonuç: Hız, düşünmemek değil doğru düşünmektir

Speedcubing ve oyun optimizasyonunda ustalık, zihni tamamen devre dışı bırakmak anlamına gelmez. Temel hareketler motor hafızasına aktarılınca bilinçli dikkat daha üst düzey problemlere ayrılır. Eller mevcut hamleyi tamamlarken zihin bir sonraki deseni, rotayı veya riski değerlendirebilir. Gerçek hız böyle doğar: doğru hareketi öğrenmek, onu parçalara ayırmak, kontrollü biçimde tekrarlamak ve sonunda akışın doğal bir parçasına dönüştürmek.

Neden otonomi gerekli?

Bir komutun Dünya’dan Mars’a gidip sonucunun geri dönmesi için gereken yaklaşık süre şöyle düşünülebilir:

Burada $d$ gezegenler arasındaki mesafe, $c$ ışık hızı ve $T_{işleme}$ görev merkezindeki değerlendirme süresidir. Radyo sinyalleri ışık hızında ilerlese bile mesafe ortadan kalkmaz. Üstelik bant genişliği sınırlıdır; rover sürekli yüksek çözünürlüklü görüntü gönderemez.

Güncel görevlerde çoğunlukla karma yaklaşım kullanılır. Bilim insanları hedef bölgeyi belirler; rover ise birkaç metrelik hareket sırasında taşlardan, çukurlardan ve tehlikeli eğimlerden kaçınır.

Rover çevresini nasıl görüyor?

Otonom sürüşün ilk aşaması algılamadır. Stereo kameralar aynı sahneyi iki farklı noktadan görüntüler. İnsan gözlerindeki derinlik algısına benzeyen bu yöntemle pikseller arasındaki kayma, yani disparity, ölçülür. Basitleştirilmiş derinlik bağıntısı şöyledir:

$Z$ engele olan uzaklığı, $f$ kameranın odak uzaklığını, $B$ iki kamera arasındaki mesafeyi ve $\Delta x$ görüntülerdeki piksel farkını gösterir. Rover bu verilerden üç boyutlu bir nokta bulutu ve yerel arazi haritası üretir.

Her arazi parçasına bir maliyet atanabilir:

Burada $E$ eğim, $S$ zeminin gevşekliği, $R$ kaya riski ve $D$ hedefe olan uzaklıktır. Ağırlıklar görev önceliklerine göre ayarlanır. Böylece en kısa rota yerine en güvenli ve enerji açısından uygun rota seçilebilir.

Rota planlama nasıl çalışıyor?

Harita hücrelere veya düğümlere ayrıldıktan sonra A, Dijkstra ya da örnekleme tabanlı algoritmalar kullanılabilir. A algoritmasının temel değerlendirmesi şöyledir:

$g(n)$ başlangıçtan mevcut noktaya kadar gerçek maliyeti, $h(n)$ ise hedefe kalan tahmini maliyeti temsil eder.

from heapq import heappush, heappop

def guvenli_adimlar(baslangic, hedef, komsular):
    kuyruk = [(0, baslangic, [])]
    ziyaret = set()

    while kuyruk:
        maliyet, konum, yol = heappop(kuyruk)
        if konum == hedef:
            return yol + [konum]
        if konum in ziyaret:
            continue

        ziyaret.add(konum)
        for yeni, arazi_riski in komsular(konum):
            if yeni not in ziyaret:
                heappush(kuyruk, (
                    maliyet + arazi_riski,
                    yeni,
                    yol + [konum]
                ))
    return None

Bu sade örnek, komşu konumları arazi riskine göre kuyruğa ekler. Gerçek rover yazılımı tekerlek kaymasını, enerji tüketimini, gövde yüksekliğini ve iletişim fırsatlarını da hesaba katar.

Karar vermek yalnızca ilerlemek değildir

Rover risk yükseldiğinde durabilir, yeni fotoğraflar çekebilir veya farklı bir rota hesaplayabilir. Tekerleklerin dönüşüyle beklenen hareket karşılaştırılarak kayma tahmin edilir. Motorlar çalıştığı hâlde konum değişmiyorsa sistem gevşek kum ihtimalini fark eder.

Mars’ta başarılı otonomi, rover’ın “zekice cesur” değil, ölçülü biçimde temkinli olmasıdır. Çünkü milyonlarca kilometre uzaktaki bir robot için en iyi karar bazen yeni bir keşfe koşmak değil, durup Dünya’daki ekibin talimatını beklemektir.

Gökyüzündeki hareketler ilk bakışta kusursuz bir saat mekanizması gibi görünür. Ancak sisteme üçüncü bir gök cismi eklendiğinde işler hızla kozmik bir bilardo masasına dönüşür! N-cisim problemi; yıldızların, gezegenlerin veya galaksilerin karşılıklı kütle çekimi altında nasıl hareket ettiğini bulmayı amaçlar. Genel bir analitik çözümü bulunmadığından bilgisayarlarla küçük zaman adımları hâlinde yaklaşık sonuçlar hesaplarız.

``

Newton’dan simülasyona

İki cismin arasındaki çekim kuvveti Newton yasasıyla hesaplanır:

Burada $G$ kütle çekim sabiti, $m_1$ ve $m_2$ kütleler, $r$ ise cisimler arasındaki uzaklıktır. Fakat yönü de hesaba katmak için vektörel ifadeye ihtiyacımız vardır. $i$ cisminin $j$ nedeniyle kazandığı ivme şöyledir:

Toplam ivme, diğer bütün cisimlerin katkılarının toplamıdır:

Formüldeki $\epsilon$, iki cisim aşırı yaklaştığında ivmenin sonsuza gitmesini engelleyen yumuşatma parametresidir. Bu değer fiziksel bir yasa değil, sayısal simülasyonu kararlı tutan küçük bir emniyet yastığıdır.

Neden adım adım hesaplıyoruz?

İvme sürekli değiştiği için gelecekteki konumu tek hamlede bulamayız. Zamanı $\Delta t$ büyüklüğünde dilimlere ayırır, her dilimde ivme, hız ve konumu güncelleriz. Basit Euler yöntemi kolaydır fakat uzun simülasyonlarda enerji hatası biriktirir. Leapfrog yöntemi ise hız ve konumu birbirinin arasına yerleştirerek daha kararlı sonuç verir.

Python ile temel uygulama

Aşağıdaki kod, iki boyutlu bir sistemde bütün cisimlerin ivmelerini hesaplar ve Leapfrog adımı uygular:

import numpy as np

G = 1.0
EPS = 0.01
DT = 0.001

def accelerations(pos, mass):
    n = len(mass)
    acc = np.zeros_like(pos)

    for i in range(n):
        for j in range(n):
            if i == j:
                continue

            delta = pos[j] - pos[i]
            distance2 = np.dot(delta, delta) + EPS**2
            acc[i] += G * mass[j] * delta / distance2**1.5

    return acc

def leapfrog_step(pos, vel, mass):
    # Hızı yarım adım ilerlet.
    acc = accelerations(pos, mass)
    vel += 0.5 * DT * acc

    # Yeni hızla konumu tam adım ilerlet.
    pos += DT * vel

    # Yeni konumdaki ivmeyle hız adımını tamamla.
    acc = accelerations(pos, mass)
    vel += 0.5 * DT * acc
    return pos, vel

mass = np.array([1000.0, 1.0, 0.5])
pos = np.array([[0.0, 0.0], [1.0, 0.0], [-1.5, 0.0]])
vel = np.array([[0.0, 0.0], [0.0, 31.6], [0.0, -25.8]])

for _ in range(10000):
    pos, vel = leapfrog_step(pos, vel, mass)

İç içe döngüler nedeniyle hesaplama maliyeti $O(N^2)$ olur: cisim sayısı iki katına çıktığında etkileşim sayısı yaklaşık dört kat artar. Binlerce cisim için Barnes–Hut algoritması, uzaktaki cisimleri gruplandırarak maliyeti yaklaşık $O(N\log N)$ seviyesine indirebilir.

Sonuçları değerlendirirken yalnızca güzel yörüngelere bakmak yeterli değildir. Toplam enerji ve momentum yaklaşık korunmalıdır. Enerji sürekli artıyor veya azalıyorsa zaman adımı fazla büyük olabilir. İşte N-cisim simülasyonunun temel sırrı budur: doğru fizik kadar, hatayı kontrol eden doğru sayısal yöntem de gerekir.

Simülasyon neden sürekli değildir?

Gerçek dünyada bir nesnenin konumu zamanla kesintisiz değişir. Oyunlarda ise fizik motoru konumu belirli aralıklarla günceller. Basit Euler integrasyonunda yeni konum yaklaşık olarak şöyle hesaplanır:

Burada $v$ hız, $Δt$ ise fizik adımının süresidir. Hızı 100 m/s olan bir mermi, $Δt = 0.02$ saniyelik adımda tek güncellemede 2 metre ilerler. Duvar yalnızca 20 santimetre kalınlığındaysa mermi bir karede duvarın önünde, sonraki karede arkasında olabilir. Motor sadece iki konumu kontrol ediyorsa çarpışmayı hiç görmez. Bu olaya genellikle tunneling, sonucunda oluşan görsel probleme ise clipping denir.

Tek suçlu yüksek hız değil

Clipping hatalarının birkaç suç ortağı vardır:

• Büyük zaman adımı: $Δt$ büyüdükçe nesnenin tek adımda aldığı mesafe artar.
• İnce collider: Duvarın çarpışma hacmi ne kadar inceyse atlanması o kadar kolaydır.
• Yetersiz çözücü iterasyonu: Üst üste giren gövdeleri ayıran solver yeterince çalışmazsa nesneler gömülü kalabilir.
• Doğrudan Transform değiştirmek: Fizik gövdesini motorun hareket API’si yerine ışınlanmış gibi taşımak, hız ve temas hesaplarını bozar.
• Kayan nokta hassasiyeti: Dünya merkezinden çok uzakta küçük konum farkları duyarlılığını kaybeder.
• Aşırı kütle farkı: Çok hafif ve çok ağır cisimlerin teması çözücüyü zorlayabilir.

Sayısal kararlılık açısından önemli oran, nesnenin bir adımda aldığı mesafenin engel kalınlığına oranıdır:

$d$ engel kalınlığıdır. $r > 1$ olduğunda nesne tek adımda engelin tamamını aşabilir. Bu kesin bir hata garantisi değildir ancak parlak bir alarm lambasıdır.

Unity ile hareket yolunu taramak

Aşağıdaki örnek, hızlı bir küreyi taşımadan önce gideceği yönde SphereCast uygular. Böylece yalnızca hedef konum değil, iki konum arasındaki yol da denetlenir:

using UnityEngine;

public class SafeProjectile : MonoBehaviour
{
    public float speed = 80f;
    public float radius = 0.1f;

    void FixedUpdate()
    {
        Vector3 direction = transform.forward;
        float distance = speed * Time.fixedDeltaTime;

        if (Physics.SphereCast(transform.position, radius, direction,
                               out RaycastHit hit, distance))
        {
            transform.position = hit.point - direction * radius;
            Debug.Log("Çarpılan nesne: " + hit.collider.name);
            Destroy(gameObject);
            return;
        }

        transform.position += direction * distance;
    }
}

Raycast yerine SphereCast kullanılması, hacmi olan merminin kenardan temaslarını daha güvenilir yakalar. Fizik tabanlı bir gövde kullanılıyorsa doğrudan Transform taşımak yerine Rigidbody.MovePosition, hız veya kuvvet yöntemleri tercih edilmelidir. Motorun sunduğu Continuous Dynamic gibi sürekli çarpışma seçenekleri de hızlı gövdelerde etkinleştirilebilir.

Dengeli çözüm nasıl seçilir?

Her nesneye en pahalı çarpışma modunu vermek doğru değildir. Yavaş dekor kutularında ayrık algılama yeterliyken mermiler, hızlı araçlar ve oyuncu karakterleri daha dikkatli ele alınmalıdır. Sabit fizik adımını küçültmek doğruluğu artırır fakat saniyedeki hesap sayısını yükseltir. Bu nedenle kritik nesnelerde sürekli algılama, çok hızlı mühimmatta şekil taraması ve büyük dünyalarda kayan başlangıç noktası yaklaşımı kullanılabilir.

Kısacası clipping, fizik motorunun “duvarları sevmemesi” değil, zaman ve konumu örnekleme biçiminin doğal sonucudur. Hız, zaman adımı, collider kalınlığı ve çözücü ayarları birlikte değerlendirildiğinde hayalet mermiler azalır; duvarlar da yeniden duvar gibi davranmaya başlar.

Işığın arkasındaki temel matematik

Bilgisayar grafiklerinde bir yüzeyin görünen rengi; ışık kaynağına, yüzey malzemesine ve kameraya bağlıdır. Basit Lambert aydınlatmasında dağınık ışık şu şekilde ifade edilir:

Burada $I_l$ ışık şiddetini, $k_d$ malzemenin ışığı yansıtma oranını, $\vec{N}$ yüzey normalini ve $\vec{L}$ ışığın yönünü temsil eder. Normal ile ışık yönü birbirine yaklaştıkça yüzey daha parlak görünür.

Gerçekçi sahnelerde ışık yalnızca kaynaktan yüzeye gelmez. Duvarlardan sekebilir, parlak yüzeylerde yansıyabilir ve saydam nesnelerden kırılarak geçebilir. Render denklemi bu davranışı genel biçimde açıklar:

Bu integralin eksiksiz hesaplanması pahalıdır. Oyun motorları bu nedenle hız ile doğruluk arasında çeşitli numaralar yapar; grafik programlamanın sihri biraz da buradadır.

Gerçek zamanlı ray tracing

Ray tracing, kameradan sahneye ışınlar göndererek bu ışınların hangi üçgenlerle kesiştiğini araştırır. Çarpışma noktasından gölge, yansıma veya dolaylı aydınlatma için yeni ışınlar üretilebilir. Böylece ekran alanının dışında kalan nesneler bile yansımalarda görülebilir.

Bir ışının parametrik gösterimi şöyledir:

$O$ başlangıç noktası, $D$ yön ve $t$ ilerleme mesafesidir. Modern ekran kartlarındaki özel çekirdekler ve BVH gibi hızlandırma yapıları, milyonlarca üçgen arasındaki kesişme aramasını yönetir.

Aşağıdaki sade HLSL örneği, gölge ışını sonucuna göre görünürlüğü belirler:

float visibility = 1.0;
RayDesc shadowRay;
shadowRay.Origin = hitPosition + normal * 0.001;
shadowRay.Direction = lightDirection;
shadowRay.TMin = 0.0;
shadowRay.TMax = distanceToLight;

TraceRay(scene, RAY_FLAG_ACCEPT_FIRST_HIT_AND_END_SEARCH,
         0xFF, 0, 0, 0, shadowRay, visibility);

Buradaki küçük normal ofseti, ışının çıktığı yüzeye tekrar çarpmasını önler. İlk engelde aramayı durdurmak da gölge hesabını hızlandırır.

Önceden hesaplanmış aydınlatma

Baked lighting yönteminde doğrudan ve dolaylı ışık, oyun yayınlanmadan önce hesaplanır. Sonuçlar lightmap adı verilen dokulara veya light probe verilerine kaydedilir. Çalışma sırasında ağır ışık simülasyonu yerine bu veriler okunur.

Bu yaklaşım özellikle duvarların, zeminin ve ışıkların hareket etmediği sahnelerde son derece verimlidir. Ancak bir oyuncu lambayı devirdiğinde lightmap bunu umursamaz; gölge hâlâ eski yerde kalabilir. Dinamik nesneler için probe, shadow map veya ekran alanı teknikleriyle destek gerekir.

Hangisini seçmeli?

Hareketli ışıkların, aynaların ve yıkılabilir çevrenin öne çıktığı bir oyunda ray tracing güçlü bir seçenektir. Mobil oyunlarda, düşük sistem gereksinimi hedeflerinde veya büyük ölçüde sabit mekânlarda baked lighting daha mantıklıdır.

Pratikte kazanan çoğunlukla hibrit yaklaşımdır. Statik ortamın dolaylı ışığı lightmap ile saklanırken karakter gölgeleri shadow map, parlak yansımalar ise ray tracing ile üretilebilir. Gürültülü ışın izleme sonuçları temporal accumulation ve denoiser filtreleriyle temizlenir. Böylece kalite bütçesi gerçekten görünür alanlara harcanır; ekran kartı da küçük bir güneşi simüle etmeye çalışırken tamamen ter içinde kalmaz.

``

VaR tam olarak ne söyler?

VaR üç bileşene dayanır: portföy değeri, zaman ufku ve güven düzeyi. Örneğin günlük %95 güven düzeyinde VaR değeri 20.000 TL ise ifade şu anlama gelir:

Normal piyasa koşulları altında, portföyün bir günlük kaybının %95 olasılıkla 20.000 TL’yi aşmaması beklenir.

Bunun tersinden söylenmesi daha öğreticidir: Günlerin yaklaşık %5’inde kayıp 20.000 TL’den büyük olabilir. VaR, oluşabilecek en yüksek kaybı söylemez. Kuyruğun başladığı eşiği gösterir; kuyruğun ne kadar korkutucu olduğunu ise tek başına açıklamaz.

Getiri $R$ ve güven düzeyi $c$ olmak üzere VaR, getiri dağılımının sol kuyruğundaki kantil üzerinden tanımlanabilir:

Burada $V_0$ portföyün bugünkü değeri, $Q_{1-c}$ ise getirilerin $(1-c)$ kantilidir. Eksi işareti, negatif getiriyi pozitif bir kayıp tutarı olarak sunar.

Başlıca hesaplama yöntemleri

Parametrik yöntemde ortalama getiri $\mu$, standart sapma $\sigma$ ve standart normal dağılımın kritik değeri $z_{1-c}$ kullanılır:

%95 güven düzeyinde sol kuyruk değeri yaklaşık $z_{0.05}=-1.645$ olur. Volatilite yükseldikçe VaR da büyür; başka bir deyişle portföyün kalp atışları hızlandıkça risk göstergesi kırmızıya yaklaşır.

Python ile tarihsel ve parametrik VaR

Aşağıdaki örnek, günlük portföy getirilerinden iki farklı VaR tahmini üretir. Gerçek bir uygulamada returns dizisi, portföy bileşenlerinin ağırlıklı getirilerinden veya portföy değer serisinden hesaplanmalıdır.

import numpy as np
from scipy.stats import norm

# Örnek günlük portföy getirileri
returns = np.array([
    0.004, -0.012, 0.006, -0.021, 0.003,
    -0.008, 0.011, -0.017, 0.002, -0.005
])

portfolio_value = 1_000_000
confidence = 0.95

# Sol kuyruktaki %5 kantilini bulur.
historical_quantile = np.quantile(returns, 1 - confidence)
historical_var = -portfolio_value * historical_quantile

# Ortalama ve volatiliteyle normal dağılım yaklaşımı kurar.
mu = returns.mean()
sigma = returns.std(ddof=1)
z_score = norm.ppf(1 - confidence)
parametric_var = -portfolio_value * (mu + z_score * sigma)

print(f"Tarihsel VaR: {historical_var:,.2f} TL")
print(f"Parametrik VaR: {parametric_var:,.2f} TL")

Tarihsel yöntemde np.quantile, gözlemlerin en kötü %5’lik bölümünün başladığı noktayı belirler. Parametrik yöntemde ise norm.ppf, seçilen güven düzeyine karşılık gelen kritik değeri verir. Veri sayısı az olduğunda her iki sonuç da oynak olabilir; yüzlerce veya binlerce günlük gözlem daha anlamlıdır.

Zaman ufku ve VaR’ın sınırları

Bağımsız ve benzer dağılan getiriler varsayılırsa günlük VaR, karekök-zaman kuralıyla yaklaşık olarak ölçeklenebilir:

Örneğin 10 günlük VaR yaklaşık olarak günlük VaR’ın $\sqrt{10}$ katıdır. Fakat kriz dönemlerinde getiriler bağımsız davranmayabilir ve volatilite kümelenebilir. Bu nedenle formül mekanik biçimde kullanılmamalıdır.

VaR ayrıca eşik sonrasındaki kaybı açıklamadığı için Expected Shortfall ile desteklenmelidir. Expected Shortfall, VaR aşıldığında ortalama kaybı ölçer. Sağlam bir risk sistemi; geriye dönük testler, stres senaryoları ve farklı güven düzeyleriyle sonuçları sınamalıdır. VaR kullanışlı bir pusuladır, fakat finansal fırtınalarda haritanın tamamı değildir.