Bu haber 2 aylık yanlış hatırlamıyorsam.. sanırım bir sıkıntı oldu, release i ve dolayısı ile yarışmanın tarihini de aynı şekilde bilinmeyen bir geleceğe attılar gibi..

Benim şimdiye kadar farklı projelerde denediğim şu iki yöntem var;

1) Network katmanında Packet gibi bir base class dan türeyen LoginRequestPacket, ChatMessagePacket, XXXPacket gibi alt sınıflar tanımlayıp, her sınıfın kendi içerisinde bir adet serialize() ve bir adet de deserialize() fonksiyonunu overload etmesini sağlamak. Burada datayı (java ile konuşacak olursam) ByteBuffer içerisie yazıyor ya da okuyorum. Veri writeInt(), writeUTF(), writeByte() gibi fonksiyonlar ile gayet sıkışık bir düzende yazılıyor. Yine aynı şekilde de okunuyor. Mesajlar kendi içerisinde kendi uzunluklarını da tutuyorlar, bu şekilde değişken uzunlukta mesajlar gönderebiliyoruz. Örneğin; UserListPacket gibi bir paket içerisinde kullanici_adi, puan ikilileri var diyelim. Tabii o anda sistemde kaç kullanıcı var ise bu paketin boyu da dinamik olarak değişiyor. Deserialize eden fonksiyon paket büyüklüğüne göre okuma işlemini yaptığında bir sorun olmuyor. Bu tarz bir 1mesaj=1paket yaklaşımının güzelliği; network arayüzü gayet açık bir şekilde ortaya konuluyor, kaynaklar (bandwidth) çok verimli kullanılıyor, herşey speclere göre ortada , proje yönetimi gayet mutlu oluyor. Negatif yönü; her küçük mesaj için gidip bir daha sınıf tanımı yapmak bir süre sonra can sıkıcı hale gelebiliyor, ayrıca paket uzunluğu felan hesaplarken bir hata yaparsanız canınız çok sıkılabiliyor, çünkü bu tarz hatalar kimi durumlarda uzun süre ortaya çıkmayabiliyor. (yazdığım network katmanındaki bir paketin boyutu ile ilgili hatayı 1.5 - 2 sene sonra şans eseri görmüştüm - arada sırada random client lar oyundan kopuyorlardı... )

2) Java,  .net gibi platformlardaki reflection mekanizmalarını kullanarak serialization işini otomatiğe bağlamak; kendi custom RPC mekanizmanı geliştirmek. ıyi yanı; el ile paket oluşturma zahmetinden kurtarıyor, kod teorik olarak daha az potansiyel bug lı oluyor; kötü yanı: her platforma uygun değil (managed olmayan bir ortamda ciddi meta programming gerektirir ki benim harcım değil açıkçası), paket başına bir miktar sabit overhead getirir (uygulamaya göre göz ardı edilebilir, ya da edilmeyebilir )

Yanlız java ile bir sunucu sistemi programlıyor iseniz her koşulda MINA gibi bir frameworke iletim katmanını bırakmanızı tavsiye ederim. Java tarafında blocklamalı + bol thread li socket kullanma devri biteli çok oluyor; ama raw NIO kullanmak da bir o kadar karın ağrısı.. böyle bir ortamda MINA gibi kütüphaneler ilaç gibi geliyor.

deniz.

tebrikler; kolay hızlı ve eğlenceli bir oyun, yani tam hızlı yayılmaya uygun.. birde flash gibi bir ortamda yazılsa idi çok geniş kitlelere ulaşabilirdi... rekorum 70.. halen çalışıyorum.

Aslında bir istanbul ofisi var; ama bu ofis iş geliştirme, reklam - tanıtım faaliyetleri gibi uğraşlar ile meşgul. Céidot çekirdek bir kadroya sahip, ve bu kadronun bir arada tempolu bir şekilde çalışması gerekiyor. Daha önceki -kötü- deneyimlerimiz bize zaten küçük olan geliştirici ekipleri birbirinden ayırmanın orta vadede epey zararlı sonuçlar doğurduğunu gösterdi. Maalesef uzak mesafede olan ekiplerde koordinasyonu sağlamak büyük yönetimsel tecrübe isteyen çok ciddi bir yük. ıstanbul 'da yetenekli insanlar olduğunu biliyoruz.. fakat en azından projelerin şu anki büyüklüğü içerisinde kısa süreli böyle bir planımız bulunmamakta. ılerleyen zamanda aynı anda yürüyen ve sürekliliği olan birbirinden bağımsız projelerimiz olur, çalışan sayımız 30 - 40 ile ifade edilir düzeye gelirse neden olmasın, istanbul da da bir ofis açılır. ıstanbul güzel, rakı güzel, kebbab güzel, ailecek seviyoruz aslında ama turist olarak - yaşanmaz oraların keşmekeşinde

Organizasyon bu sene geçen senekine göre dersine çok daha iyi çalışmış idi. Katılımcıların ürettikleri projelerdeki gelişme de dikkat çekici. Organizasyonun muazzam şekilde başarı ile kotarıldığını düşünüyorum. Organizasyonda emeği geçenlere, katılımcılara ve tüm destekleyenlere tebrikler.

Ben genellikle bilmediğim bir kütüphane ile uğraşırken ilk olarak kütüphane ile gelen -varsa- örneklerden işime yarayabilecekler üzerinden gidiyorum. Yapacağım ufak tefek değişiklikler ile bu kod üzerinde birşeyleri bozana kadar denemelerimi yapıyorum, sistemi iyice anladığımı düşündüğüm noktada kendi kodumu öğrendiklerim doğrultusunda baştan temize çekip yazıyorum. Sana bu yöntemi kullanmanı tavsiye ederim; raknet dökümantasyonu harika değil, ama raknet ile beraber gelen örnek uygulamalar oldukça yeterli. Ayrıca internet te insanların hazırladığı pekçok giriş seviyesi döküman da var; şu aşağıdaki döküman ilk başladığımızda bizim bayağı işimize yaramıştı; izlemeni tavsiye ederim; Açıkçası buradaki problemini tam olarak anlayamadım, kusura bakma.

step1 deki irrlicht e özgü kısımları atlatırsan gerisi network kodu;
http://www.daveandrews.org/articles/irrlicht_raknet/step1.htm

Kolay gelsin, iyi çalışmalar;

ekleme;
Üstteki mesajında ingilizcenin yeterli olmadığından dem vurmuşsun; ukalalık olarak algılama fakat bence bu noktada kendin için yapacağın en iyi şey raknet felan bırakıp teknik belge okuyabilecek kadar ingilizce bilgini ilerletmen. "Salak mı ne bu herif" diyebilirsin, ama inan ki yabancı belgeleri anlayamıyor isen programlama ile uğraştığın her alanda bir şekilde biryerlerde çarçabuk takılıp kalmaya ve yılgınlıkla başladığın işi bırakmaya mecbur kalacaksın. Umarım yanlış anlaşılmam.

udp mesajlaşma problemlerini (paket kaybı, yer değiştirme vb) acısızca halletmek için enet (http://enet.bespin.org/) gibi bir kütüphane kullanabilirsin. Daha da güzeli raknet gibi çok daha üst seviye bir network kütüphanesi kullanmak olacaktır. Zaten latency ile boğuşmak, client ları anlık lag altında senkronize edebilmek, veri frekansını azaltarak bandwidth den tasarruf etmek ve daha nice problem ile bolca uğraşmak zorunda kalacağın için birde alt seviye sıkıntılar ile debelenmek en son isteyeceğin şey olacaktır.

Eğer haberleşme mimarisinde yüksek oranda veri sıkıştırmaya ihtiyaç duymuyorsan kendi çapında bir rpc mekanizması oluşturmak akıllıca=acısız olacaktır. Bu sayede yeni paket tanımlama, paket yapısı değiştirme gibi bolca olan durumları çok rahat ve hızlı halledebilirsin. Üstelik yapıyı bir kez oturtursan bir daha da bug lar la felan uğraşmadan kodunu diğer kısımlarına konsantre olabilirsin.

Veri transferi garantiye alınmış UDP gibisi de yoktur, bence bundan şaşma. kolay gelsin. bol arge diliyorum.

Son mesajımdan beri öküz zaman geçmiş, kendime de koca bir oha diyorum, ve izleyici sandalyeme geri dönüyorum. - herkese sevgi, saygı.