Tablice informatyczne. Unity

1. 4 oceniona przez: 2018-07-17

2. 1 potwierdzona zakupem i oceniona przez: Rafał Tadajewski, 2018-07-11

   Jestem programistą Unity od prawie 3 lat. Myślałem początkowo, że będzie to bardzo przydatna pozycja ale gdy zacząłem ją czytać to się zdziwiłem ile można rzeczy źle zrobić na 6 stronach. Pierwsze kryterium mojej oceny to możliwość stworzenia gry na bazie tego opracowania bo wg opisu tablice są bardzo przydatne. Mając do dyspozycji wiedzę z tych tablic nie da się zrobić najprostrzej gry bo nie ma tu nawet wzmianki o kilku podstawowych klasach. Tu od razu wymienie opisywane klasy (takie gdzie powiedziano coś o ich polach czy metodach): Transform, Input, Camera, Light, MeshFilter, SpriteRenderer, MeshRenderer, Material, Terrain, Rigidbody, Collider, NavMeshAgent, Canvas, AudioSource, RectTransform, Random. Jest powiedziane po zdaniu o paru innych klasach ale nie będę ich wymieniał. Najważniejszą klasą jest Monobehaviour na bazie, której tworzone są wszystkie skrypty. Nie ma o tej klasie ani słowa. Nie ma też żadnej wzmianki o klasie Object, VectorX, SceneManager, Debug, Mathf, Physics, Time, które wymieniam jako minimum potrzebne do utworzenia prymitywnej gry. Opis tablicy na stronie mówi, że można będzie znaleźć najważniejsze opcje bez zaglądania do wyszukiwarki. Ja wam, gwarantuję, że będziecie weryfikować niektóre fragmenty tego opracowania. Teraz kwestia poziomu opracowania. W mojej ocenie opracowanie jest bardzo słabe. W opisach tematów jest wiele błędów, o które opisuję na końcu opinii. Opracowanie jest w większości tłumaczeniem treści dokumentacji. Przejrzałem opisywane tematy w dokumentacji. Tam gdzie dany temat jest opisany w jednym miejscu, to taki opis jest bez zarzutu i może być przydatny. Natomiast tam gdzie wymagana jest oprócz opisu własna wiedza i znajomość większego obszaru dokumentacji, to takie fragmenty tablicy są często błędne. Jak na 6 stronicowe opracowanie to jest o co się czepiać. LISTA BŁĘDÓW: W części porównującej Unity i Unreal nie rozumie w grupie platformy autor wymienia iOS Playera i Web Playera jakby były to jedyne platformy, które możemy kompilować. Do tego Web player od kilku wersji nie jest wspierany. Okno Project Window – autor dzieli okno na dwie części Favourites i Assets. Pierwsza kwestia te dwie części będą jednocześnie gdy wybierzemy Two Column Layout. Druga kwestia – autor twierdzi, że aby do Favourites coś dodać wystarczy to przeciągnąć. Prawda jest taka, jedynym typem assetu który można tam przeciągnąć są foldery. Pozostałe assety można tam dodać tylko jako kryteria wyszukiwania – kryteria zostaną dodane gdy wciśniemy przycisk gwiazdki. Okno SceneView – Autor porównuje te okno z oknem gry, twierdząc, że tylko w oknie sceny znajdują się ikonki niewidocznych obiektów czyli gizmos. Pierwsza sprawa, ikony to ikony a gizma to elementy rysowane z pomocą klasy Gizmos. Druga sprawa, gizma widoczne są także w oknie gry, wystarczy wcisnąć przycisk Gizmos w tym oknie. Trzecia sprawa – co to są "ikonki niewidocznych obiektów"? Gizma można przypisać każdemu obiektowi nawet widocznemu. Handlesy są widoczne tylko w SceneView. Menu gizmos służy nie tylko włączania/ wyłączania widoczności ikonek ale także i rysowanych gizm. Okno Hierarchy window – autor twierdzi, że znajdują się tu wszystkie obiekty w scenie, i są uporządkowane pod względem hierarchii logicznej. Pierwsza sprawa nie obiekty tylko gameObjekty. Druga sprawa, co to porządkowanie względem hierarchii logicznej? Defaultowo mamy ustawione Transform Sorting czyli ustawienie gameObjektów będzie zależało od wzajemnych zależności komponentów Transform czyli tego jak ustawimy je w oknie Hierarchii. Możemy także włączyć alfabetyczne sortowanie obiektów gdy włączymy odpowiednią opcje w oknie Preferences wyświetlającą odpowiedni przycisk. Create - nie tworzy "obiektów standardowych typów" tylko gameObjecty posiadające określoną konfiguracje gameObjectów i komponentów aby nie trzeba było samemu od zera łączyć elementów. Okno Inspector Okno inspectora ma wygląd zależny od typu obiektu. Opisy nie mówią czego dotyczą jakby wygląd inspectora był uniwersalny. Opis inspectora dla gameObjectu jest pomieszany z wyglądem inspectora dla assetów. Toolbar. Narzędzia mają określone nazwy. Hand Tool - nie poruszamy sceną tylko kamerą w widoku sceny. Layers pozwalają także blokowanie zaznaczania gameObjektów w wybranych warstwach. Okno GameView Display służy do pokazywania jak będzie wyglądał obraz na danym wyświetlaczu gdy korzystamy z wielu wyświetlaczy naraz. Dodatkowo tłumaczenie jako "pokaz" jest niezbyt adekwatne. Google Translator nie zawsze ma racje. Skróty klawiszowe Zbiór skrótów powstał na bazie strony w dokumentacji gdzie wypisane są skróty. Ta strona istnieje od Unity 3.5(2012 rok) i nie była aktualna nawet wtedy. Skrótów klawiszowych jest znacznie więcej. W samym rozdziale Working in Unity można znaleźć wiele innych skrótów. Autor się nie wysilił aby przeczytać i pozbierać te skróty. Druga sprawa to nazwy kategorii skrótów. Kategorie skrótów powiązane są z określonymi oknami. Niektóre kategorie w tabeli nie mówią, jakich okien dotyczą skróty. Co do wymienionych skrótów to Lock View to Selected (Shift+F) jest źle opisany, nie wspomina o blokowaniu widoku na gameObiekcie. Autor opisał go jak Frame Selection (F). Skrót Shift+Del oprócz typowego usuwania obiektów służy do usuwania elementów tablic. Jeśli chodzi o skróty powiązane z oknem Animation to zostały ich opisy przepisane z dokumentacji bez jakiejkolwiek weryfikacji. Co to "wybrany klucz" i "zmodyfikowany klucz"? Autor nie wie jak działają te skróty. Emmisive Material – EM odziaływuje także na obiekty dynamiczne gdy skorzystamy z próbników światła. Druga sprawa, że gameObiekt, który korzysta z tego materiału musi być statyczny aby mógł oświetlać inne obiekty. MeshRendererer – wymaga komponentu MeshFIlter a nie Mesh. Light Probes – tłumaczy się jako próbniki światła a nie próbki światła. Podobna sytuacja dla Reflection Probes. Komponent Material – nie znam takiego komponentu. Material jest assetem nie komponentem. Każdy komponent dziedziczy z klasy Component. W części o fizyce autor wymienia komponenty dziedziczące z typu Collider. Podaje tu kollidery dla fizyki 3D i fizyki 2D. Unity używa dwóch silników fizycznych NVIDIA PhysX i Box2D. To dwa różne silniki i nie są ze sobą kompatybilne. Kollidery dla fizyki 2D dziedziczą z typu Collider2D. Dodatkowo przy wymienianiu komponentów zostało pominiętych kilka kolliderów jak SphereCollider2D, EdgeCollider2D, TilemapCollider2D, CompositeCollider2D czy CharacterController. Dalej wspomniane jest o Rigidbody i Jointach i wymienione 3 z nich dla fizyki 3D. Nie widzę tu logiki opisu fizyki a także rozumienia tej tematyki. Fizyka 2D i 3D jest pomieszana raz wymieniane są komponenty z obu a dla innych komponentów z tylko jednej. Collider – przy omawianiu, isTrigger opis jest bezsensowny. Dodatkowo autor wspomina, że kollider zostanie zignorowany przez system fizyki gdy checkbox będzie wciśnięty, co jest całkowitą bzdurą. Metody i pola klasy Collider bounds – to nie przestrzeń otaczająca collider. Pojęcie Bryły brzegowej na Wikipedii opisuję o co tu chodzi. O elementach fizyki: Opisy callbacków OnTriggerXXX i OnCollisionXXX są wrzucone do klasy klasy Collider i Rigidbody. Nie można do nich się odwołać z tych klas ani zdefiniować ich ciał. Można to zrobić jedynie w ciałach dziedziczących z MonoBehaviour. Nie wiem czemu są omawiane w klasie Rigidbody i Collider. Kolejna sprawa opisy. Są słabe. Pierwsza kwestia – istnieją w dokumentacji tablice kolizji mówiące jakie rodzaje kolliderów oddziaływują z jakimi kolliderami. Opisy albo nie mówią tego albo mówią niedokładnie. Druga sprawa. Nazywanie wszystkiego kolizją jest niewłaściwe. Nie bez powodu nazwy funkcji się różnią. DUSZKI Sprite Editor - Aby skorzystać z okna Sprite Editora pierw grafika musi mieć ustawione Texture Type na Sprite, inne ustawienia grafiki nie pozwolą na otworzenie tego okna. Sprite Renderer – nie wymieniono pól Sorting Layer i Sorting Order, które decydują o wzajemnym ustawieniu spritów. Sprite Packer – jest to narzędzie przestarzałe. Od Unity 5.6 czasu należy używać Sprite Atlasów. KONTROLER ANIMACJI Nie omówiono okna Animation, służącego do tworzenia pojedynczych animacji gameObjektów. Animator Controller – nie łączy on poszczególnych klatek animacji i nie pozwala zarządzać przejściami między nimi. Klatka kluczowa to pojęcie powiązane z oknem Animation. Assety typu AnimationClip są zbiorem klatek kluczowych tworzących razem pojedynczą animacje. Animator Controller pozwala łączyć i przechodzić między AnimationClipami. Connections – nie ma czegoś takiego. Jest natomiast Transition. MENADŻER USTAWIEŃ TimeManager – FixedTimestep – autor twierdzi, że ta wielkość decyduje od częstotliwości wywoływania funkcji OnFixedUpdate. Nie znam takiej funkcji. Te ustawienie określa częstotliwość wykonywania obliczeń fizycznych i niektórych callbacków np. takich jak FixedUpdate. SPECJALNE FOLDERY Gizmos, Resources – te foldery powiązane są ściśle z metodami z klas Resources i Gizmos. Opisy nie są zbyt klarowne do czego służą te foldery. Opis StreamingAssets także będzie problematyczny do zrozumienia dla czytających bo przetłumaczenie fragmentu opisu z dokumentacji nie wystarczy. Inne uwagi. Opisy przycisków okien mogły by zawierać obrazki przycisków. Dużo miejsca ikonki przycisków nie zajmują. Zwracane wartości nie są podawane w jakim układzie współrzędnych. GameObjekty są nazywane w opracowaniu często obiektami co zaciemnia zrozumienie zagadnień. Podobnie z innymi elementami. W Unity występuję wyraźny podział na gameObjecty, komponenty i assety bo ma to wpływ na działanie wielu funkcjonalności. Jest też kilka metod które, będą działać inaczej w zależności od typu obiektu. Opisy w tablicy powinny być klarowne a nie być tłumaczeniem z angielskiego na polski dokumentacji bez zrozumienia. Wymagam od osoby piszącej minimum rzetelnej wiedzy a nie pisania aby zapełnić określoną ilość stron tym bardziej, że jest ich tylko 6. Nie polecam tych tablic.

więcej opinii

ukryj opinie