Rozpocząłem programowanie w języku C #, aby później opracować gry za pomocą XNA. Przeczytałem dobrą książkę do tworzenia gier dla C #. Ponieważ znałem już inne języki, mogłem szybko nauczyć się funkcji C # i kodu składniowego. Potem przeszedłem do XNA. Ponieważ książka, którą czytałem, była nieco stara, odłożyłem ją na bok i zacząłem przeglądać samouczki dotyczące tworzenia gier na temat XNA przez Internet. Mogłem osiągnąć i zrozumieć większość z nich za pomocą grafiki 2D. Tworzyłem animowane duszki, kazałem moim postaciom poruszać się w dowolnym kierunku, przewijałem tło wraz z ruchem moich postaci i tak dalej. Wszystko zostało zrobione przy użyciu „surowego” XNA.
Niektóre z tych rzeczy były dla mnie trudne do zrozumienia i odkryłem, że niektóre rzeczy już są wbudowane w ramy. Znalazłem inne silniki gier, które mogłem wyraźnie zrozumieć przynajmniej proste kody linii, takie jak „ FlatRedBall ” , „ Axiom ” i „ Quick Start Engine ” . Znałem już te znane, takie jak „OGRE” , „Unreal” i „Unity” . Jednocześnie kusiło mnie, żeby to wszystko wyrzucić i zacząć uczyć się słynnego programowania silnika gry. Chciałem zostać z XNA, ponieważ nauka zajęła mi trochę czasu; czas nie chciałbym tego marnować.
Tym razem pozostawiam to doświadczonym. Czy mogę przejść przez silnik gry i skorzystać z jego oferty, nawet jeśli zaczynam od tworzenia gier? Niektórzy mogą myśleć, że dobrze jest przyzwyczaić się do nudnych procedur nagiej ramy. Jeśli tak, to jaki byłby zalecany na początek? Słyszałem, że różni się w zależności od rynku. Być może moglibyśmy rozważyć, że chcę gry RPG.
Odpowiedzi:
To zależy od tego, czego chcesz się nauczyć. Jeśli chcesz „po prostu stworzyć grę”, możesz być dobry z silnikiem. Ja osobiście tego nie polecam.
Jeśli chcesz naprawdę zrozumieć, jak działa grafika komputerowa, musisz zagłębić się i nauczyć wszystkich rzeczy. Od odświeżenia algebry liniowej (przynajmniej macierzy, wektorów i przestrzeni liniowych) po zrozumienie działania potoków graficznych. XNA to najlepszy framework na początek. Była w nim moja pierwsza gra (mam na myśli prawdziwą grę, pierwszą aplikacją 3D były czołgi bojowe w openGL). Jeśli chcesz rozpocząć programowanie 3D, nie masz tak ambitnych planów, nie możesz teraz robić RPG. Powinieneś spróbować stworzyć grę, w której lecisz w przestrzeni pełnej kostek i próbujesz strzelać do czerwonych, aby nauczyć się podstaw. Prawdopodobnie zajmie ci to więcej czasu niż myślisz :). Ale wiele cię nauczy.
I idź na całość! Programowanie grafiki 3D to najlepsza rzecz, jaką możesz zrobić dla życia. To trudne, zabawne i kreatywne w jednym pakiecie.
źródło
Nie ma nic złego w używaniu istniejącego silnika, wszystko sprowadza się do twoich celów.
Jeśli najbardziej interesuje Cię tworzenie niektórych gier lub projektowanie gier, im szybciej przejdziesz do kodu gry, tym lepiej. Coś takiego jak Unity jest tutaj świetne, ponieważ możesz wykorzystać swoją wiedzę w języku C # i zacząć dołączać skrypty do obiektów i natychmiast uruchomić coś.
Jeśli chcesz zostać programistą gier, musisz zrozumieć rzeczy na niższym poziomie. Framework taki jak XNA jest dobrym miejscem startowym. Możesz polegać na frameworku, aby zacząć działać, a następnie zacznij zastępować jego części własnym kodem, gdy nauczysz się, jak budować każdy składnik gry.
źródło
PORADY AMATORA
// Od zera do amatora przez lata nauki
Zdecydowanie trzymałbym się z dala od silników wysokiego poziomu, takich jak Unity lub Torque2D MIT. Są świetne dla małych prototypów, ale nigdy nie wziąłbym ich na poważnie, aby opracować własną grę wideo. Dlaczego miałabym? Jaki jest sens, chyba że był to zwykły remake SideScroller lub Arcade?
Większość silników gier, bibliotek lub frameworków wykonuje tylko najprostsze zadania z dużą ilością rozdętego kodu z funkcjami i funkcjami, których nigdy nie użyjesz.
Kiedy wiele lat temu byłem nowy w tworzeniu gier, zacząłem na szczycie. Silniki na bardzo wysokim poziomie. Nie ma czegoś takiego jak RPG MAKER, ale zdecydowanie wysoko tam, jak Unity i Torque. Potem poszedłem niżej, do XNA i C #, ponieważ miał tak wiele zasobów i samouczków. Mój główny projekt wymagał wydajności, a może po prostu mam obsesyjno-kompulsywne pragnienie niewiarygodnej wydajności w moim oprogramowaniu, nawet jeśli nie jest to duży projekt. XNA po prostu tego nie wyciął i miałem wiele problemów z silnikiem, który przeczytałem, wymagało bólu głowy do naprawienia. Jaki jest sens używania czegoś „wyższego poziomu”, takiego jak XNA / C #, gdy wykonuje się tę samą pracę (naprawianie błędów i problemów XNA), jak przy tworzeniu własnego silnika w C ++?
Po dość długim okresie nauki w końcu dowiedziałem się o projektowaniu silników gier i zacząłem analizować kod samych silników. Czytając to, co ma do powiedzenia większość profesjonalistów, a także skargi krytyków silników gier uświadomiłem sobie: „Po co w ogóle korzystać z silnika?”.
Oczyszczanie mojego C ++ i naprawdę wchodzenie w niektóre filozofie używane w tym języku bardzo mi pomogło. Jednak tyle czasu poświęciłem na naukę tak wielu rzeczy, że chciałem po prostu zacząć grę.
Skończyło się na tym, że mam dość pochwał, był C ++ i bardzo niski poziom: SDL. Niestety był to ból głowy. Jest tak niski poziom, nie widzę żadnego powodu, aby nawet korzystać z tej biblioteki. Wolę po prostu nauczyć się OpenGL i zrobić to od zera. Szczerze mówiąc, to głównie fakt, że potrzebowałem zaimplementować własny kod, aby zrobić coś tak podstawowego jak odwrócenie obrazu (a implementacja innych nie działała z powodu tego, jak obchodziłem się ze sprite'ami), skłoniła mnie do trwałego wyrzucenia SDL. To świetnie, jeśli chcesz renderera oprogramowania, ale IMO wolę wyrzucić go, aby obniżyć go ze sprzętem (OpenGL) lub wyższym (SFML).
Nie chcąc kupować kolejnej książki na Amazon i uczyć się kolejnego API, poszedłem wyżej. SFML jest po prostu wspaniały, nie wspominając o bardzo chwalonej w Internecie. Przeczytałem prawie nieskończoną liczbę pozytywnych recenzji, bez żadnych negatywnych opinii. Nie mogę powiedzieć tego samego o SDL. Obsługuje wszystkie ekstremalne podstawy, ale resztę pozostawia mi i innym wybranym bibliotekom. Utknąłem z tym do tej pory.
IMO, silnik gry jest po prostu głupi. Biblioteki niskiego poziomu są znacznie lepszym wyborem zarówno dla ekspertów, jak i początkujących programistów.
Warto również zauważyć, że nauczyłem się więcej o koncepcjach programistycznych i wyostrzyłem swoje umiejętności tworzenia oprogramowania, gdy zmuszony byłem radzić sobie z rzeczami na niższym poziomie, niż kiedykolwiek nauczyłem się z silnikami WYSIWYG na wysokim poziomie.
Co daje ci coś takiego jak Unity w porównaniu z XNA? Edycja wizualna i kula. Początkujący w końcu dowiedzą się, że nadal będziesz musiał kodować prawie całą grę, tak jak gdybyś miał już C ++, a edytory wizualne są nieefektywne w stosunku do czegoś, co sam możesz stworzyć.
Co daje coś takiego jak XNA w przypadku SFML lub własnej implementacji OpenGL i innych przydatnych bibliotek? IMO, absolutnie nic dobrego. Gorsza wydajność, C # zamiast C ++, mnóstwo samouczków dla początkujących, ale znacznie mniej profesjonalizmu, a niektórzy oszczędzający ból głowy, że IMO są po prostu kulą do tego, czego powinieneś nauczyć się z C ++. Początkowo byłem zastraszany przez C ++ i uwielbiałem C #, głównie ze względu na słyszenie i pogłoski o opiniach głupców, którzy mieli takie same kłopoty, jak na początku w C ++: Chciałem po prostu wystarczająco dobrego programisty. Zdałem sobie sprawę, że muszę nauczyć się więcej podstaw i wyostrzyć swoje słabości, aby przezwyciężyć problemy z C ++, które C # „ułatwił”. Czy kiedykolwiek tęsknię za prostotą niektórych rzeczy w C #? Nawet nie! Wiem, jak to zrobić w C ++ bez żadnych problemów.
Jeśli zastraszają Cię biblioteki niskiego poziomu lub nauka DirectX / OpenGL, poczekaj, aż zaczniesz się komplikować, tworząc pełną grę wideo.
Moją filozofię dotyczącą silników gier można streścić w dwóch przykładach wyjaśniających nadmiarowość i bezużyteczność silników, z wyjątkiem pojedynczych okoliczności.
Początkujący zastraszani bibliotekami niskiego poziomu będą mieli atak, gdy odkryją, że nawet przy silniku wysokiego poziomu, takim jak Unity (oprócz renderowania grafiki, odtwarzania audio, ładowania treści; naprawdę podstawowych rzeczy) będzie to prawie identyczne z tworzeniem gry od zera. Złożoność polega na zaprojektowaniu gry, niezrozumieniu interfejsu API lub opracowaniu klas do renderowania na wyświetlaczu.
Eksperci, którzy nie są zastraszani złożonością tworzenia pełnej gry w coś takiego jak Unity, nie mają pożytku dla Unity, ponieważ czas, w którym pewnie zajęło by nauczenie się API i wymagań konkretnego silnika, prawdopodobnie bardziej boli mnie głowa i więcej czasu zajęłoby kodowanie kilku klas wymaganych do podstaw.
Silniki są więc bezużyteczne dla początkujących, ponieważ początkujący nie mogą nic z nimi zrobić, ponieważ brakuje im umiejętności inżynieryjnych. Podobnie, silniki są bezużyteczne dla weteranów, ponieważ mają już umiejętności inżynieryjne, aby zrobić to bez silnika, i równie dobrze mogą rzucić własnym bardziej wydajnym, specyficznym „silnikiem”, niż męczyć się z nauką interfejsu API silnika gry, funkcje i dziwactwa wydajności. Nie wspominając już o ogromnym koszmarze pracy z silnikami, których czasami nie można dotknąć, ponieważ nie są one oprogramowaniem typu open source (a nawet jeśli tak, czytanie kodu innej osoby może być czasem koszmarem).
Do diabła, nawet niektóre „niskie poziomy” „frameworki” są niczym więcej niż kilkoma klasami do tworzenia okna, renderowania na wyświetlacz i odtwarzania dźwięku. Jest to coś, co profesjonalista mógłby zrobić od zera przy użyciu innych bibliotek, takich jak SDL / SFML lub własnej implementacji OpenGL / DirectX / OpenAL, w ułamku czasu potrzebnego na ukończenie pełnej gry wideo.
TLDR;
Jeśli chcesz programować, naucz się być programistą .
Unikaj używania silników , ale nie bądź głupcem i ignoruj niezwykle przydatne biblioteki.
Jeśli chcesz zostać projektantem gier , wypróbuj silnik WYSIWYG i wypompuj te gry!
Jeśli chcesz zostać programistą gier , unikaj silników takich jak kule.
Dla mnie używanie silników gier wyższego poziomu osłabiło moją zdolność zostania programistą. W momencie, gdy zacząłem korzystać z bibliotek niższego poziomu lub w ogóle nie korzystać z żadnej biblioteki, zacząłem się tak dużo uczyć, że szybko przeszedłem od zupełnie nowego początkującego do kogoś, kto może teraz tworzyć gry wideo bez żadnego odniesienia, samouczków lub książki obok mnie. Tylko mój kompilator i dużo inżynierii i praktyki.
Ilość nauki, którą zdobyłem z bibliotek niskiego poziomu w KRÓTKIM okresie czasu była znacznie większa niż ilość, którą zdobyłem W BARDZO DŁUGIM czasie z SILNIKAMI wyższego poziomu. **
źródło