Artykuły » Jak zrobić wygodną w produkcji grę.

Jak zrobić wygodną w produkcji grę.

Warte polecenia
Dodany	17 kwietnia 2010, 07:55	Odsłon	2085
Kategoria	b/d	Ocena	(20 głosów)

1. Wstęp:

Czytając ten artykuł zastanawiasz się jaki jest jego sens? Otóż, zdecydowałem się go napisać by wspomóc w rozbudowie fabryki i pokazać młodym twórcom jak zrobić złożoną grę by była wygodna w produkcji.

2. Rozwinięcie:

A więc co jest magiczną receptą na nieskomplikowane (na dalszym etapie) tworzenie? Otóż, jest nią niezawodne wczytywanie danych zewnętrznych, tj. z pliku, bądź innej ramki, oraz korzystanie ze zmiennych.
Pytasz: czemu? Odpowiedzi jest kilka:

• jeśli chcesz zmienić właściwości jakiegoś elementu (np. statystyki broni), to nie musisz szukać tego w kodzie, bo przy wyjątkowo skomplikowanych projektach jest to bardzo trudne,

• nie musisz dodawać dziesiątek niepotrzebnych zdarzeń, bo korzystając z własnego języka wystarczy w jakimś pliku dodać odpowiednią funkcję,

• kod jest czytelniejszy jeśli są w nim tylko najistotniejsze zdarzenia,

• dzięki takiemu rozwiązaniu łatwiej stworzyć filmiki, czy system rozmów.

Zalety można by wymieniać bez końca, ja wymieniłem tylko te najważniejsze (czyli te które przyszły mi akurat do głowy).

Ok, ale jak coś takiego zrobić?
Najlepszym sposobem jest stworzenie odpowiedniego silnika który wczytywałby dane z pliku, choćby za pomocą INI Wbrew pozorom nie jest to trudne. Możemy do tego celu użyć szybkich pętli, ale nie zawsze jest to wymagane.
Przykładowe wczytywanie kilku danych może wyglądać następująco (posłużę się tutaj moim nowym silnikiem npc):

1. Uruchamianie pętli x razy (dajmy na to x = ilość plików w folderze)

2. Tworzenie w pętli odpowiedniej ilości obiektów

3. Porównywanie w pętli wartości identyfikacyjnej z numerem kroku pętli i wczytywanie zmiennych dla obiektu

Cała magia polega na tym, że są to tylko 3 zdarzenia i możemy to dowolnie i w prosty sposób zmieniać. Dodatkowo sztuczka ta działa dla wielu ramek naraz bez konieczności kopiowania kodu.
Kolejnym plusem jest to, że gra może być w dużej części modyfikowalna co daje szerokie spektrum działania dla moderów, a to zwiększa grywalność i popularność gry. Jeśli jednak nie chcemy, by dane były dostępne dla każdego, możemy je po prostu zaszyfrować.

Jakie są inne korzyści?
Przede wszystkim dzięki temu rozwiązaniu tworzenie jest wygodniejsze i w każdej chwili możemy zmienić jakąś wartość nie przełączając okien w naszym MMFie czy TGFie.
Z własnego doświadczenia wiem, że jeśli wszystko jest napchane w kodzie to ciężko zrobić jakieś specjalne zdarzenia w prosty sposób. Przykładem może być moja Postapokalipsa, niby w teorii część danych była wczytywana z pliku, ale nie zrobiłem żadnych komend i tworzenie jednego npc wraz z zadaniem jakie nam powierzył zajmowało mi ponad 2 godziny.
Innym plusem jest to, że największy 'wysiłek' musimy wykonać na samym początku etapu tworzenia, a później jest już z górki.

3. Zakończenie

Tak więc, drogi klikowcu! Pamiętaj, aby działania jakie wykonujesz na początkowym etapie produkcji nie utrudniły ci pracy na dalszych etapach.

Tak powiedziałem ja, Piter. Teraz możecie mnie zjechać.

Ostatnio edytowane 17 kwietnia 2010, 08:04 przez Piter

Komentarze

	Maniek @ 28 sierpnia 2010, 11:39
	Boję się tych zmiennych...pewnie chodzi ci o Alterable Values,Piter...ale spróbuję . Ostatnio edytowane 28 sierpnia 2010, 11:43 przez Maniek
	Shivek @ 19 kwietnia 2010, 21:01
	A ja myślę, że tworzenie silników przez "młodych twórców" powinno być ważne. Dzięki silnikowi łatwo stworzymy następne części gry lub jeśli nam się spodoba i dopracujemy go - coś nowego. Osobiście nie stworzyłem jeszcze własnej gry, którą bym wydał. Staram się testować różne rozszerzenia, ogarnąć w pełni MMF'a. Za produkcję zajmę się wtedy, kiedy poznam środowisko, tworzenie będzie przyjemnością.
	Zax37 @ 19 kwietnia 2010, 16:53
	OK, może rzeczywiście czas się przerzucić na obsługę plików... ; p 5/6
	Piter @ 18 kwietnia 2010, 18:11
	Może faktycznie masz rację.
	Seelkadoom @ 18 kwietnia 2010, 17:56
	Tak, rozumiem cię. Twój poradnik jest bardzo przydatny, jedynie dedykowanie go "młodym twórcom" jest nieco dziwne
	Piter @ 18 kwietnia 2010, 17:17
	Seelkadoom, trochę mnie źle zrozumiałeś. Chodziło mi o to, że łatwiej operować na własnym języku, niż tworzyć dla każdego obiektu kolejne niepotrzebne zdarzenia.
	Seelkadoom @ 18 kwietnia 2010, 17:07
	A według mnie artykuł trochę bez sensu. Każesz "młodym twórcom" skupić cały wysiłek na silniku, potem na właściewj zawartości. Czyli de facto, "żeby ci sie przyjemnie tworzyło, to najpierw spędź X godzin babrając się w silniku, po czym stwierdź, że i tak właściwie nadal masz tak mało gry, jak wcześniej" Nie zrozum mnie źle - sam doceniam potencjał silników, jednak dedykowanie tego artykułu "młodym twórcom" może przynieść nieco odwrotny efekt. Niemniej, 5/6
	pikor @ 17 kwietnia 2010, 12:11
	art króciutki, lecz przydatny... rzeczywiście łatwiej się pracuje na danych zewnętrznych. sam raczej tworze moduły.. nadaje te same nazwy oa w róznych grach i kopiuje potrzebne mi grupy do innych gier, przykładowo moduł cegiełek przesuwanych o pole przy wielokrotnym dotyku włącznika - taki z diamenciarza uzylem wiele razy.. między innymi w Ka Zone jedynie niebezpieczenstwem uzywania modułow to - duze podobienstwo miedzy roznymi grami.. ale zalety sa duze bo blyskawicznie importuje do gry grupy: klucze, przeciwnicy poruszajacy sie od det lewego do prawego, podstawowy system ruchu, i wiele innych.
	Fadex @ 17 kwietnia 2010, 11:28
	Oj, racja, racja Podejrzewam, że gdyby Upadłe Ostrze wszystkie informacje miało wbudowane, liczba zdarzeń mogłaby sięgnąć granicy 600. A tymczasem jest prawie 250, a prawdopodobnie mogłoby być jeszcze mniej ;P Nie wspominając już o 1 ramce, która wczytuje wszystkie poziomy - bardzo wygodne rozwiązanie. Jako, że w artykuł jest trochę zbyt ogólnikowy - 5/6 Ostatnio edytowane 17 kwietnia 2010, 11:34 przez Fadex
	szymat @ 17 kwietnia 2010, 10:13
	Przydatne 6/6