Hello World, progress bar. – rozdzielczość

Mam ci ja progress bar, jest on piękny. W pozycjonowanie w oknie oczywiście włożyłam dużo czasu i wysiłku. Odpalam grę, i widzę coś takiego:

errorResize2
WTF?

Pasek zwiększa się wraz ze zwiększeniem ekranu, ale ucieka do góry i nic nie widać. Cóż robić, jak żyć?

Trzeba będzie jakoś „przypiąć” element do okna, tak, aby znajdował się w odpowiedniej procentowej odległości od krawędzi. Te małe trójkąty widoczne w Scene View to są właśnie szpileczki.

Pins_initial
Te trójkąty na środku nazywać będę szpileczkami.

Każda odpowiada za jeden róg naszego elementu, i określa jego położenie względem obiektu Canvas.

Na obrazku widać, że rysunek ma się przemieszczać tak, aby środek (bo wszystkie szpileczki są razem) znajdował się cały czas w takim samym stosunku do środka ekranu. Ale, ale: przecież na animacji widać, że wysokość pola gry się nie zmienia. Skąd więc ta ucieczka do góry?

width_resize
Stąd!

Mówi to nam ogólnie: „Jeśli masz zdecydować, czy ważniejsze jest zachowanie proporcji względem szerokości czy wysokości, wybierz szerokość”.

Przeciągamy wajchę na stronę „Height” i co się dzieje? Nasz uroczy Progress Bar ucieka do góry. Czemu?

errorResize3
Wracaj tu!

Problemem jest Reference Resolution, która ma domyślną wartość 800×600. Podgląd gry miał, w moim wypadku, 477×638 pikseli. Wobec tego Canvas Scaler, w zależności od ustawienia, dopasowywał rozdzielczość 850.(6)x638, albo 477×357.75. Duże różnice!

Pierwszym ważnym krokiem w rozwiązaniu tego problemu byłoby ustawienie Reference Resolution na przynajmniej zbliżoną do tego, co będziemy chcieli obserwować podczas gry, już na etapie układania elementów interfejsu. Na razie świadomie daruję sobie ten krok. Ręcznie przesuwam pasek na z góry upatrzone pozycje, i uruchamiam.

errorResize5
Lepiej!

Następnie manipulujemy szpileczkami. ^^

pins corrected
Ustaw szpileczki w środku obrazka, mówili. Będzie lepiej, mówili.
errorResize4
Jest lepiej, chociaż przez niewłaściwą Reference Resolution wciąż niestabilnie. Idzie przeżyć.

Okej, a co jeśli chcemy żeby długość paska postępu to było zawsze 30% długości ekranu, a wysokość niech się sama dopasuje?

pins example 1

A jeśli wysokość ma się sama dopasować, ale tylko zwiększając rysunek do dołu, żeby nam pasek postępu nie urósł poza ekran?

pins example 2

A jeśli dodatkowo wysokość ma być stale 4% wysokości ekranu?

pins example 3

Jeśli obiekt ma się zwiększać i rozszerzać zgodnie z rozszerzeniem ekranu, ale tak żeby nie wyszedł nam bardzo zdeformowany potworek? Czyli: zwiększaj wysokość i szerokość, ale nie mniej/więcej w każdą stronę niż ileśtam % ekranu?

pins example 4
Nie mniej % niż pokazują szpileczki.
pins example 5
Nie więcej % niż pokazują szpileczki.

No, to chyba tyle, intuicja już powinna być. Aby uzyskać bardziej naukowy opis, proponuję oficjalne szkolenie Unity (LINK).

Jako wisienka na torcie miał być skrypt. Skrypt miał nam mówić jakie konkretnie wymiary ma obiekt UI (w pikselach). Przyznaję – pokonało mnie to. Ciężko ustalić faktyczną wielość elementu UI w pikselach. Nie dzisiaj.

 

Hello World, progress bar.

Pierwszy post ocierający się o kwestie techniczne. Zacznę od napisania progress bar. Z paskiem postępu trochę jak z koniem. Każdy widzi jaki powinien być, więc po co się rozpisywać? Spróbuję jednak pokusić się o szczątkową dokumentację w tym miejscu.

Publiczne pola:

  1. tekst – n.p. Mana, Health, Time, może być pusty.
  2. kolor głównego paska
  3. pozycja na ekranie
  4. max value
  5. min value

Publiczne funkcje:

  1. SetValue(int value) – powoduje przejście paska do kolejnego stanu. No i właściwie tyle.

Proste, intuicyjnie jasne, i trochę nudne.

Ominę tworzenie prefabs, każdy pewnie wie albo się domyśli jak to zrobić. Zaczęłam nawet pisać, ale w połowie zorientowałam się że wyszło ponad 1000 słów czegoś co nie daje się czytać. Zamiast długiego wpisu oferuję więc animacje gotowych efektów:

progress1 progress2 progress3Jeśli chodzi o część możliwą do wyklikania w UI, najbardziej istotne wydały mi się dwa problemy.

  1. Jak skalować element?
    Dla ustalenia uwagi przypuśćmy, że chcemy aby pasek zajmował niezmiennie 10% szerokości i 3% wysokości ekranu, był umieszczony 5% od lewego boku i 3% od górnej krawędzi ekranu.
    Druga, bardziej prawdopodobna opcja: chcemy aby pasek był umieszczony 5% od lewego boku i 3% od górnej krawędzi, natomiast przy skalowaniu zachował oryginalny stosunek szerokości do wysokości.
  2. Wybuch gwiazdek odbywa się na scenie, obiekt Progress Bar jest dzieckiem obiektu Canvas. Jak zapewnić sobie, aby wybuch zawsze następował na końcu tego paska?

Jeśli chodzi o część związaną z kodem, to pomimo swojej prostoty zasługuje ona na osobny wpis. Jutro (dzisiaj) – dwa wpisy!

Wstęp do wstępu – jak ma wyglądać skończona gra?

Za siedmioma górami, za siedmioma lasami, żyło sobie waleczne Ucho. Ucho dysponowało wieloma zaklęciami i różnymi rodzajami broni. Głównym celem walecznego Ucha były pojedynki z innymi Uszami, w wyniku których zyskiwało ono Doświadczenie oraz nowe Przedmioty, umożliwiające tym efektywniejsze dobijanie przeciwników. Gdzieś w tym całym zamieszaniu jest być może jakaś księżniczka, chwała, i Wyższe Cele, ale bardziej prawdopodobna jest postać Smutnego Developera, który chciałby wycisnąć kasę z użytkowników telefonów z systemem Android i IOS.

Gra wyglądać ma tak jak widać obrazku powyżej. Gracz wciela się w Ucho, które wali w inne Uszy, najlepiej w trybie multiplayer. Ponieważ internet w komórkach słaby, będzie to prawdopodobnie walka turowa. Atak i obrona wykonywane będą poprzez zakreślenie na wyświetlaczu wybranego kształtu, szybkie klikanie w wyświetlacz, machanie telefonem i inne gesty – w zależności od ilości czasu jaki poświęcę na projekt.

Mechanika gry będzie raczej prosta, zabawa ma się sprowadzać do odblokowywania kolejnych zaklęć i zwiększania swojego miejsca w rankingu. Część zaklęć można sobie wyczekać, albo dostać wraz ze zwiększeniem poziomu, ale oczywiście nie wszystkie, bo gdzież byłby wtedy zysk?

Żadna gra mobilna nie może się obyć bez nachalnych, paskudnych, zniechęcających Gremlinów Mikropłatności. Ktoś to w ogóle kupuje? Ja uciekam jak tylko te potworki wyskoczą z lasu. W temacie dodawania mikropłatności do aplikacji jestem jeszcze kompletnie zielona, więc, poza doskonaleniem warsztatu Unity, będzie to świetne pole do nauki, i prawdziwa wartość dodana projektu.

O czym będzie projekt i w ogóle o co chodzi?

„Ania, weźmy udział w konkursie na bloga” – powiedział kolega z pracy. No, może nie do końca to powiedział, ale do tego się sprowadzało. Link do całej akcji powinien znajdować się gdzieś w menu albo na dole, ale na wszelki wypadek powtórzę: dajsiepoznac.pl

Skoro konkurs, to wypadałoby zrobić coś ciekawego. Całymi dniami ślęczę, Wy prawdopodobnie też, przy aplikacjach biznesowych mających na celu dokładniejsze raportowanie, spełnianie wymogów, promocję synergii i inne korpo słowa-klucze. Jest to strasznie nudne, więc w ramach odreagowania zrobię grę. Ma się błyszczeć, świecić, piszczeć, wibrować i nie służyć niczemu pożytecznemu.

Dlaczego silnik Unity? Dlatego że łatwo było zacząć. Instalujesz edytor, przeciągasz obrazki do okienek i działa. Magia.

Jakie jeszcze technologie/frameworki będą w użyciu? Nie wiem, bo się na tym jeszcze nie znam. Zobaczymy gdzie projekt mnie poniesie. Co do zasady wybierać będę to, w czym najszybciej uda mi się połapać. Wszystkie sugestie mile widziane.

Skąd pomysł na grę? Aurikuloterapia to dziedzina medycyny alternatywnej polegająca na wbijaniu igieł w uszy. Nie testowałam, jestem dość sceptyczna, ale znajomi mówią że działa. Jeśli ktoś chce spróbować, polecam tutaj (LINK). Od wbijania igieł w uszy dość blisko do ucha ze szpadą, nieprawdaż?

Dlaczego taka grafika? Jest darmowa! Rijksmuseum udostępnia całe tony swoich wydruków w domenie publicznej. Nic tylko brać (LINK).

Na koniec jeszcze uwaga: nie studiowałam informatyki tylko matematykę, jestem więc w dużym stopniu samoukiem. Jeśli Czytelniku zauważysz ze gdzieś siada obiektowość, nie są używane design patterns, albo z dowolnego innego powodu dostajesz wysypki, daj znać w komentarzu. Chętnie poprawię.