Oyunları modellemek için gerçekten diyagramlar kullanıyor musunuz? [kapalı]


17

Çoğunlukla UML demek istiyorum, ancak çalışan herhangi bir yöntem uygulanabilir. Peki - aslında oyunlarınızı UML / diğer diyagramlar veya farklı yöntemlerle modelleyiyor musunuz? Üniversitemde UML ile modelleme konusunda bir konu vardı ve bunun gerçek faydadan daha fazla çaba gibi göründü, ancak bunun sadece büyük bir karmaşık BT sistemi oluşturmadığım için olabileceğini fark ettim. Peki zaman ayırmaya değer mi ve genellikle hangi tür diyagramlar / yöntemler * en iyisidir?

* Tabii ki, beton problemlerine birçok kez beton aletlerin seçilmesi gerekir, ancak belki de bazı desenler vardır.

Düzenleme: Önemli bir şeyi unuttum - bir şey uygulamadan önce veya sonra diyagramlar oluşturuyor musunuz? Demek istediğim - bir kişi bir şeyi tasarladığında ve uyguladığında, genellikle zihni değiştirirse ya da beklenmedik bir şey ortaya çıkar ve bazen değişiklikler yapmak zorunda kalır, bazen büyük olanlar - ve zaten karmaşık diyagramlarda yapmak, kodun kendisinde olduğu gibi umutsuz görünüyor.


5
Bu genel olarak programlama ile ilgili bir sorudur, bu yüzden şu soruya bir göz atın: programmers.stackexchange.com/questions/152997/…
congusbongus

3
Bağlantı için teşekkürler ama aslında bu soruyu kasten buraya koydum - gamedev'in bu açıdan diğer BT alanlarına benzer olup olmadığını görmek istedim.
NPS

Yanıtlar:


21

Etrafımızdaki her şeyin şu ya da bu şekilde bir diyagram aracılığıyla temsil edilebileceğini düşünüyorum. Zaman içinde belirli bir nesnenin durumları arasındaki geçişi temsil eden doğrusal bir diyagram olsa bile (yaşayan bir varlık gibi, doğumdan ölüme kadar bir dizi durumdan geçerek). Gerçek uygulama için düşüncelerimi ve fikirlerimi ortaya koymak için diyagramları kullanıyorum. Ben oldukça doğaçlama yapıyorum.

Bu nedenle, diyagramlarım çoğu zaman çok yüksek bir seviyede ve zihin haritaları gibi hissediyorum .

Bazı örnekler vermek gerekirse, bu aslında etkileşimli nesnenin temel tip olduğu oyunumda bir sınıf mirası haritası (kesilmiş olan).

Etkileşimli Nesne temel türdür

Bu, bir sivri tuzak için bir FSM ( Sonlu durum makinesi ) diyagramıdır (bastığınız ve sivri uçların yerden göründüğü müthiş tuzaklar ).

Basit başak tuzağı için FSM diyagramı

Bu, son zamanlarda çizdiğim bir el kitabı diyagramıdır (bu şekilde adlandırılmıştır, çünkü sık sık diyagrama geri dönmesi amaçlanmıştır ). Bir oyunun bileşenlerini ana hatlarıyla belirtir ve ayrıca neyin gerekli olup neyin olmadığını hemen görebileceğiniz için gerekli varlıkları toplamaya yardımcı olur. Bunları küçük projelerde öneririm, çünkü büyük projelerde oldukça büyük olurlar. Yine de daha da genişletilebilirler, bu da işleri düzeltebilir.

Oyun değerlendirmesi

Daha düşük bir seviyeye gittiğimde, bunun nedeni genellikle mimarimin en karmaşık yönlerini planlamam gerektiğidir ve genellikle orada UML ile uğraşırım. Yine de kesinlikle temiz ve doğru UML çıktısına konsantre olmadım. UML konvansiyonu hakkında en çok sevdiğim şeyi kabul ettim ve güzel bir zihin haritası UML'sine dönüştürdüm. Bu basit ve benim için işi yapıyor, ancak bununla birlikte, gerçek UML'nin beklendiği bir ortamda, belli nedenlerle gitmem.

Daha düşük bir seviyeye gitmem gerektiğinde başka bir durum, gerçek algoritmaları tanımlamam gerektiğidir. Akış diyagramları dediğim şeyi kullanıyorum . Beyaz kutu testinde kullanılan diyagramlardan esinlenen bir formattır .

Şu anda çizdiğim başak tuzağı için bir örnek şöyle görünecektir: Daha detaylı başak tuzağı akış şeması

Bu normalde diyagramlar ve gerçek algoritma uygulamaları arasındaki son katmandır. İhtiyaç ortaya çıkarsa, akış diyagramlarını daha ayrıntılı olarak incelerim (ekstra yürütülen talimatlarla) ve karmaşıklığı çıkarır veya tahmin eder ve doğru test senaryoları oluştururum. Ben de sahte kod yerine diyagramları tercih ederim.

Oyun geliştirme ile ilgili değil, çok ekranlı bir uygulamadaki ekranları, kullanıcının her ekranda tetikleyebileceği işlevselliği ve ekranlar arasındaki ilişkiyi tanımlamak için güzel bir formatım var. Normalde gerçek gelişime başlamadan önce bunları inşa ediyorum ve geliştirme süreci boyunca bir harita gibi davranıyorlar. Bir müşteri içinse, ekran diyagramı daha da yararlıdır! Başından başlayarak tüm projeyi gözden geçirmeme ve ihtiyaç duyacağı tüm işlevleri dikkate almama yardımcı oluyor. Bu nedenle, doğru bir maliyet ve zaman tahmini sağlamak çok değerlidir.

Evet, kesinlikle her şeyi ve her şeyi çiziyorum. Eğer bir fikrim varsa, kesinlikle bir şema çizebilirim ve çizeceğim. Bir şekilde beni desteklemek için en azından çok geniş bir diyagramı olmayan bir projeye başlarsam, sakat hissediyorum.


4
Bir sidenoteta, diyagramlar için yEd kullandınız mı? Çok kullanışlı buluyorum.
Kromster, Monica'nın

4
Kesinlikle! Başka bir kullanıcı gördüğüme sevindim. Geçtiğimiz yıllarda çok kullanıyorum, şimdiki favorim.

2
Yed için +1. Tek dezavantajı, UML'nin sezgisel olmamasıdır. Ancak diğer tüm diyagramlar için ücretsiz bir uygulama için şaşırtıcı.
Sidar

2
AiGameDev'in AI yarışması için davranış ağaçlarını tasarlamak için yEd kullandım.
Nick Caplinger

15

Kesinlikle yapıyorum - hem yapısal hem de davranışsal - temel kuralım şemayı yapmanın maliyeti bir ay sonra ne düşündüğümü hatırlamaya çalışmaktan daha az olduğunda veya kendimi açıkça anlatmam gerektiğinde şemalar yapmak. başka bir geliştirici

Kalıtım hiyerarşisi yeterince karmaşık hale geldiğinde sınıf diyagramları

Nesnelerin somutlaştırılması gibi şeyler, farklı parçalardan bir Frankenstein canavarı oluşturulmasıyla sınırlanan bir şey haline geldiğinde, özellikle gerekli lavabo bitlerinin ve piksel gölgelendirici kullanıcılarında, gerekli tüm bitlerin borudan itildiğinden emin olmak için yararlı olan nesne şemaları

Bir nesne kümesi arasındaki ayrıntılı etkileşimler karmaşık hale geldiğinde sıra diyagramları - bu, zar zor ilgili aşağı akış konumlarında daha önce hesaplanmış bilgilerin gerekli olduğu karmaşık render akışlarının modellenmesinde son derece yararlıdır


Önemli bir şeyi unuttum - bir şey uygulamadan önce veya sonra diyagramlar oluşturuyor musunuz? Demek istediğim - bir kişi bir şeyi tasarladığında ve uyguladığında, genellikle zihni değiştirirse ya da beklenmedik bir şey ortaya çıkar ve bazen değişiklikler yapmak zorunda kalır, bazen büyük olanlar - ve zaten karmaşık diyagramlarda yapmak, kodun kendisinde olduğu gibi umutsuz görünüyor.
NPS

6
ah ha - bağlıdır - eldeki sorun için hangi yol işe yarıyorsa - bazen kodu kemanlamak ve sonra diyagramlamak daha kolaydır, bazen diyagramı çizmek ve sonra oluşturmak daha kolaydır - bunun için zor ve hızlı bir kuralım yok one
Mark Mullin

@ Mark: bu bit cevabın bir parçası olmalı;)
Kromster, Monica'nın

8

Diyagramlar, tasarımınızı iletmenin, belgelemenin ve yardımcı olmanın harika bir yoludur ve tasarım, yazılım geliştirmenin en önemli parçasıdır. UML'nin birçok özelliği vardır, ancak hepsini aynı anda kullanmanız amaçlanmaz, sadece yararlı olanlar.

Yeni bir şehirde seyahat ederken, sadece işaretlere devam etmek ve onları takip etmek yerine durup bir haritaya mı bakıyorsunuz? Tasarım ve kodlama ile ilgili olan budur. İşler yabancı olduğunda, sorun karmaşık olduğunda, kendinizi kaybettiğinizde, tasarım hakkında düşünmek en yararlı olanıdır ve bunu daha sonra yapmak daha iyidir. Herhangi bir şey uygulamadan önce tasarımınızı değiştirmek çok daha kolaydır .

Diyagramlar, sorunu görselleştirmek ve tasarımınıza yardımcı olmak için, özellikle görsel düşünürler için (ki çoğumuz hayal ettiğim gamedev'de) harika bir yoldur. Bir çok sorun önemsiz hale gelir, bir diyagram üzerinde açıkça eşleştirildiğinde kusurlar belirginleşir. Bir diyagramda bulabileceğiniz bazı sorunlar:

  • Tek bir bileşene çok fazla bağlantı var mı? Bakımı zor bir tanrı nesneniz olabilir
  • Çok fazla ara bağlantı var mı? Mimariyi daha az kırılgan hale getirmek için modülerlik geliştirilebilir
  • İki bileşen arasında çok fazla yol mu var? Belki sıkı bir bağlantınız var
  • Oyunlar gibi yüksek performanslı uygulamalar için, sıcak yol veya iç döngüde çok fazla bileşen var mı? Bu performansınızı etkileyebilir
  • Bununla birlikte, çoğu zaman diyagram, tasarladığınız tasarım ile gerçek uygulama arasındaki tutarsızlıkları gösterecektir.

Ayrıca, diyagramlar, tasarımınızı teknik olmayan kişilere veya projenizde yeni olan kişilere iletmek ve belgelemek için mükemmeldir - ve 6 ay içinde projede hemen hemen yeni olduğunuzu unutmayın!

UML'yi nasıl kullanacağınız bu hususlardan kaynaklanmalıdır. Kendi iyiliğiniz için diyagram mı? En rahat olduğunuz notasyonu kullanın. Diğer geliştiricilerle işbirliği mi yapıyorsunuz? API çağrılarının ayrıntılarını, mesaj türlerini, bağımlılık yönlerini eklemeye çalışın. Mimariyi mi tartışıyorsunuz? Kara kutular ve basit bağlantılar yeterli olacaktır. Hiç kimse zaten UML özelliklerinin tamamını kullanmaz , ayrıca birçok insanın anladığı bir dizi standartlaştırılmış gösterim olarak çok kullanışlıdır - oysa peçete doodle'larım sizin için anlaşılmaz olabilir veya tersi de geçerlidir.

Kendime gelince, diyagramları her zaman kullanıyorum - kişisel projeler için basit not defteri çizimleri, iş yerinde basit UML diyagramları. Bu UML diyagramı , çok karmaşık olduğunu düşündüğüm şeydir ve asla üretmeyeceğim bir şeydir, çünkü onu üretmenin ve sürdürmenin maliyeti faydasından daha ağır basar, ancak elbette YMMV.


Sizin için büyük bir soru - IIUC, basit diyagramlara (her zaman) bağlı kalmaya çalışıyorsunuz. Ancak diyagramlar genellikle uygulama karmaşıklaştığında gereklidir. Geniş ve karmaşık sistemleri modellerken diyagramları nasıl küçük ve basit tutarsınız?
NPS

@NPS Amaç / hedef kitleye bağlıdır ve tecrübelerime göre karmaşık sistemleri modellemek için basit diyagramları kullanabilirsiniz. Genellikle sahip olduğunuz farklı insanlar için birçok farklı basit diyagramdır veya sistemin farklı yönlerini gösterir - bu yüzden kısmen UML'de farklı diyagram türleri vardır. Karmaşık sistemler genellikle hepsi basit olan birçok yönleri veya katmanları olduğu için karmaşıktır. Gerçekten karmaşık sistemler çok nadirdir, çünkü en iyi uzmanlar tarafından anlaşılması çok zordur.
congusbongus

8

İki çeşit diyagram olduğunu söyleyebilirim. Resmi diyagramlar ve karalamalar.

Resmi diyagramlarla ilgili olarak, diğer programcılarla çalışırken bunları yaparım, ancak bunu yalnız programlama yaparken nadiren yaparım.

Ancak bu, aklıma gelen her şeyi kodladığım anlamına gelmez. Kanımca, programlama (veya aslında hayattaki herhangi bir şey) sırasında en önemli şey önce düşünmek ve daha sonra yapmaktır .

Kodlama çok mekanik bir iştir. Siz yazın ve ekranda kelimeler görünür. Fikir, kodlamaya başladığınızda, sorunu zaten çözmüş olmanız gerektiğidir. Karalama yapmak, düşüncelerinizi sıralamak ve hatta kodlama kısmını doğru bir şekilde yapmanız gereken düşünceyi yapmaya zorlamak için harika bir yoldur. Karalamalar gelecekteki referans için kaydedilmeyecek, böylece düşünce süreçlerinizi kolayca anlayabilirsiniz.

Düşünmeye fazla zaman ayırırsanız endişelenmeyin. Zamanınızın% 90'ını düşünürken ve% 10'unu kodladığınızda iyi bir denge olduğunu düşünüyorum. "Düşünmek için vaktimiz yok, sadece yapmak için" yaşayan birkaç "kıdemli" programcı ile tanıştım. Ancak kodlarını, yaptıklarını düşünmek için zaman ayıranlardan daha önce "tamamlandı" olarak adlandırsalar bile, (veya daha sonra bırakılan şanssız ruhlar), doğru şekilde inşa edilmesi gereken bir şeyi düzeltmek ve yama yapmak için sayısız saat harcarlar. başlangıçtan beri.

En iyi şey düşünme özgürlüğüdür! düşünmek için bilgisayarınızda oturmak zorunda değilsiniz. Yemek yerken, işe giderken, egzersiz yaparken kodu düşünebilirsiniz ... Aslında, en iyi fikirler onları en az beklediğinizde gelir, bu yüzden zihninizi her zaman açık tutun ve sadece ne yaptığınızı gerçekten bildiğinizde kodlamaya başlayın Kod yazacağız.

İşte kabul ettiğim ilgili bir makale .

Düzenleme : Gerçek biçim ve diyagram türü ile ilgili olarak, ben serbest stil gitmek ve aslında önceden paketlenmiş araçları kullanmak yerine el yazısı tavsiye ederim. Unutmayın ki, düşünce sürecinizde size yardımcı olmak, istediğinizi çizmekten çekinmeyin. Anlambilim, onların olmasını istediğiniz şeydir ve diyagramlar arasında ve hatta diyagramın farklı bölümleri arasında farklı olabilirler.

Hazır ambalajlı araçlara göre serbest stil / el yazısı diyagramlarının üç ana faydası vardır:

  1. Seçtiğiniz herhangi bir araç tarafından desteklenen diyagram türüne uymak zorunda değilsiniz. Bazen harita zihinleri çalışır, bazen UML gibi daha iyi bir şey olurken, diğer zamanlarda bir mantık diyagramı işe yarayacaktır. Diğer zamanlarda tamamen özel bir şema işe yarar ve hiçbir araç size serbest stil diyagramlarının tüm esnekliğini veremez (kağıtta bir delik açmayı ve kağıdın arka tarafında, en sevdiğiniz pakette devam etmeyi deneyin ve ne olduğunu görün)

  2. Aracı kullanmak yerine, diyagram oluşturmak için daha fazla zaman harcayacaksınız. Araçtan bağımsız olarak, kalem ve kağıt, diyagramlamada her zaman aradığınız belirli öğeleri bulmak için klavyeden ve menülerden fareye göre daha hızlıdır.

  3. El yazısı için bir bilgisayara ihtiyacınız yok. Çoğu zaman karmaşık tasarımlar yapıyorum, bunları bir kütüphanede, bir kafede, hatta bir uçağın içinde yapıyorum. Ayrıca, iyi fikirler her zaman en az uygun anda ortaya çıkar, bu yüzden her zaman yazacak bir şeyler ve yazacak bir şeyler taşıdığınızdan emin olun.


3
ve bu "karalamalar" sadece zihninizde var olabilir ya da hiçbir resmi diyagram kuralına uymaz. Ve tasarımınızı ilerletirken ayarlamaktan ve yeni bilgiler elde etmekten korkmayın. Tabii ki başkaları için çalışıyorsanız ve tasarımdan sadece onlar sorumluysa (bunu öneri ve istekte bulunabilirsiniz), ancak kendi başınıza iseniz, devam edin ve deneyin. Sık sık oturup bir şeyler yapmaya başlarım, yaptığım şeyden evrimleşen bir tasarım buluyorum ve bir diyagram ya da belgede resmileştirecek kadar fikrim var.
jwenting

0

2013 Oyun Geliştiricileri Konferansı'ndan birkaç tasarım diyagramı görüşmesine değinmek faydalı olabilir. Bunlar çok pratik ve yol testinden geçmiş örnekler - ve yıllar boyunca birçok konferansta sunulmuş gibi görünüyor.

(Diğer cevaplar, tasarım odaklı diyagramların bir kod tabanının planlanması, oluşturulması, büyütülmesi ve sürdürülmesinde neden ve nasıl çok yararlı olabileceğini göstermek için takdire şayan bir iş yaptı, bu yüzden bu yönü yalnız bırakacağım ve bu kaynakların yararlı olabileceğine güveneceğim soruyu ziyaret eden herkese.)

Joris Dormans ve Ernest Adams, Machgines oyun tasarımı / denge diyagramlama sistemini tartıştılar . ( GDC EU 2012'den bir ödeme duvarı GDC Kasası videosu ; Dormans'ın wiki'sinde GDC 2013'ten örnekler .) Paraphrase girişimi yerine, wiki sistemi şu şekilde açıklıyor:

Makineler, oyunları dinamik sistemler olarak tanımlayan ve içlerindeki kapalı geri besleme döngülerine odaklanan teorik bir çerçeve ve etkileşimli, dinamik, grafiksel bir gösterimdir. Amaç, oyun yapılarını metodolojik olarak ifade etmek ve araştırmak (tekrarlayan) bir yol bulmaktır. Machations, oyun tasarımı ve dengelemenin sezgisel ve hassas uygulamasında yeni bir lens sunuyor.

Noah Falstein "Bulmaca Bağımlılığı Diyagramları Arcane Sanatı" (ödeme duvarı GDC Kasası videosu ) adlı bir konuşma yaptı . Burada herhangi bir ödeme yapılmayan bağlantı bulamıyorum, ancak çeşitli kişiler notlarını çevrimiçi olarak tartıştılar veya yayınladılar.

Her iki görüşme de bu diyagramları oluşturduklarında ve bu diyagramları nasıl ya da böyle koruduklarını tartıştı.


0

Oyun döngünüzü tanımlamak için basit bir soyut dilbilgisi kullanma, tasarım sorunlarını tanımlamanıza nasıl yardımcı olabileceği ve bu düzeyde yinelemenin ne kadar kolay olduğu hakkında muhtemelen bu makaleyi kontrol etmelisiniz.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Ayrıca, daha çok oyun döngüsünün ekonomisine dayanarak, fırsatlar, şans veya hazırlık gibi şeyleri izlemek için soyut kaynakları kullanarak, konuyla ilgili kendi çalışmamı işaret edebilirim:

http://www.stephanebura.com/diagrams/

Bu yaklaşımı yararlı bulursanız, bu diyagramları yapmak ve simülasyonlarını çalıştırmak için bir araç olan Joris Dormans 'Machgines'e bir göz atmalısınız:

http://www.jorisdormans.nl/machinations/

Tüm süreci kitabında açıklanmıştır:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.