Znajdź zawartość

Robię sobie plugin na minigry Arcade. Był już taki, ale chce napisać go od nowa i zbudować w ogóle innych design, który pozwoli na jeszcze więcej funkcji. Cały kod od początku powstaje jako open-source. Można go znaleźć na GitHubie - https://github.com/ShootGame/Arcade2. Obecnie nie ma możliwości pobrania pluginu, ponieważ dopiero buduje jego strukturę. Projekt Arcade - bo tak to nazwałem - ma się składać z pluginu na mini-gry, plikami serwerowymi i kilkoma przykładowymi mapami do właśnie tych gier. Projekt od samego początku powstaje jako publiczny i z otwartym kodem źródłowym. Initial commit wprowadziłem 25 grudnia zeszłego roku. Była to 1 klasa i 22 linie kodu; dzisiaj (10/02 2016) jest to ponad 350 klas i ponad 20 000 linii kodu. Design Plugin chce napisać jak najbardziej abstrakcyjnie jak to możliwe, aby umożliwić łatwe dopisywanie nowych funkcji do pluginu. Chcę go oprzeć o moduły, które będą włączone i wyłączane w potrzebie do każdej z map. Cała logika pluginu będzie polegać na przenoszeniu się między mapami. 1. Ładowanie mapy oraz jej ustawień. 2. Włączanie modułów pluginu. 3. Przenoszenie graczy. 4. Startowanie gry. 5. Kończenie gry. 6. Wyłączanie modułów pluginu. 7. Patrz punkt 1. Każdą mapę będzie można dobrowolnie konfigurować, niezależnie od innych map. Działanie pluginu będzie oparte właśnie o te konfigurację. Folder mapy (w którym znajduje się level.dat, oraz inne pliki mapy) należy umieścić w folderze repozytorium map. Taki folder powinien posiadać plik XML map.xml z jej konfiguracją. Plugin poprzez kolejkowanie map będzie je ładował (najpierw kopiował do swojej lokalizacji światów) i uruchamiał według ustawień zawartych w konfiguracji. Cały plugin działa na modelu publikacji-subskrypcji - dla zielonych - mam dużo eventów, tak jak w Bukkit, nasłuchuje je w innych częściach kodu. Konfiguracja mapy Przykładowa konfiguracja wygląda tak - link. Obecnie mam napisaną podstawową logikę pluginu, system tasków, zarządania modułami, mapami, grami, regionami, kitami - w sumie wszystko z podstaw. Teraz to testuje i rozwijam moduły. Mam już napisany moduł na rozgrywanie meczy oraz tworzenie drużyn. Na samym początku pliku konfiguracyjnego należy zdefiniować nazwę mapy, wersję, opis (cel gry), jej autorów oraz ustawienia świata Minecraft. Do ustawień świata zalicza się - poziom trudności (easy/normal/hard/peaceful), środowisko (normal, nether, the end), pvp (włączone/wyłączone globalnie na całej mapie). Dodatkowo można także podać generator który ma być wykorzystany - domyślnie jest to void, pusty świat. Można ustawić vanilla, normalny generator (aczkolwiek zabija CPU), lub z zainstalowanego pluginu na serwerze, na przykład TerrainControl. U ustawieniach należy także podać domyślny spawn - będą się na nim spawnować przyszli obserwatorzy modułu match. Piszcie propozycję do pluginu i pomysły na jego rozwój "Game" No dobrze, ale co daje ten Arcade? Szczerze? nic... Tak... nic.. no prawie. Wprowadza on tak na prawdę zarządzanie obiektami Game, który odpowiada za trwającą rozgrywkę na serwerze. Całą resztę wprowadzają moduły, które dobrowolnie włącza się niezależnie w konfiguracjach map. Każda mapa musi posiadać plik map.xml (tak, to jest XML, nie YAML - patrz niżej). Przykładowo na mapie można włączyć moduł match. Odpowiada on za rozgrywanie meczy na mapie. Jest to odliczanie do startu (jeżeli mapa i gracze są gotowi do startu). Start meczu aż do zaliczenia wszystkich celów meczu przez minimum jedną drużynę. Zakończenie meczu - odliczanie do przeniesienia na następną mapę. Ten poziom modułu - definiujący tryb działania mapy nazwałem "środowisko" - czyli "environment". Kolejnym poziomem modułu jest "format", ale tylko w match, bo są one zależne od niego. Ten moduł definiuje tryb działania graczy na mapie. Na razie implementuje tylko drużyny, aczkolwiek w przyszłości planuje dodać FFA - Free-for-all, to znaczy - każdy gra dla siebie. Co ciekawe, taka zmiana nie powinna popsuć jakichkolwiek mini-gier! Zaprezentujmy więc te drużyny... Poniżej znajdują się dwie drużyny - Blue Team oraz Red Team. Oba mają mieć friendly-fire, to znaczy, że członkowie nie mogą się nawzajem atakować. Ilość slotów to 50, aczkolwiek moderator, lub inna osoba z dodatkowym uprawnieniem może wejść nawet jeśli są pełne. Ostateczne ograniczenie to przepełnienie - overfill. Po przepełnieniu do drużyny nie może wejść już żadna osoba. <teams> <team id="blue-team" name="Blue Team" color="blue" friendly-fire="true" slots="50" overfill="60"> <kits> <kit>spawn-kit</kit> </kits> <spawns> <region yaw="90"> <cuboid min-x="43" min-y="25" min-z="-69" max-x="60" max-y="25" max-z="-62" /> </region> </spawns> </team> <team id="red-team" name="Red Team" color="red" friendly-fire="true" slots="50" overfill="60"> <kits> <kit>spawn-kit</kit> </kits> <spawns> <region yaw="270"> <cuboid min-x="-59" min-y="25" min-z="63" max-x="-42" max-y="25" max-z="70" /> </region> </spawns> </team> </teams> Kolejnym poziomem modułu meczu to cele, czyli objectives. Wszystkie inne są najniższym poziomem modułów i nie wpływają aż tak bardzo na rozgrywkę. Cele to inaczej gry, ale dlaczego nie games? Ponieważ plugin Arcade wprowadza możliwość ich mieszania! Można wymieszać Destroy The Core i Destroy The Monument jednocześnie! Dzięki temu drużyna musi zniszczyć rdzeń(ie) i monument(y) przeciwnika, aby wygrać mecz. Dzięki temu, jak i systemowi modułów każda mapa może stworzyć unikalną, niepowtarzalną mini-grę. Gry Napisałem już w pełni działający Destroy The Core. Zadaniem Twojej drużyny jest zniszczenie rdzenia drużyny przeciwnej, przy czym musisz chronić także swój. Przeciwnik ma identyczne zadanie. Rdzeń to najczęściej kula z obsidianu zalana w środku lawą. Aby wygrać, lawa musi wylać się poza rdzeń ilość bloków zdefiniowaną w konfiguracji mapy. Drużyna do której rdzeń należy może oczywiście wyciek lawy zatamować. Może zablokować go wstawieniem z powrotem bloku w miejsce wycieku. To wszystko tworzy niesamowitą rozgrywkę walki dwóch (lub więcej) drużyn. Przykładowa konfiguracja dwóch rdzeni - jeden należy do blue-team, drugi do red-team. Wygrana nastąpi po wycieku lawy 8 bloków poniżej rdzenia. Oba rdzenie nazywają się "Core". Materiał rdzenia nie jest podany, oznacza to, że będzie to obsidian. Typ cieczy nie jest podany, oznacza to, że plugin sam wykryje co znajduje się w jego wnętrzu - akceptowane ciecze (lawa i woda). <leak> <leakable id="blue-core" name="Core" owner="blue-team" detector-level="8"> <region> <cuboid min-x="11" min-y="26" min-z="-53" max-x="17" max-y="32" max-z="-47" /> </region> </leakable> <leakable id="red-core" name="Core" owner="red-team" detector-level="8"> <region> <cuboid min-x="-16" min-y="26" min-z="48" max-x="-10" max-y="32" max-z="54" /> </region> </leakable> </leak> Napisałem już także Deathmatch, z czego na razie działa Team-deathmatch, z tego względu, że napisałem na razie jedynie moduł na drużyny jako format meczu. Deathmatch oparty jest o punkty. Punkty zdobywa się za zabicie. <score> <kills>1</kills> <!-- Za zabicie otrzymuje się 1 punkt --> <limit>250</limit> <!-- Wygrana po zdobyciu 250 punktów --> </score> Następne gry jakie chciałbym zaimplementować to między innymi Destroy The Monument. XML... użyj lepiej YAMLa... YAML jest świetnym systemem zapisu, ale ma spore ograniczenia. XML jest łatwo rozbudowywalny poprzez skoncentrowanie całej struktury na elementach. Dodatkowo w XML można upchać znacznie więcej informacji, niż w YAML. YAML do potrzeb jakie stawia sobie Arcade jest po prostu niewystarczający... Dlatego zdecydowałem się na XML. Potem opisze jeszcze system regionów i filtrów. Na razie mi się nie chce Pozdrawiam A tak szczerze to wątpię, że ktoś to całe przeczytał. Pobierz: Aktualnie plugin jest we wczesnej wersji deweloperskiej. W związku z tym nie chce dawać pobierania, bo po prostu się do normalnego uruchomienia nie nadaje, a ja jeszcze nie chce się bawić w wersjonizację na tym etapie rozwoju. Kod źródłowy: https://github.com/ShootGame/Arcade2

Siema, patrząc na społeczność Minecraft jaka jest na Polskich serwerach postanowiłem upublicznić mój dotychczas największy projekt open-source. Plugin Arcade to (prawdopodobnie) największy plugin Bukkit jaki kiedykolwiek powstał na Polskiej scenie Minecraft. Na sam projekt całych mini-gier składa się tak na prawdę kilka repozytoriów. Commons - główna biblioteka całego projektu. Zawiera metody, które są używane w każdym innym pluginie, itd. Obsługa multi-serwerów, tabliczki, pakiety, baza danych, komendy, multi-języczność, itd. ShootBungee - plugin do BungeeCorda. Zawiera w pełni edytowalne MOTD (niedokończone), informację o serwerach po najechaniu na ping na liście serwera. Komendę /lobby ShootGame - główny plugin Bukkit. Zawiera prymitywny anty-logout i komendy do przechodzenia na różne serwery. Translations - tłumaczenia serwera na różne języki. Open-source od zawsze z tego wględu, że każdy mógł tłumaczyć serwer. Plugin Arcade jest nie-tłumaczalny z powodu, że dodałem to później i nie chciało mi się wszystkich stringów podmieniać. Permissions - plugin od uprawnień dla Arcade. Jest wiele pluginów od uprawnień, ale nie było takiego, żeby był dostosowany pod drużyny oraz obserwatorów - napisałem więc swój. Arcade - no i oczywiście najważniejszy plugin. Mini-gry. Dlaczego taki duży? własne API - łatwa implementacja na inne silniki (Sponge/Diorite/itd), moduły dzięki którym każda mapa mini-gry możebyć w zupełności unikalna. Krótko twórca mapy może tak na prawdę tworzyć swoje własne mini-gry Główne API, implementacja API dla serwera Bukkit, moduły i debugger stworzony, aby API włączyć w czystej Javie. Wszystkie projekty znajdują się na GitHubie -> https://github.com/ShootGame