Porady dla początkującego twórcy gier

Zainspirowany pewną marną produkcją, postanowiłem napisać artykuł mający na celu pomóc wszystkim nowym twórcom w zrobieniu ciekawych produkcji. Nie będę się tutaj rozwodził nad konkretnymi przykładami, jak zrobić sztuczną inteligencję, itp. Tylko takie ogólne porady, jak zacząć, jak prowadzić i jak skończyć Zacznijmy więc.

1. Silnik
Zaczynając produkt, zwykle nigdy nie zaczynajmy od menu. Jeśli mamy pomysł, energię to od razu rozpocznijmy tworzenie tego, co nazywa się silnikiem – czyli takiego levelu, gdzie zamiast grafik mogą być zwykłe kwadraty, chodzi o samo napisanie skryptu dla całej gry. Wyobraźmy sobie że ta gra to platformówka. W każdym poziomie będzie zatem zachodzić zdarzenie:
# Gracz koliduje z tłem > gracz – zatrzymaj.

I tutaj jest właśnie ta mądrość w robieniu silnika. Zamiast na każdym poziomie powielać to zdarzenie, wystarczy że zrobimy je raz, a potem będziemy kopiować ten cały level z silnikiem. Czyli jak to robić w praktyce? Wpierw robimy silnik. Gdy już skończymy, oznaczmy charakterystycznie ten poziom, a następnie go skopiujmy kilka razy. Potem, wystarczy już tylko poukładać obiekty tła, wrogów i bonusy na swoje miejsca i mamy gotowy poziom. Nic więcej nie musimy robić, chyba że oczywiście chcemy dodać jakieś specyficzne zdarzenia charakterystyczne tylko dla tego poziomu. Dlaczego to takie ważne? Początkowo Twoje produkcje mogą mieć 10, 20, nawet 50 zdarzeń. Ale jak będziesz miał ich ponad 1000, to zrozumiesz o czym mowa Po skończeniu silnika, innych leveli możemy wtedy dorobić całą resztę, menu, tabele wyników, autorów itp.

2. Komentowanie kodu.
Nie ma nic ważniejszego niż komentarze w kodzie! Jeśli masz 10 zdarzeń, oczywiście są one zbędne, ale gdy masz ich ponad 1000, to zrozumiesz o czym mowa Komentarze możesz wstawiać tak często jak tylko chcesz, ale wg mnie komentowanie najprostszych zdarzeń typu „kolizja z tłem > odbij” nie ma sensu. Najlepiej komentować zdarzenia które składają się z kilku warunków, zajmują pół ekranu i na następny dzień nie wiesz do czego służą. Komentowanie zdarzeń zaoszczędzi ci mnóstwo czasu i może bardzo pomóc w pracach zespołowych, np. gdy robisz grę w teamie.

3. Warunki
Przykładowo robimy prosty level. Mamy na nim gracza [małpę], banana i drzewo. Celem gracza jest zdobycie banana, powrót do drzewa a gra wtedy przechodzi na inny poziom. Dajemy zatem zdarzenie:
# Małpa + kolizja z drzewem > następny poziom

Wszystko cacy, nie? Otóż nie do końca. Dlaczego? Ponieważ gracz wcale nie musi zbierać banana. Wystarczy że podejdzie do drzewa i już będziemy mieli następny poziom. To poważny błąd! Jak się przed tym uchronić? Musimy przebudować nasze zdarzenie:
# Małpa + kolizja z drzewem + wszystkie obiekty typu „banan” zostały zniszczone> następny poziom

Dopiero teraz nasz poziom ma sens i jest logiczny. Jak wstawiać warunki? Jako że pracuje z MMF2, opiszę to procedurę na podstawie tego programu. Wstawianie warunków jest banalne na dobrą sprawę, ja opisuję to tylko dlatego że zanim na to wpadłem to minęło kilka miesięcy {wtedy jeszcze nie było internetu! No, u mnie}

To jak wstawić ten warunek?
W edytorze zdarzeń (tam gdzie są zapisane wszystkie zdarzenia, gdzie jest dużo kolum i wersów, przypomina excela, klikamy PPM [prawy przycisk myszy np. na 2 (liczbaporządkująca wersy) -> dajemy INSERT > potem ADD NEW EVENT. To spowoduje nam dodanie nowego zdarzenia, wybieramy więc np małpa koliduje z drzewem. Teraz mamy nową linijkę z tym zdarzeniem. To co wstawimy w linijce nazywamy akcją. Akcją będzie " > następny poziom". Ale gdzie ten warunek? Ano, więc teraz klikamy PPM na tym zdarzeniu (małpa + kolizja + tło) i wciskamy instert > dodajemy nowe zdarzenie, "wszystkie obiekty typu 'banan' zostały zniszczone. To wszystko, dodaliśmy nowe zdarzenie i warunek do niego. Może wygląda to trochę nieczytelnie, ale gdy już trafisz w dobrą opcję na pewno zapamiętasz. Warunki wyglądają tak (te plusiki takie):
http://h.imagehost.org/0807/AQQ.jpg

4. Zapisywanie gry
Wszystkie gotowe produkcje powinny być zapisane jako pliki wykonywalne (o rozszerzeniu .exe). Musimy ją zapisać poprzez "zapisz jako samodzielną grę" albo "save as stand-alone game". Tylko dzięki temu w naszą grę będą mogli zagrać inni, którzy nie posiadają The Games Factory albo innych programów z tej rodziny. W dodatku, do gier skompilowanych poprzez TGF albo MMF (nie dotyczy "dwójek", TGF2 i MMF2) potrzebne są pliki DLL:
# cncs.dll dla KNP,
# cncs32.dll dla TGF,
# cncs232.dll dla MMF,
Niektórze rozszerzenia potrzebują dodatkowych DLL, np. rozsz. DMC2 dla TGF potrzebuje pliku bass.dll

5. Muzyka i dźwięki
Ich dobór powinien być w miarę logiczny. Nie dołączajmy do levelu który możemy przejść w 30 sekund piosenki znanego autora w formacie .WAV zajmującej 40MB - zwiększa to niebotycznie rozmiar gry, utworu nikt i tak nie przesłucha a do tego łamiemy prawa autorskie.

Tak samo do gry horroru nie powinniśmy dodawać "słodkiej muzyki", granie na flecie albo innych badziewi. Przydałaby się jakaś mroczna muzyka, trzymająca w napięciu, coś w tym stylu. Dźwięk i muzykę powinno dać się wyłączyć albo regulować jej głośność. Nie jest to strasznie trudne, a tylko uprzyjemni niektórym rozrywkę i przeważy na korzyść twórcy. Szukając dźwięków możemy poszukać w standardowych bibliotekach dołączonych do edytorów [TGF, TGF2], albo czegoś w internecie. Pamiętajmy o tym żeby nie łamać praw autorskich. Jeśli do całej gry użyjesz tylko i wyłącznie piosenek Behemota to wg mnie złamałeś prawa autorskie. Jeśli do jednego konkretnego levelu użyjesz 30 sekund jednej piosenki, to chyba nic strasznego się nie stanie, nie? Prawo w tej kwestii ciągle nie jest jednolite dlatego zdajmy się na własny rozsądek. Najlepiej jednak zawsze korzystać z darmowych źródeł.

6. Grafika
Jeden z bardzo ważnych elementów. Podobno grafika się nie liczy, liczy się grywalność. Przykładem może być wiecznie żywy CS 1.6, GTA Vice City, Max Payne i inne znane gry z nienajlepszą już jak na dzisiejsze czasy oprawą graficzną. Pamiętajmy jednak, aby nie przesadzać. Jeżeli w naszej gry wszystkie obiekty mają jaskrawe kolory, są rysowane w kilka sekund w paincie to jest to przegięcie. Znaczy to o kompletnym pominięciu grafiki przez autora produkcji co automatycznie odrzuca od niej. Nietórzy, patrząc na screeny z gry mogą sobie przecież tak pomyśleć: "skoro nie przyłożył się do grafiki, to pewnie do innych elementów też, nie ściągam, idę grać po raz setny w sapera, szkoda że nie ma fajnych gier". Widzisz? Grafika to kluczowy element.

7. Kontrola, obsługa, instrukcja
Wypuszczając grę w "świat" postaraj się zachęcić do niej gracza. Wyobraź sobie grę z piękną grafiką, dopracowanym silnikiem i chorym sterowaniem. Zamiast strzałek albo klawiszy WSAD gracz porusza się wciskając F1, F2, F3, F4. Nikt w to nie będzie grał, chyba że jakiś świr - jeśli nie korzystasz z ogólnie przyjętej kontroli staraj się ją dokładnie opisać. Np. w dołączonym do gry pliku .TXT

8. Zapisywanie prac nad projektem
dodane dzięki: Slawo
Ważne i pomocne. Jeżeli już nasz projekt rozrósł się do jakichś pokaźnych rozmiarów, warto zapisać projekt jako nowy plik. Czyli przykładowo zapisywaliśmy wszystko w pliku "nasza_gra.mfa". Potem tworzymy nowy plik (kolejne postępy nad grą) i zapisujemy ją jako odrębną wersję, np: "nasza_gra_kopia1_czerwiec.mfa". Polecam stosować daty w nazwach, łatwiej można się odnaleźć w kopiach, jeśli mamy ich dużo. I starych wersji nie ruszamy już, tu chodzi o to że jeżeli stracimy coś w "nowej" kopii, to zawsze możemy wrócić do starszej wersji :- )

Kończąc:
się wydłużył trochę ten mój artykuł W przyszłości może napiszę kilka dodatkowych porad, na razie zostańmy przy tych najważniejszych. Sądzę, że jeśli się do nich zastosujesz Twoje produkcji drogi twórco na pewno staną się z jakimś czasem "lepsiejsze" : P

Autor: Mateusz9206