``

Akıllı ev cihazları hangi verileri toplar?

Bir cihazın topladığı veri, sunduğu özellikle doğrudan ilişkilidir. Akıllı termostat sıcaklık tercihlerini öğrenirken robot süpürge evin haritasını çıkarabilir. Kapı sensörleri ise evde bulunulan saatlerin tahmin edilmesine yardımcı olabilir. Tek başına önemsiz görünen bu kayıtlar birleştirildiğinde ayrıntılı bir davranış profili ortaya çıkar.

Mahremiyet riski basitçe şu modelle düşünülebilir:

Burada $P$ saldırının gerçekleşme olasılığını, $E$ açığa çıkacak verinin miktarını, $V$ ise verinin hassasiyetini temsil eder. Çok güçlü şifrelenen bir sistemde $P$ azalır; cihaz gereksiz veri toplamıyorsa $E$ küçülür. Sağlık veya kamera verileri söz konusu olduğunda ise $V$ doğal olarak yüksektir.

Veriler nasıl kötüye kullanılabilir?

En yaygın tehlikelerden biri varsayılan parolaların değiştirilmemesidir. Saldırganlar internete açık cihazları tarayarak bilinen kullanıcı adı ve parola kombinasyonlarını deneyebilir. Güncellenmeyen yazılımlar, güvensiz bulut servisleri ve şifrelenmemiş bağlantılar da diğer giriş kapılarıdır.

Tehlike her zaman dışarıdan gelmez. Üretici firmalar kullanım verilerini reklam, analiz veya ürün geliştirme amacıyla üçüncü taraflarla paylaşabilir. Kullanıcı sözleşmesindeki belirsiz ifadeler, teknik olarak izin verilmiş fakat kullanıcı açısından beklenmeyen veri kullanımlarına yol açabilir.

Temel koruma katmanları

Güvenli bir akıllı ev, tek bir sihirli ayar yerine katmanlı savunma yaklaşımıyla kurulur.

1. Varsayılan parolaları değiştirin: Her cihaz için uzun ve benzersiz parola kullanın.
2. Çok faktörlü doğrulamayı açın: Hesap parolası sızsa bile ikinci bir kontrol katmanı oluşturur.
3. Cihazları ayrı ağa alın: IoT cihazlarını bilgisayar ve telefonlardan ayıran misafir ağı veya VLAN kullanın.
4. Güncellemeleri izleyin: Otomatik güncellemeyi açın; desteği sona ermiş cihazları değiştirin.
5. Gereksiz özellikleri kapatın: Kullanılmayan mikrofonu, uzaktan erişimi ve konum takibini devre dışı bırakın.
6. Gizlilik politikasını okuyun: Verinin nerede saklandığını ve nasıl silinebildiğini kontrol edin.

Ağınızdaki cihazları kontrol edin

Teknik kullanıcılar, yönlendirici kayıtlarını incelemenin yanında yerel ağdaki aktif cihazları Python ile listeleyebilir. Aşağıdaki örnek, sistemdeki ARP tablosunu göstererek ağa yakın zamanda bağlanmış cihazların IP ve MAC adreslerini görmeye yardımcı olur:

import subprocess

result = subprocess.run(
    ["arp", "-a"],
    capture_output=True,
    text=True,
    check=True
)

print("Ağda görülen cihazlar:")
print(result.stdout)

Bu kod bir güvenlik tarayıcısı değildir; yalnızca envanter çıkarmanın basit başlangıcıdır. Tanımadığınız bir cihaz görürseniz yönlendirici panelinden bağlantıyı engelleyebilir ve Wi-Fi parolanızı yenileyebilirsiniz.

Sonuç olarak akıllı ev güvenliği, cihaz satın alınırken başlamalıdır. Düzenli güncelleme sunan, açık gizlilik politikası bulunan ve yerel veri işleme seçenekleri sağlayan üreticiler tercih edilmelidir. Evinizi akıllandırırken temel ilke şu olmalı: Toplanmayan veri sızdırılamaz, erişilemeyen cihaz kolayca ele geçirilemez.

``

Temel çalışma mantığı

Bir işlem algoritması genellikle dört aşamadan oluşur: veri toplama, sinyal üretme, risk kontrolü ve emir yürütme. Sistem önce fiyat, işlem hacmi, emir defteri veya ekonomik gösterge gibi verileri alır. Ardından bu verilerden alım ya da satım sinyali çıkarır. Risk motoru pozisyon büyüklüğünü sınırlar; yürütme katmanı ise emri borsaya iletir.

Basit bir hareketli ortalama stratejisinde kısa dönem ortalaması uzun dönem ortalamasını geçtiğinde alım sinyali üretilebilir:

Burada $P_t$ ilgili zamandaki fiyatı, $n$ ise incelenen dönem sayısını gösterir. Örneğin $SMA_{10} > SMA_{50}$ olduğunda algoritma yükseliş eğilimi varsayabilir. Ancak bu yalnızca bir hipotezdir; kesin kazanç garantisi değildir.

Sinyalden gerçek emre

Doğru sinyal üretmek tek başına yeterli değildir. Algoritma piyasa emri verdiğinde hızlı gerçekleşme elde eder, fakat beklenenden kötü bir fiyatla karşılaşabilir. Limit emri fiyatı kontrol eder, ancak hiç gerçekleşmeyebilir. Büyük emirler de piyasayı hareket ettirebilir. Bu nedenle bazı sistemler emri küçük parçalara ayırarak zamana yayar.

Gerçekleşme fiyatı ile karar anındaki beklenen fiyat arasındaki fark kayma olarak adlandırılır. Yaklaşık işlem sonucu şöyle modellenebilir:

Kâğıt üzerinde başarılı görünen pek çok strateji, bu maliyetler eklendiğinde cazibesini kaybeder.

Küçük bir Python örneği

Aşağıdaki kod, kısa ve uzun hareketli ortalamaları karşılaştırarak örnek sinyal üretir. Gerçek para ile emir göndermez; yalnızca stratejinin karar katmanını gösterir.

import pandas as pd

def sinyal_uret(fiyatlar: pd.Series) -> pd.DataFrame:
    sonuc = pd.DataFrame({"fiyat": fiyatlar})
    sonuc["kisa_ortalama"] = fiyatlar.rolling(10).mean()
    sonuc["uzun_ortalama"] = fiyatlar.rolling(50).mean()

    sonuc["sinyal"] = 0
    sonuc.loc[
        sonuc["kisa_ortalama"] > sonuc["uzun_ortalama"], "sinyal"
    ] = 1
    sonuc.loc[
        sonuc["kisa_ortalama"] < sonuc["uzun_ortalama"], "sinyal"
    ] = -1

    return sonuc

Burada 1 alım yönünü, -1 satış yönünü, 0 ise kararsız durumu temsil eder. Üretim ortamında veri eksikliği, bağlantı kopması, tekrar gönderilen emirler ve borsa reddi gibi durumlar ayrıca yönetilmelidir.

Backtest neden yeterli değildir?

Backtest, stratejiyi geçmiş veriler üzerinde çalıştırır. Fakat geçmişte iyi görünen sonuçlar aşırı uyumdan kaynaklanabilir. Algoritma piyasa davranışını değil, veri setindeki tesadüfleri ezberlemiş olabilir.

Risk yönetiminde maksimum pozisyon, günlük zarar limiti ve acil durdurma mekanizması bulunmalıdır. Sharpe oranı gibi ölçüler de getiri ile oynaklığı birlikte değerlendirir:

Sonuç olarak algoritmik işlem; finans, istatistik, yazılım mühendisliği ve operasyon disiplininin birleşimidir. En iyi algoritma en karmaşık olan değil, varsayımları anlaşılır, maliyetleri gerçekçi ve risk sınırları açık olandır. Kod hızlı olabilir; fakat kontrolsüz risk ondan da hızlıdır. Bu içerik yatırım tavsiyesi değil, teknolojik sürecin eğitim amaçlı açıklamasıdır.

Bir tedavinin işe yarayıp yaramayacağını hastaya uygulamadan önce görebildiğimizi düşünün. Dijital ikiz teknolojisi, bir organın veya fizyolojik sistemin verilerle beslenen sanal bir kopyasını oluşturarak bu fikri gerçeğe yaklaştırıyor. Böylece farklı ilaç dozları, cerrahi yaklaşımlar ya da yaşam tarzı değişiklikleri bilgisayar ortamında sınanabiliyor. Kısacası doktorlar, gerçek hastaya dokunmadan önce onun dijital benzeri üzerinde güvenli bir prova yapabiliyor. ``

Dijital ikiz tam olarak nedir?

Dijital ikiz, yalnızca üç boyutlu bir organ modeli değildir. Anatomik yapının yanında kan akışı, elektriksel aktivite, metabolizma ve ilaçlara verilen tepki gibi dinamik süreçleri de temsil eder. Manyetik rezonans görüntüleri, bilgisayarlı tomografi, laboratuvar sonuçları, genetik veriler ve giyilebilir sensör ölçümleri ortak bir modelde birleştirilebilir.

Modelin temelinde matematiksel denklemler bulunur. Örneğin kandaki ilaç yoğunluğunun zamanla değişimi basitleştirilmiş olarak şöyle gösterilebilir:

Burada $C$ ilaç konsantrasyonunu, $D$ uygulanan dozu, $V$ dağılım hacmini ve $k$ ilacın vücuttan uzaklaştırılma hızını temsil eder. Hastaya özgü böbrek fonksiyonu veya vücut ağırlığı değiştiğinde bu parametreler güncellenir. Böylece aynı ilacın iki kişide neden farklı sonuçlar doğurabileceği simüle edilir.

Sanal hasta nasıl oluşturulur?

Süreç genellikle dört aşamada ilerler:

1. Veri toplama: Görüntüleme, tahlil, sensör ve hasta geçmişi verileri alınır.
2. Model kurma: Organın geometrisi çıkarılır ve fizyolojik kurallar modele eklenir.
3. Kalibrasyon: Simülasyon sonuçları hastanın gerçek ölçümleriyle karşılaştırılır.
4. Senaryo denemeleri: Farklı dozlar ve tedavi seçenekleri sanal ortamda test edilir.

Basitleştirilmiş bir doz simülasyonu

Aşağıdaki Python örneği, farklı dozların kandaki tahmini ilaç yoğunluğunu nasıl değiştirdiğini hesaplar. Gerçek klinik modeller çok daha karmaşıktır; bu kod yalnızca temel mantığı gösterir.

import math

def konsantrasyon(doz, hacim, atilim_hizi, saat):
    # Tek doz sonrası üstel azalmayı yaklaşık olarak hesaplar.
    baslangic = doz / hacim
    return baslangic * math.exp(-atilim_hizi * saat)

hasta = {
    "dagilim_hacmi": 42,
    "atilim_hizi": 0.12
}

for doz in [50, 100, 150]:
    sonuc = konsantrasyon(
        doz,
        hasta["dagilim_hacmi"],
        hasta["atilim_hizi"],
        saat=8
    )
    print(f"{doz} mg için 8. saat: {sonuc:.2f} mg/L")

Bu simülasyonda dağılım hacmi ve atılım hızı hastaya göre değiştirilerek kişiselleştirme yapılır. Ardından sonuçlar, hedeflenen güvenli konsantrasyon aralığıyla karşılaştırılabilir. Ancak model çıktısı tek başına tedavi kararı değildir; doktor değerlendirmesi ve klinik kanıt gerekir.

Nerelerde kullanılabilir?

Kalbin dijital ikizi, ritim bozukluğunda elektrotların en uygun konumunu araştırabilir. Tümör modelleri, radyoterapi dozunun sağlıklı dokuya etkisini tahmin edebilir. Akciğer ikizleri ventilatör ayarlarını, damar modelleri ise stent yerleşimini değerlendirebilir. Sürekli sensör verisi geldiğinde ikiz de güncellenir; yani statik bir fotoğraf değil, hastayla birlikte değişen dijital bir yol arkadaşıdır.

Güçlü fakat kusursuz değil

Eksik veri, hatalı sensörler ve aşırı basitleştirilmiş biyolojik varsayımlar güvenilmez sonuçlar üretebilir. Ayrıca sağlık verilerinin mahremiyeti, algoritmik önyargı ve modelin kararından kimin sorumlu olacağı önemli tartışma alanlarıdır. Bu nedenle dijital ikizler doktorların yerini alan makineler olarak değil, kararlarını sayısal deneylerle destekleyen araçlar olarak görülmelidir.

Gelecekte daha hızlı hesaplama, gelişmiş yapay zekâ ve standartlaştırılmış sağlık verileri sayesinde kişiye özel sanal denemeler yaygınlaşabilir. Belki de reçete yazılmadan önce dijital ikizimiz kısa bir prova yapacak; fakat son sözü yine klinik uzmanlık, etik ilkeler ve gerçek dünya kanıtları söyleyecek.

``

Finansal zaman serisi nedir?

Bir varlığın belirli zamanlarda ölçülen fiyatları bir zaman serisi oluşturur:

Burada $P_t$, varlığın $t$ anındaki fiyatıdır. Fakat doğrudan fiyatları modellemek çoğu zaman yanıltıcıdır. Fiyat serileri genellikle durağan değildir; ortalamaları ve oynaklıkları zamanla değişebilir. Bu nedenle analistler çoğunlukla getiri kullanır:

Logaritmik getiri ise farklı dönemleri toplamayı kolaylaştırır:

Örneğin fiyat 100’den 103’e çıkarsa basit getiri yaklaşık yüzde 3’tür. Bilgisayar açısından asıl soru şudur: Önceki getiriler, sıradaki getiri hakkında anlamlı bilgi taşıyor mu?

Bilgisayar hangi sinyalleri arar?

Algoritmalar trend, momentum, mevsimsellik, işlem hacmi ve oynaklık gibi özellikleri araştırabilir. Ancak bulunan her ilişki gerçek bir ekonomik mekanizma değildir. Bazen model, verideki rastlantısal gürültüyü öğrenir; buna aşırı öğrenme denir.

Basit bir hareketli ortalama, son $n$ fiyatın ortalamasıdır:

Kısa dönemli ortalama uzun dönemli ortalamayı geçtiğinde yükseliş sinyali üretilebilir. Ne var ki bu, geleceğin kesin yükseleceği anlamına gelmez; yalnızca geçmiş hareketin belirli bir özetidir.

Python ile küçük bir deney

Aşağıdaki kod fiyatlardan getiri üretir, beş günlük hareketli ortalamayı hesaplar ve bir sonraki günün yönünü tahmin etmek için lojistik regresyon kullanır:

import pandas as pd
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score

# CSV dosyasında Date ve Close sütunları bulunduğunu varsayıyoruz.
df = pd.read_csv("prices.csv", parse_dates=["Date"])
df = df.sort_values("Date")

df["return"] = df["Close"].pct_change()
df["ma5"] = df["Close"].rolling(5).mean()
df["distance"] = df["Close"] / df["ma5"] - 1
df["target"] = (df["return"].shift(-1) > 0).astype(int)
df = df.dropna()

split = int(len(df) * 0.8)
train, test = df.iloc[:split], df.iloc[split:]

features = ["return", "distance"]
model = LogisticRegression()
model.fit(train[features], train["target"])

prediction = model.predict(test[features])
print("Doğruluk:", accuracy_score(test["target"], prediction))

Buradaki kronolojik ayırma kritik önemdedir. Veriyi rastgele karıştırmak, gelecekteki bilgilerin eğitim kümesine sızmasına yol açabilir. Bu durum modelin gerçekte sahip olamayacağı bir avantaj kazanmasıdır.

Tahmin başarısı nasıl değerlendirilir?

Yüzde 52 doğruluk ilk bakışta etkileyici görünmeyebilir; ancak işlem maliyetleri düşükse değerli olabilir. Tersine, yüzde 60 doğruluk yüksek komisyonlar ve büyük kayıplar nedeniyle zararla sonuçlanabilir. Bu yüzden doğruluğun yanında getiri, maksimum düşüş, Sharpe oranı ve işlem maliyetleri incelenmelidir.

Bilgisayar geçmişten olasılıksal ilişkiler öğrenebilir; fakat savaşlar, düzenlemeler, şirket haberleri ve yatırımcı psikolojisindeki kırılmalar geçmişte bulunmayabilir. En iyi yaklaşım, modeli bir kâhin değil, belirsizlik altında karar vermeye yardımcı olan ölçüm aracı olarak görmektir. Finansal tahminin asıl başarısı geleceği kusursuz bilmekten değil, yanlış çıkıldığında riski yönetebilmekten gelir.

``

Segmentasyon neden gereklidir?

Segmentasyon, görüntüdeki her pikselin hücreye mi yoksa arka plana mı ait olduğuna karar verme işlemidir. Gri tonlu bir görüntü matematiksel olarak $I(x,y)$ yoğunluk fonksiyonuyla temsil edilebilir. En basit yaklaşımda bir eşik değeri $T$ seçilir:

Burada $M$, ikili hücre maskesidir. Kan hücreleri arka plandan daha koyu görünüyorsa eşikten küçük pikseller hücre kabul edilir. Ancak sabit eşik, düzensiz aydınlatmada başarısız olabilir. Otsu yöntemi, sınıf içi varyansı küçülten eşiği otomatik seçer; adaptif eşikleme ise görüntünün farklı bölgeleri için farklı eşikler hesaplar.

İşlem hattı nasıl çalışır?

Tipik bir hücre sayım sistemi şu adımları izler:

1. Ön işleme: Görüntü yeniden boyutlandırılır, gri tona çevrilir ve Gauss filtresiyle gürültü azaltılır.
2. Segmentasyon: Otsu, adaptif eşikleme veya renk uzayı analiziyle hücre maskesi üretilir.
3. Morfolojik düzeltme: Açma işlemi küçük lekeleri temizler; kapama işlemi hücre içindeki boşlukları doldurur.
4. Hücreleri ayırma: Birbirine temas eden hücreler distance transform ve watershed algoritmasıyla ayrılır.
5. Sayım: Bağlı bileşenler veya konturlar bulunur; alanı makul aralıkta olan nesneler hücre kabul edilir.

İkili maskede hücre alanı, hücreye ait piksellerin toplamıdır:

Bir konturun alanı $A$, çevresi $P$ ise dairesellik $C=\frac{4\pi A}{P^2}$ ile ölçülebilir. Kusursuz çemberde $C=1$ olur. Böylece uzun çizikler veya boya kalıntıları hücrelerden ayrılabilir.

Python ve OpenCV ile örnek sayım

Aşağıdaki kod, hücreleri koyu nesneler olarak kabul eder. Gürültüyü temizler, dış konturları bulur ve çok küçük parçaları sayım dışında bırakır:

import cv2
import numpy as np

image = cv2.imread("kan_ornegi.jpg")
gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
blurred = cv2.GaussianBlur(gray, (5, 5), 0)

# Koyu hücreleri beyaz maskeye dönüştürür.
_, mask = cv2.threshold(
    blurred, 0, 255,
    cv2.THRESH_BINARY_INV + cv2.THRESH_OTSU
)

# Küçük gürültüleri morfolojik açma ile temizler.
kernel = np.ones((3, 3), np.uint8)
mask = cv2.morphologyEx(mask, cv2.MORPH_OPEN, kernel, iterations=2)

contours, _ = cv2.findContours(
    mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE
)

cells = []
for contour in contours:
    area = cv2.contourArea(contour)
    if 150 < area < 5000:
        cells.append(contour)
        cv2.drawContours(image, [contour], -1, (0, 255, 0), 2)

print(f"Tahmini hücre sayısı: {len(cells)}")
cv2.imwrite("sonuc.jpg", image)

Alan sınırları mikroskobun büyütmesine ve görüntü çözünürlüğüne göre kalibre edilmelidir. Sabit 150 değeri her laboratuvar görüntüsünde sihirli biçimde çalışmaz; ne yazık ki algoritmaların da mikroskop ayarı vardır!

Üst üste binen hücreler ve doğrulama

Basit kontur sayımı, temas eden üç hücreyi tek nesne sanabilir. Watershed yaklaşımı, distance transform üzerindeki yerel tepeleri hücre merkezleri olarak kullanıp birleşik bölgeleri ayırır. Daha karmaşık örneklerde U-Net veya Mask R-CNN gibi modeller, piksel düzeyinde segmentasyon sağlayabilir.

Sistemin başarısı yalnızca tahmini sayıya bakılarak ölçülmemelidir. Uzman tarafından hazırlanmış gerçek maske ile karşılaştırma yapılabilir. Kesişim-birleşim oranı

şeklindedir. Ayrıca sayım hatası için $MAE=\frac{1}{n}\sum \vert y_i-\hat{y}_i\vert $ kullanılabilir. Yüksek IoU doğru sınırları, düşük MAE ise doğru hücre sayısını gösterir. Böylece sistem sadece hızlı değil, ölçülebilir biçimde güvenilir hâle gelir.

``

Her Şeyin Kalbi: Oyun Döngüsü

Oyun motorlarının merkezinde game loop, yani oyun döngüsü bulunur. Motor çalıştığı sürece bu döngü girdiyi okur, oyun dünyasını günceller ve yeni kareyi ekrana gönderir.

Basitleştirilmiş akış şöyledir:

while oyun_calışıyor:
    girdileri_oku()
    fiziği_hesapla()
    oyun_mantığını_güncelle()
    sahneyi_render_et()

Bir karenin işlenme süresi ile saniyedeki kare sayısı arasındaki ilişki şu formülle gösterilebilir:

Örneğin bir kare $0.0166$ saniyede hazırlanıyorsa oyun yaklaşık $60$ FPS üretir. Ancak bütün sistemleri değişken $\Delta t$ ile güncellemek doğru değildir. Render döngüsü ekran hızına göre değişebilirken fizik hesaplamaları çoğunlukla sabit zaman aralıklarında çalıştırılır.

Render Döngüsü Nasıl Çalışır?

Render sistemi, oyun dünyasındaki nesneleri GPU’nun anlayabileceği komutlara dönüştürür. Kamera dışında kalan nesneler ayıklanır, görünür yüzeyler belirlenir, materyaller hazırlanır ve çizim komutları GPU’ya gönderilir.

Unity; Built-in, URP ve HDRP gibi farklı render yaklaşımları sunar. Unreal Engine ise deferred rendering, Nanite ve Lumen gibi sistemlerle yüksek detaylı sahneleri yönetir. Her iki motorda da amaç aynıdır: Görsel kaliteyi korurken kare süresini bütçe içinde tutmak. 60 FPS hedefinde bu bütçe yaklaşık $16.67$ milisaniyedir.

Fizik Neden Sabit Döngü Kullanır?

Fizik motorları çarpışma, hız, ivme ve kuvvet hesaplarını mümkün olduğunca tutarlı gerçekleştirmelidir. Temel hareket denklemlerinden biri şöyledir:

$\Delta t$ sürekli değişirse aynı kuvvet farklı bilgisayarlarda farklı sonuçlar üretebilir. Unity bu nedenle fizik işlemlerini ağırlıklı olarak FixedUpdate düzeninde yürütür. Unreal Engine tarafında fizik güncellemeleri tick grupları ve alt adımlar aracılığıyla kontrol edilebilir.

Girdi Sistemi ve Gecikme

Klavye, fare veya kontrolcü verileri işletim sisteminden alınır ve motorun girdi katmanına aktarılır. Girdi mümkün olduğunca erken okunursa oyuncunun yaptığı hareket ile ekrandaki sonuç arasındaki gecikme azalır.

void Update()
{
    float yatay = Input.GetAxis("Horizontal");
    hareketYonü = new Vector3(yatay, 0f, 0f);
}

void FixedUpdate()
{
    govde.AddForce(hareketYonü * kuvvet);
}

Bu Unity örneğinde girdi her karede okunur; fiziksel kuvvet ise sabit döngüde uygulanır. Böylece kısa süreli tuş hareketleri kaçırılmaz ve fizik davranışı kare hızından daha az etkilenir. Modern Unity Input System ve Unreal Enhanced Input, girdileri eylem tabanlı tanımlayarak farklı cihazları ortak bir soyutlama altında toplar.

İş Parçacıkları ve Senkronizasyon

Güncel motorlar tüm işleri tek çekirdekte yürütmez. Render hazırlığı, animasyon, ses ve fizik görevleri iş parçacıklarına dağıtılabilir. Unity Job System ve Unreal Task Graph bu yaklaşımın örnekleridir. Yine de render, fizik ve oyun mantığı birbirinin verisine ihtiyaç duyduğundan senkronizasyon noktaları oluşur. Bir görev geciktiğinde diğer sistemler bekleyebilir.

Sonuç olarak oyun motoru, farklı hızlarda çalışan orkestraya benzer. Girdi sistemi notaları toplar, fizik ritmi korur, render sistemi ise performansı seyirciye sunar. Başarılı bir oyun mimarisi, bu döngülerin doğru sırada ve mümkün olduğunca az bekleyerek çalışmasını sağlar.

Bir oyunun zorlu olması başka, bazı oyuncular için gereksiz yere oynanamaz olması başkadır. Küçük yazılar, yalnızca renkle aktarılan bilgiler veya altyazısız diyaloglar; geliştiricinin fark etmeden koyduğu engellere dönüşebilir. Erişilebilirlik tasarımı, oyunu basitleştirmek değil, oyuncuların bilgiye farklı yollarla ulaşmasını sağlayarak gerçek oyun deneyimine katılmalarını mümkün kılmaktır. ``

Erişilebilirlik neden temel bir tasarım kararıdır?

Erişilebilirlik, geliştirme bittikten sonra ayarlar menüsüne eklenen birkaç kutucuktan ibaret değildir. Oyunun görsel dili, ses sistemi, kontrolleri ve geri bildirim mekanizmaları tasarlanırken ele alınmalıdır. Bunun temelinde eşdeğer bilgi ilkesi bulunur: Önemli bir bilgi yalnızca tek duyusal kanalla aktarılmamalıdır.

Örneğin yaklaşan bir düşman sadece ayak sesiyle haber veriliyorsa işitme engelli oyuncu dezavantaj yaşar. Aynı bilgi ekrandaki yön göstergesi, titreşim veya görsel efekt ile de sunulabilir. Benzer biçimde, takım üyelerini yalnızca kırmızı ve yeşil renkle ayırmak bazı renk körlüğü türlerinde sistemi kullanışsız hâle getirir.

Renk tek başına konuşmamalı

Renk körlüğü tek bir durum değildir. Deuteranopi yeşil, protanopi kırmızı, tritanopi ise mavi tonlarının algılanmasını etkileyebilir. Bu nedenle hazır bir “renk körü filtresi” her zaman yeterli olmaz. Bilgiyi renk dışında şekil, ikon, metin ve desenle desteklemek daha güvenlidir.

Metin ve arka plan okunabilirliğinde kontrast oranı önemli bir ölçüdür:

Burada $L$, rengin göreli parlaklığıdır. $C$ yükseldikçe öğeleri ayırt etmek kolaylaşır. Ancak matematiksel olarak yeterli kontrast, hareketli ve karmaşık bir sahnede otomatik olarak iyi okunabilirlik anlamına gelmez. Tasarım gerçek oyun görüntüleri üzerinde test edilmelidir.

Sesleri görünür hâle getirmek

Altyazı yalnızca konuşma metni değildir. Konuşmacının kimliği, sesin yönü ve önemli çevresel sesler de aktarılabilir:

• [Sol taraftan metal sürtünmesi]
• Komutan: Kapıyı kapat!
• [Müzik hızlanır]

Oyuncuya yazı boyutu, arka plan opaklığı ve konuşmacı rengi seçenekleri vermek altyazıları çok daha kullanışlı yapar. Rekabetçi oyunlarda görsel ses göstergeleri dikkatle dengelenmeli; erişilebilirlik seçeneği, sesi kullanan oyunculardan daha fazla taktik bilgi vermemelidir.

Ayarları veri odaklı tasarlamak

Aşağıdaki Unity C# örneği, altyazı tercihlerini tek bir yapı içinde tutar ve arayüzün bu ayarlara göre güncellenmesini sağlar:

using UnityEngine;

[System.Serializable]
public class AccessibilitySettings
{
    public bool subtitlesEnabled = true;
    [Range(18, 48)] public int subtitleSize = 28;
    [Range(0f, 1f)] public float backgroundOpacity = 0.75f;
    public bool showSoundDirection = true;
}

public class AccessibilityManager : MonoBehaviour
{
    public AccessibilitySettings settings;
    public SubtitleView subtitleView;

    public void ApplySettings()
    {
        subtitleView.gameObject.SetActive(settings.subtitlesEnabled);
        subtitleView.SetFontSize(settings.subtitleSize);
        subtitleView.SetBackgroundOpacity(settings.backgroundOpacity);
        subtitleView.ShowDirection(settings.showSoundDirection);
    }
}

Bu yaklaşım, değerleri oyun koduna gömmek yerine merkezi ve kaydedilebilir hâle getirir. Aynı model renk paletleri, titreşim yoğunluğu ve kontrol şemaları için genişletilebilir.

Son kontrol: Oyuncuyla test

Simülasyon araçları yararlıdır fakat gerçek kullanıcı testlerinin yerini tutmaz. Farklı ihtiyaçlara sahip oyuncular geliştirme sürecine erken katılmalı, ayarlar ilk açılışta bulunabilir olmalı ve seçeneklerin etkisi anında önizlenebilmelidir. Sonuçta erişilebilir tasarım yalnızca belirli gruplara yardım etmez; gürültülü ortamda altyazı kullanan, küçük ekranda oynayan veya geçici sakatlık yaşayan herkese daha esnek bir deneyim sunar. İyi erişilebilirlik görünmez bir yardımcı gibidir: İhtiyaç duyulduğunda oradadır ve oyuncuyla oyun arasındaki gereksiz duvarları kaldırır.

Bir oyunda verdiğiniz masum bir kararın saatler sonra bir krallığın çökmesine yol açtığını düşünün. Bu sonuç önceden yazılmış tek bir senaryodan değil, seçimlerinizi değerlendiren dinamik bir hikâye motorundan doğabilir. Prosedürel anlatı; karakterleri, olayları ve sonuçları belirli kurallar doğrultusunda birleştirerek her oyuncuya farklı bir hikâye deneyimi sunmayı amaçlar.

``

Prosedürel anlatı nedir?

Geleneksel anlatıda yazar, olayların sırasını büyük ölçüde önceden belirler. Oyuncu bazen farklı yollar seçse de bunlar çoğunlukla elle yazılmış dallardır. Prosedürel anlatıda ise yazar yalnızca olayları değil, olay üretme kurallarını da tasarlar.

Bir hikâye motorunun kararını basitçe şöyle modelleyebiliriz:

Burada $S_t$ mevcut dünya durumunu, $A_t$ oyuncunun eylemini, $R$ anlatı kurallarını ve $S_{t+1}$ yeni durumu temsil eder. Örneğin oyuncu bir tüccarı soyarsa para miktarı artabilir; fakat itibar düşer, muhafızların şüphe seviyesi yükselir ve tüccarın ailesi ileride intikam görevi başlatabilir.

Durum değişkenleri ve koşullar

Dinamik hikâye motorlarının hafızası, durum değişkenlerinden oluşur. İtibar, korku, sadakat, kaynak miktarı ve karakter ilişkileri bu değişkenlere örnektir. Motor, uygun olayları seçerken koşulları kontrol eder.

Aşağıdaki Python örneği, dünya durumuna göre yeni bir anlatı olayı seçer:

import random

def uygun_olaylari_bul(durum, olaylar):
    uygunlar = []

    for olay in olaylar:
        kosullar = olay["kosullar"]
        if all(durum.get(anahtar, 0) >= deger
               for anahtar, deger in kosullar.items()):
            uygunlar.append(olay)

    return uygunlar

def olay_sec(durum, olaylar):
    uygunlar = uygun_olaylari_bul(durum, olaylar)
    return random.choice(uygunlar) if uygunlar else None

olaylar = [
    {"ad": "Köylülerin İsyanı", "kosullar": {"korku": 70}},
    {"ad": "Kraliyet Daveti", "kosullar": {"itibar": 60}},
    {"ad": "Gizemli Tüccar", "kosullar": {"altin": 20}}
]

uygun_olaylari_bul fonksiyonu, koşulları sağlanan olayları filtreler. olay_sec ise bunlardan birini rastgele seçer. Gerçek bir motorda rastgelelik genellikle ağırlıklıdır; önemli olayların seçilme ihtimali daha yüksek tutulabilir.

Bir olayın puanı şu şekilde hesaplanabilir:

Burada $R$ rastgelelik, $D$ dramatik değer, $C$ mevcut durumla uyum ve $T$ yakın zamanda tekrar edilme cezasıdır. $w$ katsayıları tasarımcının hangi özelliğe önem verdiğini belirler.

Anlamlı seçim nasıl üretilir?

Her seçimin dünyayı değiştirmesi gerekmez; ancak oyuncu, kararının fark edildiğini hissetmelidir. İyi bir sistem üç katmanda tepki verir:

1. Anlık sonuç: Karakter hemen kızar veya ödül verir.
2. Sistemsel sonuç: İtibar, ekonomi ya da ilişki değeri değişir.
3. Gecikmiş sonuç: Eski karar, saatler sonra yeni bir görev veya düşman üretir.

Buradaki en büyük tehlike, sayısız ama yüzeysel seçenek sunmaktır. Beş anlamsız düğme yerine, bedeli açık olmayan iki güçlü seçenek genellikle daha etkilidir. Ayrıca sistemin tamamen kontrolsüz olması komik tutarsızlıklar doğurabilir: Dün ölen kralın bugün oyuncuya mektup göndermesi gibi!

Tasarımcı hâlâ hikâyenin yazarı mı?

Evet; fakat artık yalnızca sahneleri değil, olasılık uzayını da yazar. Karakterlerin hedeflerini, dünyanın sınırlarını ve hangi olayların birlikte anlamlı olduğunu tanımlar. Böylece motor doğaçlama yaparken temadan kopmaz.

Başarılı bir dinamik hikâye motoru, matematiksel kurallar ile insan yaratıcılığını birleştirir. Amaç sonsuz içerik üretmek değil, oyuncunun seçimlerinin hatırlandığına ve dünyanın gerçekten karşılık verdiğine inanmasını sağlamaktır.

``

Speedrun yalnızca hızlı oynamak değildir

Speedrun, belirlenmiş kurallar altında bir oyunu ya da oyun bölümünü en kısa sürede tamamlama yarışıdır. Oyuncular rotalarını tekrar tekrar deneyerek hareketleri, kaynak kullanımını ve savaşları optimize eder. Bu süreç matematiksel olarak bir maliyet minimizasyonuna benzetilebilir:

Amaç, toplam süreyi küçültmektir. Bir kısayol hareket süresini 20 saniye azaltırken başarısız olma riski nedeniyle ortalama 30 saniye kaybettiriyorsa rekor denemesi için uygun olmayabilir. Bu nedenle oyuncular yalnızca tekniğin teorik kazancını değil, başarı olasılığını da değerlendirir:

Buradaki $p$, hareketin başarı ihtimalidir. Dünya rekoru peşindeki oyuncu düşük olasılıklı bir yöntemi seçebilirken maraton yayınındaki oyuncu daha güvenli bir rota kullanabilir.

Glitch nasıl keşfedilir?

Glitch, oyunun kodu ile oyuncunun eylemleri arasındaki beklenmeyen etkileşimdir. Keşif bazen tesadüfen gerçekleşir: Oyuncu zıplarken menüyü açar ve karakter bir kapının arkasına ışınlanır. Topluluk daha sonra olayı yeniden üretmeye çalışır, gerekli koşulları belirler ve bulguları kare kare inceler.

Bir glitch’in geliştirilmesi genellikle şu aşamalardan geçer:

1. Gözlem: Beklenmeyen davranış fark edilir.
2. Yeniden üretim: Aynı sonucun hangi girdilerle oluştuğu aranır.
3. Modelleme: Kamera, çarpışma ve bellek gibi sistemlerin rolü incelenir.
4. Optimizasyon: Daha hızlı ve güvenilir uygulama geliştirilir.
5. Belgeleme: Video, zaman damgası ve rehber toplulukla paylaşılır.

Yani meşhur kısayol, çoğunlukla tek bir kişinin şans eseri bulduğu numaradan ziyade kolektif bir araştırma ürünüdür.

Kareler, girdiler ve ölçüm

60 FPS çalışan bir oyunda tek kare yaklaşık olarak $1/60$ saniye, yani 16,67 milisaniyedir. Bir hareket yalnızca iki karelik pencerede yapılabiliyorsa oyuncunun doğru girdiyi yaklaşık 33 milisaniyelik aralıkta vermesi gerekir. Bu yüzden speedrunner’lar kayıtlarını analiz eden küçük araçlar kullanır.

splitler = [42.18, 39.72, 41.05, 38.91]
hedef = 40.00

for bolum, sure in enumerate(splitler, start=1):
    fark = sure - hedef
    durum = "yavaş" if fark > 0 else "hızlı"
    print(f"Bölüm {bolum}: {abs(fark):.2f} sn {durum}")

Bu Python örneği, bölüm sürelerini hedef değerle karşılaştırır. Gerçek analiz araçları aynı mantığı kişisel en iyi dereceler, ortalamalar ve rota alternatifleri üzerinde uygular.

Glitch kullanmak hile midir?

Cevap kategoriye bağlıdır. Any% kategorisi oyunu izin verilen her yöntemle bitirmeyi hedefler. Glitchless kategorisi belirli hataları yasaklar. 100% ise tanımlanan tüm içeriklerin tamamlanmasını ister. Kuralları topluluk belirler; emülatör, mod, makro veya dışarıdan kod müdahalesi çoğunlukla yasaktır.

Speedrun kültürünü ilginç yapan şey, oyuncuların oyunu bozarken aslında onu olağanüstü ayrıntılı biçimde öğrenmesidir. Geliştiricinin kurduğu dünya bir laboratuvara, kontrolcü deney aracına, her başarısız deneme de yeni bir veri noktasına dönüşür. Ekranda birkaç saniyelik kısayol görünür; arkasında ise yüzlerce saatlik merak, iş birliği ve ustalık vardır.

``

Temel teknoloji: WebRTC

Modern telemedicine uygulamalarının büyük bölümü WebRTC teknolojisinden yararlanır. WebRTC, tarayıcılar ve mobil uygulamalar arasında eklenti gerektirmeden gerçek zamanlı ses, video ve veri aktarımı sağlar. İletişim mümkün olduğunda eşler arası, yani P2P kurulur. Böylece medya paketleri gereksiz bir uygulama sunucusu turu yapmaz.

Bir görüşmenin yaklaşık uçtan uca gecikmesi şöyle modellenebilir:

Burada kamera görüntüsünün alınması, sıkıştırılması, ağ üzerinden taşınması, çözülmesi ve ekranda gösterilmesi ayrı ayrı gecikme üretir. Akıcı bir görüşme için toplam gecikmenin genellikle 300 milisaniyenin altında tutulması hedeflenir.

Bağlantı nasıl kuruluyor?

WebRTC medya aktarımını yönetir ancak tarafların birbirini bulması için bir signaling sunucusu gerekir. Bu sunucu SDP adı verilen oturum bilgilerini ve ICE adaylarını aktarır. Ardından STUN sunucusu cihazların genel ağ adreslerini keşfetmesine yardımcı olur. Kurumsal ağ veya sıkı bir güvenlik duvarı doğrudan bağlantıyı engellerse trafik TURN sunucusu üzerinden geçirilir.

const connection = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:stun.example.com:3478" },
    {
      urls: "turn:turn.example.com:3478",
      username: "temporary-user",
      credential: "temporary-password"
    }
  ]
});

const stream = await navigator.mediaDevices.getUserMedia({
  video: { width: 1280, height: 720 },
  audio: { echoCancellation: true, noiseSuppression: true }
});

stream.getTracks().forEach(track => connection.addTrack(track, stream));

Bu örnek, kamera ve mikrofon akışını alarak WebRTC bağlantısına ekler. Gerçek sistemlerde TURN kimlik bilgileri kısa ömürlü üretilmeli; kaynak koduna sabit parola yazılmamalıdır.

Değişken ağ koşullarına uyum

Hastalar her zaman güçlü Wi-Fi kullanmaz. Paket kaybı, düşük bant genişliği ve titreşim anlamına gelen jitter, görüntüyü bozabilir. Platformlar bu sorunlara uyarlanabilir bit hızıyla karşılık verir. Ağ kötüleştiğinde önce çözünürlük veya kare hızı azaltılır; bağlantı iyileştiğinde kalite yeniden yükseltilir.

Gerekli ham veri miktarı kabaca şu ilişkiyle düşünülebilir:

$W$ ve $H$ çözünürlüğü, $FPS$ saniyedeki kare sayısını, $Q$ ise kalite katsayısını temsil eder. H.264, VP8, VP9 veya AV1 gibi codec’ler bu ham veriyi sıkıştırır. H.264 geniş cihaz desteği sunarken AV1 daha verimli sıkıştırma sağlayabilir fakat eski cihazlarda daha yüksek işlem yükü oluşturabilir.

SFU, kayıt ve ölçeklendirme

İki kişilik muayenede P2P yeterli olabilir. Görüşmeye uzman, tercüman veya hasta yakını katıldığında SFU kullanmak daha verimlidir. SFU, her katılımcıdan tek akış alır ve uygun kalitedeki katmanları diğer katılımcılara yönlendirir. Simulcast sayesinde istemci aynı videoyu düşük, orta ve yüksek kalite seçenekleriyle gönderebilir.

Sağlık verisi sıradan toplantı verisi değildir. Aktarım DTLS-SRTP ile şifrelenmeli, erişimler yetkilendirilmeli, kayıtlar açık rızaya bağlanmalı ve KVKK gibi düzenlemelere uygun saklanmalıdır. Ayrıca paket kaybı, gidiş-dönüş süresi, bitrate ve bağlantı kopmaları izlenmelidir. Kısacası başarılı bir telemedicine deneyimi yalnızca net görüntü değil; düşük gecikme, güvenli tasarım ve kötü ağlarda bile kontrollü biçimde çalışabilen dayanıklı bir sistem gerektirir.