Bir fizik motorunun tasarımı nasıl görselleştirilir?


17

Bir fizik motoru yapıyorum ve her şeyi takip etmek oldukça zorlaşıyor. Genellikle bir aradan sonra koduma geri döndüğümde neden işe yaramadığını hatırlamıyorum. Sorunların çoğu basit programlama hataları değil, fizik motorumdaki tasarım kusurları. Bu yüzden programlamadan önce tasarlamayı bitirmeliyim.

Ancak, fizik motorumun tüm tasarımını kağıda yazmanın bir yoluna ihtiyacım var. Yoksa yarın unutacağım ve tekrar kaybolacağım. Bir UML sınıf diyagramı bir fizik motorunun tasarımı için hiç uygun değildir. Sınıfları gerçekten önemsemiyorum ama süreci. İş süreç şemasını gerçekten kullanışlı görmüyorum çünkü işlemimin tek bir adımını (çerçevesini) modellemek, motorumun son davranışını birçok adımda anlamama yardımcı olmaz.

Peki, süreci takip etmeme yardım etmek için ne tür bir diyagram kullanmalıyım? Profesyonel bir fizik motoru yapmak için hangi diyagram diyagramlarını kullanır?


4
İlk olarak, motorun nasıl kullanıldığını ve işleri nasıl değerlendirdiğini göstermek için yüksek seviyeli bir akış diyagramı öneririm. Veya OpenGL boru hattı şemasına benzer bir şey ( openglinsights.com/pipeline.html ). Ardından, diğer kişilerin nasıl yaptığını görmek için bir Google Görseller araması "Fizik motoru şeması" yapardım! ;)
SinirliWithFormsDesigner

4
"Bir UML diyagramı" ile muhtemelen bir sınıf diyagramı mı kastediyorsunuz? Sınıf diyagramı UML'deki 7 yapısal diyagramdan biridir. Ayrıca 7 tür davranış diyagramı vardır.
GELMEKTEDİR

Her şeyden önce, fizik motorunu çok iyi anlamalısınız; her küçük ayrıntı ve her şeyin birlikte nasıl çalıştığı Programlama ile ilgisi yok. Ardından, programlama varlıkları (sınıflar) ve etkileşimlerde modellemeye çalışırsınız. İstediğiniz araçları kullanabilirsiniz (eskizler ve elle yazılmış notlar bile). Ardından, sınıfları birer birer oluşturursunuz. Bir konsol uygulaması yazarak başlayın. Küçük sınıflarınızın çalıştığından ve beklediğinizi yaptığınızdan emin olmak için birim / sınıf testleri kullanabilirsiniz
John Kouraklis

6
Deneyimlerime göre, profesyonel programcılar bir şeyler tasarlamak için tasarım belgeleri veya diyagramları kullanmazlar. Belki bir beyaz tahtada. Çağdaş programlama dilleri ile tasarımlar baş ve koddadır. Tasarım belgeleri veya diyagramları çoğunlukla iletişim için kullanılır. Açıklamanıza dayanarak, tahminim tasarımınızın ayrıştırılması gerekiyor.
JimmyJames

1
"Bir UML sınıf diyagramı bir fizik motorunun tasarımı için hiç uygun değildir." Neden olmasın? Sınıflar tamamen endişelerin ayrılmasıyla ilgilidir. Herhangi bir sistem farklı rollere sahip bileşenlere ayrılabilir ve bu bileşenler genellikle sınıflara ayrılabilir.
Tanner Swett

Yanıtlar:


29

Yapılacaklar listeleri harika şeylerdir.

// #TODO: blah blah yorumlarından bahsetmiyorum. Demek istediğim, Tanrı defterlerine dürüst ol.

Yapmanız gereken önemli bir şeyi ne zaman hatırlayacağınızı asla bilemezsiniz. Bir defter sessizce orada oturacak ve el yazınızın nasıl derlenmeyeceğinden şikayet etmeden düşünmenizi sağlayacaktır. En iyi fikirlerimden bazıları banyoda oluyor (evet su geçirmez bir defterim var ama o kadar ileri gitmenize gerek yok).

Cepte dikilmiş (yapıştırılmamış) cep boyutlarında olanlar alabilirsiniz, böylece cebinizde parçalanmazlar. Yerleşik bir kitap işareti ile süslü bir tane almayı başaramadınız mı? Teyp, makas, şerit ve hiç kimse bilmeyecek.

Bir fikir çarptığında sadece not alın. Her bir fikrin yanına küçük kutular çizin ve kolayca tamamlandı olarak işaretleyebilirsiniz. Sayfanın üst kısmına bir kutu koyun ve sayfanın ne zaman bittiğini bilirsiniz.

Hangi sıralı erişim sizin için yeterli değil? Evet, cep bağlayıcılar da yapıyorlar. Bu biraz fazla gibi görünebilir ama notları boğmaktan veya Jira'daki her şeyi yakalamaya çalışmaktan daha iyidir.

İşleri yarıya bırakmayın

Geliştirmelerinizi küçük ve ulaşılabilir tutun. Bir oturuşta bitirilemeyecek hiçbir şeye başlama. Bunun için büyükse, daha küçük adımlara bölün. Her zaman testlerini derleyen ve geçen kodu bırakın. Oh ve hiç görmediğin testlerden geçme. Hem başarılı hem de başarısız bir test yapmak testi nasıl test ettiğinizdir.

Tüm tasarıma kağıt üzerinde ihtiyacınız olduğunu düşünmeyi bırakın

Yapmanız gereken, gelişen planınızı yakalamak. İşiniz bittiğinde işlerin nasıl görüneceğini bilmiyorsunuz, öyleymiş gibi davranmayı bırakın. Çözdüğünüzü olabildiğince yakalayın. Gerekirse peçete ve mum boya kullanın. Zaten çok az insan UML'nin% 90'ını anlıyor. Göstermeniz gerekenleri göstermek için istediğiniz şekilde kullanın. Arayüzlerimi ve neyi bildiklerini göstermeye odaklanıyorum.

Kodlamayı durdurduğunuzda notlar yazın

Parmaklarınızı anahtarlardan çıkardığınız an, ne yaptığınızı (ve ne planladığınızı) ve şimdi yaptığınız zamanı en son anlayacaksınız. Bu anlayışı bazı notlarda mümkün olan en iyi şekilde yakalayın. Eğer tüm yorumlarınız varsa o zaman hala bilgisayara bağlı ve muhtemelen bir su birikintisi sandalyede bırakacaksınız. Yine, bir deftere sahip olmak harika bir şey.

Bu şekilde beyninizi nazikçe yere indirebilir, mesanenizi koruyabilir ve daha sonra kafein ve dişleri gıcırdatmadan tekrar çıkarabilirsiniz.


(Aynı zamanda akıllı olan dürüst bir dizüstü bilgisayar olarak, Emacs Org modu iyi çalışır. Benzer bir araç, hatta bir sorun izleyici bile, süreçlere bağlı olarak iyi çalışabilir. Bir kağıt defter taşımak için harika ve hızlı grafikler ve düşünürken harika olan resimler .)
9000

6
İçin +1 Don't start anything that can't be finished in one sitting. If it's to big for that then break it down into smaller steps.. Sanayide öğrendiğim en önemli şeylerden biri.
Akshat Mahajan

8

"Her şey yukarıdan aşağıya inşa edilmelidir, ilk kez hariç" diyorlar.

En düşük seviyeden başlayacağım (örneğin, temel vektör matematiği) ve iyi anladığımdan emin oldum ve iyi bir test kapsamı var. Sonra bunun üzerine bir kat daha inşa ederdim, daha soyut operasyonlara izin veririm (örneğin gruplar / varlıklar, çarpışma tespiti, çarpışma mekaniği). Yine, testlerle kaplardım; motordaki bu soyutlamaların gerçek kullanım durumlarını düşünmeme yardımcı olur.

Tüm motoru çok iyi anlamadığınız sürece (örneğin, iyi bilinen mevcut bir motoru yeniden uyguladığınızda), bu katmanlara sahip olmak genellikle iyidir; belirli bir katman üzerinde bir önceki katman açısından düşünmenizi sağlar ve genellikle daha derin değildir. Yeni yararlı soyutlamalarla bir katman deneyebilir ve oluşturabilirsiniz; gerçekte pratik olduğunu kanıtlayan şey genellikle ilk fikirlerden sapmaktadır.

Umarım her katman, onun için karmaşık bir şemaya ihtiyacınız olmayacak kadar küçüktür veya yararlı bir katman bulmak kolaydır.

Hiç yararlı bir karmaşık kod diyagramı ile karşılaşmadım. Bununla birlikte, etkileşim ve yaşam döngüsü diyagramları yararlıdır. Çoğu zaman böyle bir diyagram 1-2 katmanla sınırlıdır ve bu nedenle basittir.

Genellikle en değerli bulduğum şey, her seviye tarafından sağlanan arayüz tanımları ve garantilerdir. Vektör matematiğinin formatı ve sayısal hatalarda ne olduğu; daha büyük nesnelerin tanımlarının formatı (her zaman dışbükey? her zaman saat yönelimli?, nasıl kesişir? vb.), etkileşimin mekanik parametreleri (zaman nasıl ilerler? kütle nasıl ele alınır? momentum her zaman korunur? kuvvetler nasıl hesaplanır?) etkileşimler uygun (sürtünme nasıl ele alınır? deformasyon? parçalanma?) mekanik enerjinin ısı kayıplarına dönüşmesi bir şeydir?).

Her katman, sağladığı ve sağladığı garantili şeyleri gözlemleyebilecek kadar küçük olmalıdır. Bu açıklama, herhangi bir uygulama kodu yazılmadan bile hazırlanabilir (henüz). Bu, üç kat derinlikte korkunç derecede yanlış bir şey yaptığınızı belirleme şansını azaltır; eğer bunu yaparsanız, zaten en fazla iki kat derinlikte görülebilir.


Kod kümenizi oluşturmayı, sorun kümenizi gittikçe daha etkileyici hale getiren katmanları oluşturmayı seviyorum. Ama onları ilk seferde doğru yapacağınızı düşünmeyin. Daha yüksek şeyler uygulamak için bir katman kullanmaya başladığınızda, API'nizle ilgili sorunlar bulacaksınız ve geri dönüp onu değiştirmeniz gerekecektir. Sorun değil.
Justsalt

4

Mimarinin şemalarını yapın! OpenGL boru hattı diyagramları FrustratedWithFormsDesigner comments programı için büyük bir örnektir gönderilmiş akışı , ama bu yararlı olabilir diyagram sadece bir tip.

Diyagramlar tasarlarken , kodun anlaşılmasını basit ve sezgisel hale getirmek istersiniz ; bu, hem üst düzey kavramları (bu OpenGL boru hattı şemasındaki düğümlerin üst satırı gibi, bir şey söyleyerek) veya çok ayrıntılı, teknik ayrıntıları (tam işlevli bir çağrı grafiği gibi) kapsayabilir.

İdeal olarak, belgeleriniz ayrıca kodu diğer kişilerin anlaması için kolaylaştırmalıdır; bu, kod incelemeleri veya açık kaynak işbirliği gibi şeyleri kolaylaştırabilir. Bunu nasıl başardıklarını görmek için büyük projelere bakın - yüz binlerce veya milyonlarca kod satırıyla çalışırken, programın okumak zorunda kalmadan nasıl çalıştığını anlamak, kod tabanını takip etmek veya başkalarına tanıtmak için büyük önem taşır . 1.3 milyon LOC'a sahip Vim deposu, /src/README.txt dosyasında bunun için oldukça büyük üst düzey belgelere (IMO) sahiptir . Aşağıdakileri sunar:

  • Her dosyadaki kod ne yapar
  • Önemli küresel değişkenler ve değerleri
  • Ana döngüde ne olur ve işlevleri çağırır
  • Her bir modda ne olur ve bunları idare eden ana işlevler
  • Yerel hata ayıklama özellikleri nelerdir

Bir yamaya katkıda bulunmak istiyorsam, genellikle hedeflerime çok fazla kazmadan ulaşmak için hangi dosyayı değiştirmem gerektiğini biliyorum.

Vim'in en iyi özelliklerinden biri, /src/README.txtbulmanın ne kadar kolay ve ne kadar kapsamlı olduğudur; herhangi bir anlamda ayrıntılı değildir, ancak srcGithub'daki klasörü tıklarsanız otomatik olarak yüklenir ve diğer kodu veya belgeleri bulmak için yön verir. Bir örnek için baktığım ancak Vim'lere eşdeğer bir dosya veya dosya bulamadığım Powershell repo ile kontrast /src/README.txt. (988 bin LOC ile bir proje için kötü bir işaret!)

Diyagramlamak veya belgelemek isteyebileceğiniz bazı şeyler şunlardır:

  • Kavramsal program akışı (Program neyi başarıyor ve hangi sırayla?)
  • Uygulanan program akışı / işlev çağrı grafiği (Program hedeflerine nasıl ulaşır? Hangi işlevler çağrılır veya sınıflar oluşturulur?)
  • Hangi dosyalarda hangi kod var? Organizasyon şeması nedir ve yeni bir fonksiyonun nereye gittiğini belirlemek için hangi kurallarınız var? Güçlü bir organizasyon şemanız varsa, belirli bir işlev veya sınıf için hangi dosyanın aranacağını bilmek, IDE veya IDE benzeri “proje çapında bul” özelliği olmasa bile kolay olacaktır.
  • İlgili olarak, hangi dosyalar hangi diğer dosyaları (bir işlev çağrısı grafiğiyle ilişkili) içerir?
  • Hangi sınıflar diğer sınıflardan miras alır? Her sınıfın amacı nedir?

Bu diyagramları nasıl yapabilirsiniz? Seviyenizde ve ilk taslaklar için kalem ve kağıt muhtemelen en iyi / en hızlı yöntemdir. Diyagramlar ve belgeler daha rafine hale geldiğinde şunları inceleyebilirsiniz:

  • Dot / Graphviz, .dotdosyalardan grafik oluşturmak için bir dizi program .
  • LaTeX / TikZ, herhangi bir tür grafik veya resim oluşturmak için çok karmaşık ve ayrıntılı bir araç - özellikle tüm düğüm konumlandırması manuel olduğu için ihtiyaçlarınız için çok ağır olabilir, ancak özellikle bir kağıt ya da daha sonra böyle bir şey.
  • C, GSON en için egyptkanca gccve çıkışlar .dotçağrısı grafik. Otomatikleştirilebilir veya makegüzel bir komuta gömülebilir !
  • İlgili olarak, GNU cflow, C için salt metin çağrı grafikleri oluşturabilir. Diğer diller için eşdeğer araçlar bulunabilir, ancak genel olarak otomatik araçlardan uzaklaşmak isteyebilirsiniz - grafiği manuel olarak oluşturmak, kod anlayışınızı engelleyebilir veya uygunsuz bir şekilde sağlayabilir karmaşık ayrıntı düzeyi (hangi işlevlerin çağrıldığını bilmek printf()genellikle oldukça yararsızdır).

Gerçekten iyi belgelere sahip olmaktan endişe duyuyorum, ancak şimdilik kodum sürekli yeni algoritmalar ve bir şeyler yapmaya çalışır. Örneğin, sürekli çarpışma algılamayı algılayan kodda, Vücut sınıflarında önceki konumların depolanmasından, Vücut hareketinden önceki konumun hesaplanmasına kadar birçok kez geçtim. Bu mesleksizlik eksikliği, programlama sırasında bir şeyi tasarlamamdan kaynaklanıyor çünkü fizik motorumda bir şey tasarladığımda bunun gerçekten mümkün olup olmadığını kontrol etmek istiyorum.
Kış

Sanırım bu projeyi deneysel olarak düşünmeli ve daha sonra yaptığım prototiple sıfırdan yeniden yazmalıyım, ancak her şeyi yeniden yazmak zorunda kalmadan onu temiz tutacak kadar çaba sarf etmeliyim.
Kış

0

Petri Nets tabanlı bir diyagram kullanmayı deneyin. Diyagramı bilgisayar programlarına sistematik bir şekilde çevirmek mümkündür ve yüksek seviyeli diyagramları düşük seviyeli diyagramlarla entegre etmek mümkündür.

Referanslar

Net Unsurlar ve Ek Açıklamalar: Genel Amaçlı Görsel Programlama Dili (2016). Boş https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Bilgisayar Programlama için Net Unsurlar ve Ek Açıklamalar: PDF'de Hesaplamalar ve Etkileşimler (2014). Boş https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

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.