Oyun yapmaya karar verdiniz, fikriniz de çok güzel, bir yerlerden de XNA diye bir şey duydunuz; “güzelmiş” dediniz. Sizde de kişilik özelliği olarak extra sabır ve kararlılık var tam bu işin adamısınız. Peki nasıl başlayacaksınız?

Ön Şartlar:

. C# bilmek.    

. .Net çatısında biraz tecrübeli olmak ve sınıflar geliştirip onları etkileşime sokabilmek

. 3B Grafik desteği olan bir bilgisayar.(Direcx9.0c, shader model 1.1 veya üstü)

. Windows XP SP2 veya Windows Vista

. Visual Studio geliştirme ortamı veya Express sürümleri

. XNA Game Studio’nun kendisi (Arama motorunuzdan geliştirme ortamınıza uygun sürümü aratabilirsiniz)

. Eğer Xbox’a yönelik oyun yazmak istiyorsanız PCnize bağlı bir XBox 360

. Yapacağınız oyuna yönelik ön çalışma; örneğin RPG oyunu yapmak isteyen birisinin D&D D20 kurallarını bilmesi oyunun karar mekanizmasını yazarken kolaylık sağlayacaktır, burada önemli olan bu kuralları ayen almak yerine örnek alıp, sizin oyununuza daha uygulanabilirini yazmaktır.

. Temel fizik, analitik ve matematik bilgisi. Bu oyun dünyasının olmazsa olmazıdır. Örneğin duvardan seken bir topun geliş açısına göre sekme açısı ve yönü belirlenmelidir.

Bu önşartları hallettiniz, şimdi bir oyun programcısı olabilirsiniz; Peki bu yolda size neler kolaylık sağlayacaktır?

            . XNA Creators Club Üyeliği, bu sitede pek çok doküman ve modül bulabilirsiniz.

            . Elinizin altında kolayca ulaşabileceğiniz bir kitap. (kitap daima iyidir)

. Daha önce sizin yaşayacağınız muhtemel sorunları yaşamış insanların bulunduğu bir Türkçe forum.( Ama benim için dil farketmez diyorsanız büyük ihtimalle Creators club işinizi görecektir)

. Katmanı mimari, Tasarım şablonları vb… mimari yaklaşımları bilmek ve OOP’in sunduğu Kalıtım, Arayüz vb… avantajları kullanabilmek

Kolaylık sağlayacak konulardan da haberiniz var hadi ne duruyorsunuz bir “Oyun Programcısı” olun.

Bu aralar bu konuda bayağı meraklıyım özellikle WCF konusuna Imagine Cup zamanında yüzeysel olarak girmek zorunda kalmıştım. Ama yaz olup da boş kaldıktan sonra artık bu konuyu halledeyim dedim. Umarım bu konuyu öğrenmek çok zaman almaz.

Bu saçma giriş bölümümden sonra sorumu soruyorum: nedir dağıtık sistemler?

Aslında bunun için internette bir sürü teknik açıklama dolu. Ben teknik tanımlamalarla çok kafa karıştırmak istemiyorum ama isteyen olursa da yardımcı olurum. En basit şekliyle bir dağıtık sistem bilgisayarlar arası bir ağdır, ama öyle bir ağdır ki bu ağ üzerinde bilgisayarlar kaynaklarını (işlemci, hafıza vb…) paylaşabilirler. Yani kocaman bir bilgisayar düşünün bir kısmı bir odada diğer kısmı başka odada diğer bir kısmı da komşunuzda…

Ya da başka bir bakış açısıyla ortada yapılması gereken bir sürü iş var ve bunlar çeşitli bilgisayarlar tarafından yerine getirilip sonuç veri, ihtiyacı olan kısma gönderiliyor.

Böylelikle; uzaydaki olayları inceleme gibi devasa işlem gücüne ihtiyaç duyacak olan işler kullanıcılar arasında bir program vasıtasıyla paylaştırılıyor ve milyonlarca dolar tutacak süperbilgisayarların işi ucuz ve çok sayıdaki kişisel bilgisayar tarafından yapılıyor.

(bu gerçekte olan bir uygulama ama tembellik ettiğimve linki hatırlamadığım için linkini koyamıyorum)

Tabi bu olay yapılırken verilerin nasıl aktarıldığı gibi problemler olsa da bunlara değineceğim.

Sonuç olarak dağıtık sistemler tam gaz gitmekte ve Microsoft ve Sun gibi dev firmalar da geliştirdikleri apilerle bunu desteklemekte. Bu nedenle bu konuyu anlamakta fayda görüyorum.

Son zamanlarda dünyada ve özellikle IBM’in konferansından sonra Türkiye’de de hızla önem kazanan bir konu SOA (service oriented architecture).  Peki SOA nedir?

Herşeyden önce SOA’nın değişik bir yaklaşım olduğunu kabul etmemiz gerekiyor. Burda değişikten kasıt Fonksiyonel programlamadan da, Nesne Yönelimli (OOP) programlamadan da farklı olması. Klasik nesne yönelimli yaklaşımda herşeyi bir nesne olarak görüp nesnelerin birbirleri arasındaki iletişimi modelleyerek programlarımızı oluşturuyoruz. SOA da ise adından da belli olduğu üzere işin odağında servisler var.

Servisleri, basitçe yerine getirilmesi gereken işleri yapan, işverenden bağımsız işçiler olarak düşünebiliriz.

Zaten pek çoğumuz farkında olarak ya da olmadan Web Servisleri aracılığıyla ucundan da olsa bu yaklaşımı kullandık. Bildiğiniz üzere web servisleri yayınladıkları servislere gelen uygun istekleri değerlendirip uygun sonucu geri çeviriyorlar, bunu yaparken de istemcinin aynı projenin bir parçası olup olmadığını önemsemiyorlar. Zaten amaç da işinde uzman servisler yaratıp bu çözüme talip olacak uygulamala hizmet verebilmek.  En güzel yanı da servsin nasıl kodlandığı hakkında bir şey bilmenizin gerekmemesi. Sadece verileri uygun formatta yolluyorsunuz gerisini servis halediyor.  

“Verileri uygun formatta yollamak”demişken farkettiğiniz üzere SOA da öne çıkan bir diğer önemli konu ise haberleşmenin şekli, öyle rastgele servis odaklı sistemler kuramıyoruz. İşte burda belitmeliyim ki SOA nın kendisi zaten bir soyut framework, kendi kuralları kendi yöntemleri olan bir yaklaşım ve bunun sayesinde Platformalar arası bağımsızlık sağlanıyor, bu da maliyetten tasarruf ve müşteri portföyünde artış olarak yansıyor.

SOA’nın gerektirdiklerine bakacak olursak SOA:

            .Referans modeline uygun servisler içermeli,

            .Kullanıcı ve Servisler arasında görünürlüğü sağlamalı

            .Servisler ve kullanıcı arası etkileşime nasıl aracılık edeceğini bilmeli

            .Servislerin nasıl kullanışacağını anlatmalı

.Servisin yaptığı iş hakkında bilgi vermeli

            .Yeniden kullanılabilir olmalı

            .Modüler olmalı

            .Mümkün olan en küçük parçalardan oluşmalı

.Poliçelerin nasıl ele alındığı hakkında bilgi vermelidir.

Servislere bakacak olursak etkileşim esnasındaki özelliklerini ve genel özelliklerini ayırmanın iyi olacağı kanısındayım;

Servislerin Etkileşim esnasındaki özellikleri ;

1) Görünürlük:  Adından da anlaşılacağı gibi görünürlük kullanıcı ile hizmet verenin birbirlerini görebilmesidir. Tabi bunun da bazı koşulları vardır.

            a) Farkındalık: Kullanıcı ile hizmet birbirlerinin farkında olmalıdır.

            b) İsteklilik: Özellikle servis sağlayıcının bu alışverişe istekli olmasıdır.

            c) Erişilebilirlik: Servisin başvurulduğu anda erişilebiliyor olması demektir

                        (Doğru adreste olması, izinlerinin uygun olması …)

2) Etkileşim: Servislerle etkileşime girilebilmesidir. Bu genellikle gönderilen mesajlar aracılığıyla olur. Tabi bu mesajlar da bazı kurallara bağlıdır.

            a) Bilgi Modeli: Servise gönderilecek bilginin şekillendirilmesidir.

                        . Yapı: Verinin yapısıdır, kullanıcı için açıklamalar bulundurmalıdır.

                        . Anlam: Gönderilen veri ilgili herkes tarafından anlaşılabilir olmalıdır.

b) Davranış Modeli: Servisin talepten sonra nasıl davranacağının ve geri dönüşünün bilinmesidir.

c)Hareket Modeli: Servisin işlem sırasında hangi yöntemleri kullandığının bilinmesidir

3) Gerçek Hayata Etkisi: Kullanıcı uygulamanın sahibinin hizmet verenden beklentisi vardır ve bu hizmetin sonucunda hedeflenen amaca ulaşılıp ulaşılmadığı önemlidir.

Servislerin genel özellikleri:

1)      İyi tanımlanmış ve anlatılmış olmalı

2)      Erişilebilir ve fonksiyonel olmalı

3)      Poliçeler ve Kontratlar içermeli

4)      Gevşek bağlı olmalı (loose binding)

Servis odaklı mimariyi kullanmak illaki sıfırdan SOA özelliklerini sağlayan bir yazılım üretmek gerekmiyor, zaten bunca yardımcı API varken eğer gerçekten lazım değilse sıfırdan üretim zaman kaybı olurdu.  WCF işte tam burada devreye giriyor. COM+, .Net Remoting gibi Dağıtık sistem geliştirme araçlarını da içeren bir toplama API gibi düşünebiliriz WCF’yi. Ama sadece bu tanımı yapmak da WCF ye haksızlık olur. Asıl amacı Hızlı bir bişimde SOA yazılımları geliştirebilmek ve hakkaten bunu becerebiliyor. En azından benim görüşüm bu, kendi öğrenci başıma geliştirdiğim bazı ufak tefek yazılımlarda yıldırım hızı kazandırdığı bir gerçek. (Kısmet Firmalarda Çalışmakta ahh ahh). ( bu arada bir parantez notu WCF’yi anlattığım bir arkadaş bana sadece windows makinaların yararlanacağı bir servisi ben ne yapayım demişti ama WCF diğer platformlardaki makinalara servis verebilecek yazılımlar geliştirmemize olanak sunuyor, ama o bunu anlamamakta ısrarcı )

WCF ile yapılan servislerin çalışma prensibi için temel olarak bilmemiz gereken şeyler şunlar:

            . Aynı ya da farklı bilgisayarlardaki farklı uygulama alanlarıyla etkileşim sağlanabilir.

            . Servis - Kullanıcı etkileşimi esnasında bir proxy nesnesi kullanılır

            . Servise giriş ve Servisten çıkışlarda bir endpoint nesnesi bulunur.

Birinci madde aslında dağıtık sistemin özü, çünkü bilgisayarlararası bir etkileşim söz konusu.

Proxy nesnesi ise servise gelen istekleri endPoint’e yollar ya da endPointten gelen verileri İstemciye ulaştırır.

endPoint nesnesi aslında servise ulaşmak isteyen kullanıcılara bir arayüz, çıkan veriler için ise son şekillerndirme noktasıdır.

(EndPoint hakkında ayrıca bir yazı yazarak içeriğinden bahsedeceğim)

Başlangıç olarak WCF hakkında bir fikir vermek istedim, konuya diğer yazılarımda devam etmek istiyorum (öğrendikçe).

Yıllardan beri çok iyi bir PC oyuncusu olmuşumdur. Özellikle strateji ve rpg alanlarında çıkan şaheser oyunların çoğunu bitirmişimdir. Yalnız içimde hep bir boşluk vardı evet oyunlar iyiydi güzeldi ama benim hayal gücüme küçük geliyorlardı ben de lise yıllarından beri hep bir oyun yapmayı hayal ettim. Üniveristeye geldiğimde ise bir yandan okulda gösterdikleri dilleri öğrenirken bir yandan da DirectX’i araştırmaya başladım. C# ile yazılabildiğini gördüğüm an indirmiştim SDK sını. Bayağı uğraştım directX ile ama zaman gerçekten bir sorundu. Dolayısıyla 3B oyun yapacak kadar geliştiremedim kendimi. Ama bu yolda bir sürü sınıf da yazmıştım, onlar da bilgisayarımın tozlu harddiskinde beklemeye mahkum kaldılar.

Aradan bayağı zaman geçtikten sonra Imagine Cup ’08 finallerinde Mehmet Tunçkanat’ın bilgisayarında XNA logosunu gördüm, XNA hakkında az da olsa bilgim vardı, XNA 2.0 iken geçmeyi düşünüyordum ama hep başlama vuruşunu beklemişim. O gün logoyu gördükten sonra Mehmet hocayla küçük bir sohbet yaptık ve sonunda bana kitap yollayabileceğini söyledi ben de büyük bir sevinçle kabul ettim. Bir süre sonra gerçekten de kitap elime ulaştı. Burdan Mehmet Tunçkanat’a tekrar tekrar teşekkür ederim. Artık başlama vuruşu yapılmıştı ve benim XNA yolunda hızla ilerlemem gerekiyordu. Kitabı kısa sürede bitirdim gerçi şu an hala 2 boyutla uğraşıyorum ama temeli sağlam atmak istiyorum. Ama burda XNA’den fırsat buldukça bahsedeceğim çok eğlenceli bir konu ve insan ilgilenirken gerçekten mutlu oluyor.

Imagine Cup’08 Yarıfinalinde projemizin sensör kısmını simule etmek için arkadaşın PDA’sını kullandım. Tabi PDA’ya kod yazmak bizim kullandığımız normal framework ile olmuyordu. Bunun için Windows CE gibi tabiri caizse ufaltılmış işletim sistemleri için geliştirilmiş olan .Net Compact Framework (.netCF) gerekliydi. Hemen geliştirme takımının üyesi olan kişilerin bloglarını okuyarak ihtiyacım olan kısım için .netCF’yi anlamaya başladım, gerisi geldi tabiki hatta en sonunda PDA ve PC arasında WCF Api’sini kullanarak bir mini SOA modeli yazıp kullandım. Bu şekilde başladı .netCompactFramewok’e olan yolculuğum.

Imagine Cup’08 de Rota takımı olarak üçüncü olduktan sonra bize hediye edilen PDA’lardan sonra ise artık bir zorunluluk oldu. Elimden geldikçe kendi programlarımı kendim yazıyorum ne de olsa çok da büyük programlar yazılmıyor PDA’lere. Ama birkaç projem var bakalım olursa. Fırsat buldukça bu konuda da yazacağım.

Yıl 2005 birinci sınıfın son günleri; Kantinde bir masada oturmuş sohbet ediyoruz. Karşımda Bilgehan abi var o sene mezun olacak, bize dedi ki “arkadaşlar c öğreniyorsunuz güzel de; piyasada iş bulmak istiyorsanız Java gibi C# gibi dilleri mutlaka öğrenin”. Her şey o cümle ile başladı. O yaz Eskişehir’e gittiğimin ertesi günü bir kafeye gittim, Eskişehir’deki evimizde internet yoktu (hala yok) . Hemen arama motorlarına saldırdım “c#” yazdım nasıl başlayacağım aklımdayken. Bir de kitap buldum Teachyourself C# in 24 hours diye. Ordaki yönergeleri izledim, C# express’i indirdim. Eve gider gitmez kurdum ve kendi kendime öğrenmeye başladım başlarda zordu ama ben bundan zevk alıyordum, sonra kolaylaştı. Necdet Hocam sağolsun çok güzel algoritma temeli attırmış bize. Dilin imlası hariç hiç zorlanmadım. Ne de olsa daha OOP nedir bilmeden kendimi atmıştım bu derin sulara. Zamana oturdu o yaz her şey yerine ve ikinci senem başladığında artık c#’ı dil olarak biliyordum. O andan itibaren de C# ile ilgili teknolojileri API’leri çalışmaya başladım.

Böyle başladı benim C# hikayem. Her engeli kendi tırnaklarımla aşmış olmam nedeniyle C#’ı çok seviyorum sanki çocuk sever gibi sanki beraber büyüdük…

Tabi o zamandan bu zamana bir hayli tecrübelendim nice kitaplar devirdim, hatta İspanya’da olmasaydım bu yaz sertifika sınavları için girişimde bulunacaktım.

Bu nedenle C# hakkında da yazmak iştiyorum bloguma zamanında takıldığım yerleri bazi ipuçlarını vermek için. Ama benim de her zaman başvuduğum kaynak öğrenme konusunda önce MSDN sonra C# Nedir sitesi. İlk yazımda da bunu tavsiye etmiş olayım.

Merhabalar!!!

Uzun bir kavgadan sonra servis sağlayıcım(host) ile olan sorunlarımı aştım. Tekrar beraberiz. Artık yazılarımı gönül rahatlığıyla kendi alanımda yayınlayabileceğim... Elimde biriken yazılar var yazılması planlanmış ama hiç yazılmamış yazılar var... İşim zor ama yapacağım.

Umarım bir daha bu teknik aksaklıkları yaşamam bu kaçıncı temenni ama napalım... bu sefer oldu gibi bir iki yazı yazdım sorun çıkmadı hiç bakalım gerisi kısmet.

Bu yazımda biraz üç katmanlı mimariden bahsetmek istiyorum. Tabi ki katman sayısını üçle sınırlamak doğru değil ama başlangıç için bence en ideali üç katman.

Yazılımı Neden Katmanlara Ayırıyoruz?

Aslında cevap herkesin aklına geldiği gibi yönetimi ve bakımı kolaylaştırmak. Şimdi aklınıza bir yazılım getirin bu yazılım veritabanına bağlı olsun. Bu yazılımın tüm kodu bir iki sınıfa sığdırılmış olsun, ve bir zaman sonra yazılımın veritabanına bağlantısında bir hata olduğu ortaya çıksın. Böyle bir durumda tüm kod açılacak içinden zorlukla veritabanı ile ilgili kod bulunacak, gerekli yer düzeltilecek tüm proje baştan derlenecek. Ve tam bu anda yanlışlıkla arayüzü sağlayan kodun bir kısmını sildiğinizi farkediyorsunuz. Onca kod arasından uğraşıp sildiğiniz kodun ne işe yaradığını bulacaksınız tekrar yazıp tekrar derleyeceksiniz. Bu hem size hem de işini yaptığınız kişiye zamana mal olacak.

Peki bundan nasıl kurtulacaksınız?

Cevap şu en başta yazılımı tasarlarken her işi ayırmalı ve mümküm olan en küçük ve en özel sınıfları amaçlamalısınız. İşte bu durumda da çeşitli iş öbekleriyle karşılaşacaksınız. Bazı sınıflar veritabanı ile iletişim kurarken bazıları iletişim kurmuş bu sınıflardan gelen verileri işleyecek ve bunları arayüze yani görünen kısma taşıyacak. İşte tam burada katmanlı mimari devreye giriyor, yapılan işe göre sınıflar kategorize ediliyor. Konumuz olan üç katmanlı mimaride adından da anlaşılacağı üzere 3 katman vardır. Bunlar:

. Veri Katmanı

. İş Katmanı

. Arayüz (Sunum) Katmanı

Veri katmanı:

Veri katmanı adı üstünde veri ile ilgilenir başka hiçbir şey yapmaz. Database ve Stored Procedure ler bu katmandadır.

Önemli nokta: bu katmanda asla verilerle işlem yapılmaz.

İş Katmanı:

Veri katmanından alınan veriler buradaki sınıflarca işlenmelidir. Burda her türlü işlem yapılır. Hesaplamalar, verilerin değişimi vb… Ve ancak bu katmanın işi bitince veriler veritabanına aktarılmak üzere veri katmanına ya da gösterilmek üzere arayüz’e yollanır.

Bu katmanda herhangi bir veri depolanmamalı, arayüze sonuç bastıracak kodlar bulunmamalıdır. Sadece veriyi almalı, işlemeli sonucu geri dönüş değeri olarak döndürmelidir.

Arayüz (Sunum) Katmanı:

Verilerimiz İş katmanında işlendi, ve ekrana sonuçların bastırılması gerekiyor. İş katmanından gelen verileri bu katmandaki sınıflar aracılığıyla alıp ekrana bastırıyoruz veya ilgili başka bir programa aktarıyoruz. Yani bu katman sadece programın üreteceği son değerin şekillerdirilmesi(anlaşılır hale getirilmesi) ve gösterilmesi işinden sorumlu.

Bu katmanda da hiçbir veri işleme işi yapılmamalı sadece iş katmanından gelen veriler biçimlendirilerek sunulmalıdır.  

Üç katmanlı mimari işte bu kadar asıl iş projeyi üç katmanlı hale gelebilecek şekilde moduler olarak tasarlayabilmekte. Bu sağlandığı takdirde Sadece veri tabanımızda sorun varsa veri katmanındaki ilgili sınıfa gidebilir değişikliği yaparız ve programın geri kalanı bu değişimden hiç etkilenmez. Bu şekilde tasarım aynı zamanda takım çalışmasına atılan ilk adımdır. Her programcı başka katmanlarla uğraşabilir, örneğin ben iş katmanını yazarım, kod yazmaktan anlamayan bir sanatçı da arayüzü tasarlar. Gelecek verilerin şekli belli olduğu için, bunu yaparken zorluk da çekmeyecektir.

Hepimizin zaman zaman harika fikirleri  oluyor ama iş bunları koda dökmeye gelince bazı noktalarda tıkanıyoruz nasıl sınıflar olmalı ne nerden hangi veriyi almalı vb…  Peki bu sorunu nasıl aşabiliriz?

Imagine Cup ile başlayan tasarım serüvenimde birkaç noktanın önemini farkettim, bunlar;

. Projeyi hayal etmek

. Bu hayalin aşamalarını Kağıda dökmek (kağıt gerçekten projenin olmassa olmazı)

. Sonra bu aşamaları kendi aralarında ufak parçalara bölmek( mümkün olan en küçük sınıflara ayrılmalı ki modulerlik ve bağımsızlık sağlanabilsin)

. Ve mümkün olduğunca Interface(arayüz) ve Inheritance(türetme) kullanın.

. Bu ufak parçaları ve parçaların birbirlerine olan ilgilerini kağıt üzerinde küçük temsili şekillerle ve oklarla göstermek

. Eğer biliyorsanız UML’den yararlanıp bilmiyorsanız hayal gücünüzle bu parçaları sınıf haline dönüştürmek (hala kağıt üzerinde).

. Sınıf haline dönüştürürken içerebileceği değişkenleri ve metotları (sadece yaptıkları işi kısaca örneğin topla() gibi anlamlı bir isimle) belirtmek

. Sınıfların nasıl haberleşeceğini düşünmek. Burada mutlaka son teknolojileri uygulayabileceğiniz bir yazıım yaratmaya çalışın.

. Bu aşamada karşımıza bir proje şablonu çıkmış olmalı; bu şablonu iyişleştirmek için üzerine kafa yormak (örneğin kod tekrarını yoketmek, gerekirse tasarım şablonlarından faydalanmak)

.  Şu ana kadar hiç kusurunuz yoksa o kusuru bulmak, çünkü mutlaka değişmesi gereken bir yer vardır

. yavaş yavaş koda dökmye başlamak, bazı yerlerin daha kolay yapılabileceğini keşfetmek ve mümkün olan en küçük sınıfları kullanmış olduğunuz için şükretmek.( çünkü değişikliği sadece bir sınıfta yaptık, diğer sınıflarımız güvende)

Bir yandan da;

. O an aklınıza gelen yapmayı düşündüğünüz her şeyi not alın aklınız defter değil bunu unutmayın.

. Kodu yazarken sürekli yorum satırları kullanın ki tekrar döndüğünüzde algoritmanızın ne yaptığını anlayabilesiniz.

. Çizimleri mümkün olduğunca Kurşunkalem kullanarak yapın ki sildiğinizde ki kesinlikle düzeltmeniz gereken yerler olacak; iz kalmasın.

. Ara sıra çıkıp temiz hava alın, aklınızı boşaltın, hiç olmadık anlarda aklınıza muhteşem fikirlerin geldiğini göreceksiniz, ve neden daha önce düşünemedim diye hayıflanacaksınız.

Anlayacağınız üzere iş projeyi tasarlamakta bitiyor, kod nasıl olsa yazılır.