Jakim

Ja planuję i tak własny system komunikatów, więc to, co podałeś, to na bank będzie (zapisywanie do .log) :D. Dzięki za komentarze.

Opis komend też na końcu będę musiał poprawić :). Dzięki za spostrzeżenie, wrzuciłem fix'niętą wersję.

Zmieniałem nazwę funkcji przed uploadem, iteratorów nie poprawiłem - powinny mieć indeks skryptu, w którym się znajdują. Już wrzucam poprawkę. A tak przy okazji iteratorów: przez tę strukturę zagnieżdżanie funkcji skończy się (ba, nie skończy się) nieprzerwaną pętlą. Jeżeli chcesz zagnieżdżać - to znaczy, że coś robisz już źle w momencie planowania.

Generator pól do Farmer Frana? :D Nie ma bata, trzeba zrobić demo z tego.

W sumie jest rzecz, z którą można by mi pomóc, mianowicie edytory ITM/CRE/CHR/STR/itd. Chciałbym, żeby dla oszczędności miejsca i pamięci były napisane w C++/C#, niestety nie mam narzędzi/bibliotek, by to sporządzić tak, żeby działało również na nowszych systemach. To są proste programiki, relatywnie szybko się je pisze. Na przykład walidacja STR to dosyć przyjemna rzecz, mogę opisać cały algorytm sprawdzania poprawności pliku.

Mam wrażenie, że pisząc fusion, w głowie kręci się styl konkretnego zespołu - mówimy o pewnym nurcie; nurt nie ma jasno określonych granic. Positive Infinity podpada pod określenie "połączenie jazzu i rocka" w pełni. Chyba że coś mi umknęło.

Biliński, a potem Leningrad! :thumbsup: I tak nikogo to nie obchodzi, ale porcja świetnego, żywego fusion z cziptunami! Positive Infinity - Serket PS Zrzuty YT są denerwujące, zwykłe linki są lepsze.

Z przyjemnością, ale muszę trzymać się własnych priorytetów, bo za łatwo zbaczam z własnych torów ;).

No i cóżeś uczynił. Teraz będę nocami olewał moje obowiązki i szukał optymalnych stałych dla tego skryptu, dla którego wariancja jest największa przy stałej gęstości na stałą jednostkę obszaru :/. A tak na serio: bez zaglądania do skryptu propsy. PS Proste lokalne transformacje izometryczne pozwalają uniknąć efektu linearyzacji.

Zapraszam tu, może znajdziesz pomysły dla siebie (Game Maker): https://forum.gmclan.org/index.php?showtopic=30458 Pozdrawiam!

Tytuł: RPG Structure System Opis: niżej. W skrócie: rozbudowany system organizacji danych dla gry RPG (i nie tylko!). Wersja: 0.5 Download: https://gmclan.org/up506_4_RPG_Structure_System.html Rozmiar pliku: 96 KB Autor: Jakim Wersja GM: Game Maker 8.1 Szczegółowy opis: Oto kompleksowy system plików, który pozwoli stworzyć postacie, dialogi, przedmioty czy plansze w sposób spójny i zorganizowany. Kluczowym elementem tej struktury jest elastyczność - to od dalszego kodowania zależy jedynie, jak bardzo gra na bazie tej struktury będzie dała się modyfikować i ulepszać z zewnętrznego poziomu. Struktura plików: System obsługuje następujące typy plików: .STR (string: łańcuchy znaków) Główny plik zawierający wszystkie używane przez grę łańcuchy znaków - elementy menu, kwestie dialogowe, komunikaty i tak dalej. Wszystkie nazwy poza własnymi, jak np. postaci, będą uchowane właśnie tu. To rozwiązanie jest szczególnie przydatne, gdy zamierzamy tłumaczyć naszą grę/edytować nazwy istniejącej już gry bez przeszukiwania silnika czy też samych plików istot. Warto pamiętać, że w grze pozostają jedynie informacje o id tekstu, do którego się dany obiekt odnosi. Za każdym razem w miejscu creature_name czy item_name wartością jest INTEGER, nie STRING. Dodatkowo, warto posługiwać się stałymi referencjami do odpowiednich kwestii - ułatwia to pracę. W tym celu stworzony został plik refs.cns. W przyszłości tekst, o określonym charakterze, będzie można połaczyć z dźwiękiem; za każdym razem, gdy się pojawi w określonym przez typ kontekście, zostanie wydana komenda odtworzenia dźwięku. Z racji tego, iż radzę unikać wbudowanego systemu obsługi dźwięków, wprowadziłem komendę wav_play. Kwestie zawarte w STR mogą zawierać znaczniki typu [CHARNAME] czy [HP], które automatycznie będą zamieniane na inny tekst/wartość odpowiedniej zmiennej (przez variable_global_? Nie wiem jeszcze). Planuję dodać również inicjowanie globalnych akcji z tego poziomu. .ITM (items: przedmioty) Wszystko, co powinniśmy wiedzieć o przedmiocie, powinno być tu zapisane, a więc atak, czy bonusy wynikające z noszenia/atakowania danym przedmiotem. Możemy ustalić liczbę dodatkowych parametrów i wprowadzić specjalne efekty broni. Podobnie jak typ powyżej, struktura zostanie omówiona szerzej w detalach technicznych. .ARE (areas: lokacje) Mapa lokacji. Teren o ustalonych wymiarach składa się z trzech warstw - pierwsza odpowiada za kolor, druga za literkę obiektu (na potrzeby roguelike'a), a trzecia symbolizuje, czy obiekt stanowi przeszkodę czy nie. Po wypełnieniu informacji o całej lokacji, na końcu ładowane są obiekty specjalne: spawnpointy, NPC czy aktywatory odpowiadające za przenoszenie do innego obszaru. .CHR (characters: postacie) Upgrade'owany CRE o status gry, a więc informacje wynikające z prowadzenia fabuły, niepotrzebne "zwykłym" postaciom niezależnym. .STO (stores: sklepy) Plik zawierający listę sprzedawanych przedmiotów. Polecam obejrzeć sto_save/sto_load, by zobaczyć strukturę pliku. W przyszłości dodam informację o przelicznikach cen oraz wpływie reputacji na cenę. .TBL (tables: tabele) Tu znajdują się tabele. Ich głównym celem jest łączenie zasobów z wybranym przez nas identyfikatorem (głównie na potrzeby edytorów aniżeli samej gry); w przyszłości również tabele doświadczeń na następne poziomy, liczby możliwych zaklęć w zależności od poziomu - ogólnie wszystko, co da się zapisać w formie prostej tabeli. Poniżej przedstawiono struktury, których wprowadzenie jest dopiero w planach lub nie jest możliwe bez silnika samej gry. .SPL (spells: czary) Ta opcja, mimo iż kluczowa dla wielu RPG, pozostaja na razie pusta - z racji tego, jak różnie można podejść do tej kwestii przy pisaniu własnego silnika; nie chcę narzucać żadnych odgórnych rozwiązań. Tym niemniej postaram się niedługo zamieścić przykład użycia. .DLG (dialogs: dialogi) System dialogów połączony z triggerami i akcjami, a więc inicjowaniem cutscenek, zdarzeń gry czy zmiany statusu gry. Oczywiście, pliki .dlg nie zawierają informacji o wypowiedzianych kwestiach, odnoszą się do pliku .str. Na razie jednak triggery i akcje muszę zostawić niezaimplementowane, gdyż silnie zależą od niezależnego od struktury systemu gry. .ACT (actions: akcje) Pliki akcji, czyli ewentualne oskryptowanie wszystkiego, co się rusza w świecie gry, rzucam jedynie jako sugestię. Zaletą tego rozwiązania jest tworzenie świata gry spoza, co jest właściwie głównym celem tego silnika. Bez tego feature'a jakiekolwiek modyfikowanie gry z zewnątrz będzie ograniczone, a czasami nawet niemożliwe. Wadą - spowolniona komunikacja między graczem a silnikiem gry. Tym niemniej zalecam korzystać z tego typu plików, chociażby dla zachowania spójności silnika. WAV i PNG nie wymagają tłumaczenia. To drugie będzie jedynie źródłem grafik do zaimportowania przez Game Makera. Parę technicznych komunikatów. Główne pliki (ITM/CRE/ARE...) mają poniższą strukturę: 1. Nagłówek 2. Podstawowe parametry 3. Listowane dodatkowe elementy O ile kwestia nagłówka jest jasna (na razie nie jest nam potrzebne nic więcej poza typem pliku), o tyle wyjaśnienia może wymagać dalsza część. Wygodnie będzie posłużyć się screenem: Nagłówek i podstawowe parametry mają stały rozmiar, dalsza część zależy od ilości dodatkowych elementów, które są naliczane w ostatnim bajcie drugiej sekcji - ten ostatni bajt zawiera informację o ilości podstruktur niższego rzędu o stałej wielkości, wyznaczoną przez xxx_secondary_size oraz poszczególne wielkości elementów size_xxx_. Kluczową rolę odgrywają dodane stałe. Przy każdej modyfikacji liczby i własności czy to przedmiotów, postaci czy obszarów, gra się nie wysypie - bo o to głównie chodzi - by móc tworzyć RPG bez obawy, że trzeba będzie przerabiać pół gry, by wprowadzić dodatkowy współczynnik istot lub usunąć nieprzydatną. Kopia wprowadzonych stałych znajduje się w pliku engine.cns i, o ile wcześniej nie napiszemy własnego edytora do gry, z poziomu tego pliku modyfikujemy najistotniejsze dla silnika rzeczy. Nieco inaczej wygląda struktura plików STR, która bardziej przypomina tablicę alokacji. 1. Nagłówek 2. Licznik kwestii 3. Offsety i długości kwestii 4. Tekst Pon nagłówku występuje licznik (3 bity są zarezerwowane na wszelki wypadek, 2 jeszcze można przekroczyć) wszystkich elementów. Dalej, dla każdego elementu znajduje się jego absolutna pozycja i długość (z technicznego punktu widzenia można byłoby operować samą długością wejść, jednakże proszę sobie wyobrazić odczytywanie ostatnich stringów - byłoby to niewspółmiernie obciążające przy dużych plikach) elementu. Na końcu pozostaje umieścić sam tekst. Jak widać, silnik jest mocno inspirowany Infinity Engine - moim skromnym zdaniem jest to pewien wzór do naśladowania. Nie jest on optymalny - np. brakuje narzędzia, które przydzielałoby określone miejsce zmiennej w pamięci gry (wszak wszystkie zmienne użyte w grze są z ustalonego zakresu, który co prawda można podnieść/obniżyć), co, chociaż można byłoby naprawić z użyciem odpowiedniej biblioteki, na razie zarzucam. Również kusiłoby wykorzystanie metod do powtarzających się fragmentów kodu - to jest jednak poza zasięgiem Game Makera. Przy tak wielu niezaimplementowanych rzeczach, można byłoby spytać, czemu publikuję już w tym momencie. Odpowiedź jest prozaiczna: umieszczam ten szkielet struktury już w tym momencie, ponieważ im szybciej zauważycie jakieś błędy bądź nieprzemyślenia silnika, tym łatwiej będzie je wyeliminować. Poza tym przy ciągłym supporcie mogę dostosowywać silnik do waszych potrzeb i wprowadzać rozwiązania, na które sam nie wpadłem. Podstawowe skrypty: xxx_save/xxx_load zapisuje do/ładuje z pamięci podręcznej informacje o przedmiocie/postaci/lokacji. strings_get_ pobiera wartość z zadanego pliku tekstowego STR. Ścieżki do plików uzyskuje się za pomocą komend file_path_. Dodatkowe skrypty: Zawarłem kilka dodatkowych, technicznych skryptów do obsługi plików binarnych, np. - file_bin_copy_string(file,start,length) - kopiuje łańcuch znaków z pliku binarnego, - file_bin_copy_value(file,start,length) - jak wyżej, tyle że wartość o ustalonej długości, - file_bin_read_value(file,length) - odczytuje wartość o ustalonej długości (bez zmiany pozycji pliku), - file_bin_write_chain(file,value,length) - zapisuje łańcuch bajtów na podstawie zadanej wartości, - file_bin_write_string(file,position,string) - zapisuje ciąg znaków, - decompose(value,index) - wyciąga odpowiedni bajt z n-bitowej wartości. Posługuję się cienkokońcowym (little endian) sposobem zapisem informacji, według mnie jest to naturalna i przystępna droga kodowania danych. Co będzie w przyszłości? - rzeczy wymienione, aczkolwiek niezaimplementowane jeszcze, - edytor CRE/ARE/ITM/TBL (napisany raczej już nie w GM) i, jeżeli się uda, kompleksowy edytor i walidator całego świata, - silnik błędów i komunikatów, - kilka przykładowych tagów i kwestii połączonych z dźwiękiem w pliku STR, - przykład nieużywanych jeszcze elementów SPL (czary), - przykładowa gierka RPG wykorzystująca cały system, wliczając osobny, prosty system skryptowania oraz zapis do SAV, - automatyczne tworzenie pliku TBL na podstawie katalogów ITM/CRE, - pakowanie i zabezpieczanie danych przed edycją, - szczegółowy help. Jaki jest cel tego silnika? Może zamiast odpowiedzieć, rzucę pytanie, które zawiera esencję tego, czego oczekiwałbym po dobrym, niestarzejącym się RPG: - Czy jako gracz mogę stworzyć swój własny świat i własną historię na podstawie tej gry, jeżeli tylko dostanę odpowiednie narzędzia? Oczywiście, nie musisz dążyć do tego podczas robienia swojej gry RPG (a może i nie tylko RPG?). Drugi powód jest jeszcze prostszy - zamierzam kiedyś skończyć roguelike ;).

A ja właśnie piszę system struktury plików a'la Infinity Engine (a właściwie całego szieletu engine'u gry) i dzisiaj chciałem opublikować, troszkę (niezamierzenie) konkurencyjnie wyjdzie :(. Bardzo liczę na chociażby grywalne demko, przepadam za tego typu produkcjami. PS TĘ klasę. Konsekwentnie trzymałbym się albo braku polskich znaków diakrytycznych, albo pozostaniu przy ogonkach.

Może wszedł na ten etap, gdzie trolling staje się sztuką, życiowym performancem - z tej sytuacji nie ma już odwrotu :D.

:crying: Do zapamiętania: po linii najmniejszego oporu. Anyway, jeszcze poprawić przecinek przed by, bo, wyprowadzenie nowego zdania przy nie daj się złapać i będzie świetnie. Swoją drogą, gdybyś nie dał tego tekstu: to nie myślałbym, że wszystko jest już zauważone i tylko czeka do poprawki ;). Yup, bałem się jedynie, że zapomnę wspomnieć ANtEmu, że nonszalancko wszystko zbywa ironicznym tonem ;).

ANtYku drogi, jeżeli już kwestionujesz jakieś rozwiązania, warto podawać zdawkowe chociażby uzasadnienia. Na forum pełno Twoich kontestacji, nomen omen; cóż po nich, jeżeli niczego wartościowego nie wnoszą. To bardziej rada na przyszłość, aniżeli sugestia co do tej konkretnej wypowiedzi.

Tym niemniej każdy* raz w życiu** powinien spróbować sobie taki silnik sprawić i postarać wykorzystać. * - każdy zainteresowany ** - w odpowiednim dla siebie etapie życia

Nie znam się na C#, ale warto uprzednio ustalić, czy Twój program: - posiada pętlę główną, - kończy się wraz z wykonaniem ostatniego polecenia. Jeżeli to drugie, na alarmy nie ma co liczyć, możesz co najwyżej bawić się datą systemową.

To niechybnie Grażyna Żarko polskiego gamedevu. Innej opcji nie widzę.

Bardzo sympatyczne :).

Ruchy nie są płynne, co najwyżej postać slizga się jak po lodowisku, a nie pływa. Poza tym odczuwam wysoki dysonans między rzeczywistym celem gry a fabularnym celem tejże rozgrywki. Fabuła sobie, gra sobie.

To w niczym nie pomoże. Debuguj zmienne 'room1' i 'room2' i sprawdź, jakie mają identyfikatory. Spróbuj z poziomu debuggera przełąć między poziomami i daj znać, co z tego wywnioskowałeś. Póki co wygląda właśnie na konfilkt nazw zmiennych.

Czy wspominałem już, że jest wprowadzony i działający system achievementów? Na obecną chwilę jest ich 70, w sumie będzie ze 100.

Masz Hitlera w barze ;o.

Instrumenty bez artykulacji, ale wszystko jest ładne i schludne. Estetyka to chyba największa zaleta tych utworów. Reasumując: dobre, chociaż Last Stand kompozycyjnie nie dorównuje brzmieniu.

Offtop acz pilny: Podwawelska, opróżnij skrzynkę.