Pierwsza gra w portfolio powinna dać się uruchomić, zrozumieć i ocenić bez długiej wymiany wiadomości z autorem. Nie musi mieć rozbudowanego świata ani autorskiej grafiki. Potrzebuje za to zamkniętej rozgrywki, czytelnego kodu i opisu decyzji, które podjąłeś samodzielnie. Zacznij od małego projektu, w którym potrafisz wskazać konkretny problem techniczny oraz pokazać, jak go rozwiązałeś.
Wybierz jedną mechanikę i ustal koniec projektu
Zamiast planować wieloosobową grę fabularną, wybierz zadanie mieszczące się na jednej planszy: unikanie przeszkód, zbieranie przedmiotów albo układanie krótkiej sekwencji ruchów. Opisz pętlę rozgrywki jednym zdaniem, na przykład: gracz porusza postacią, omija przeciwników i próbuje poprawić wynik. Ustal również warunek porażki lub zwycięstwa oraz sposób ponownego rozpoczęcia. Dzięki temu od początku wiadomo, co oznacza działająca całość. Jeśli dopiero poznajesz silniki, pomocne będzie wprowadzenie do programowania gier. Sam silnik dobierz do umiejętności, które chcesz ćwiczyć. W tym poradniku przykładem jest Godot i niewielka gra 2D.
Oficjalny kurs tego silnika również zaczyna od prostej, kompletnej gry dwuwymiarowej, ale zakłada już podstawowe doświadczenie w programowaniu. Nie traktuj więc nauki składni i budowania całej gry jako jednego zadania.
Przykład hipotetyczny: przygotowujesz grę o zbieraniu paczek na małej mapie. Pierwsza wersja obejmuje ruch, przeszkody, licznik i ekran końcowy. Edytor map, sklep z ulepszeniami oraz rozgrywkę sieciową zapisujesz na osobnej liście pomysłów. Wrócisz do niej dopiero po ukończeniu wersji, którą inna osoba może samodzielnie sprawdzić.
Zbuduj wersję, w której widać Twoje decyzje
Ukończenie samouczka pomaga poznać narzędzia, lecz w portfolio wyjaśnij, co pochodzi z kursu, a co dopisałeś. Możesz zmienić sposób naliczania wyniku, dodać drugi typ przeszkody albo przebudować sterowanie. Wybierz zmianę, której działanie potrafisz uzasadnić i porównać z wcześniejszym wariantem. Sama wymiana kolorów oraz nazwy gry niewiele mówi o rozumieniu kodu. Materiał GDQuest pokazuje budowę niewielkiej gry w Godot 4: od ruchu postaci i kolizji, przez przeciwników, po obsługę zdrowia i ekran końcowy. Jest po angielsku. Poszczególne rozdziały pozwalają wrócić do konkretnego etapu, ale po przerobieniu ćwiczenia zaplanuj własną modyfikację. Nie przedstawiaj odtworzonego kursu jako projektu napisanego w całości od podstaw.
Rozdziel odpowiedzialności w kodzie tak, by można było znaleźć obsługę wejścia, zasady punktacji i zmianę stanu gry. Nie potrzebujesz wielu warstw architektury. Potrzebujesz struktury, którą umiesz objaśnić: skąd przychodzi zdarzenie, co je obsługuje i dlaczego aktualizacja jednego elementu nie powinna przypadkowo zmieniać innego. W opisie projektu wskaż jeden taki wybór oraz jego ograniczenie.
Przygotuj repozytorium i krótki opis uruchomienia
Załóż repozytorium na początku pracy, zamiast przesyłać cały kod dopiero po ukończeniu gry. Zapisuj zmiany w porcjach opisujących konkretne zadania. Historia nie musi być idealna, ale powinna pomagać odnaleźć moment dodania funkcji lub naprawy błędu. Jeśli potrzebujesz podstaw, przeczytaj materiał o zarządzaniu wersjami kodu w Git. Przed udostępnieniem sprawdź także, czy repozytorium nie zawiera danych dostępowych lub prywatnych plików.
- W Godot 4.1 i nowszych katalog .godot przechowuje dane podręczne projektu i jest wskazywany w dokumentacji jako element do pominięcia w kontroli wersji. Edytor potrafi wygenerować pliki .gitignore i .gitattributes. Korzystaj z zaleceń dla swojej wersji silnika, ponieważ zasady dla starszych wydań mogą się różnić. Po pobraniu projektu do nowego katalogu sprawdź, czy źródła otwierają się bez ręcznego odtwarzania brakujących ustawień.
- Plik README ma ułatwić pierwsze uruchomienie, a nie zastępować cały podręcznik. Podaj wersję silnika, sposób startu, sterowanie i cel gry. Dopisz zakres własnej pracy, znane błędy oraz pochodzenie użytych grafik, dźwięków i fragmentów kodu. Przy zasobach zachowaj informacje o autorach i warunkach ich wykorzystania. Szersze opisy przenieś do osobnej dokumentacji; w uporządkowaniu ich pomoże poradnik o pisaniu dokumentacji kodu.
Oddaj grywalną paczkę i dowody działania
Kod źródłowy i gotowa wersja do uruchomienia służą innym celom. Pierwszy pozwala przejrzeć implementację, druga sprawdzić rozgrywkę bez konfigurowania edytora. W Godot eksport wymaga ustawienia platformy docelowej oraz odpowiednich szablonów eksportu. Nie myl eksportu samych zasobów PCK lub ZIP z kompletną grywalną wersją projektu. Sprawdź zawartość paczki przed jej udostępnieniem.
| Element portfolio | Co umożliwia ocenę | Co sprawdzić przed oddaniem |
|---|---|---|
| Grywalna wersja | Obsługa, przebieg i zakończenie partii | Start bez edytora i komplet plików |
| Repozytorium | Struktura kodu i sposób wprowadzania zmian | Brak prywatnych danych i zbędnych plików |
| README | Uruchomienie i zakres własnego wkładu | Wersja narzędzi, sterowanie i ograniczenia |
| Krótkie nagranie | Przykładowa partia przed pobraniem gry | Zgodność nagrania z udostępnioną wersją |
Nagranie jest dodatkiem do działającej gry. Pokaż w nim wejście do rozgrywki, podstawową czynność i zakończenie rundy. Nie ukrywaj długiego ładowania lub błędu montażem, który sugeruje inne działanie programu. Jeżeli wersja demonstracyjna ma ograniczenia, nazwij je w opisie. Możesz też dodać zrzut ekranu, który pokazuje rzeczywisty interfejs zamiast grafiki koncepcyjnej.
Sprawdź projekt tak, jak zrobi to obca osoba
Przetestuj paczkę po rozpakowaniu do nowego katalogu, poza folderem roboczym. Sprawdź te same czynności w edytorze i w wyeksportowanej wersji, bo poprawne działanie podczas pisania kodu nie potwierdza jeszcze kompletności paczki. Poproś inną osobę o uruchomienie gry wyłącznie na podstawie README. Zapisz miejsca, w których potrzebowała dodatkowego wyjaśnienia.
- Uruchom grę od początku i sprawdź wszystkie opisane klawisze.
- Doprowadź do zwycięstwa lub porażki, a następnie rozpocznij nową partię.
- Sprawdź zachowanie po kilku kolejnych restartach i zmianie rozmiaru okna.
- Porównaj instrukcję z faktycznym sterowaniem oraz zawartością paczki.
- Wypisz znane problemy i rozdziel je od funkcji odłożonych na później.
Dobierz opis projektu do roli, o którą chcesz się ubiegać. Programista może pokazać obsługę kolizji, organizację stanów gry lub sposób znalezienia błędu. Jeśli dopiero wybierasz kierunek, szerszy obraz stanowisk daje artykuł o tym jak zacząć karierę w branży gier. Gotową próbkę traktuj jako materiał do rozmowy o umiejętnościach, bez obietnicy, że sam projekt zapewni zatrudnienie. Najpierw doprowadź jedną małą grę do stanu, w którym można sprawdzić jej działanie i zrozumieć Twoją pracę.
