Oyun planlama ve yazılım tasarımı? UML'nin uygun olmadığını düşünüyorum

Üniversitemde, her zaman oyun yapısı tasarımı ile iyi çalışmayacağını düşündüğüm UML tasarımı ve konularına vurgu yapıyor ve hiperak ediyorlar. Şimdi, sadece oyun tasarımıma nasıl başlamalıyım konusunda profesyonel bir tavsiye istiyorum. Hikaye, programlama konusunda biraz yetenekli olduğum ve bazı 2D platformerların çalışmasını sağlamak gibi çok küçük oyunlar yaptım. Programımla ilgili bulduğum sorunlar düşük kaliteli tasarım. Bir süre kodladıktan sonra, zayıf planlama nedeniyle işler bozulmaya başlıyor (Yeni özellik eklerken, tüm programı yeniden kodlamam gerekiyor). Ancak, her şeyi tek bir tasarım kusuru olmadan planlamak biraz fazla ideal. Bu nedenle, oyunumu nasıl planlamalıyım? Görünür resimlere nasıl koymalıyım ki ben ve arkadaşlarım tasarımları gözden geçirebilelim.

Arkadaşımla bir oyun kodlamaya başlamayı planladım. Bu benim ilk takım çalışmam olacak, bu yüzden herhangi bir profesyonel tavsiye bir zevk olacaktır. UML'den başka alternatif var mı?

Başka bir soru da "prototip" in normalde nasıl göründüğüdür?

Sadece oyun tasarımıma nasıl başlamalıyım konusunda profesyonel bir tavsiye istiyorum.

Oyun tasarımı, oyunun özellikleri, varlıklar, puanlama sistemleri vb. - bunlar yazılıma özgü değildir. Bu nedenle, UML bu görev için yanlış bir araçtır.

Bu sistemleri uygulamak için kod tasarlamaya gelince, UML görev için iyi bir araçtır, ekibinize bilmesini sağlar ve daha yaygın diyagram türlerine sadık kalır. Normal olarak, bir özellik tasarlamaya çalışırken bir açıklama mı yoksa şema mı kullanmanız gerektiğini bilirsiniz. Bir şema kullanmanız gerekiyorsa, UML size çizim için standart bir yol sunar, bu iyi bir şeydir.

Bir süre kodladıktan sonra, zayıf planlama nedeniyle işler bozulmaya başlıyor (Yeni özellik eklerken, tüm programı yeniden kodlamam gerekiyor).

Bu, genellikle nasıl planladığınızdan ziyade, programlama şeklinizle ilgili bir sorun. İyi yazılım genellikle genişletmek ve yeniden kullanmak kolaydır. İyi programlama uygulamalarına sadık kalırsanız, bu problem azalacaktır. Ancak daha iyi planlama da yardımcı olacaktır ve bunun için karmaşık diyagramlara ihtiyacınız yok. Sadece bir özellik listesine sahip olmak, bir şeyi kodladığınızda diğer özellikleri göz önünde bulundurduğunuzda ve bunları kod olarak kabul edebileceğiniz anlamına gelir.

Bu nedenle, oyunumu nasıl planlamalıyım? Görünür resimlere nasıl koymalıyım ki ben ve arkadaşlarım tasarımları gözden geçirebilelim.

Burada iki sorunu karıştırıyorsunuz, oyun tasarımı ve kod tasarımı gibi.

İhtiyacınız olan özellikleri, ihtiyaç duyduğunuz grafikleri ve sesleri, oyunun nasıl kazanıldığını ve kaybedildiğini vb. Belirtmek için ilk önce temel bir oyun tasarımı yazmanızı öneririm.

Oradan, kodlamanız gereken özellikler hakkında bir fikriniz olacak. Her özelliğe sırasıyla bakabilir ve bunları nasıl uygulayacağınızı düşünmeye çalışabilirsiniz. Diyagramlar, oyununuzdaki farklı sınıflar ve nesneler arasındaki ilişkileri göstermeye yardımcı olabilir, ancak hangi nesnelerin olması gerektiğini bilme becerisi, pratik ve / veya daha fazla okuma yoluyla öğrenmeniz gereken bir şeydir.

Ayrıca, daha küçük ve daha az iddialı projeler üzerinde çalışmayı deneyin. Bu, kapsamlı bir planlama veya yeniden yazmaya gerek kalmadan iyi, çalışma kodu yazmaya alışmanızı sağlayacaktır.

Bir şeyi anlamak, işten çıkarmayı kolaylaştırır. UML, sahip olduğunuz fikirleri yapılandırılmış bir şekilde iletmek için kullanılan bir mühendislik aracıdır. Oyun, diğerleri gibi tasarlanabilen bir sistemdir. Eğer bir şey varsa, bir oyunun karmaşıklığı ve dinamizmi, parçalarının ve etkileşimlerinin görsel bir sunumunu paha biçilmez kılar.

UML şemaları, tartışılmakta olan sistemin modelinin farklı görünümleridir. Programımın önünde oturan ve başlatan biri için kullanım durumları ile başlıyorum. Bir oyunda iki tür kullanıcı vardır: tasarımcılar ve oyuncular. Yaptıklarını görebildiğim her şey için bir kullanım çantası yazıyorum. Daha sonra hangi hizmetleri vermem gerektiğini bulmak için bazı CRC kartları hazırlıyorum. Daha sonra bu hizmetleri sağlayacak arayüzler ve bunların ilişkileri için bir sınıf diyagramı hazırlıyorum. Bu, CRC kartlarına dayanmaktadır. Daha sonra planlama ve düzenleme gerektiren başlatma gibi olaylar için dinamik diyagramlar geliyor. Sonra arayüzleri uygulayan sınıfları gösteren daha ayrıntılı statik diyagramlar.

Tüm bu süre boyunca kod yazıp prototip yapıyorum ve oyunun şartlarını yerine getirmeyi destekleyecek hizmetleri sağlama yönünde geliştiriyorum. Kullanım durumlarında kullanıcıyı desteklemeyen hiçbir şey oluşturulmaz. Bazı işe yaramaz şema elemanları yazıyorum, fakat arabirim kodlaması ile şema arasında çok az işe yaramaz kod yazıyorum. Diyagram bana yazdığım sınıfın tüm sisteme uyma şeklini anladığım konusunda güven veriyor.

Yapmaya çalıştığım nokta, önemsiz bir programın plan olmadan yazılabileceği, ancak oyunun önemsiz bir şey olduğu. Bir süre önce, OOP yeniyken, çok fazla deney vardı ve bazı en iyi uygulamalar öne çıktı. Yazılım geliştirme topluluğu, yazılım tasarımları hakkında yazmak ve analiz etmek için bir dile ihtiyacımız olduğunu kabul etti. UML geliştirdiğimiz dildir. Hepimiz biliyoruz ve anlıyoruz, bu nedenle başkalarının problemlerinize (kitaplar, çevrimiçi tartışmalar, makaleler, desen katalogları, vb.) Çözümlerini kullanmak ve tekerleği yeniden icat etmek istemiyorsanız, standart notasyonu okumayı öğrenmelisiniz. Bonus olarak, sisteminizi başka bir dilde düşünmeye zorladığınızda, beklenmeyen şeyleri öğrenirsiniz.

Birçok farklı metodoloji mevcuttur, ancak hepsi problemi tanımlar ve bir çözümü sistematik bir şekilde tanımlar. Bu mühendislik. UML devasa ve karmaşıktır, ancak hiçbir yapı her yapıyı kullanmaz. İsviçre çakısı gibi. Bunu tanımak ve mühendislik sürecinizi desteklemek için nasıl kullanacağınızı bulmak zorundasınız. Önemli olan hangi işlem ya da metodoloji değil, sizin sahip olduğunuzdur. Aksi takdirde karmaşıklık içinde boğulacaksınız.

Ayrıca bir arkadaşımla (2 kişilik takım) bazı bağımsız oyun projeleri üzerinde çalışıyorum. Sizinkine benzer bir durumda olan biri olarak, yararlı bulduğum birkaç haber verebilirim.

1. Fikirleriniz kaba ise, süper küçük prototip oluşturma projelerinde bunları birer birer uygulamayı deneyin. Örneğin, şimdi 2B platform oyunu yapıyorum ve oyuncunun doğru atlayışını almak benim için çok önemli. Böylece, sadece 2 şeyin gerçekleştiği yeni bir proje yaptım a) Müzikçaları ekrana çekmek, ve b) Girdiyi tespit etmek ve zıplamayı yeniden çizmek [karakter sola veya sağa hareket edemiyor]
2. Bazı insanlar bu tavsiyenin üzerine kaşlarını çatabilir, ancak önce oyun kılavuzunu yazmayı düşünün (kavramları, kontrolleri, amaçları açıklamak için). Bu sizin için 2 şey yapabilir - çok ihtiyaç duyulan bir belge üretir, ancak oyununuzun alt sistemlerini ve oyuncu için gerekli tüm ayrıntıları ana hatlarıyla belirtir. Oyuncunun bilmesi gerekenleri önceden biliyorsanız, o zaman önceden yapmanız gerekenleri bilirsiniz.
3. Kodunu yeterince küçük ( modüler modda ) küçük parçalar halinde yazın, parçalanmış parçaların hareket ettirilebileceğini veya daha iyi bir şekilde organize edildiğini veya orta büyüklükteki spagetti parçalarını bir tabaktan çıkarmaya çalıştığınızı hissetmeden daha iyi organize edildiğini görün.

Umarım orada en az bir yararlı bilgi parçası buldunuz ve iyi şanslar!

UML'den inkar edemeyeceğiniz bazı değerli paketler olduğunu düşünüyorum. Öte yandan, UML'nin iş süreçleri için inşa edildiğini unutmayın, bilirsin, pek çok insanla etkileşime giren, hepsi farklı istek ve ihtiyaçları ve arzuları olan sistemleri modelleme . UML, hiçbir şeyi dışarıda bırakmadığınızdan veya ayrıntılara boğulmadığınızdan emin olmaya çalışır.

UML "bir sistemin mimarisini görselleştirmenin standart bir yoludur"

UML açıklar

• faaliyetler
• aktörler
• iş süreçleri
• veritabanı şemaları
• (mantıksal) bileşenler
• programlama dili ifadeleri
• yeniden kullanılabilir yazılım bileşenleri

Fakat basit bir oyun çıkarıyorsanız, gerçekten tüm bunları modellemeniz gerekiyor mu?

• Aktörler: Oyuncu.

Bu ne kadar yardımcı oluyor?

Diğer bazı şeyleri modellemek çok yararlıdır. Örneğin, küçük bir MMO yapıyorsanız, kesinlikle iyi tasarlanmış bir veri tabanı şeması istiyorsunuz.

Bu nedenle, UML'den ayrılma mükemmel olsa da (ne yaptığınızı öğrenin, gereklilikleri yazın ve ihtiyaç duyduğunuz her yerde akış şemalarını çizin) ve unsurları çok faydalı olsa da, tam UML işleminin tam olarak olduğunu hissetme eğilimindeyim. Oyunlar için bir kare mandal yuvarlak delik.

UML, bir kısmı diğerlerine pek değer vermeyen şeylerden oluşan bir şey değildir. eski stil Kullanım Durumları (en azından "kullanım durumları" dediğimiz)

• isim
• Gereksinimler
• önkoşul
• tetikleyiciler
• eylemler
• alternatif eylemler
• istisnalar

oldukça yararlı olabilir. bir web araması yaparsanız (resimler) genel yazılım için daha fazlası olduğunu düşünüyorsanız "Kullanım Durumları" için ne bulursanız.

Ayrıca Sınıf diyagramına da bir miktar kredi verirdim. bu, tüm nesneleriniz arasındaki ilişkiyi gösterebildiğinizi ve mimarinizin düzenini bildiğinizi gösterir.

Bunun anlamı, özellik setinizin tümünün planlanmış olması ve modellemeden önce int (bir ihtiyaç / istek kurulumunda kiralanmış) olarak kilitlenmesi gerektiği ve şema oluşturma işleminin başlaması gerektiğidir. bunların hepsi Kısa / Muamele / Scriptinizde olmalıdır (bazen adım, özellik belgesi ve hikaye olarak da adlandırılır). o zaman oradan modellerinizi ve diyagramlarınızı içeren teknik dokümanlarınızı yaparsınız.

UML kullanan şirketler var, ancak bunlar genellikle ayrı tasarım ve uygulama ekipleri olan şirketler. Tüm belgelerini oluşturacak ve daha sonra bir prototip / alfa oluşturmak için onu kod maymunu ekibine verecekler. Eğer oyununuzu doğru bir şekilde modelleyebiliyorsanız, onu tamamen farklı bir takıma verebilmeniz ve daha doğrusu daha kesin bir hayal olsa da, onları programlayabilmeniz gerektiğini söyledi.

Fikirlerinizi ekibinizin geri kalanına iletmenize yardımcı olacak ve öğretim görevlilerine temel yazılım mühendisliği ilkeleri hakkında iyi bir çalışma bilgisine sahip olduğunuzu göstermek için size üniversitenizde UML hakkında eğitim verecekler.

Dil, araçlar veya tasarım üzerine yapılan herhangi bir tartışma gibi - genellikle onu nasıl kullandığınıza bağlı olarak gelir. İş için en iyi aracı / dili / tasarımı seçin ve seçiminizi güçlü bir gerekçeyle destekleyin. UML'nin oyun üretimi için çok esnek olmadığını kabul ediyorum, ancak bunu ağ iletişimi ve zamanlama, paralel görev yönetimi ve kullanım durumları gibi motor özelliklerini modellemek için etkili bir şekilde kullandığımızı söyleyebilirim. Aynı şeyi 5 farklı ekip üyesine 10 farklı kez açıklamaktan daha kötü bir şey yoktur çünkü tam olarak anlamadılar. İşte belgeler, oku.

Ne kadar sağlam tasarladığınıza ve ekibinizin ne kadar disiplinli olduğuna bağlı olarak, kendi yapınızı henüz başlamamış olanlar etrafında modellemek ve henüz tam olarak nasıl çalışacaklarını bilmeniz oldukça verimli olabilir. dokümantasyon.

Buna rağmen, muhtemelen YAŞAM DOKÜMANLARI olduklarını duyacaksınız (ve sert bir şekilde fark edeceksiniz) ve düzenli olarak gözden geçirilip güncellenmedikleri sürece, eski ve hızlı bir şekilde işe yaramaz hale gelecektir.