Pierwsze kroki w tworzeniu gier: czy XNA to dobry wybór? [Zamknięte]

Długoletni czytelnik; pierwszy pytający:

Od jakiegoś czasu chciałem być częścią branży gier, ale moje CV to w 100% cała praca backendowa.

Jestem silnym programistą C ++ / C #, bez praktycznego doświadczenia w tworzeniu gier. Moje doświadczenie z backendem czyni mnie dobrym kandydatem do pracy z backendem (ponieważ wiele gier ma obecnie aspekty oparte na usługach), ale jest to dziedzina bardzo konkurencyjna i szukam sposobów na wyróżnienie się.

Ponieważ nikt nie podchodzi do mnie i nie daje mi pracy w branży gier, postanowiłem spróbować swoich sił w pisaniu własnych gier.

Rozumiem, dlaczego C i C ++ są językami defacto w tworzeniu gier, ale naprawdę podoba mi się filozofia stojąca za XNA. Jak powiedziałem wcześniej, jestem biegły zarówno w C #, jak i C ++, ale jeśli dobrze pamiętam, XNA działa tylko w językach zgodnych z CLR (być może tylko w C #).

Czy skupienie się na tworzeniu gier przy użyciu XNA i C # zamiast C ++ ograniczy moje szanse na znalezienie pracy w branży gier? VB ma nieuczciwą reputację, ponieważ nie jest prawdziwym językiem programowania, a programiści VB zostali złapani w to piętno. Czy tak jest w przypadku używania C # w społeczności, która składa się głównie z programistów C ++?

Czy też podstawy tworzenia gier, których można nauczyć się od pisania gier, przekraczania języka i technologii?

Nie sądzę, by to zaszkodziło twoim szansom. C # staje się coraz bardziej popularny, szczególnie w XNA i SlimDX. Użyłem zarówno C #, jak i C ++ i muszę powiedzieć, że zdecydowanie wolałem XNA. Praca była po prostu czystsza, ale nie tak bardzo, że wydawało się, że nic nie robisz.

Jeśli chodzi o karierę, chciałbyś wspomnieć, że jesteś przyzwyczajony do XNA, choć nie sądzę, by to zaszkodziło twoim szansom. W rzeczywistości, ze względu na sposób, w jaki jest łatwiejszy w użyciu, twoje elementy portfela mogą być lepsze.

Pojęcia pozostają takie same, tylko składnia staje się inna. O ile nie wybierasz zadania graficznego niskiego poziomu, układ tego, co musisz zrobić, byłby zbliżony do tego samego (nie pisząc kodu ładującego shadera ani pamięci podręcznej siatki, zamiast tego ładując go).

Z mojego doświadczenia wynika, że ​​te same pojęcia stosowane w XNA przenoszą się tam iz powrotem między różnymi bibliotekami i językami. Byłem w stanie skutecznie przeskakiwać między różnymi technologiami gier i zacząłem od XNA.

Praca z C # i XNA pomogła mi skupić się na jednym konkretnym celu uczenia się („Co sprawia, że ​​gra tyka?”) W przeciwieństwie do mieszania celów („Jak nauczyć się X i jednocześnie tworzyć grę?”). Zauważyłem, że za każdym razem, gdy łączyłem cele, kończyłem z dość fatalnymi wynikami. Zaczynanie w strefie komfortu i opieranie się na XNA pomogło mi jednak zacząć działać.

Jeśli potrafisz stworzyć fajną grę, a tak naprawdę jesteś utalentowanym inżynierem, nie masz się czym martwić. Nikt cię nie oszukuje za twoją grę.

Gry nie są utrzymywane tak, jak wiele innych programów. Tworzy się mniej kodu do wyrzucania niż w branży efektów specjalnych, ale nadal możemy uciec z dużą ilością hacków dla wygody.

Po prostu załatw robotę. Na koniec tego właśnie dotyczy tworzenie gier.

Powiedziano mi, że:

1. Treść jest znacznie ważniejsza niż narzędzia używane z pewnymi wyjątkami.

2. Chociaż podstawą większości większych gier jest C ++, to dlatego, że narzędzia są opracowane w C ++. Jeśli nie kodujesz narzędzi, możliwe, że i tak nie będziesz programować w C ++.

Edycja: Również posiadanie ukończonego projektu demo w jakimkolwiek języku (C # itp.) Jest znacznie lepsze niż posiadanie czegoś niekompletnego w trudniejszym języku (C ++ itp.).