Jak silnik wybrać do gry mobilnej

Cześć,

Pisałem grę z myślą o iPhone i kilka tygodni temu dowiedziałem się, że silnik do gier 3D Apple'a jest soft deprecated - mowa tutaj o SceneKit.
Soft deprecated nie oznacza, że jest usunięty z iPhone'a, ale pewnie kiedyś będzie, nie wiadomo kiedy.
Oznacza to, że silnik nie będzie dostawać nowych funkcji i może być niewspierany przez nowe rozwiązania, a naprawiane będą tylko krytyczne błędy z nim związane.

Tak więc mam 2 możliwości (może więcej?)

1. Nie przepisywać gry z SceneKit i liczyć na to, że zostanie usunięty dawno po tym jak już wydam grę oraz przez kilka lat po jej wydaniu.
2. Przepisać na inny silnik graficzny.

Do opcji 2 Apple rekomenduje RealityKit, ale to nie pasuje do mojego przypadku użycia.
Poza tym nie chcę się już wiązać z frameworkami Applowskimi, bo nigdy nie wiadomo kiedy zostaną usunięte albo oznaczone deprecated.
Z drugiej strony to użycie SceneKit miało wiele zalet np. moja gra była bardzo mała.

Ogólnie kodu nie ma dużo, ale jednak trochę jest i przepisanie tego na cokolwiek innego powoduje, że łapię depresję, bo spędziłem nad tą grą dobre 2-3 lata w nadgodzinach.

Z opcji jakie widzę to:
Unity
Godot

Szukam czegoś stabilnego, co nie spowoduje, że będę musiał za 2 lata ponownie przepisywać grę.
Silnik musi wpsierać 3d, ale nie potrzebuję jakichś super zaawansowanych efektów, to jest prosta gra logiczna.
Sama gra nie jest za duża, więc liczę na to, że jak silnik będzie dobry i w miarę łatwy to przepisanie nie powinno mi zająć długo, a z drugiej strony mam trochę spaghetti kodu, więc napisanie w czymś innym może być pewnego rodzaju wybawieniem.

Plusem innych silników jest oczywiście wieloplatformowość, na której chyba zaczyna mi zależeć, po tym co wyprawia Apple.

Kompilowałem gry Unity na iOS. Unity tworzy projekt Xcode, z którego tworzymy build na iOS.
iOS jest zamkniętym systemem i obsługa tej platformy przez Unity może okazać się niewystarczająca.
W moim projekcie był problem z mechanizmem ładowania scen ( https://docs.unity3d.com/ScriptReference/SceneManagement.SceneManager.LoadScene.html ).
Nie zawsze ale dość często ładowanie sceny powodowało crash aplikacji.
Rozwiązaniem może być trzymanie wszystkiego w jednej scenie, która ładuje się przy starcie aplikacji.
Wtedy nie wykonujemy operacji, które powodują crash.
Levele gry można ładować z AssetBundle albo Resources.
Nie wiem, czy to naprawiono.

Jeśli nikt nie naciska, to i tak z mobilnych platform Android jest bardziej przyjazny dla programistów ;)
Może lepiej tworzyć grę Android-first ;)
No... może poza biurokracją dodawania nowej aplikacji do sklepu...

Opłaca się w ogóle pisać gry na iphone? Nie widziałem żeby ktoś grał w coś na iphonie (ale w zasadzie rzadko też widuję żeby ktoś grał na androidzie poza samolotem). Większość użytkowników iphone'ów to kobiety, a te nie są zbyt dużymi fankami gier. Mężczyźni i osoby techniczne raczej stawiają na androida.
Polecam Unity jako wieloplatformowy silnik, żeby nie musieć tracić czasu specjalnie na tę jedną platformę.

Godot zyskał na popularności gdy unity zmienił warunki licencyjne i chciał pieniądze od każdej instalacji ale poszli po rozum do głowy i już jest z powrotem akceptowalnie, myślę że obecnie nie ma sensu go używać, unity ma znacznie większą społeczność i wsparcie.

@obscurity: Niestety, czy tego chcemy, czy nie, iPhone ma sporo użytkowników. Nie ważne, czy ich widzisz, czy nie ;)
Chyba nie obracasz się w gronie nastolatków, którzy są przyspawani do swoich telefonów?

Skoro większość użytkowników iPhone to kobiety, to jeśli taka zostanie matką, to pewnie kupi dziecku iPhone z obawy, że z innym nieznanym sprzętem mogłaby sobie nie poradzić. Tym sposobem ilość użytkowników rośnie.

obscurity napisał(a):

Opłaca się w ogóle pisać gry na iphone?

Pewnie nie, to się okaże jak wreszcie wydam tą grę, mam nadzieję że kilka $ na niej zarobię, ale może się mylę i zarobię 0. Wydaje mi się, że warto zaryzykować.

Polecam Unity jako wieloplatformowy silnik, żeby nie musieć tracić czasu specjalnie na tę jedną platformę.

Chyba najbardziej ku temu się skłaniam, muszę rozpoznać temat, dzięki.

Godot zyskał na popularności gdy unity zmienił warunki licencyjne i chciał pieniądze od każdej instalacji ale poszli po rozum do głowy i już jest z powrotem akceptowalnie, myślę że obecnie nie ma sensu go używać, unity ma znacznie większą społeczność i wsparcie.

Dzięki za wyjaśnienie, tego nie wiedziałem :)

Spine napisał(a):

Kompilowałem gry Unity na iOS. Unity tworzy projekt Xcode, z którego tworzymy build na iOS.
iOS jest zamkniętym systemem i obsługa tej platformy przez Unity może okazać się niewystarczająca.
W moim projekcie był problem z mechanizmem ładowania scen ( https://docs.unity3d.com/ScriptReference/SceneManagement.SceneManager.LoadScene.html ).

Dzięki za te szczegóły, będę o tym pamiętać :)
Ja raczej będę mieć tylko 1 scenę, do której zamierzam dynamicznie dodawać jakieś obiekty.
Czy łatwo można zaimplementować drag and drop w Unity?

Jeśli nikt nie naciska, to i tak z mobilnych platform Android jest bardziej przyjazny dla programistów ;)
Może lepiej tworzyć grę Android-first ;)

Nie mam żadnego telefonu z Androidem, a chciałbym żeby chociaż w jakimś stopniu gra się zwróciła, nie chcę ładować do niej reklam.

No... może poza biurokracją dodawania nowej aplikacji do sklepu...

Ta biurokracja jest też w przypadku iOS.

Ogólnie zastanawiam się czy nie najlepiej było by napisać własny silnik, ale to pewnie jest strata czasu i overkill dla takiej gry, a i tak zawsze coś może pójść nie tak i mój silnik przestanie działać.
Z drugiej strony bardzo dużo mógłbym się nauczyć pisząc silnik, ale chcę też wydać grę w miarę szybko, bo jest już praktycznie na ukończeniu.
Może SceneKit nie zostanie tak szybko skasowany, tylko obawiam się sytuacji jak już ktoś zapłaci za jakieś zakupy w mojej grze a ona przestanie działać, a ja już wydam te pieniądze :D :D :D Dopóki to będzie mała kwota, mogę zwrócić :D

Myślę, że było dużym błędem zdecydowanie się na SceneKit, nie przewidziałem, że nie będzie rozwijany i automatycznie usuwam się z innych platform.

Chociaż z drugiej strony moja gra w SceneKit zajmuje 7MB a czysta gra z Unity bez niczego - podstawowy szablon 129MB :(

CyanApple napisał(a):

Czy łatwo można zaimplementować drag and drop w Unity?

Raczej nie powinno być problemu
Nawet miałem okazję zaimplementować taką mechanikę w jednym projekcie.

Jeśli nie potrzebujesz obsługi multi-touch'a, to powinno wystarczyć jak oprogramujesz zdarzenia dla myszki. Wtedy to obojętne czy ktoś używa myszki, czy ekranu dotykowego.

jak by mieli usunąć to pewnie w jednej wersji iOS by zrobili deprecated a dopiero pewnie 1-2 wersje później usunęli. Jak gra by chwyciła to miałbyś na to kasę i przestrzeń a jak nie to po prostu uśmiercasz i tyle. IMO przy pierwszym produkcie nie ma to żadnego znaczenia. Bo szansa że będziesz umiał to zmonetyzowac na coś więcej niż projekt hobbystyczny jest mała.

Dokładnie - przykładowo terraria powstała na frameworku XNA który przestał być wspierany w 2013 roku, a gra była bardzo popularna i potrzebowała aktualizacji i wsparcia na inne platformy. Twórcy terrarii ostatecznie w zasadzie "przejęli" ten przestarzały framework, najpierw tworząc własne rozszerzenia do niego które ewoluowały w osobny autorski silnik gry.
Nie ma się co przejmować że silnik jest deprecated, zwłaszcza w finalnej fazie projektu - po pierwsze gry zazwyczaj w większości przypadków tylko bugfixujesz, nie musisz tego robić w najnowszej technologii, po drugie ciągłe zmiany stacka to największy wróg programisty - zastanów się czy na pewno musisz go zmieniać czy to po prostu forma prokrastynacji bo skończyły się fajne, wymagające zadania.
Po trzecie - zmiana silnika nie powinna być aż tak bolesna, całą logikę gry, assety, tekstury, skrypty, modele, dźwięki, zachowania masz już obmyślane i gotowe - wystarczy przenieść to do nowego silnika i trochę zaadoptować. Nie powinno być z tym większego problemu, o ile nie pisałeś bardzo customowych zachowań pod konkretny silnik.
Jeśli spędziłeś nad grą 3 lata to proponuję ją skończyć a jeśli gra chwyci to sequel napisać w czymś nowszym (chociaż znająć życie to nie zrobiłeś dobrej single playerowej gry tylko jakieś candy crush z mikropłatnościami i nie planujesz robić sequela tylko co najwyżej dodać nową czapeczkę).

Z mojej perspektywy jako programisty, który na iOS tworzy appki od dekady to mam wrażenie, że akurat tą dziedzinę, czyli tworzenie gier na platformę iOS/macOS Apple strasznie zaniedbuje.
Ostatnimi czasy wprowadzili możliwość portowania gier z innych platform (Windows) https://developer.apple.com/games/game-porting-toolkit/ wiedząc, że one po prostu tam głównie powstają.
Nie oszukujmy się - dla takiego dużego developera jednak rynek zbytu jest większy poza macOS'em.
Jak ja bym dzisiaj chciał stworzyc gierke na iOSa to pewnie bym wybrał Unreal Engine https://dev.epicgames.com/documentation/en-us/unreal-engine/setting-up-an-unreal-engine-project-for-ios albo Unity (jeśli preferujesz C# zamiast C++).

To co pisał kolega wyżej ma sens, bo możesz też spokojnie grę rozwijać w tej technologii, którą już masz i później albo ją przepisać na coś bardziej "nowoczesnego" albo po prostu kolejną część już zrobić w innej technologii. Nic nie jest na zawsze i zmiana frameworka to nic złego :).

Schadoow napisał(a):

jak by mieli usunąć to pewnie w jednej wersji iOS by zrobili deprecated a dopiero pewnie 1-2 wersje później usunęli. Jak gra by chwyciła to miałbyś na to kasę i przestrzeń a jak nie to po prostu uśmiercasz i tyle. IMO przy pierwszym produkcie nie ma to żadnego znaczenia. Bo szansa że będziesz umiał to zmonetyzowac na coś więcej niż projekt hobbystyczny jest mała.

Właśnie dokładnie tak jest, tj. wraz z iOS26, kótry będzie mieć premierę we wrześniu SceneKit staje się deprecated, a kiedyś w przyszłości będzie całkiem usunięty, tylko nie wiadomo kiedy. Skłaniam się chyba do wypuszczenia gry dopracowanej w 90% tj. tylko tryb nieskończony gry z wzrastającym poziomem trudności bez leweli, żeby zobaczyć czy pomysł w ogóle ma sens i czy jakoś chwyci, znając życie pewnie nie, ale będę mieć pierwszą walidację.

Muszę dorobić kilka in-app purchases i lokalny ranking graczy i tyle.

obscurity napisał(a):

Nie ma się co przejmować że silnik jest deprecated, zwłaszcza w finalnej fazie projektu

Dzięki, chyba do tego najbardziej się przychylam.

• po pierwsze gry zazwyczaj w większości przypadków tylko bugfixujesz, nie musisz tego robić w najnowszej technologii, po drugie ciągłe zmiany stacka to największy wróg programisty - zastanów się czy na pewno musisz go zmieniać czy to po prostu forma prokrastynacji bo skończyły się fajne, wymagające zadania.

Właśnie nie chcę go zmieniać, ale czuję się niepewnie z tym, że za jakiś czas nie wiadomo kiedy gra może przestać działać i będę musiał zwracać ludziom pieniądze za zakupy zrobione w grze, jak to będzie kilkaset dolarów to nie ma problemu, gorzej jeżeli gra by chwyciła, ale masz rację, że może być to pewnego rodzaju prokrastynacja.

Po trzecie - zmiana silnika nie powinna być aż tak bolesna, całą logikę gry, assety, tekstury, skrypty, modele, dźwięki, zachowania masz już obmyślane i gotowe - wystarczy przenieść to do nowego silnika i trochę zaadoptować. Nie powinno być z tym większego problemu, o ile nie pisałeś bardzo customowych zachowań pod konkretny silnik.

Właśnie niestety pisałem trochę customowych rozwiązań pod ten silnik, robiłem mały research nowego silnika i dużo rzeczy musiałbym rozwiązać na nowo w inny sposób, z czego nie jestem zadowolony.

Jeśli spędziłeś nad grą 3 lata to proponuję ją skończyć a jeśli gra chwyci to sequel napisać w czymś nowszym (chociaż znająć życie to nie zrobiłeś dobrej single playerowej gry tylko jakieś candy crush z mikropłatnościami i nie planujesz robić sequela tylko co najwyżej dodać nową czapeczkę).

Właśnie to jest trochę coś w stylu candy crush saga, ale póki co nie mam jeszcze modelu mikropłatności.
Najłatwiej było by mi wypuścić grę za np 4,99Euro/USD, ale pewnie nikt mi jej w takiej cenie nie kupi - powód jest prosty nie muszę programować mikropłatności, co też zajmie mi chwilę, nie chcę też dawać reklam do gry, ale robiąc płatną grę ryzykuję, że nikt jej nie kupi.

Mam bardzo dużo pomysłów na dalszy rozwój sequel i w sumie chyba robie inny błąd, bo wszystko chciałbym zawrzeć w pierwszej wersji, stąd zajęło mi to tyle czasu.
Z drugiej strony nie jestem super doświadczony w gamedev, więc to kolejny czynnika.
Już raz tą grę przepisywałem z silnika 2d SpriteKit na 3d SceneKit, bo na początku myślałem, że silnik 2d mi wystarczy.

moonfade napisał(a):

To co pisał kolega wyżej ma sens, bo możesz też spokojnie grę rozwijać w tej technologii, którą już masz i później albo ją przepisać na coś bardziej "nowoczesnego" albo po prostu kolejną część już zrobić w innej technologii. Nic nie jest na zawsze i zmiana frameworka to nic złego :).

Oczywiście, że zmiana frameworka na coś innego to nic złego, tylko to mi zajmie znowu dużo czasu.