Unity3D motor tasarımının ardındaki nedenler (oyun nesnesi / dönüştürme bileşeni)

Unity3D motor tasarımının ardındaki mantığı anlamaya çalışıyorum ve bu henüz kafamı bulamıyorum: neden veri, isim, katman maskeleri ve GameObject'in bir parçası olmak yerine ayrı bir bileşende depolanıyor etiketler? Zaten diğer tüm bileşenler gibi kaldırılamaz, alternatifi yoktur ve bu nedenle çıkarılmasına gerek yoktur.

architecture unity component-based

— snake5
kaynak

Bana göre bu kulağa mimari miras gibi geliyor. Belki bu dönüşüm bileşeni normal, isteğe bağlı bir bileşenti, böylece Kartezyen alanından "dışarı" nesneler olabilir. Daha sonra bazı uygulama kısıtlamaları (optimizasyon?) Bu bileşenin her zaman mevcut olmasını gerektiriyordu ve bu şekilde kaldı. Ama bu sadece varsayım, Birlik'ten bir mühendisin bu soruyu gerçek olarak cevaplaması gerekir.

— Laurent Couvidou

Yanıtlar:

Sadece Birlik geliştiricileri bu tasarım için gerçek motivasyonlarını verebilir, ancak bunu bu şekilde yapmayı destekleyen bir argüman, bir yazılım projesindeki her sınıfın bir ve sadece bir sorumluluğu ele alması gerektiği iddiasıdır . GameObject, adlandırılmış bir Bileşenler koleksiyonudur ve buna konum / döndürme / vb. Eklemek 2 sorumluluğa sahip olacağı anlamına gelir. Dönüştürme bileşeni konum ve döndürmeyi işler ve bu nedenle diğer (potansiyel olarak ilgisiz) bileşenlerin adlandırılmasından veya birleştirilmesinden de sorumlu olmamalıdır. Bu nedenle bu 2 kavramın 2 ayrı nesnede var olması mantıklıdır.

Daha genel olarak, bu soru "X ve Y arasında bire bir ilişki olup olmadığı, neden Y X'in bir parçası değil veya tam tersi?" Ve genel cevap, 2 parça her zaman birlikte çalışsa bile, yazılımın daha küçük müstakil parçalara ayrıldığında geliştirilmesinin ve bakımının daha kolay olmasıdır.

— Kylotan
kaynak

Bunu da düşündüm ama GameObject filtrelemeyi (katmanlar, etiketler) aynı nedenden ötürü ayrı bir bileşene taşıyabilirlerdi - ve henüz etmediler. Ayrıca, dönüşüm bileşeni, hiyerarşi verileri (ebeveyn, çocuk vb.) Tutularak sistemde çok derin bağlanır.

— snake5

Katmanların ve etiketlerin bir adlandırma biçimi olduğu, adın yanında yaşaması gerektiği ve bu nedenle sistemdeki bir bileşen koleksiyonunu oluşturan şeyin gerçek bir parçası olduğu iddia edilebilir. Ebeveynliği tutan dönüşümlere gelince, bir noktanız var, ancak kimse Birlik sisteminin mükemmel olduğunu iddia etmedi. Benim sistemim olsaydı, Dönüşümleri ayrı tutar ve ebeveyn / çocukları GameObject'e yerleştirirdim.

— Kylotan

Dönüşüm, Birlik'te zorunlu bir bileşendir.

Bir dönüşümün zorunlu bir bileşen olmasının nedeni, oyun nesnelerinin bir sahnede yer alması ve bu nedenle bu nesne hakkında uzamsal bilgilere (konum, yönlendirme ve ölçek) ihtiyaç duymasıdır. (Bu bilgi her zaman kullanılmaz, ancak dönüştürme bileşenini zorunlu tutmak işleri biraz daha basit tutar).

— Mortennobel
kaynak

Soru, bileşen tabanlı tasarımın ne olduğu ile ilgili değildir. Yaklaşık var yanı "dönüşümü" neden bir bileşen değildir

— bummzack

Ancak Transform, Unity'deki bir bileşendir! docs.unity3d.com/Documentation/ScriptReference/Transform.html . Dönüşümle ilgili tek garip şey, bunun GameObject için zorunlu bir Bileşen olmasıdır.

— Mortennobel

Sanırım soru neden kaldıramayacağınızla ilgili? OP terime aşina olmasaydı sorusunu "bileşen tabanlı" olarak etiketlemezdi.

— bummzack

Haklısın - teşekkürler. Soruyu daha iyi cevaplamak için cevabı güncelledim.

— Mortennobel

Soru, dönüşüm verilerinin neden ayrı bir bileşen olduğu ile ilgilidir (GameObject içindeki ad, katman maskeleri, etiketler gibi düz verilerin aksine). Yazımın en son revizyonunda bunu daha açık hale getirmeye çalıştım.

— snake5

TransformComponentEn zor Componentdüzgün video oyun mimarisinde tasarım. Hemen hemen her insanın Componentbelirli bir GameObjectpozisyonu, dönüşü veya ölçeği hakkında bilgi sahibi olması gerekir, bu nedenle bu birbiriyle ilişkili tüm sistemlerin düzgün şekilde ayrıştırılması doğal olarak zordur.

Mimarlıkta daima ödünleşmeler olacaktır. Sahip olarak TransformComponentstatik (yani değil dinamiği), Unity geliştiriciler bu varsayımı altında kodunu yazabilirsiniz. Bu, tarafımıza rahatsızlık vermeden çok daha kolay olduğunu düşünürdüm. Bu, bir nesne yönelimli paradigma, benzer olduğunu GameObjectolurdu extendbazı abstract class, Transformable.

— Alex
kaynak