Kiedy powinieneś uruchomić własny silnik gry? [Zamknięte]


20

Od 5 lat jestem programistą i chcę zająć się tworzeniem gier na iOS. Bawię się z iOS SDK przez około 2 lata, uczestnicząc w spotkaniach cocoaheads i czuję, że dobrze rozumiem cel-c, kakao, a nawet c-c ++.

Mam pomysł na grę i wiem, że użyję Box2D, ale zastanawiam się, czy powinienem użyć cocos2D, czy nie. Główne powody to:

  1. Mogę chcieć robić rzeczy, jeśli chodzi o grafikę, które nie są dostępne w cocos2d.
  2. Jeśli uruchomię własny silnik gry, będę mieć większą kontrolę.

Oczywiście głównym powodem korzystania z już istniejącego silnika gry jest czas, który oszczędza i ułatwia to, co trudne; ale czy ma to sens dla kogoś, kto ma techniczne kotlety do rzucania swoimi własnymi?


7
Jeśli powiesz „C / C ++”, jest całkiem prawdopodobne, że nie znasz dobrze przynajmniej jednego z nich i prawdopodobnie obu.
DeadMG

10
Rozumiem, że niektórzy mylą te dwa elementy i prawdopodobnie powinienem powiedzieć C / C ++ / Objective-C, aby powtórzyć, że rozumiem główne języki, których można używać do programowania na platformie iOS. Nie miałem ochoty powiedzieć, że C / C ++ automatycznie oznaczałoby, że pomylę te dwa jako jeden.
Joey Green

Podoba mi się to pytanie, ponieważ stanowi mile widzianą zmianę w stosunku do zwykłego „jak zrobić własny silnik?” pytania. +1 dla pana, proszę pana.
Ray Dey

1
@DeadMG Coś mówię „C / C ++” i doskonale je rozumiem.
Ciaran

Powiedziałbym, że to nawet , że to zrobił
bobobobo

Odpowiedzi:


38

Większość innych postów będzie brzmiała: „stwórz grę, a nie silnik”, ale zakładam, że masz na myśli konkretną grę, którą chcesz stworzyć i chcesz wiedzieć, kiedy warto zacząć od kodu innej osoby oprzeć lub zacząć od zera.

Nie powinieneś rzucać własną technologią, chyba że wiesz, że musisz rzucić własną . Może to zabrzmi źle, ale to naprawdę jedyna poprawna odpowiedź. Podobnie jak w przypadku większości decyzji, istnieją kompromisy. Tylko Ty możesz określić dla swojej konkretnej sytuacji analizę kosztów / korzyści.

Powinieneś rozumieć następujące rzeczy (ta lista nie obejmuje wszystkich).

  • Jakie oprogramowanie pośrednie jest już dostępne („silnik” lub w inny sposób)
  • Co to oprogramowanie pośrednie przynosi na stół, pod względem funkcji.
  • Jak dojrzałe / sprawdzone jest oprogramowanie pośrednie, szczególnie jeśli zależy Ci na obsłudze wieloplatformowej
  • Jakie narzędzia zapewnia lub nie zapewnia oprogramowanie pośrednie, aby przyspieszyć programowanie (nie dyskontuj narzędzi własnymi technologiami)
  • Jakie ograniczenia ma oprogramowanie pośrednie (jako prosty przykład Unity 3.x nie robiło cieni w czasie rzeczywistym z dynamicznych świateł na iOS)
  • Jakie konkretne funkcje musi mieć Twoja gra .
  • Jakie są twoje terminy i ile czasu będziesz musiał poświęcić, aby dostać się do punktu, w którym dostaniesz oprogramowanie pośrednie, a ile kosztuje to oprogramowanie pośrednie.
  • Jak rozszerzalne jest oprogramowanie pośrednie (na przykład możesz obejść problem z cieniem w iOS w Unity, używając cieni kropelkowych. A może cieni projekcyjnych).

(Zauważ, że specjalnie nie umieściłem tam „większej kontroli”. To załadowane wyrażenie może mieć zakres od „Nie lubię kodu, którego nie piszę” do „Muszę być w stanie widzieć, rozumieć i popraw wszystkie zmienne w silniku fizyki, aby osiągnąć ten konkretny efekt. „Pierwszy nie jest tak naprawdę uzasadniony, ale drugi jest.)

Osobiście uważam, że wdrożenie własnej technologii w grze o niskim budżecie nie jest nigdy warte wysiłku. Ilość mocy, jaką zyskujesz obecnie w tanich silnikach, jest absurdalna. Nie jesteś w momencie, w którym decydujesz się na wielomiliardową potrójną licencję silnika A, czy nie. Nie będziesz w stanie pokonać tego, co, powiedzmy, oferuje Unity za 3 000 $. Lub Cocos2d za cokolwiek kosztuje (czy to nie za darmo?).

Teraz, jeśli twoja gra koncentruje się głównie na technologiach, których inne silniki nie są w stanie zapewnić lub zapewniają rozsądną szybkość klatek, być może warto zbadać, co możesz zrobić. Nie oznacza to jednak, że całkowicie wyrzucasz inne oprogramowanie pośrednie. To, że potrzebujesz własnego, powiedzmy, renderera, nie oznacza, że ​​nie możesz użyć innego oprogramowania pośredniego do fizyki, dźwięku, interfejsu użytkownika ani tego, co masz.


7
Zgoda. Jak tldr: Jeśli musisz zadać pytanie, prawdopodobnie lepiej będzie skorzystać z istniejącego silnika.
Chris Subagio

Twoja pogrubiona notatka podsumowuje moje doświadczenie.
Inżynier,

1
Społeczność jest również ważna. Coś z silną społecznością, takie jak XNA, rozwiązuje określone problemy znacznie ułatwia , ponieważ ktoś już to zrobił lub może udzielić wskazówek.
ashes999

14

Nie rzucaj własnym silnikiem. Rzuć własną grę. Jeśli zdarzy ci się pisać silnik w tym samym czasie, to jest to dla ciebie dobre, jeśli nie, zawsze możesz refaktoryzować wszystkie części, które chciałbyś użyć ponownie, aby uczynić go bardziej „silnikiem”.

Ludzie często nie doceniają tego, co trzeba napisać w „silnikowej” części gry. Jeśli zrobisz tylko to, czego potrzebujesz, nie potrwa to długo. Trudność polega na tym, aby nie utknąć w infrastrukturze pisania i pisać tylko to, co jest absolutnie konieczne, aby rozwiązać problem.

Korzystałbym z istniejącego silnika, gdy:

  • Mam napięty termin
  • Mam znany stały zestaw funkcji, dzięki czemu mogę wybrać do tego silnik

3

Myślę, że powinieneś po prostu napisać swoją grę, a może później skończysz z silnikiem . Pisanie silnika graficznego (to wszystko, o czym mówisz) od zera przy użyciu niczego, ale OpenGL prawdopodobnie tylko zmarnuje twój czas. Jest to stosunkowo dobrze rozwiązany problem, więc na ogół zmieniasz tylko kształt interfejsu API, nie dodając wiele istotnych nowych funkcji w stosunku do innych dostępnych rozwiązań innych firm.

Jeśli Cocos2D lub inna warstwa graficzna spełnia Twoje wymagania, użyj go. Jeśli Twoje wymagania zmienią się podczas tworzenia, możesz stosunkowo łatwo zamienić zaplecze renderowania - jeśli naprawdę wierzysz, że masz doświadczenie i środki do samodzielnego stworzenia silnika, z pewnością powinieneś mieć to, czego potrzeba, aby ustrukturyzować grę tak, aby zamienić się renderowanie zaplecza jest stosunkowo trywialną operacją.

Zbuduj swoją grę, pozwól jej na określone potrzeby, aby sterować zestawem funkcji pisanego kodu, i pisz kod z myślą o możliwości ponownego użycia i dobrej architekturze. Naturalnie skończysz z „silnikiem” po ukończeniu kilku takich projektów i ukończysz je szybciej, ponieważ nie pozwalasz się zaplątać w pełzanie funkcji na poziomie frameworka.


Jeśli jego celem jest nauka, nie jest to strata czasu.
Ciaran

3

To jest bardzo proste. Jaki jest twój główny cel: nauka czy czas na marketing?

Unikaj korzystania z biblioteki, jeśli twoim głównym celem jest wyciąganie wniosków z wdrażania koncepcji rozwiązanych przez bibliotekę. Ilekroć rozwijam grę (w niepełnym wymiarze godzin), moim celem jest wyłącznie nauka. Nie obchodzi mnie, ile to zajmie, dlatego robię to wszystko od zera! Teraz ty decydujesz.


0

Powinieneś uruchomić własny silnik gry, gdy wiesz, że jest to potrzebne .

Powiedzmy na przykład, że nie masz pieniędzy na Unity. Lub wolisz wydać go na nowy sprzęt. Lub występują problemy z wydajnością dostępnych bezpłatnych silników lub musisz mieć większą kontrolę na niskim poziomie.

Jeśli lubisz pisać oprogramowanie ze względu na pisanie oprogramowania, to spodoba ci się pisanie silnika gry. Częstym pułapką początkujących programistów jest przyłapanie się na pisaniu silnika jako pewnego rodzaju wieczystego projektu. Szczerze wierzę, że tak powstały te wszystkie silniki gier typu open source - programiści, którzy tak naprawdę nie zrobili

Następnie w takim przypadku napisz własny silnik.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.