Jump to page: 1 24  
Page
Thread overview
Basitten karmaşığa bir kodun hikayesi
Oct 17, 2012
mert
Oct 17, 2012
Salih Dinçer
Oct 17, 2012
mert
Oct 17, 2012
mert
Oct 17, 2012
Salih Dinçer
Oct 18, 2012
mert
Oct 18, 2012
mert
Oct 18, 2012
Salih Dinçer
Oct 19, 2012
mert
Oct 19, 2012
Salih Dinçer
Oct 19, 2012
mert
Oct 19, 2012
Salih Dinçer
Oct 19, 2012
Salih Dinçer
Oct 19, 2012
mert
Oct 19, 2012
Salih Dinçer
Oct 19, 2012
mert
Oct 19, 2012
mert
Oct 28, 2012
mert
Oct 29, 2012
mert
Oct 29, 2012
Salih Dinçer
Oct 29, 2012
mert
Dec 09, 2012
Salih Dinçer
Dec 10, 2012
Salih Dinçer
Dec 10, 2012
mert
Dec 15, 2012
erdem
October 17, 2012

Merhabalar,
Uzun zaman önce D dilini çalışırken, "Bir oyun yazmaya kalksam, tasarım aşamalarını acaba nasıl gerçekleştirebilirdim"? sorusuna şöyle yaklaşmıştım.

"Bir kahraman tasarlarım. Bu kahraman oyuna başlandığında bir bıçakla donatılır. Gelişme kaydettikçe sırasıyla kılıç, tabanca, tüfek, bomba gibi silahlara sahip olur. Devamını getirebilirsem kendisini bisiklet, motosiklet, atv, pikap, tank gibi araçlarla donatırım"

Her ne kadar bu plan tam bir tasarım faciası olsa da dil üzerinde keyif alarak alıştırma yapabilmemi kolaylaştıracak, öğrenme eğrime katkıda bulunacaktı.

Bu oyun alıştırmasını gerçekleştirme fikrine sanırım http://ddili.org/ders/d/islevler.html bu dersin sonunda kapılmıştım. Öyle ya boru değil irisi ufaklısıyla tam otuziki konu üzerinde çalışmış yeterince palazlandığıma iyice ikna olmuştum.

Başlangıçta kahramanımızın bir enerji seviyesi olacaktı. Kendisinin kullanımına sunulan her silah düşmanında da bulunacak birbirleri ile dövüşürlerken vurduğu/aldığı darbeleri kullanılan silahın türüne göre hesaplattıracaktım.

Ne vardı ki bu basit kodu yazamayacak:

import std.stdio;

void main()
{
   double kahramanınEnerjisi = 100_000;
   double düşmanınEnerjisi   = 100_000; /// [1]
   double bıçakDarbesi       = 0.1;     /// [2]

   // Kahramanımız beceriksiz çıkıyor ve kendini yaralıyor
   double bıçakDarbeliKahraman = kahramanınEnerjisi * bıçakDarbesi;
   writeln("Kendini kesen Sakar kahraman : ", bıçakDarbeliKahraman);
}

// Kendini kesen Sakar kahraman : 10000

Eh acemice de olsa bir başlangıç yapmıştık. Ancak bütün kodlamaları main'in içinde toplamanın kodlamam ilerdikçe bana sıkıntı yaratacağı da aşikârdı.

Buna bir çare bulmalıydım...

[1] '_' Rakamların kodlama aşamasında kolayca takibi için ayraç
[2] Hazır değer. Her iki not için ilgi http://ddili.org/ders/d/hazir_degerler.html

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 17, 2012

Bu konuyla yakından ilgileniyorum çünkü şu günlerde FarmVille2 oynuyorum...:)

Oradaki her bir nesnenin değeri (para, deneyim, yem, su, gübre, seviye, ürün adetleri vb.) birbirleri ile o kadar ilişkili ki! Eğer yeminiz varsa sahip olduğunuz hayvanı besleyebilirsiniz. Yoksa tarlaya tohum ekip yeme çevirmelisiniz. Tohum da yoksa paranız ile satın almalısınız. Ama sonuçta ekme, biçme, çevirme (pazarda satma) hatta besleme sizin seviye artmanızı sağlıyor. Seviyeniz arttıkça gizli olan ürünleri satın alabiliyor, tarlanızı çevresindeki arsalar satışa çıkıyor ve böylece (her manada!) genişliyorsunuz...

Biliyorum çok aptalca! Çünkü her şey; bir veritabanı içindeki büyük bir tablonun satır/sütunları arasındaki değerlerin birbirine dönüşmesi ve kendinizi iyi bir şey yapıyor hissi vermesinden başka bir şey değil. Gerçek hayatta bu işler o kadar kolay değil...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 17, 2012

FarmVille2 'i denemedim de ben Generals hayranı olduğumdan o oyunun tasarımını beğeniyorum. Uçaklar, tanklar vs. vs. Her birinin birimin hem vuruş hem darbe,hem seviye, hem hareket algoritmaları var. Çoğunlukla oradan akıl yürütüyorum. İşte bir barakadan değişik işlevlere sahip askerlerin türemesi, her birinin benzerlikleri farklılıkları falan filan.
Neyse bakalım kodumuzu nereye kadar geliştirebileceğiz :-)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 17, 2012

Sakar kahramanımın ona sağladığım silahları kullanmayı öğrenene kadar kendisinden başka bir düşmana ihtiyacının olmadığını anladıktan sonra 'düşmanım' yordamını bir süreliğine gözardı edebileceğimi düşünüp main() işlevimi toparlamaya karar verdim.

Öyle ya main işlevi programımın başlayıp bittiği yer. Programın bütün tasarımını orada yapacaksam bir süre sonra kodları takip etmekte zorlanacağım. Eh işlevleri de hazır daha yeni öğrenmişim diyerek kahramanımın ve olası düşmanlarının alacağı bıçak darbelerini hesaplatabileceğim bir işlev tasarlayarak bu sorunuma nasılsa çare bulurum diyerek kodlamaya başladım:

import std.stdio;

void bıçakDarbesiniHesapla(ref double kahramanınEnerjisi) //[1]
{
   kahramanınEnerjisi = kahramanınEnerjisi * 0.1;        // [2]
}

void main()
{
   double kahramanınEnerjisi = 100_000;
   bıçakDarbesiniHesapla(kahramanınEnerjisi);

   writeln("Bıçak darbesi alan kahramanım : ", kahramanınEnerjisi);
}

// Bıçak darbesi alan kahramanım : 10000

Gayet güzel. Kahramanım elindekini kullanmayı öğrenene kadar bu işlev yetecek gibi...

Madem ki bir işlev tasarladım, bari hakkını vereyim diyerek olası hatalarıma/ eniyileştirme olanaklarına bir kez daha göz atabilmek için http://ddili.org/ders/d/islevler.html dersine yeniden dönüş yaptım.

İyiki de dönüş yapmışım...

[1] ilgili bağlantıda 'iş yapmak' konusu altında belirtilen yan etki oluşturan işlevimiz
[2] Halen kullanmakta olduğum hazır değer

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 17, 2012

Alıntı (acehreli):

>

Bence çok güzel olacak! :)

Hocam...

Bu yorumunda çok derin anlamlar yatıyor...:)

Peki, güzel olması için ne tür tedbirler almalıyız? Yani karmaşığa gideceğini biliyoruz; örneğin Kahraman sınıfının, ileride üye sayıları artacak. Hatta biz bu sınıfın kopyalarını başka sınıflar ile paylaşıp (miras alma olayı) işte o zaman işler sarpa saracak. Birbirine benzeyen üyeler, override olması gerekenler vb...

Yine de iki şeyi hatırlıyorum:

  • Ara eniyileştirmelerden (code optimization) kaçın
  • Bir şeyi hemen sınıfa dönüştürme, önce yapı sonra gerekiyorsa sınıf

En iyisi yapı ve sınıflar ile ilgili dersleri tekrar bir gözden geçirelim...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 17, 2012

Bence çok güzel olacak! :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 18, 2012

Alıntı:

>

Salih:
Bu yorumunda çok derin anlamlar yatıyor...:)

Moral desteği :-)

Alıntı:

>

Salih:
Peki, güzel olması için ne tür tedbirler almalıyız? Yani karmaşığa gideceğini biliyoruz; örneğin Kahraman sınıfının, ileride üye sayıları artacak. Hatta biz bu sınıfın kopyalarını başka sınıflar ile paylaşıp (miras alma olayı) işte o zaman işler sarpa saracak. Birbirine benzeyen üyeler, override olması gerekenler vb...

Onlara gelene kadar olası güzelliğin yerini sıkıntıya bırakacağını düşünüyorum ben. Ama nihayetinde bir yalınlaştırma alıştırması deniyorum. Belki bu çalışmadan sorduğun sorulara yanıtlar bulabilecek aşamaya gelebiliriz, bilemiyorum sonucuna bakmak gerek.

Alıntı:

>

Salih:
Ara eniyileştirmelerden (code optimization) kaçın

Bu sapma işlevler dersine yeniden referans verebilmek için zorunlu olarak yapıldı. Burada amacım yan etkiler üzerine söylenmiş olanları derleyip toparlamak. Bu aşamada yan etki üreten kod yapılarının tartışılarak daha iyi anlaşılmasını sağlayabilir miyim diye düşünüyorum? Forumda bilgisi çok az. Ali hocam yeterince açıklamış ancak çoğu defa gözden kaçırdığımız bir durum olduğunu düşündüm. Ne dersin Salih, bu biçimde bir açılım sağlasak iyi olur mu?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 18, 2012

Alıntı:

>

acehreli:
Tabii kodun ne gerektirdiği baştan biliniyorsa gereksizce yetersiz kod yazmak da anlamsız. Bir yazı dizisi olarak yararlı olacak. Yeni başlayanlar bir sürü olanağın birlikte kullanıldığı kodlar görüp neden öyle yazıldığını anlayamıyorlar(dır). Böyle bir gelişim tam o ihtiyacı karşılıyor.

Hislerime tercüman olan yorum:-) Zorlanmıştım başlarda.
Alıntı:

>

acehreli:
Aslında onun kararını tasarımın en başında verebilmek çok daha yararlı oluyor(muş) ve zaten çokşekillilik gerekiyorsa zaten sınıftan başka çare yok.

Sınıfları ve yapıları henüz yeterince kavrayamamış bir öğrenci deneyiminden yola çıktığımızdan koşullar deneyim sahibini oraya sürükleyecektir muhtemelen. İzlemekte yarar var :-)
Alıntı:

>

acehreli:
Tabii bir tasarım yapı ile başlayıp sonra sınıfa da dönüşebilir. Bunun sıkıntılı olacağını düşünüyorum. O türü kullanan ve zaten yazılmış olan kod değer türü düşünülerek yazılmışsa onun yerine referans türü gelince programda hatalar olabilir.

Bu yoldan geçilmişti diye hatırlıyorum ilk modelimizde. Burada da hikâye olduğu gibi aktarılacak.

Şu aşamada "Yan etki" konusuna şöyle bir dokunup geçeyim istiyorum. Çünkü değer döndüren bir işlev ile yola devam edilmesinin mantığı açıkta kalmamalı. Ayrıca sarma konusuna da iyi bir referans olur. Katkılar için tam zamanı :-)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 18, 2012

Alıntı (acehreli):

>

Alıntı (Salih Dinçer):

>

Bu yorumunda çok derin anlamlar yatıyor...:)

Fazla derine dalarsak şu bile bulunabilir: "Şimdi kötü olmuş. Çoook ileride iyi olacak!" :) Ama hayır, aklımın ucundan bile geçmedi.
Aynı şekilde benim de aklımdan böyle bir şey geçmedi. Ama Ali hocamdan ilginç bir açılım beklediğimi itiraf etmeliyim...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

October 18, 2012

Alıntı (Salih Dinçer):

>

Bu yorumunda çok derin anlamlar yatıyor...:)

Fazla derine dalarsak şu bile bulunabilir: "Şimdi kötü olmuş. Çoook ileride iyi olacak!" :) Ama hayır, aklımın ucundan bile geçmedi.

Yazının düzeni kendim program yazarken düşündüklerime benziyor. Amaca götüren en basit kod, gerek duyulduğu için değişiyor.

Alıntı:

>

karmaşığa gideceğini biliyoruz; örneğin Kahraman sınıfının, ileride üye sayıları artacak.

Tabii kodun ne gerektirdiği baştan biliniyorsa gereksizce yetersiz kod yazmak da anlamsız. Bir yazı dizisi olarak yararlı olacak. Yeni başlayanlar bir sürü olanağın birlikte kullanıldığı kodlar görüp neden öyle yazıldığını anlayamıyorlar(dır). Böyle bir gelişim tam o ihtiyacı karşılıyor.

Alıntı:

>
  • Bir şeyi hemen sınıfa dönüştürme, önce yapı sonra gerekiyorsa sınıf

Aslında onun kararını tasarımın en başında verebilmek çok daha yararlı oluyor(muş) ve zaten çokşekillilik gerekiyorsa zaten sınıftan başka çare yok.

(Aslında C'de bile kullanışlı olmasa da NYP yapılabildiğini bildiğimize göre D yapılarıyla da işlev göstergeleri filan kullanarak çokşekillilik gerçekleştirilebilir ama gerek yok tabii.)

Bazı türlerin yapı olacakları çok belli: Bir kaç verinin bir araya getirilmesinden oluşan bir tür. En güzel örneklerinden birisi düzlemdeki nokta olabilir: x ve y koordinatlarını bir araya getirir. Aynı noktayı gösteren iki nesnenin kimlik açısından birbirlerinden farkları yoktur. Aynı değeri taşırlar.

Öte yandan davranışı farklı olabilen bir tür ile ilgileniyorsak o zaman sınıf olmalıdır. Bu Hayvan nesnesi o Hayvan nesnesi gibi davranmaz ise o zaman sınıf olmalı.

Tabii bir tasarım yapı ile başlayıp sonra sınıfa da dönüşebilir. Bunun sıkıntılı olacağını düşünüyorum. O türü kullanan ve zaten yazılmış olan kod değer türü düşünülerek yazılmışsa onun yerine referans türü gelince programda hatalar olabilir.

Alıntı:

>

En iyisi yapı ve sınıflar ile ilgili dersleri tekrar bir gözden geçirelim...

Sınıflarla ilgili bir çok bölüm yeniden gözden geçti ve düzeltildi ama daha siteye koymadım. Bir iki hafta sonra koyarım.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

« First   ‹ Prev
1 2 3 4