Wpis z mikrobloga

#vicinityonline #gry #mmo #programowanie #gamedev

Ostatnim razem opisywałem plan działania jeżeli chodzi o technologie. Dzisiaj, a w zasadzie już kilka dni temu, zostało to zakodowane.
Podsumowując:

Technologie mają mieć maksymalnie 6 poziom. Głównym czynnikiem wykorzystywanym przy opracowywaniu technologii będzie czas, czasem bardzo rzadko drobne ilości surowca. Niezależnie od ilości planet, jednocześnie będzie można pracować nad jedną technologią. Posiadając odpowiednie budynki i badania, ilość planet natomiast będzie skracała czas potrzebny na zakończenie badań.

Przez ostatnie kilka dni pracowałem nad komunikacją client-server. Dzisiaj chciałem się podzielić kilkoma szczegółami technicznymi wykonania i problemem, który udało mi się rozwiażać (stąd tag #programowanie - może kogoś zainteresuje).

Server to zespół małych aplikacji/modułów pisanych w javie. Komunikacja odbywa się przy pomocy JMS, a broker to ActiveMQ. Do tego, moduły mają dostęp do pamięci rozproszonej (Hazelcast). To wszystko było w miarę proste do zakodowania.
Większym problemem okazało się stworzenie publish-subscribe, tak by klient mógł nasłuchiwać zmian wykonanych przez dane moduły. Początkowo myślałem nad Kaazing jako bramę pomiędzy serwerem a światem, ale jest to rozwiązanie płatne (do dziś nie wiem ile - nie dostałem żadnej odpowiedzi na moje zapytanie).
Ponieważ nie wiem ile ten produkt kosztuje, zdecydowałem się wybrać inny (ze względu bezpieczeństwa wolę nie podawać nazwy) i dzisiaj udało mi się wykonać pierwszą udaną subskrypcję klienta do serwera! Działa to na zasadzie takiej:
moduł wysyła jedną wiadomość, odbiera ją brama. Brama posiada informację n/t podłączonych klientów i rozprowadza tą wiadomość do odpowiednich użytkowników. Z założenia, jeden użytkownik może istnieć w kilku reprezentacjach (kilka urządzeń na raz może być zalogowanych jako ten sam użytkownik!). Ponieważ moduły komunikują się miedzy sobą za pomocą JMS, używają pamięci rozproszonej, można je osadzić na różnych fizycznych maszynach, dzięki czemu cały system może obsłużyć więcej zapytań!
To, że to już działa i sprawuje się OK to ogromny krok na przód - była to dla mnie największa bariera do tej pory. Ale wiem, że budując pradiwłowe podstawy będzie to owocowało w przyszłości.

Wiele kodu od ostatniego raportu napisałem, w zasadzie więcej frameworku aniżeli konkretnych części gry. To jednak było wymagane by posunąć się do kolejnego etapu...

Kolejny etap to obsługa tego co do tej pory napisałem (zapytania RESTowe, pub-sub, no i budowanie budynków/badanie technologii) przez Androida. Pierwsze linijki kodu już napisane, logować się już można!
Plan jest taki, by przez najbliższe kilka dni wprowadzić potrzebne poprawki po stronie serwerowej (które pewnie wyjdą podczas pisania klienta), oraz wprowadzić obsługę budowli i technologii po stronie Androida, co oznacza pierwszą nie-developerską integrację!

Dalej już tylko bardziej emocjonująco, bo mam plan na budowę statków, opracowywanie poszczególnych elementów takich jak kadłuby, osłony, bronie, moduły komunikacji, silniki, ... Poszczególne elementy będą produkowane przez różne budowle - będą osobne budynki do produkcji kadłuba i osobne do produkcji np broni. Kolejne poziomy tych budynków będą zmniejszały koszty/czas, a technologie powiązane z danymi częściami ulepszały ich atrybuty.
Planuję wprowadzić również pewien element losowości, tak by wprowadzić konkurencję w postaci możliwości handlu tymi częściami z całym universum, ale o tym później, bo to długa historia! :)

Następnym razem postaram się pokazać pierwsze screeny appki na Androida.
Cześć!
  • 5