Niezależny rozwój między platformami

Kilka lat temu, jeśli napisałeś w C i jakimś podzbiorze C ++ i użyłeś wystarczającej liczby abstrakcji platformy (przez SDL lub cokolwiek innego), możesz uruchomić na każdej platformie, na której indie może się dostać - Linux, Windows, Mac OS różnych wersji , niejasne rzeczy, takie jak BeOS, oraz otwarte konsole, takie jak GP2X i Dreamcast po śmierci. Jeśli w pewnym momencie dostałeś kontrakt na zamkniętą platformę, możesz przenieść swoją grę na tę platformę z „minimalnymi” zmianami kodu.

Dzisiaj niezależni programiści muszą korzystać z XNA, aby dostać się na Xbox 360 (i nadchodzący telefon z Windows); nie wolno używać XNA do pracy nigdzie indziej niż Windows; do niedawna musiał korzystać z Java na Androida; Flash nie działa na telefonach, HTML5 nie działa na IE. W przeciwieństwie do np. DirectX vs. OpenGL lub Windows vs. Unix, są to zmiany w podstawowym języku, w którym piszesz swój kod, i nie można na niego nakładać bez pisania kompilatora. Możesz przenieść logikę gry do skryptów i dołączyć interpretera - z wyjątkiem sytuacji, gdy nie możesz, ponieważ iPhone SDK nie pozwala na to, a wydajność spada, ponieważ nikt nie pozwala na JIT.

Co więc możesz zrobić, jeśli chcesz naprawdę wieloplatformową przenośną grę, a nawet znaczną część silnika i kodu logicznego?

Czy to nie jest problem, ponieważ platformy zasadniczo się rozeszły - po prostu nie warto próbować atakować zarówno iPhone'a, jak i Xboxa 360 za pomocą dowolnego wspólnego kodu, ponieważ taka gra byłaby zła? (Uważam to za bardzo mało prawdopodobne. Z łatwością widzę, że chcę udostępnić grę między telefonem z systemem Windows Mobile a telefonem z Androidem lub Xbox 360 i iPadem.) Czy interfejsy są na tak wysokim poziomie, że czas przenoszenia jest znikomy? (Mogę w to uwierzyć w przypadku aplikacji biznesowych, ale nie w przypadku gier o ścisłych wymaganiach dotyczących wydajności).

Czy w przyszłości będzie to bardziej widoczne? Czy podział będzie, choć trochę przerażający, nadal spadać na linie dostawców? Czy wszyscy będziemy polegać na oprogramowaniu pośredniczącym wysokiego poziomu, takim jak Flash lub Unity, aby zrobić coś międzyplatformowego?

tl; dr - Czy przenoszenie problemu jest problemem, czy będzie większym problemem w przyszłości, a jeśli tak, to jak go rozwiązać?

Dzięki silnikowi Unity możesz się tam dostać bardzo daleko. Napisz raz, a będziesz mieć Mac / Windows Standalone i przeglądarkę internetową. Dostosuj swoje dane wejściowe i pamiętaj o swoich losowaniach i jesteś na iOS / Android.

Dla małego niezależnego programisty, który ma ograniczone fundusze / czas (a być może bardziej koncentruje się na „robieniu czegoś fajnego” niż „robieniu czegoś zyskownego”), próba przejścia na różne platformy od samego początku może przynieść efekt przeciwny do zamierzonego. Opracowanie solidnych narzędzi i technologii między platformami (różne interfejsy API grafiki, endianowość, urządzenia wejściowe i inne) wymaga dużo wysiłku - czasu, który można by poświęcić na bardziej kreatywną stronę tworzenia gier.

Ale prawdopodobnie chcesz się upewnić, że masz świetną grę, która działa naprawdę dobrze na jednej platformie, zanim zaczniesz się zbytnio martwić, że dostaniesz się na jak najwięcej platform! Jeśli gra jest flopem, nie ma sensu marnować czasu i wysiłku czyniąc ją wieloplatformowym flopem, prawda?

Jeśli piszesz w C / C ++, głównie od zera, to dopóki utrzymujesz kod dość modularnie i podejmujesz rozsądne decyzje dotyczące formatów danych i oprogramowania pośredniego / bibliotek, to późniejsze wsparcie innych platform nie powinno być zbyt bolesne.

Jeśli technologia / narzędzia innych platform (np. Unity) innej firmy są opcją dla twojego projektu, na pewno warto to rozważyć.

Głównymi „platformami problemowymi” dla indies wydaje się być Xbox360 Indie Games (tylko C #, ograniczony dostęp do sieci itp.) I prawdopodobnie Android (ogromne różnice w wydajności urządzenia / rozmiarze ekranu / urządzeniach wejściowych). Jeśli jesteś zdeterminowany, aby je wesprzeć, spodziewaj się znacznie większego zadania przenoszenia lub planuj skupić się wyłącznie na nich.

Mówisz, że rozwój niezależny od wielu platform . Największą przeszkodą są zatem zasoby, a to oznacza brak czasu przez większość czasu, ale także brak know-how i ewentualnie finansów (opłaty licencyjne, zakup urządzeń itp.).

Niezależnie czy nie, największą przeszkodą jest projekt. Jak mówisz, gra działająca na Xbox360 i iPadzie może działać, ale muszą również zasadniczo różnić się stylem. 360 ma kontroler, iPad ekran dotykowy. Ponadto programowanie dla 360 odbywa się w systemie Windows przy użyciu C # jako języka, iPad może być kierowany tylko na komputery Mac OS i przy użyciu C, C ++ lub Objective-C. Lub Javascript, jeśli wolisz. Niektóre rzeczy po prostu nie mieszają się tak dobrze, co robisz.

To, co mówisz o różnych platformach, sprawdza się dzisiaj. Użyj C / C ++ i SDL, a będziesz mógł pisać program między platformami na komputerach podobnych do komputerów PC, prawdopodobnie znacznie płynniej niż przed laty. Jednak zawsze był to problem i zawsze pozostanie problem z przenoszeniem gier z komputera na konsolę i urządzenia mobilne i odwrotnie. W ostatnich latach stało się to bardziej wyraźne, umożliwiając programistom Indie programowanie na konsole (lub programiści włamują się do niego, aby tworzyć gry typu homebrew) oraz wzrost liczby urządzeń mobilnych wystarczająco mocnych do uruchamiania gier.

Przenoszenie ma takie same problemy, jak kiedykolwiek, ale jest więcej urządzeń do przeniesienia. A niektóre porty po prostu nie mają sensu bez przeprojektowania rdzenia gry. Nie jest to problem, który można rozwiązać, należy go rozważyć od samego początku, nawet przed napisaniem pierwszego wiersza kodu. Wtedy będzie to wykonalne, nie więcej, nie mniej.

Myślę, że naprawdę potrzebna jest prosta, przenośna i otwarta platforma interfejsu. Niektóre rozważania:

Obecnie wydaje się, że istnieją cztery popularne metody wprowadzania danych do gry: klawiatury, myszy, kontrolery i powierzchnie wielodotykowe. (Na razie omówię problemy związane z różnymi możliwościami, na przykład gamepadów i joysticków, choć ostatecznie należy się tym zająć).

Idealnie byłoby, gdyby nasz programista mógł określić w ogólny sposób kilka różnych interfejsów użytkownika, które mają sens dla rodzaju tworzonej gry. (Mogą zdecydować się na podanie interfejsu użytkownika Klawiatura i Mysz, Interfejs Tylko Mysz i Interfejs Multi-Touch, jako arbitralny przykład).

Struktura jest następnie odpowiedzialna za pośredniczenie we / wy między platformą a kodem gry, podobnie jak funkcjonują międzyplatformowe struktury GUI, takie jak QT i GTK.

Posiadanie takiego frameworka nie rozwiązałoby problemu niekompatybilnych wymagań językowych, ale przynajmniej zamknęłoby wszystkie specyficzne dla systemu wywołania wspólnego API, co powinno uprościć przenoszenie języka.

Cóż, teraz, kiedy to wszystko napisałem: Czy ktoś wie, czy taki framework już istnieje?

W przypadku projektów takich jak MonoTouch i XNATouch wyglądało na to, że XNA może sprawić, że będziesz na większości platform z odrobiną ulepszeń. Niestety Apple trochę torpedowało, że kiedy zmienili swoje Warunki, aby ograniczyć języki, których możesz używać. Jedność przechodzi teraz prawie wszystko, chociaż na XBOX dostaniesz się na XBLA, ale nie na XBLIG, więc nie jest to opcja dla mniejszych indies.

Jednym z podejść może być stworzenie frameworka, który będzie korzystał z tych samych konwencji w wielu językach / platformach, wtedy wystarczy tylko dostosować składnię gier portowych. Możesz chcieć uruchomić swoją grę we Flashu, którą można szybko opracować i dotrzeć do dużej grupy odbiorców, a następnie, jeśli zakończy się sukcesem, przenieść na iPhone'a, XNA itp. W ten sposób wiesz, że masz fajną grę przed nadmiernym zaangażowaniem.

Myślę, że to problem ekonomiczny, a nie techniczny. Platformy takie jak xbox360 mają silną motywację do wykluczenia, ponieważ starają się, aby użytkownicy wybrali platformę zamiast innej platformy. „Mamy te fajne ekskluzywne gry” jest o wiele bardziej interesujące niż „możemy również grać w te gry, które mają wszyscy inni”. Ekosystem jest zdominowany przez producentów sprzętu.

Podejrzewam, że to się zmieni, gdy dojdzie do dojrzewania rozgrywki w sieciach społecznościowych, ponieważ potencjalnie jest o wiele więcej pieniędzy na zapewnienie wszystkim tego samego systemu gier społecznościowych niż na zrobienie jeszcze jednego FPS-a z seksowną grafiką.

Właśnie odkryłem Haxe i NME . Podobno jest to aplikacja wieloplatformowa, która obsługuje wszystkie główne komputery stacjonarne i urządzenia mobilne oraz Flash, z jednej bazy kodu. Warte zobaczenia.

Wieloplatformowe narzędzie programistyczne, które jest tak nowe, że niekoniecznie polecam to http://www.monkeycoder.co.nz/

Uderza w każdą platformę, o której wspomniałeś.

Chociaż jest zbyt nowy, aby naprawdę go oceniać, ma świetny rodowód: jego twórca wcześniej stworzył Blitz3D i BlitzMax, które były świetnymi narzędziami programistycznymi dla niezależnych twórców gier.

Miałem szczęście z pakietem Airplay SDK - przynajmniej na x86 i najwyraźniej dobrze celuje w iPhonie (chociaż wciąż muszę jeszcze zainstalować aplikację na iPhonie).