0. SPIS TREŚCI:

1. Wstęp.
2. Pomysł.
      2.1. Kilka pomysłów.
3. Projekt.
      3.1. Założenia.
      3.2. System gry.
      3.3. Engine graficzny.
      3.4. Engine fizyczny.
      3.5. Sztuczna inteligencja.
      3.6. Scenariusz.
      3.7. Duperelki.
4. Programowanie.
      4.1. Wykorzystanie projektu.
      4.2. Implementacja według założeń.
      4.3. Samo kodowanie.
      4.4. Sprawdzanie błędów.
5. Testowanie.
      5.1. Alfa.
      5.2. Beta.
      5.3. Wersja finalna.
6. Dalsze zarządzanie.
      6.1. Publikacja.
      6.2. Nowe wersje.
7. Zakończenie.

1. WSTĘP

Zawsze uważałem, że debiut, w którymś z kącików AM powinien być naprawdę mocny i dobry. Dlatego też jako pierwszy postanowiłem wysłać ten art. Tekst powstał na podstawie jednej z moich programistycznych potrzeb :) - podzielenia się swoim doświadczeniem z innymi. Programuję od trzech lat, w języku C++ od dwóch. Lubisz programować? Jeśli tak, to czytaj dalej. W tekście omawiam poszczególne etapy tworzenia gry. Dla programistów-amatorów (czyli takich, którzy sami programują dla hobby, ja nim jestem) bardzo ważne jest organizowanie czasu. A co jeśli mamy pełno pomysłów na grę. Też tak mam i z prostego doświadczenia wiem, jak to rozwiązać. Niektórzy po stworzeniu aplikacji, przetestowaniu, itp. nie publikują jej. W tym artykule znalazło się miejsce na to, jak opublikować naszą pracę w internecie (tworzymy stronę i umieszczamy na ftp program). Ten tekst jest stworzony po prostu dla programistów-amatorów, którzy tworzą gry (a tych jest wiele) lub chcą zacząć je tworzyć (a nie wiedzą jak zacząć).

2. POMYSŁ

W każdej pracy twórczej bardzo ważny jest pomysł. Tak, programowanie to też praca twórcza. Wymaga mózgu :), ambicji i umiejętności. Nie napiszemy książki, jeśli nie znamy podstaw języka polskiego. Niektórzy (jak np. kilku moich kolegów) uważają programowanie za stratę czasu, czarną robotę i nic potrzebnego. Jednak My programiści, spostrzegamy nic nieznaczące linijki kodu dla zwykłych ludzi, jako sposób myślenia, odrębny świat. Wklepując litery zastanawiamy się, skłaniamy się do refleksji czy wyobrażamy sobie gotową grę i "gramy" w nią w wyobraźni. Po prostu - LUBIMY PROGRAMOWAĆ. Wielu programistów programuje po to, aby programować, aby wklepywać literki, które tworzą klimat, dzięki czemu nie patrzymy na zegarek i programujemy. Zaczynamy o 22:00 a kończymy o 6:00 myśląc przez cały czas, że jest 24:00. Tu sprawdza się powiedzenie - "Szczęśliwi czasu nie liczą" ;D. Jeszcze raz powtórzę - liczy się pomysł. Musimy wpaść na dobry. Mnie taki pomysł często nachodzi po dobrym filmie. Potem musimy go utrwalać, aby nie stał się nieciekawy. Podczas projektowania czy programowania od czasu do czasu przeglądaj encyklopedię na dane tematy, bliskie pomysłowi, przeglądaj internet w poszukiwaniu takich tematów (internet to w końcu Jedna Ogromna Encyklopedia Świata). Przed rozpoczęciem projektowania musimy być pewni, że nasz projekt nam się nie znudzi, bo wtedy padnie cały pomysł, kod, projekt i reszta. Efekt naszej pracy po prostu zostanie wyrzucony w błoto. Błoto, które ma głębokość tysięcy kilometrów. Staraj się wybrać jak najlepsze pomysły. I jeszcze jedno - nie wpadaj z nowym pomysłem od razu w projekt. Zawsze na początku wydaje się on bardzo dobry i najlepszy. Prześpij się z tym pomysłem - zaczekaj do następnego dnia. To pomoże Ci się zastanowić nad trafnością decyzji.

2.1. KILKA POMYSŁÓW

Często mamy kilka pomysłów na raz i nie wiemy, który wybrać. Z pomocą przychodzą nam tabelki ważone. To uczciwy sposób na wybranie najlepszej gry. Tworzy się je jak normalne tabelki. Weźmy na przykład typ tworzonej gry:
Turówka RTS RTW Korzyści Waga 7 8 6 Czy grywalna? 7 5 7 8 Czy długa? 5 9 8 8 Czy ciekawa? 10 164 161 162
U górze piszemy opcje do wybrania. Pod Korzyści piszemy pytania, a w waga piszemy wagę (od 1 do 10). Wagę mnożymy przez ocenę pod nazwą gry. To wszystko sumujemy i wygrywa ten kto zgromadził najwięcej punktów. Według moich gustów najlepiej jest stworzyć turówkę (co zgadza się z moim prawdziwym mniemaniem). Polecam tworzenie takich tabelek, zrób ją chociażby na kartce, czy w Excelu. I pamiętaj - gdzieś zapisz wynik. Gdy zwątpisz w swoją decyzję, to odgrzeb taką tabelę w plikach czy pod stosem kartek i przypomnij sobie o słuszności dokonanej decyzji. W tym tekście będziemy "tworzyć" platformówkę.

3. PROJEKT

Gdy jest pewne na cacy, że masz dobry pomysł, możesz wpaść w rozdział, który nazywa się projektowaniem. Tutaj omówię go bardzo szczegółowo. Najpierw zaprojektujemy założenia, potem całą resztę. Do dzieła!

3.1. ZAŁOŻENIA

Założenia - bardzo ważna rzecz w projektowaniu (jeśli nie najważniejsza). Zapomnij o tych wszystkich bibliotekach i całym kodzie - załóż sobie co byś oczekiwał od programisty, który zrobi grę i wykonaj to. Efektem tej fazy może być coś takiego (w przypadku naszej platformówki):

Założenia:
- ładna,
- dużo broni,
- dużo przeciwników,
- rozbudowane misje.

Uwaga! Nie używaj słowa fajne czy dobre, bo to nic nie oznacza: np. fajne misje. Co to by oznaczało? Pamiętaj, że możesz wymyślać co chcesz. Teraz przypomnij sobie całe programowanie i usuń z tej listy rzeczy, których nie możesz/nie jesteś w stanie wykonać.

3.2. SYSTEM GRY

Tu zastanówmy się nad całą grą i jej stroną techniczną oraz graficzną. Wyobraź sobie grę, jej ekran główny i ekran gry. Co widzisz? Jeśli myślisz, że nieźle to teraz przełącz się na tryb myślenia programistycznego i pomyśl jakby tu zaimplementować ten kod. Właśnie, zapisz sobie podstawowy system gry czyli takie jakby relacje między tym wszystkim. W przypadku mojej platformówki wyglądałoby to tak:
System gry: |-------MENU--------| GRA--| |-OPCJE OBSŁUGA KLAWIATURY------OKIENKO
Ten przedstawiony u góry jest po prostu za prosty i nieprzydatny, dlatego nie bierz go pod uwagę.

3.3. ENGINE GRAFICZNY

Jedna z ważniejszych rzeczy w grze - mieć dobry silnik graficzny. Bez tego nie obędzie się dobra gra. Można go stworzyć samemu (i wykorzystywać w innych swoich produkcjach) lub też wykorzystywać silnik kogoś innego za jego zgodą. Ważne jest bardzo, ile pamięci zajmuje, czy wykorzystuje wiele wątków i inne duperele. Ja jednak proponuję stworzyć własny silnik, bo i jego możliwości bardziej znamy (nie musimy się uczyć dokumentacji) jak i większa satysfakcja, jak zobaczymy mgiełkę narysowaną naszym silnikiem ;P. Możemy też napisać do niego dokumentację i opublikować go i cieszyć się, że komuś uprościł programowanie (więcej o publikacji w podrozdziale 6.1).

3.4. ENGINE FIZYCZNY

Każda gra coś symuluje - stategie symulują dowodzenie czymś, RPG życie kimś czy też zwykłe platformówki - bycie kimś. Silnik fizyczny to jednak nie jest sama fizyka. Owszem większość niego stanowi ta nieszczęsna fizyka, lecz przedmioty muszą mieć identyfikatory, operacje itp. Po prostu - w silniku fizycznym stwórz klasy swoich obiektów (np. samochód) i odpowiednie funkcje, nazwy, itp., itd. Musisz też znać podstawy fizyki. To właśnie w enginie fizycznym zaimplementuj funkcje kolizyjne, bo to one odgrywają w nim największą rolę. Dla każdej gry przyda się inny silnik fizyczny - dla strategii do obliczania wyników starć wojsk czy skoków giełdy, a dla naszej platformówki klasy określające obiekty i sprawdzające kolizje. Fragmentem naszego silnika fizycznego dla platformówki może być nawet to:
class Obiekt { private: int x; int y; int waga; void SprawdzKolizje(int oile, strona wktora); //prywatna //(wykorzystuje ją //funkcja przesun) public: Obiekt(); //publiczny konstruktor ~Obiekt(); //publiczny destruktor void Przesun(int oile, strona wktora); //strona to typ //wyliczeniowy void Usun(); }

3.5. SZTUCZNA INTELIGENCJA

Każda gra imituje jakieś ruchy przeciwnika, człowieka czy innego stwora - bez tego nie było by takiej grywalności. Walczący UFO też w grach mają sztuczną inteligencję. My będziemy ją nazywać AI (artifical inteligention). W platformówce (którą robimy) też będzie sztuczna inteligencja. Kiedyś AI opierała się na instrukcjach sterujących (if, for, while) i do dzisiaj można to z powodzeniem stosować. W C++ jest jednak zaimplementowana sztuczna inteligencja! "Jak to!?" Normalnie, ostatnio przeczytałem książkę o programowaniu i był tam rozdział - "Rozwiązywanie problemów metodą sztucznej inteligencji w C++". Nieźle! Poznałem tam biblioteki, w których są algorytmy do wyszukiwania najlepszego rozwiązania - deklaruje się strukturę (w książce to była struktura przechowująca bazę lotów - skąd do kąd, jaka odległość, jaki czas, itp., itd.) i porównuje się. Zachęcam do kupienia tej książki (wydawnictwo Helion - "Sztuka Programowania C++" Herbert Schildt). Jednak jeśli nie znasz tej biblioteki to wykonuj sprawdzone, dobre pomysły. Projektem sztucznej inteligencji przeciwników w platformówce może być to:
mało życia - uciekam---| widzę/dużo życia - atakuję---| .--------- | nie widzę\ | Spaceruję------------------

3.6. SCENARIUSZ

Fabuła zachęca gracza do grania w grę i podtrzymuje go w graniu, dlatego jest tak ważna w wielu grach (szczególnie przygodówkach). Warto skupić się dłużej i napisać (chociaż) kilkustronnicowe dzieło. W tym czasie po prostu dasz wyobraźni trochę poświrować na czystej kartce Worda ;-). Odpoczną wtedy twoje nerwy programistyczne. Najlepiej wrzuć gracza w sam środek akcji na początku (co nieznaczy, że jeśli tworzysz shotera, to od razu mają do gracza strzelać, grałem w jedną taką grę i za nic nie mogłem przejść pierwszych sekund tej strzelanki i wyrzuciłem ją w otchłani złych gier komputerowych) gry. Drugie - pozostawiaj wiele elementów tajemniczych do ostatniego momentu gry. Taka tajemniczość wciągnie gracza (oglądaliście może serial "Zagubieni" - tu jest profesjonalny przykład tego, jak to można wykorzystać - samolot rozbija się na nie odkrytej wyspie, coś zabija kilka osób, radarem odbierają tajemniczy sygnał po francusku, znajdują francuzkę na wyspie, która siedzi tu od 16 lat, coś znowu wydaje ogromne piski i zabija kilka osób - klimat, który nie da się opowiedzieć słowami).

3.7. DUPERELKI

Ten podrozdział przyjął trochę... dziwną nazwę ;-P. Zajmiemy się teraz całą resztą gry. Na pierwszy strzał idzie...

Intro
Rzecz, bez której nie obędzie się żadna pożądna gra. Po prostu - trzeba zrobić jakiś efekt graficzny na początku i aby on był w miarę dobry. To właśnie ten efekt musi wprowadzić gracza w klimat, bo to pierwsze zostanie dostrzeżone i jeszcze jeden ważny element tego efektu - za wciśnięciem klawisza (lub myszki) pominięcie go. Jeśli gracz wiele razy będzie uruchamiał grę, to będzie znał to już na pamięć, więc po co go męczyć? Załóżmy, że w naszej platformówce będzie to bohater gry, który strzela do ekranu i pojawiają się takie jakby "rysy", które świadczą o przebitym ekranie. To nas wprowadzi w klimat.

Menu
Musi być przejrzyste, ładne, oryginalne i pasujące do klimatu stworzonego przez intro. W tej platformówce będą brązowe przyciski, a w tle będzie leciał obracający się skład amunicji z bronią.

Ekran opcji
Podobnie jak menu, tyle że musi być bardziej przejrzyste. Poza tym nie musi pasować do klimatu. Graliście Operation flashpoint: Cold War Crisis? A widzieliście te menu opcji (komputerek)? W ogóle nie pasowało do klimatu (w końcu to strzelanka wojenna), a było bardzo przejrzyste i najładniejsze jakie widziałem. W naszej platformie będzie to skrzynka amunicji (w tle) i napisy wrzucone jakby do tej skrzynki.

Zakończenie
Gra musi być kończona jakimś filmikiem. Nie może być tak jak B.E.U. (brak żadnego kończącego napisu, po przejściu ostatniej misji przejście do menu, nawet nie było napisu np. "To już jest koniec" lub "Wen Kadc został zabity i siedzi teraz w piekle"). W naszej grze będzie to filmik jak bohater ratuje swojego ulubionego szczura :-). No co? Według scenariusza... Dobra, koniec projektowania, przechodzimy do tego co tygrysy lubią najbardziej, czyli do działu...

4. PROGRAMOWANIE

Rozpoczynamy dział na temat kodowania, ale jeszcze nie włączaj IDE. Najpierw trochę omówię to.
Co trzeba (u)mieć?
Język programowania - to podstawa do tworzenia gier, polecam C++, który najlepiej się do tego nadaje.
Biblioteki - samym językiem programowania nie stworzymy gry, trzeba umieć jakieś biblioteki do Windowsa (WinAPI) czy do grafiki (OpenGL, DirectDraw, DirectX).
IDE - potrzebny nam jest IDE - po pierwsze aby skompilować program (wiadomo), po drugie aby praca była wygodniejsza (preferuję Dev-C++ 5 - darmowy, bardzo dobre różne edytory, zarządzanie projektem no i stworzone w nim programy można sprzedawać i wykorzystywać do celów komercyjnych).
Wiedzę - coś trzeba znać na temat komputerów i podstawowych pojęć.
Ambicje - programowanie to nie to samo co gotowanie - tutaj nie wykonuje się sprawdzonych przepisów, ale tworzy się nowe.

4.1. WYKORZYSTANIE PROJEKTU

Teraz przeglądnij sobie wszystkie stworzone przez Ciebie pliki i zapełnione kartki aby wiedzieć, jak to miało być. Tak jak było z pomysłem - prześpij się z projektem. Warto (wiem to z doświadczenia).

4.2. IMPLEMENTACJA WEDŁUG ZAŁOŻEŃ

Znajdź sobie jakąś kartkę i zapisz na niej rzeczy do zrobienia (np. funkcje, klasy). Jeśli zrobisz jakąś rzecz, to postaw przy niej ptaszka. Podczas robienia platformówki (a właściwie przed):
Funkcje do obługi obiektów v Silnik Graficzny v Obsługa klawiatury Obsługa menu
Taka lista nazywa się TODO (TO DO zrobienia :)).

4.3. SAMO KODOWANIE

Wejdź w swój odrębny świat kodowania i rozpocznij przygodę z wklepywaniem literek ;D. Stwórz nagłówek modułu, spójrz na zegarek i spisz datę rozpoczęcia tworzenia. Po prostu zrób program! Warto mieć podczas tworzenia programu uruchamiający się programik, choćby z pierwszymi efektami, aby mieć motywację.

4.4. SPRAWDZANIE BŁĘDÓW

"Jeśli program za pierwszym razem skompiluje się bez błędów, to na pewno posiada jakiś błąd w kodzie" - to programistyczne przysłowie sprawdza się zawsze. Musisz znaleźć błędy i przejść do działu...

5. TESTOWANIE

Bardzo ważny moment, nie publikuj od razu gry bez uprzedniego przetestowania. Częsty błąd twórców gier (szczególnie tych dużych firm) to pominięcie testowania i natychmiastowe opublikowanie.

5.1. ALFA

Alfa to wersja, która jest testowana tylko przez programistę. Programista wyłapuje błędy i je poprawia w swoim kodzie.

5.2. BETA

Beta (druga litera w alfabecie greckim) - wersja, która zostaje opublikowana po testach w wersji Alfa. Tu zbiera się informacje od graczy, którzy mają jakieś pomysły/coś im się nie podoba/wykryli błędy i wprowadza się nowe elementy. Czasem warto wysłuchać gustów graczy, nawet jeśli to ci nie odpowiada. Niestety, taki jest ich wybór.

5.3. WERSJA FINALNA

Wersja finalna (tzw. podstawowa) to wersja, która publikowana jest już naprawdę jako 1.0 lub zwiększona pierwsza liczba (w przypadku sequeli). Po tym pisze się już tylko nowe wersje.

6. DALSZE ZARZĄDZANIE

Jeden z ciekawszych etapów - zarządzanie stworzonym programem. Chodzi tu o publikację, pisanie nowych wersji, ustalenie licencji, zbieranie informacji na forach i stronach o naszej grze. W tym dziale to wszystko będzie omawiane. Ważne jest zarządzanie, bo jeśli stworzymy grę, ale gracze mówią, że gra nie ma tego czegoś, no to projekt upadnie i nie będzie ona tak popularna. T%#&^Q@YQ*&*! *$$@$&*^%! %^#$%@~!!!!! Sorry! Zasilanie od kompa padło, robiłem przy kablu jakieś pół godziny I JEST!!! W końcu! Myślałem, że cały tekst padł (notatnik nie ma opcji takiej Word - odzyskiwanie dokumentów). Aha! Tą kropkę po słowie "popularna" ocenzurowanym dopisałem dopiero po awarii.

6.1. PUBLIKACJA

Uch, dobra wracam do normalnej pracy. W tym podrozdziale stworzymy stronę internetową i umieścimy na niej naszą pracę. Musisz znać HTML. Jak nie, to od czego są AM Komputery? :) Stwórz stronkę, napisz troszkę o sobie, utwórz odnośnik do ściągnięcia programu (koniecznie musi być spakowany do zipa) i jego opis. Potem wejdź na www.yellow.pages.pl. Utwórz sobie konto, a na tym koncie wlep swoje pliki strony. I tyle! Określ licencję programu, oto kilka najpopularniejszych:

Public Domain - brak licencji,
Freeware - można rozpowrzechniać za darmo bez granic, ale nie można wprowadzać zmian w programie,
GPL - można edytować kod i go ulepszać i rozpowrzechniać zmodyfikowany/nie zmieniony program,
Shareware - wersja programu z ograniczeniami,
Trial - wersja, która przestaje działać po określonym czasie (np. 30 dni lub 10 uruchomień),
Open Source - można edytować kod i go ulepszać i rozpowrzechniać zmodyfikowany program.

Ja proponuję GPL. Po prostu dołączasz kod źródłowy i każdy programista może modyfikować twój program. Tyle, że pierwotnym autorem jesteś ty i zawsze będziesz w "Aboucie". Można też publikować kod programu, umieść wtedy na początku każdego pliku kodu źródłowego taki nagłówek:

/* NAZWA: WERSJA: AUTOR: DATA STWORZENIA: DATA MODYFIKACJI: LICENCJA: */
i oczywiście uzupełnij go. Warto też dawać nagłówek w wersji angielskiej, ja tak robię zawsze:
/* NAME: VERSION: AUTHOR: DATE OF CREATE: DATE OF MODIFICATION: LICENCE: */

6.2. NOWE WERSJE

Nie wyrzucaj kodu czy gry w kąt, tylko (choćby od czasu do czasu) pomyśl czy można coś dodać nowego, jakoś ją usprawnić. Niektórzy mówią, że nowe wersje są niepotrzebnie tworzone, ale pomyśl - jeśli by tak było, to by Gates nie stworzył Windows 98 czy XP, a zostałby przy Win3.1. "Ale systemy operacyjne to inna kategoria!". Tak? No to dam ci przykład z programów - IE6 by nie było, a zostałoby wydane IE1 lub co gorsza Windowsowy Writer (czy jakoś tak, nie pamiętam) nie zamieniłby się w Notatnik, w którym teraz piszę i nie byłoby formatu txt. "Zamiana programu na inny program to też inna kategoria!" Ok. Masz argumenty, ale i oto moje - taka zamiana programu to po prostu zmiana nazwy. No i napisanie nowej wersji. Ha! Tu Cię zagiąłem (to było napisane dla dociekliwych czytelników, którzy narzekają, że autorzy tekstów nie rozmawiają z nimi). Czyli widzicie - warto pisać nowe wersje. A czy tworzyliście sequela jakiejś gry? Czuliście jak to jest? Jeśli nie, to żałujcie. Naprawdę - WSPANIAŁE UCZUCIE JAK PISZE SIĘ SEQUELE! Jak nie wierzycie to i tak prędzej czy później doświadczycie tego. A jak sobie pomyślałem, że mogę to samo, co twórcy Prince of persia: Piaski czasu - czyli dać plansze z pierwszej części gry na najnowszym moim silniku graficznym. Naprawdę, warto. Sorry, że ten dział jest trochę przykrótki, ale wykrztusiłem z siebie to, co miałem w głowie i pamiętałem.

7. ZAKOŃCZENIE

Niestety, koniec tego tekstu zbliżył się i dzieli go od nas tylko kilkanaście bajtów :-). Mam nadzieję, że ten tekst kiedyś się przyda komuś. Miałem w tym tekście opisać całe moje doświadczenie, ale po bliższym przyjrzeniu się zrezygnowałem z tego. Powód - niektóre rzeczy nie da się opisać, po prostu trzeba je zobaczyć w akcji. Jeszcze jedna sprawa - często pisałem "po prostu" ;-). Nie lubię owijać bawełnę i wyjaśniłem niektóre pojęcia "na zdrowy chłopski rozum programisty" :). Cze!

Kurczak_blady