Postęp prac nad projektem WordHunt

Cześć, dziś chciałem podzielić się tym, co udało mi się zrobić do tej pory. Zauważyłem ostatnio, że robię wszystko żeby nie ukończyć tego projektu na czas… Rzeczy które powinienem zostawić na koniec, lub inne mniej ważne elementy programu zostały po części zrobione, a o samej rozgrywce ani widu, ani słychu. Skoro już zdałem sobie z tego sprawę, może teraz uda się pójść w dobrym kierunku. No, ale do rzeczy.

Model bazy danych

Zaczynam od rzeczy która jest akurat bardzo ważna. Dane oczywiście muszą być gdzieś przechowywane. Tutaj nie wymyślałem niczego interesującego, używam Microsoft SQL Server. Użytkownicy przechowywani są w tabelach, które generowane są automatycznie gdy używamy ASP.NET Core Identity. Wszystko byłoby pięknie, ale gdy projektowałem własne tabele, jako identyfikatora użyłem typu danych bigint, czyli long w C#. Domyślnym identyfikatorem użytkownika generowanym przez system był string, a w bazie danych nvarchar(450). Nie podobało mi się to, że w systemie będę miał dwa typy identyfikatora. Musiałem więc to zmienić. Zadanie to nie jest specjalnie trudne, ale zajęło mi trochę więcej czasu niż się spodziewałem. Myślę że napiszę o tym osobny post, dlatego nie będę się rozpisywał na ten temat tutaj. Tabele zostały zmienione, wszystko gra. Możemy przejść dalej. W systemie naturalnie muszą się znaleźć także moje tabele, nie tylko te domyślne. Tak więc usiadłem i zacząłem je rozpisywać. Zmieniałem je kilkukrotnie, ale mniej więcej udało mi się ustalić jak będą wyglądały, przynajmniej te podstawowe dotyczące rozgrywki.

Schemat tabel bazy danych związanych z rozgrywką

Tabele związane z rozgrywką.

Jak widać, wszystko sprowadza się do powiązania z tabelą Games, gdzie będą przechowane ustawienia gry. GameStatuses odpowiadać będzie za aktualny stan rozgrywki, czyja tura aktualnie trwa, czy została już zakończona etc. GameTeams, jak nazwa wskazuje, przechowuje dane drużyn które biorą udział w grze. W przypadku, gdy grą steruje tylko jedna osoba, nie jest ona powiązana z użytkownikiem. GameFields to pola na których znajdują się słowa, ich rodzaj, czy są przypisane do któregoś zespołu i czy zostało one odkryte. GameMoves to historia wszystkich ruchów, a GameClients to urządzenia które są połączone z rozgrywką. Jestem pewny że tabel przybędzie, ale na razie tyle powinno wystarczyć, wyjdzie w praniu.

Kolejne tabele to takie przechowujące słowa. W grze chce mieć możliwość wyboru języka, więc dodałem tabelę z językami, oraz kategorie żeby łatwiej było nimi zarządzać. Tabele te są dosyć proste, nic szczególnego.

Schemat tabel powiązanych ze słowami.

Tabele związane ze słowami.

WebAPI do zarządzania słowami

Tak, bardzo ważna rzecz w grze która jeszcze nie działa. Dodałem możliwość zarządzania językami, kategoriami i słowami. Jest ono zabezpieczone w taki sposób, że jedynie użytkownicy będący administratorami mają do nich dostęp. Tabele ze słowami są pomocne od początku, ale zarządzanie nimi mogło poczekać… Już się zabierałem za robienie interfejsu użytkownika do tego, ale na szczęście się powstrzymałem. Dalszy rozwój tej części aplikacji odkładam na później.

Routing aplikacji webowej

W poprzednich postach opisywałem routing w Angularze. Na tej samej zasadzie zrobiłem go w mojej aplikacji. Na stronę główną mają dostęp wszyscy, ale żeby zobaczyć coś więcej trzeba się zalogować. Do panelu administracyjnego dostęp mają tylko administratorzy. Wykorzystałem tutaj mechanizm o którym nie wspomniałem w tamtym poście, RouteGuards. Na pewno opiszę go w drugiej części posta dotyczącej routingu. A poniżej przykład:

Podsumowanie

Rozwój aplikacji nie przebiegał ostatnio w najlepszym tempie. Wydaje mi się jednak że zrobiłem dużo nudnych rzeczy, które i tak trzeba by było prędzej czy później dodać (może nawet bardzo później…). Dzięki temu teraz będę mógł przejść do konkretów i development przyśpieszy. Kolejne krotki to dodanie możliwości uruchomienia gry, czyli strona z wyborem ustawień, następnie zapisanie ich do bazy danych. Później przyjdzie czas na system rozgłaszania wykonanego ruchu przez użytkownika do innych klientów. Ale o tym w kolejnych postach.

Dokładne omówienie założeń gry oraz projektowanie interfejsu aplikacji WordHunt

W zeszłym tygodniu pracowałem trochę nad backend’em aplikacji, a konkretnie zabezpieczaniem API. Chcę zacząć pracować nad interfejsem użytkownika, ale zanim się do tego zabiorę wypada dokładnie przyjrzeć się jak powinien wyglądać. Dlatego dzisiaj opiszę dokładniej jakie jak wyobrażam sobie mechanikę gry i dostępne opcje.

Przebieg rozgrywki

Obecnie zaplanowane mam dwa tryby gry, oba polegające na tym, że wszyscy gracze siedzą razem w pokoju. Rozważam jeszcze dodanie trybu czysto online, ale taki dodam jedynie wtedy, gdy będę miał zapas czasu przed końcem konkursu (czego nie przewiduję…). W grze biorą udział co najmniej dwie drużyny (można ustawić więcej), z czego jedna osoba w drużynie jest kapitanem. Plansza do gry składa się z ustalonej podczas konfiguracji ilości pól (domyślnie 5×5). Na każdym polu zawarte jest jedno słowo. Wszystkie pola są na początku gry zasłonięte, nie wiadomo które pole należy do której drużyny.

Wygląd planszy do gry.

Plansza do gry.

Kapitan ma dostęp do klucza, czyli tak zwanej mapy. Na mapie zawarte są informacje, które pole powinna odkryć (upolować) każda drużyna. Kapitan drużyny wypowiada jedno słowo, które kojarzy się z możliwie największą możliwą liczbą pól jego drużyny oraz mówi, ilu słów dane skojarzenie dotyczy. Jego zawodnicy wybierają następnie na planszy, które pola są wg nich tymi poprawnymi. Jeżeli skończą im się pomysły, mogą zakończyć turę. Ważne jest jeszcze to, że co najmniej jedno pole (także można to konfigurować) jest polem tak zwanej nagłej śmierci, jeżeli któraś z drużyn je odkryje, automatycznie przegrywa. Drużyna wygrywa, gdy jako pierwsza upoluje wszystkie słowa na swoich terenach łowieckich. Gracze mogą korzystać z wbudowanego timer’a, który odlicza pozostały na wykonanie ruchu czas. Można go wyłączyć, traktować tylko jako swego rodzaju upomnienie, że dana drużyna zbyt długo zastanawia się nad ruchem, lub spowodować, że drużyna straci ruch po przekroczeniu dostępnego czasu.

Proponowany wygląd mapy z której korzystają kapitanowie.

Wygląd mapy gry.

Konfiguracje sprzętowe

Pierwszy z trybów przewiduje, że wszyscy gracze będą korzystali z jednego urządzenia (np. tabletu), pełniącego rolę planszy do gry. Wszystkie drużyny będą z niego korzystać do wybierania, które pola wg nich powinni odkryć. Do dyspozycji kapitanów będzie jedno urządzenie (lub więcej, dla wygody każdy może korzystać ze swojego), które będzie wyświetlać mapę gry. Do tego celu idealnie nada się na przykład smartfon. Na innym urządzeniu opcjonalne będzie uruchomienie poglądowej planszy do gry, która nie jest interaktywna np. w salonie na telewizorze. Dzięki temu podczas gdy w zabawie będzie brało udział więcej osób, będą oni dobrze widzieć planszę.

Kofiguracja sprzętowa numer jeden, w której dostępne jest jedno urządzenie interaktywne dla wszystkich, kapitanowie posiadają jedno lub więcej map i dla wszystkich dostępna jest ewentualnie plansza poglądowa.

Przykładowa konfiguracja sprzętowa pierwszego trybu.

Druga konfiguracja różni się tym, że każda z drużyn posiada swoje urządzenie z planszą do gry. Gracze logują się do gry przed jej rozpoczęciem i wybierają którą drużynę reprezentują. Reszta pozostaje bez zmian.

Kofiguracja sprzętowa numer dwa, w której jest każda drużyna ma swoje urządzenie interaktywne, kapitanowie posiadają jedno lub więcej map i dla wszystkich dostępna jest ewentualnie plansza poglądowa.

Przykładowa konfiguracja sprzętowa drugiego trybu.

Cała aplikacja będzie zawierała jeszcze inne ekrany: konfiguracji słownika słów dostępnych w grach, konfiguracji gry czy panel użytkownika. Nie są one jednak kluczowe i nie będę ich dzisiaj przedstawiał. Na koniec zapraszam do komentowania, może podrzucisz mi jakiś ciekawy pomysł, który mogę dodać do rozgrywki. Kolejny raz zachęcam także do odwiedzenia mojego profilu na Twitterze, gdzie postaram się zamieszać więcej aktualizacji dotyczących prac nad projektem!