Myślę, że przyszedł czas, abym podzielił się moimi gamejamowimi historiami. Ku mojemu zdumieniu, zebrało ich się całkiem sporo. Od dwóch lat aktywnie biorę udział w różnego rodzaju zabawach związanych z szybkim tworzeniem gier. Z perspektywy czasu widzę, że dużo mnie to nauczyło. Coraz rzadziej wymyślam skomplikowane projekty, których w ogóle nie jestem w stanie ukończyć. Nie to, że mam listę działających gier. W sumie mam jedną. Zrobiłem ją w ramach „PyWeek 29”.
Na czym polega ten game jam? W ciągu tygodnia trzeba stworzyć formę wirtualnej rozrywki w Pythonie. Temat jest narzucony. Tym razem był to „efekt motyla”. Zapoznałem się, podumałem i stwierdziłem, że zrobię niewielką grę polegająca na zarządzaniu zasobami. Zadaniem odbiorcy miało być zaspokojenie zapotrzebowania, którego przyrost zawsze wynikał od aktualnej wartości podaży. To był mój pomysł na interpretację tematu PyWeek 29. Wiecie, co jest najzabawniejsze? Ja tę grę skończyłem, ale nie zdążyłem jej wysłać. Tak, w trakcie ostatnich testów zauważyłem dwa potworne błędy. Potrzebowałem czasu na ich poprawienie i przegapiłem możliwość wysłania gry.
Za to wrzuciłem je do swojego repozytorium. Tym samym stworzyłem miejsce, w którym mają się pojawiać ukończone projekty. Mam nadzieję, że się uda, ponieważ po każdej nowej grze, pewnie będę pisał post na bloga. O tym, czego tym razem się nauczyłem. W przypadku PyWeek 29 będą to następujące rzeczy.
Przy rysowaniu GUI dla użytkownika, trzeba myśleć o tym, co i kiedy będzie się odświeżać. W przypadku mojego „dzieła” cały interfejs znajduje się na jednej warstwie. Jeśli chcę coś odświeżyć, to muszę nadpisać określony fragment ekranu. Niestety, okazało się to kiepski rozwiązaniem, mało wydajnym, ponieważ niektóre elementy powinny zostać narysowane raz, a inne odświeżane na życzenie. Gdybym stworzył odpowiednie panele i przestrzenie, ogarnięcie interfejsu byłoby łatwiejsze.
Dobrze jest zrobić, chociaż podstawowe menu i ekran kończący. Na początku uznałem, że do niczego mi się te elementy nie przydadzą. Myliłem się. W trakcie testowania zauważyłem, że znacznie bardziej czytelne dla użytkownika byłoby stworzenie, chociaż podstawowego ekranu kończącego grę. Żeby wiedział, co się stało. U mnie, w momencie przegranej, okno po prostu się zamyka. Co wygląda tak, jakby mój program zdechł, a on zadziałał zgodnie z założeniami.
Brak czytelnych komunikatów lub dźwięków psuje zabawę. Ja wiem, co dzieje się na ekranie i powinien dążyć do tego, abym użytkownik nie musiał czytać załączonego pliku README z instrukcją. Prosta gra powinna być jasna, z koherentnym sterowaniem. A nie, raz się klika, a innym razem trzeba naciskać przyciski na klawiaturze. Pomieszanie z poplątaniem.
Trzy dość istotne rzeczy, o których zawsze zapominam. Koncentruję się na stworzeniu prostej mechaniki pasującej do tematu oraz staram się ją jak najbardziej uprościć, aby ukończyć grę w terminie. A potem okazuje się, że przez niechlujny interfejs czego nie dopilnowałem, coś przeoczyłem. Liczę na to, że następnym razem będzie lepiej!
You must be logged in to post a comment.