Witam wszystkich forumowiczów.. Przychodzę tutaj prosić o radę wszystkich większych/mniejszych twórców "gier", no i chciałbym też poznać Wasze pierwsze podejście do kodu gry - za co się na początku zabieracie itd.. Otóż brak mi pomysłów od czego mam zacząć tworzenie takowego kodu. Ma to być gra RTS, mam już zapisane multum pomysłów nt. uniwersum, sytuacji w świecie gry, ogólnej fabuły, gameplayu itd.. Gra będzie z perspektywą 2d(coś a.la twierdza, wizardcraft) i pisze ją z pomocą biblioteki SDL, stworzyłem już projekt i napisałem pierwsze linijki kodu(inicjalizacja okienka gry, pobieranie rozdzielczości pulpitu itd.), no i zatrzymałem się na głównej pętli gry.. Jako, że tworzę "solo" tą produkcje, to też zajmuje się grafiką, chociaż jako-tako grafikiem nie jestem.. Gra jednak w zamyśle jest mocno rozbudowana, sztuczna inteligencja troszkę inna od pozostałych RTSów - każda postać prowadzi jakieś własne życie w Naszym królestwie(coś a.la banished). Więc ciężko mi podjąć decyzję od czego najlepiej zacząć, może od menu gry, sztucznej inteligencji, grafiki czy samego gameplayu.. Zacząć coś zawsze jest trudno, ale później to wszystko idzie coraz szybciej. Chociaż wiem, że ja sam powinienem wiedzieć jak to zacząć, aczkolwiek wcześniej nie tworzyłem tak rozbudowanych rzeczy, ogólnie moje wcześniejsze "gry" pisałem bez obiektówki, bez jakiegoś podziału na pliki, wszystko było napisane na sobie i później nie wiedziałem co jest od czego, ale chociaż działało, więc teraz postanowiłem to zmienić i ogólnie zabrać się za coś ciekawszego, większego.. Coś, z czego mogę być w przyszłości w jakiś sposób dumny..
Mam nadzieję, że ktoś podzieli się ze mną swoim "pierwszym podejściem" do kodu gry - będę ogromnie wdzięczny..
zrób najpierw klon snake'a, tetrisa, arkanoida, a dopiero potem myśl o czymś większym
Najpierw zacznij od napisania małej gry, ale porządnie, czytelnie - potem celuj w bardziej skomplikowane projekty.
W innym wypadku najprawdopodobniej bardzo szybko skończysz kupując linę oraz składane krzesło w pobliskim sklepie.
Zamiast pisać w SDL zmień na Unity 3D.
Nie piszę tego dlatego, że "wszyscy powinni tworzyć w Unity". Po prostu nauka Unity pokaże Ci jak powinien wyglądać twój kod ;)
W SDL piszesz praktycznie własny silnik gry od zera, co bez doświadczenia prowadzi właśnie do spaghetti. W Unity każdy obiekt ma działać "niezależnie" co siłą rzeczy skłania do zachowania większego porządku w projekcie.
Ma to być gra RTS, mam już zapisane multum pomysłów nt. uniwersum, sytuacji w świecie gry, ogólnej fabuły, gameplayu itd.. Gra będzie z perspektywą 2d(coś a.la twierdza, wizardcraft) i pisze ją z pomocą biblioteki SDL, stworzyłem już projekt i napisałem pierwsze linijki kodu(inicjalizacja okienka gry, pobieranie rozdzielczości pulpitu itd.),
Zapisywać pomysły możesz, tylko pytanie czy jesteś gotów do ich realizacji?
Bo zobacz, marzysz o napisaniu wielkiej gry, a zatrzymałeś się na pisaniu kodu do głównej pętli gry...
Mam nadzieję, że ktoś podzieli się ze mną swoim "pierwszym podejściem" do kodu gry - będę ogromnie wdzięczny..
Pierwsze podejście do kodu gry wcale nie musi być pisaniem tego kodu.
Weź sobie kartkę i długopis i rozrysuj sobie wszystkie potrzebne elementy (mam na myśli już techniczne elementy, rozrysowanie modułów, obiektów, funkcji etc. na kartce. Tzn. w symboliczny sposób, jakiś diagram itp.).
Chociaż wiem, że ja sam powinienem wiedzieć jak to zacząć, aczkolwiek wcześniej nie tworzyłem tak rozbudowanych rzeczy
To zacznij od mniej rozbudowanych. Zamiast zacząć od zrobienia całej gry, możesz zacząć od zrobienia jednego elementu, np. od animacji jednostek. Potem możesz dodać algorytmy typu szukanie drogi. I rozbuduj swoją grę o poszczególne elementy. Np. potrzeba menu? To je dorób itp.
Czyli podejście bottom-up, robisz szczegóły i składasz z nich aplikację.
Jest też drugie podejście top-down, czyli, że najpierw robisz ogólny szkielet gry, a potem dopiero zajmujesz się techniką.
http://www.hobbygamedev.com/adv/bottom-up-vs-top-down-game-design/
Oba podejścia mają wady i zalety, jakby co. W przypadku gier szczegóły są trudne (grafika, technikalia, algorytmy itp.), więc przydaje się podejście bottom-up, żeby najpierw opracować trudne szczegóły, a potem to zebrać w kupę. Ponadto to podejście pozwala na większą zabawę. Bo bardzo szybko widzisz już coś na ekranie. Możesz się tym bawić, eksperymentować. Z drugiej strony podejście bottom-up ma tę wadę, że łatwo nie przemyśleć wszystkiego od strony designu.
A podejście top-down ma tę zaletę, że możesz wszystko od razu przemyśleć, mieć ogólny szkielet gry, i potem go wypełniać. Ma też jednak tę wadę, że możesz się napisać, a nic nie zobaczyć na ekranie. Trochę jak takie pisanie na sucho. Poza tym zrobienie szkieletu gry wcale nie gwarantuje tego, że będzie to szkielet właściwy. To się dopiero okaże w praniu. A może stać się tak samo jak w przypadku bottom-up - że w swoim projekcie nie przemyślić czegoś, nie uwzględnisz i będziesz musiał przerabiać mocno potem aplikację, bo nie przemyślałeś pewnych rzeczy.
Tyle, że to normalne. Im masz mniej doświadczenia, tym ciężej coś zaprojektować od razu dobrze. Często przydaje się więc traktować robienie gier jako prototypowanie - projektujesz coś, piszesz coś, ale to wszystko taki prototyp. Jak się nie uda, to zaczynasz od nowa i tyle (i w rezultacie zbierasz doświadczenie, zaczynasz pamiętać co się udawało, co nie. Jakie problemy miałeś ostatnio. Jak je rozwiązałeś itp.).