Geliştirici Günlüğü #1: Sabit noktalı sayılar ve zar

Kısaca: MKA Engine'de oyun hesapları ondalıklı sayı (float) yerine sabit noktalı sayılarla (Q40.24) yapılır; böylece her bilgisayar aynı sonucu verir. Zar, durum tutmayan bir üreteçle atılır; aynı tohum ve aynı soru her zaman aynı zarı verir, atış sırası sonucu değiştirmez. Takvim 365 günlüktür ve artık yılı yoktur.
Bir strateji oyununda her şey üç şeyden yapılır: sayılar (nüfus, altın, istikrar), zar (savaşın sonucu, bir olayın çıkıp çıkmaması) ve takvim (bugün hangi gün, ay başı geldi mi). MKA Engine'in en alt katmanı bu üç aracı verir; üstteki her sistem bunların üzerine kurulur. Bu günlükte üçünü sırayla anlatacağız: nasıl çalıştıklarını, neden böyle yaptığımızı ve bedelini.
Üçünün ortak kuralı şu: aynı girdiden her zaman aynı sonuç çıkar. Bir kaydı yükleyince oyun aynı yoldan devam eder, bir hata aynen yeniden üretilebilir, bir oyun baştan sona tekrar oynatılabilir. Çok oyunculu oyunun bu kurala nasıl dayandığını ayrı bir günlükte, Çok oyunculu ve tutarlılık günlüğünde anlatıyoruz.
Birinci taş: sayılar
Bilgisayar 0,1'i bilmez
Bilgisayarlarda sayıların alışılmış tutulma biçimine ondalıklı (kayan noktalı) sayı denir. Bu biçim ondalık sayıları ikilik düzende yaklaşık tutar; en bilinen sonucu şudur: 0,1 + 0,2 işlemi 0,3 çıkmaz, 0,30000000000000004 çıkar. Bunun kendisi dert değil. Asıl dert, aynı formülün farklı makinede ya da farklı derleme ayarında farklı çıkabilmesi. Bazı işlemciler çarpma ve toplamı tek komutta birleştirir, bazıları ayrı ayrı yapar; ara sonuç farklı yuvarlandığı için iki yol farklı bit verebilir (Fiedler, Floating Point Determinism (yeni sekmede açılır)).
| İşlem | Ondalıklı sayı | MKA Engine sayısı (Fx) |
|---|---|---|
| 0,1 + 0,2 = 0,3 mü? | Hayır, 0,30000000000000004 çıkar | Evet, tam eşit |
| 0,1 × 10 − 1 (ayrı çarpma ve toplama) | 0 | 0,00000024 |
| 0,1 × 10 − 1 (birleşik komutla) | 0,0000000000000000555 | 0,00000024 |
| Sonuç her makinede aynı mı? | Derleme ve işlemciye göre değişebilir | Her zaman aynı |
Tabloda dikkat edilecek nokta, bizim sayımızın daha "doğru" olması değil. Bizim sayımız da 0,1'i tam tutamaz; en yakın değeri, 0,10000002384, tutar ve ikinci satırdaki 0,00000024 bu yüzden çıkar. Fark şurada: bu küçük hata her zaman aynı hatadır.
Çözüm: sayıları kuruş gibi tutmak

Bir banka hesabı lirayı kesirle değil, tam sayı kuruşla tutar: 12,50 lira, 1.250 kuruştur. Kuruşun yarısı diye bir şey yoktur; hesap tam sayılarla yapılır ve tam sayılar her bilgisayarda aynı çıkar. Biz de aynısını yapıyoruz, yalnız birimimiz kuruş değil, 1 / 16.777.216 (yani 2'nin 24. kuvvetinin tersi). Motorun sayı türü olan Fx, bu birimlerin kaç tane olduğunu tutan 64 bitlik bir tam sayıdır. Örneğin 1,0 sayısı, içeride 16.777.216 olarak durur.
- 64 bit bir sayının bellekteki boyu
- 40 bit tam kısım (sayının büyüklüğü)
- 24 bit kesir kısmı (sayının inceliği)
- ±549,76 milyar tutabildiği en büyük sayı
- 0,00000006 en küçük adım
Neden tam 40 ve 24 bit? Cetvel benzetmesi
Bir cetvel hem çok uzun hem çizgileri çok sık olamaz; 64 çizgilik bütçeyi bölüştürmek zorundasınız. Tam kısma çok bit verirseniz büyük sayılar sığar ama adımlar kabalaşır; kesire çok bit verirseniz incelik artar ama büyük sayılar sığmaz. Üç ayrı bölüşümü hesapladık:
| Biçim | En büyük sayı | En küçük adım | Günlük %1/yıl oranındaki hata | 100 yıl sonra 1 milyonluk şehir |
|---|---|---|---|---|
| 32 bit tam, 32 bit kesir | 2,1 milyar | 0,00000000023 | %0,0004 | 2.704.803 |
| 40 bit tam, 24 bit kesir (seçtiğimiz) | 549,76 milyar | 0,00000006 | %0,08 | 2.702.620 |
| 48 bit tam, 16 bit kesir | 140,7 trilyon | 0,000015 | %11,9 | 3.046.138 |
| Gerçek değer (kesin hesap) | — | — | — | 2.704.814 |
Birinci satır en hassas olanı ama 2,1 milyara kadar sayı taşıyor; dünya ve ülke para toplamları bunu aşabilir. Üçüncü satır çok büyük sayı taşıyor ama adımı o kadar kaba ki "yılda %1 büyüme" gibi küçük günlük oranları tutamıyor, oranı %11,9 yanlış tutuyor. İkinci satır ikisinin ortası: dünya toplamları rahat sığıyor ve günlük oranlar yüzde 0,08 hatayla tutuluyor. Karar budur.
Bunun ne demek olduğunu bir grafikle görelim. 1 milyon kişilik bir şehrin yılda %1 büyüdüğünü ve motorun bunu günde bir kez, 100 yıl boyunca hesapladığını düşünün. Her günün sonunda sonuç bizim adımımıza yuvarlanıyor; yuvarlama hatası her gün küçük bir iz bırakıyor.
100 yıl boyunca günlük hesapla büyüyen bir şehir (bin kişi)
| Etiket | Gerçek değer | Q40.24 | Q48.16 |
|---|---|---|---|
| 0 | 1.000,0 | 1.000,0 | 1.000,0 |
| 10 | 1.104,6 | 1.104,5 | 1.117,8 |
| 20 | 1.220,2 | 1.220,0 | 1.249,5 |
| 30 | 1.347,8 | 1.347,5 | 1.396,8 |
| 40 | 1.488,9 | 1.488,4 | 1.561,3 |
| 50 | 1.644,6 | 1.644,0 | 1.745,3 |
| 60 | 1.816,7 | 1.815,8 | 1.951,0 |
| 70 | 2.006,8 | 2.005,6 | 2.180,8 |
| 80 | 2.216,7 | 2.215,3 | 2.437,8 |
| 90 | 2.448,6 | 2.446,8 | 2.725,1 |
| 100 | 2.704,8 | 2.702,6 | 3.046,1 |
- Gerçek değer
- Q40.24
- Q48.16
Q40.24 gerçek değerin hemen üzerinde ilerliyor; 100 yıl sonunda fark 2.200 kişi civarında. Kaba biçim ise daha ilk 10 yılda yukarı sapıyor ve 100 yılda 340 bin kişi fazla buluyor. Strateji oyununun dilinde: kaba bir sayı biçimi, "yavaş büyüyen" bir ülkeyi sessizce "hızlı büyüyen" bir ülkeye çevirir.
Dört işlem ve yuvarlama
Toplama ve çıkarma düz tam sayı işlemidir. Çarpma ve bölme zorlar: iki Fx çarpılınca sonuç 24 değil 48 kesir bitli çıkar, geri 24 bite indirmek gerekir. Bunu, taşmasın diye araya daha geniş (128 bitlik) bir sayı koyarak yapıyoruz. Sonra 24 bite en yakın değere yuvarlıyoruz; tam yarıdaysa sıfırdan uzağa. Yani 2,5 → 3 ve −2,5 → −3. Bunun nedeni birikimdir: yarıları hep yukarı yuvarlasaydık, binlerce gün boyunca küçük hatalar hep aynı yöne yığılırdı. Sıfırdan uzağa yuvarlayınca artılar ve eksiler birbirini dengeler.
Bir de mul_div işlemi var: "a × b / c" hesabını ara adımda taşmadan ve tek yuvarlamayla yapar. Örneğin bir ülkenin gelirini bir oranla çarpıp bir sayıya bölmek, bir strateji oyununda çok gereken bir kalıptır; iki ayrı işlem yerine tek işlem, hem taşmayı hem de ikinci bir yuvarlama hatasını önler.
Bedel: Fx ondalıklı sayıdan yavaş
Dürüst olalım: bu yol ondalıklı sayıdan daha yavaş. Ne kadar yavaş olduğunu ölçtük.
Fx, ondalıklı sayıdan kaç kat yavaş? (kat)
| Etiket | Kaç kat yavaş |
|---|---|
| Toplama | 1,4 |
| Çarpma | 1,9 |
| Tamsayıya bölme | 4,6 |
| Bölme | 10,5 |
| Karekök | 7,5 |
| Üs (e üzeri x) | 28,6 |
| İşlem | Fx | Ondalıklı | Oran |
|---|---|---|---|
| Toplama | 1,23 ns | 0,91 ns | 1,4 kat |
| Çarpma | 1,88 ns | 0,99 ns | 1,9 kat |
| Tamsayıya bölme | 5,02 ns | 1,08 ns | 4,6 kat |
| Bölme | 11,56 ns | 1,10 ns | 10,5 kat |
| Karekök | 15,77 ns | 2,09 ns | 7,5 kat |
| Üs (e üzeri x) | 130,83 ns | 4,58 ns | 28,6 kat |
Toplama ve çarpma, motorun en sık yaptığı işlemlerdir ve burada fark küçük. Bölme, karekök ve üs çok daha pahalı; çünkü bölme 128 bitlik ara sonuçla yapılıyor; karekök ve üs ise bit bit aynı sonucu garanti eden, kendi yazdığımız tam sayı yöntemleri. Tamsayıya bölmeyi ise her sistemin sıcak yolunda olduğu için ayrıca 64 bitlik, daha ucuz bir yola indirdik; kodun kendi yorumu da sebebini söylüyor: 128 bitlik bölme yavaş bir kitaplık çağrısıdır. Tabloda bu, genel bölmenin yarısından az maliyetle görünüyor (5,02 ns'ye karşı 11,56 ns). Bu pahalı işlemleri sonradan hızlandırdık; yeni ölçümler Günlük #7'de.
Günlük #0'daki gün süreleri bu sayı türüyle alınmış ölçümlerdir; yani bu bedel o rakamların içinde zaten var. Aynı sonucu hız için feda etmiyoruz; hızı, bu bedeli ödedikten sonra başka yerlerden geri kazanıyoruz.
Taşarsa oyun durur
Fx'in sınırı ±549,76 milyar. Bir toplam bunu aşarsa ne olmalı? Üç yol var: sessizce yanlış sayıyla devam etmek, sınırda durmak ya da oyunu durdurmak. Normal işlemlerde oyunu durduruyoruz. Gerekçemiz şu: sessizce yanlış sayıyla devam eden bir oyunda hata fark edilmeden yıllarca sürer. Durdurunca hata hemen görünür ve son kayıtla komut günlüğünden aynen yeniden üretilebilir. Bu davranış her derlemede aynıdır; "hızlı sürümde kapalı" bir kontrol yoktur.
Kodun bilinçli olarak başka sonuç istediği yerler için iki ayrı işlem ailesi var: checked_* taşmayı "olmadı" diye bildirir, saturating_* sınırda kalır. Sıfıra bölme de aynı kuralla durdurur.
Karekök, üs ve logaritma
Bir stratejide sayılar yalnız toplanıp çarpılmaz; "nüfusun kareköküne bağlı etki" ya da "birikimli büyüme" gibi formüller de vardır. Bunlar için işlemcinin ya da kitaplığın hazır işlevlerini kullanamayız; çünkü bunların sonucu makineden makineye değişebilir. Karekök, üs, logaritma ve kuvveti yalnız tam sayı aritmetiğiyle, kendimiz yazdık.
Üs, logaritma ve kuvvet kendi içlerinde kesiri 24 değil 62 bitle (yani çok daha ince bir adımla) hesaplar; sonunda yalnız bir kez Fx'e yuvarlanır. Bu, adım adım yuvarlamanın hatayı büyütmesini önler. Her işlevin ne kadar yanılabileceği testlerle sabitlenmiştir:
| İşlev | Ne yapar | Testle sabit doğruluk sınırı |
|---|---|---|
| Karekök | √x | En yakın sonuç, yarım adım içinde |
| Üs | e üzeri x | Milyonda 1 ya da 2 adım; hangisi büyükse |
| Logaritma | x'in doğal logaritması | En çok 4 adım (0,00000024) |
| Kuvvet | x üzeri y | Yüz binde 1 ya da 1 adım; hangisi büyükse |
| Tamsayı kuvveti | x üzeri n | Tekrarlı çarpma, sabit sırayla |
"Adım", yukarıdaki 0,00000006'dır. Üsün tanım aralığı da sınırlıdır: −17,3'ün altında sonuç sıfıra yuvarlanır, 27'nin biraz üstünde sayı sığmaz ve işlem "olmadı" diye bildirir. Trigonometri şimdilik yoktur; bir büyük strateji oyununun sinüs ve kosinüse neredeyse hiç ihtiyacı olmadığı için, gerekince eklenecek.
İçerik dosyasındaki "12.5" nasıl okunur?
Oyunun ve modların sayıları, düz metin dosyalarında yazılıdır: "12.5" gibi. Bu metni önce ondalıklı sayıya çevirip sonra bizim türümüze çevirmek, kuralı daha ilk adımda bozardı. Bu yüzden metin, ondalıklı sayıya hiç uğramadan, rakamlarından doğrudan okunur: tam kısım, kesir kısmı ve tam sayı aritmetiğiyle en yakın Fx. Noktadan sonra en çok 18 rakam okunur; harf, ikinci bir nokta ya da sınırı aşan sayı hata verir, sessizce düzeltilmez.
İkinci taş: zar

Strateji oyununda şans her yerdedir: bir kuşatmanın bugün düşüp düşmeyeceği, bir olayın çıkması, bir komutanın yaralanması. Bilgisayar gerçekten zar atamaz; "rastgele" görünen sayıları bir formülle üretir. Önemli olan, bu formülün nasıl beslendiği.
Deste mi, çekmece mi?
Alışılmış yöntem bir iskambil destesine benzer: kartlar sırayla çekilir ve her çekilen kart bir sonrakini belirler. Sorun şudur: iki sistem aynı desteden çekiyorsa, hangisinin önce çektiği sonucu değiştirir. Bugün motorun hesapları birden çok iş parçacığına bölünüyor ve iş parçacıklarının hangi sırayla çalışacağı her seferinde farklı olabilir. Desteyle çalışan bir oyun, iki koşuda iki farklı tarih üretir.
Bu yüzden desteyi bıraktık. Bizim zarımız, milyarlarca çekmeceli dev bir dolaba benzer. Her çekmecenin içinde önceden belirlenmiş bir zar sonucu durur ve çekmecenin adresi beş bilgiden oluşur:
| Adres parçası | Ne anlatır | Örnek |
|---|---|---|
| Tohum | Hangi oyun | Oyun başlarken seçilen sayı |
| Adım | Hangi gün ya da tur | 1444 yılının 200. günü |
| Sistem | Zarı kim atıyor | Kuşatma sistemi |
| Varlık | Kimin için | 42 numaralı ordu |
| Çekiliş | O gün kaçıncı zar | İlk zar, ikinci zar |
Sonuç yalnız bu adrese bağlıdır; daha önce kaç zar atıldığına ya da hangi sırayla atıldığına bağlı değildir. Kuşatma sistemi ile olay sistemi aynı anda, farklı çekirdeklerde zar atabilir; hangisi önce biterse bitsin her biri kendi çekmecesini açar. Teknik adıyla buna "durumsuz, sayaç tabanlı" rastgelelik denir: adres, bir karıştırma formülünden (SplitMix64'ün son adımı) geçirilir ve çıkan 64 bitlik sayı zarın sonucudur.
Kendi ölçümümüzde bunu doğruladık: aynı 1.000 adresi önce baştan sona, sonra sondan başa okuduk; iki okuma birebir aynı sonuçları verdi. Tohum değişince ise bütün dolap değişir:
| Gün | 1. gün | 2. gün | 3. gün | 4. gün | 5. gün |
|---|---|---|---|---|---|
| Tohum 1444 | 3 | 3 | 5 | 4 | 6 |
| Tohum 1445 | 2 | 5 | 6 | 3 | 6 |
Aynı tohumla oyun her açılışta bu sırayı verir. Bir kaydı yükleyip aynı günü aynı kararlarla yeniden oynayan biri aynı zarları görür; yalnız kaydı yükleyerek zarı değiştiremez.
Zar adil mi?
Bir zarın tutarlı olması yetmez, adil de olmalı. 6 milyon zar attık ve her yüzün kaç kez geldiğini saydık:
6 milyon zar atışında her yüz kaç kez geldi? (bin atış)
| Etiket | Gelen |
|---|---|
| 1 | 999,98 |
| 2 | 999,51 |
| 3 | 1.000,15 |
| 4 | 1.001,71 |
| 5 | 998,71 |
| 6 | 999,94 |
Her yüz bir milyona çok yakın geldi; sapmalar gerçek bir zarda da göreceğiniz türden küçük dalgalanmalar. "%30 ihtimal" sorusunu da 6 milyon kez sorduk; cevap %30,05 oranında "evet" çıktı. Şans hesabı da sabit noktalı sayıyla yapılır, yani "%30" ondalıklı sayıya hiç uğramaz.
Bir ayrıntı daha: "1 ile 6 arası bir sayı" üretirken 64 bitlik sonucu 6'ya bölüp kalanı almak bazı yüzleri çok az da olsa kayırır. Biz bunun yerine 128 bitlik bir çarpımın üst yarısını alıyoruz; bu yöntemde bir çekiliş tek bir değer verir ve kayırma payı en çok 6 / 2⁶⁴, yani pratikte sıfırdır.
Karıştırma formülü ve sabitleri dondurulmuştur. Değişirlerse her kayıtlı oyunun geleceği değişir ve tekrar oynatmalar bozulur; bu yüzden bunlar motorun "dokunulmaz" parçalarındandır.
Üçüncü taş: takvim

Oyunda zaman duvardaki saate göre değil, masa oyunundaki tur sayacına göre akar. Bilgisayarınız yavaş ya da hızlı olabilir, oyunu duraklatabilir ya da en hızlıya alabilirsiniz; simülasyonun içinde bunların hiçbiri görünmez. Simülasyon yalnız "şu an hangi gün ve hangi tur" bilgisini bilir. Gerçek saat, dosya ve ağ motorun çekirdeğine giremez.
365 gün, artık yıl yok
- 365 günlük yıl, her yıl aynı
- 12 standart uzunlukta ay
- 0 artık yıl
- ±5,8 milyon yıl tarihin taşınabildiği aralık
Bir tarih, "0. yılın 1 Ocak'ından bu yana kaç gün geçti" diye tek bir tam sayı olarak tutulur; milattan önceki yıllar da geçerlidir. Ekranda ve veri dosyalarında 1444.11.11 gibi yazılır. Her yıl aynı on iki aydan oluştuğu için tarih hesabı düz tam sayı hesabıdır: "90 gün sonra hangi tarih" sorusu bir toplama ve bir bölmedir.
Artık yılın olmamasının bir bedeli var: gerçek yıl yaklaşık 365,24 gündür, bizim yılımız tam 365. Oyun takvimi her yıl gerçek takvimden yaklaşık 6 saat geri kalır; 400 yılda bu yaklaşık 97 gün eder. Bir oyun için bu bilinçli bir seçim: tarih bir etikettir, gökbilim hesabı değildir. Karşılığında 29 Şubat'ın yarattığı bütün özel durumlar ortadan kalkar; "her yıl aynı gün" kuralı her yıl gerçekten aynı güne düşer.
Gün içi turlar
Bir gün her oyun için en küçük adım olmayabilir. Bazı strateji oyunları savaşı ve hareketi saat saat yürütür; bazıları ise haftalık ya da aylık adımla yetinir. Bu yüzden adımın uzunluğunu motor değil oyun seçer:
| Oyun neyi seçer | Seçenekler |
|---|---|
| Adımın uzunluğu | Günde N tur (örneğin 2 ya da 24), günlük, haftalık ya da takvim ayı |
| Her sistemin sıklığı | Her adım, günlük, haftalık, aylık ya da yıllık |
Zaman artık "gün + gün içi tur" ikilisidir; veri dosyalarında 1444.11.11.12 gibi yazılır. Bir günün turları toplandığında tam olarak bir gün eder; yuvarlama günün sonunu kaydırmaz. Aylık bir sistem, ayın işini tek güne yığmak yerine ayın günlerine varlık varlık yayabilir; böylece ay başında oyun takılmaz. Zarın adresindeki "adım" da bu adım numarasıdır.
Kanıt: altın dosyalar
"Hep aynı sonuç" demek kolay; kanıtı şu: depoda bu üç aracın "altın dosyaları" duruyor. İçlerinde önceden hesaplanıp kaydedilmiş sonuçlar var. Her test koşusunda motor bu sonuçları yeniden hesaplayıp kayıtla bit bit karşılaştırır; tek bir bit fark testi kırar.
Sayılar için temel işlemlerin ve matematik işlevlerinin, zar için her çekiliş türünün, takvim için tarih okuma ve gün eklemenin sonuçları bu dosyalarda kayıtlıdır.
Aynı kayıtlar farklı işlemcilerde de aynı çıkmak zorunda; bunun nasıl sınandığını Çok oyunculu ve tutarlılık günlüğünde anlatıyoruz.
Sınırlar
- Sayılar daha yavaş: Yukarıdaki tablodaki oranlar gerçek. Sıcak yolda bölme, karekök ve üs kullanımı bilinçli ve ölçülü olmalı.
- Sınırlı incelik: 0,00000006'dan küçük bir fark görünmez. Bu, oyun için yeterli ama bir bilim hesabı için değil.
- Sınırlı büyüklük: 549,76 milyarı aşan bir birikim, örneğin çok uzun dönem toplam istatistiği, bugünkü sayıya sığmaz. Gerekirse ayrı, daha geniş bir toplayıcı yazılacak; şimdilik yazılmadı.
- Trigonometri yok: Gerek çıkınca eklenecek.
- Zarın formülü dondurulmuş: Daha iyi bir karıştırma formülü bulsak da değiştiremeyiz; değiştirmek eski kayıtları bozar.
- Takvim gerçek takvimden kayar: Yılda yaklaşık 6 saat. Gerçek bir tarihle birebir eşleşme gereken bir oyun bunu kendi içeriğinde düzeltmek zorunda.
- Ölçümlerin kapsamı: Hız tablosu ve zar sayımı basit ölçümlerdir; gerçek bir oyun gününün hesabı yerine geçmez.
Sık sorulanlar
Oyunlarda neden ondalıklı sayı (float) kullanılmıyor?
Kullanılabilir, ama ondalıklı sayılar farklı işlemcilerde ve derleyicilerde en son basamakta farklı sonuç verebilir. Çok oyunculu kilit adım oyununda bu küçük fark birikip iki oyuncunun dünyasını ayırır. Sabit noktalı sayılar her yerde aynı sonucu verir.
Sabit noktalı sayılar ne kadar yavaş?
Basit ölçümümüzde toplama ondalıklı sayıdan 1,4 kat, çarpma 1,9 kat, bölme 10,5 kat, karekök 7,5 kat yavaş çıktı. Bir oyun gününün çoğu toplama ve çarpma olduğu için bu bedeli kabul ettik.
Rastgele sayılar nasıl aynı kalıyor?
Zar bir tohumdan, adım numarasından, sistemden, varlıktan ve çekiliş numarasından hesaplanır. Ortada değişen bir durum olmadığı için zarların hangi sırayla ya da hangi iş parçacığında atıldığı sonucu değiştirmez.
Takvimde artık yıl var mı?
Hayır. Takvim 365 günlüktür. Bunun bedeli, oyun yılının gerçek yıldan yılda yaklaşık 6 saat kısa kalmasıdır; bir oyun için bilinçli bir sadelik.
Kaynaklar ve kayıtlar
Dış kaynaklar:
- Glenn Fiedler, Floating Point Determinism (yeni sekmede açılır)
- Vikipedi, Fixed-point arithmetic (yeni sekmede açılır)
- Vikipedi, Multiply–accumulate operation (birleşik çarpma-toplama) (yeni sekmede açılır)
- Vikipedi, Counter-based random number generator (yeni sekmede açılır))
- Vikipedi, Tropical year (gerçek yılın uzunluğu) (yeni sekmede açılır)
İç kayıtlarımız (motorun deposu kapalı olduğu için bağlantı veremiyoruz):
- Sayı modeli kararı: sayı biçimi, yuvarlama, taşma ve sıfıra bölme kuralları; durumsuz zar; 365 günlük takvim.
- Adım uzunluğu kararı: gün içi turlar, haftalık ve aylık adım, sistem sıklıkları.
- Yüz yıllık şehir hesabı: yıllık %1 büyüme günlük orana çevrilip her günün sonunda üç biçimde yuvarlandı; kesin değerle karşılaştırıldı (15 Ekim 2026). Bu bir ölçüm değil, hesaptır.
- Hız ölçümü: 15 Ekim 2026, 1 milyon sayı, her işlem için ayrı döngü, 15 turun ortancası ve 5 koşunun en iyisi; bilgisayar yüklüyken alındı.
- Zar sayımı: 15 Ekim 2026, tohum 1444, 6 milyon atış ve 6 milyon "%30" çekilişi; 1.000 adresin iki yönde okunması.
- Altın dosyalar: sayılar, zar ve takvim için kayıtlı sonuçlar; her test koşusunda bit bit karşılaştırılır.
Bir sonraki günlükte bu üç taşın neden bu kadar titiz olduğunu göreceğiz: iki oyuncunun bilgisayarı aynı dünyayı nasıl hesaplar ve bir fark çıkarsa nasıl yakalanır.
Bu günlük hakkında sorularınız ya da önerileriniz varsa bize iletişim sayfasından yazabilirsiniz. Motorun genel tanıtımı için MKA Engine sayfasına, bütün günlükler için Geliştirici Günlükleri listesine bakabilirsiniz.