Autor Wątek: Instantiate/Destroy vs Enable/Disable na mobile  (Przeczytany 969 razy)

Offline lao

  • Użytkownik

# Styczeń 20, 2017, 16:41:40
Wydajność na platformy mobilne- lepiej jest tworzyć i kasować obiekty czy trzymać je w pamięci i aktywować /dezaktywować rendering? Znalazłem takie coś w temacie:
 
Cytuj
Instantiate/Destory:
pro - easy to implement, keeps memory usage to only that what is needed (great for low memory systems)
cons - expensive to perform, dogs down garbage collection

Enable/Disable:
pro - fast on the processor, does not incur expensive garbage collector calls
cons - complicated to implement, can fill up memory if objects are complex (bad for low memory systems), can result in bugs if the state from previous time enabled isn't reset properly
Z tego co rozumiem do wyboru jest albo trzymać wszystko w RAM albo uzywać częściej procesora?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

  • +1
# Styczeń 21, 2017, 00:10:29
pytanie powinno brzmieć czy warto się bawić w optymalizację nieskończonej gry :P

Offline lao

  • Użytkownik

  • +1
# Styczeń 21, 2017, 03:14:55
Gra za ok 2 tyg laduje na Google Play :). Mechanike, część modeli, GUI i pierwszy level mam już zrobione, z trudnych rzeczy jeszcze tylko system platności mi został. Probowalem obu sposobów i przy tworzeniu/niszczeniu pojedynczych obiektow nie widze spadku wydajności, głównie chodzi o fanty które gracz zbiera i znikają, część obiektów tworzę w Start() przez Instantiate i zeby ukryć spadek fps zrobilem fade z czarnego tła, zanim się rozjaśni to wszystko jest na scenie :)

Offline JasonVoorhees

  • Użytkownik
    • The Immortal Life of the Son of Jay

# Styczeń 22, 2017, 11:57:19
Gra za ok 2 tyg laduje na Google Play :). Mechanike, część modeli, GUI i pierwszy level mam już zrobione, z trudnych rzeczy jeszcze tylko system platności mi został. Probowalem obu sposobów i przy tworzeniu/niszczeniu pojedynczych obiektow nie widze spadku wydajności, głównie chodzi o fanty które gracz zbiera i znikają, część obiektów tworzę w Start() przez Instantiate i zeby ukryć spadek fps zrobilem fade z czarnego tła, zanim się rozjaśni to wszystko jest na scenie :)
Wciąż nie brzmi to jak kompletna gra, w której ktokolwiek skorzysta z systemu płatności :P Lepiej poczekaj z wejściem na Google Play zanim będziesz miał solidny, rozbudowany produkt. Wcześniej też daj to znajomym do pogrania, żeby się przekonać czy możesz konkurować z innymi grami free to play - kiedy użytkownik może wydać swoje pieniądze na grę, to czemu akurat na Twoją?
« Ostatnia zmiana: Styczeń 22, 2017, 12:00:11 wysłana przez JasonVoorhees »

Offline deadeye

  • Użytkownik

# Styczeń 22, 2017, 12:45:40
Jeśli robienie Instantiate/Destroy ci nie spowalnia gry, to stosuj to. Nie optymalizuj czegoś czego nie ma sensu optymalizować.

Offline matheavyk

  • Użytkownik

# Styczeń 23, 2017, 21:08:54
Zgadzam się z deadeye, jak nie ma spadków wydajności to zostaw.
Za to nie do końca się zgadzam z JasonVoorhees. Tzn. faktycznie z wypowiedzi można wnioskować, że gra nie jest skończona i że nie jest to jakościowo super produkt, ale ładuj na google play! ;). Powiem więcej - jeśli system płatności ma ci sprawić problem (bo mówisz, że to jedna z "trudnych rzeczy"), to wrzucaj na google play bez systemu płatności, a dorób sobie ten system później i wtedy wrzucisz nowe apk. To trochę zależy od tego, czy "ewentualna" mała liczba ściągnięć twojej gry jakoś na ciebie wpłynie, bo jeśli się okaże, że mało osób ją ściągnie, to system mikropłatności nie będzie potrzebny, bo i tak nie przyniesie pieniędzy. No, ale to zależy jakie masz cele i w ogóle, co tam sobie myślisz :).

A co do tematu, poczytaj o temacie "object pooling". Szczególnie możesz poszukać wątków na ten temat na forum unity3D, bo zdarzyło mi się już kilka razy trafić na ludzi, którzy wrzucali tam testy porównujące wydajność różnych rozwiązań np. Instantiate vs SetActive vs "Wszystko ręcznie wyłączać, ale bez SetActive".

Offline lao

  • Użytkownik

# Styczeń 24, 2017, 01:59:35
Pod względem graficznym gra jest ok, w końcu jestem grafikiem ;), grywalność przygodówkowa, tzn zbieramy itemy po planszy zeby coś tam odblokować/zrealizować misję, nic trudnego wszystko robione triggerami. Najwięcej czasu zajmuje robienie modeli bo nawet do krótkiej gry trzeba tego tonę, kilka ściągnąłem z asset store (głównie skały) ale jednak większość trzeba robić samemu. Natomiast jesli chodzi o programowanie to nigdy nie wychodziłem poza silnik, tzn. nie pobieralem danych z zewnatrz z jakiejś bazy z serwera, a zeby zrobić płatność to jakoś to musi być zrealizowane, jeszcze nie wiem jak dlatego określiłem to jako trudne, spodziewam się że jest to w unity jakoś przystępnie zrobione (widziałem nawet na asset store taki moduł za 35$ bodajże), ogarnę dokumentację to zrobię :).

Offline matheavyk

  • Użytkownik

# Styczeń 24, 2017, 04:18:52
Biorąc pod uwagę te informacje, tym bardziej skłaniam się ku temu, żebyś zostawił Instantiate tak jak jest, skoro gra jest w miarę statyczna. A skoro jesteś grafikiem i robisz coś przygodówkowego, to może jednak ten produkt będzie w miarę skończony i IAPy się przydadzą ;)

Jeśli nie masz zamiaru obsługiwać płatności w jakichś egzotycznych sklepach, to wykorzystaj rozwiązanie do IAPów dostarczane razem z Unity. Tutaj manual: https://docs.unity3d.com/Manual/UnityIAP.html
Robiłem to i działa bez żadnych problemów na google play, appstore i windows store. Poza tym jest bardzo proste w implementacji. Osobiście jestem gorącym zwolennikiem korzystania z asset store'a, ale akurat w kwestii IAPów nie wiem, po co miałbym to robić.

Tutaj chyba najlepiej wyjaśnione jak to zrobić: https://unity3d.com/learn/tutorials/topics/analytics/integrating-unity-iap-your-game (przede wszystkim na dole strony jest skrypt z całym potrzebnym kodem, który musisz lekko na własne potrzeby przerobić).