atarionline.pl Adventure Studio (demo) - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorilmenit
    • CommentTime21 Jan 2010
     
    Hej,

    Sporo osób się dopominało o narzędzie do robienia przygodówek. No to zrobiłem :)
    Na razie dostępne jako demo, ale wkrótce udostępnię wraz ze źródłami i instrukcją używania.
    Wersja pełna będzie wymagała sporo pracy, ale mam nadzieję, że znajdą się chętni do pomocy.
    Kompilacja dla Windows wymaga biblioteki alleg42.dll (nie wrzucałem tu dla zmniejszenia zipa).
    • 2: CommentAuthordhor
    • CommentTime22 Jan 2010
     
    G-E-N-I-A-L-N-E!!

    No to teraz graficy będą się mogli wykazać :)
    • 3:
       
      CommentAuthorripek
    • CommentTime22 Jan 2010
     
    rewelacja !
    no to robimy compo na najlepszą grę ;)
    • 4:
       
      CommentAuthorFly
    • CommentTime22 Jan 2010 zmieniony
     
    In Win7 64-bit me says that miss ALLEG42.DLL

    :-(
    • 5: CommentAuthorPiesiu
    • CommentTime22 Jan 2010
     
    WOW! Fantastyczna sprawa, niestety w pracy mam Win98 :P, a biblioteka alleg42.dll z takim zabytkiem nie chce gadać, więc zapoznam się ASd dopiero po powrocie do domciu, ale już na podstawie dołączonego "Lure of the Temptress" widać, że program daje rade. BRAWO!!!
    • 6: CommentAuthorilmenit
    • CommentTime22 Jan 2010 zmieniony
     
    Fajnie, że się podoba. Motywuje to do pracy :)
    Od razu mówię, że nie jest to narzędzie typu RAD, ale zbiór "obiektowego" API do tworzenia przygodówek wraz z prostym managerem pamięci dla obsługi obrazków. Jest też narzędzie do wycinania grafiki z plików MIC/COL.
    Kto wie, może z czasem doczeka się generatorów kodu (do udostępnionej wersji postaram się taki generator zrobić przynajmniej do definiowania obrazków, bo aktualnie ich rozmiary trzeba wpisywać z palca).

    Nie wiem, czy nie ten program to nie jest strzelanie do własnej bramki, bo graficy mogą stracić zainteresowanie innymi projektami ;)
    • 7:
       
      CommentAuthorxeen
    • CommentTime22 Jan 2010
     
    sprawdzę niestety dopiero w domciu, co bardzo mnie męczy :)

    jeżeli da się wydzielić api ogólne dla średnio poziomowych (w sensie języka programowania :D) programistów (zarządzeni obrazkami, może jakiś mini engine do duszków, jakieś inne dodatki) to będzie juz absolutna rewelacja (biblioteka ilmenit.h? :D)
    • 8: CommentAuthorirwin
    • CommentTime22 Jan 2010
     
    Ilmenit - świetna robota!!!
    U mnie co prawda program się wywala ale pewnie to wina mojego pc który zawsze sprawia problemy.
    Graficy są stęsknieni takich narzędzi, nawet nasz grafik nr 1 ;) (wiadomo kto) zainteresował się tematem.

    Póki co mam taki komunikat (dll oczywiście sciągnąłem)
    • 9: CommentAuthorPiesiu
    • CommentTime22 Jan 2010 zmieniony
     
    Niestety u mnie na XP pojawia się ten sam błąd co u Irwina
    (Aplikacja nie została właściwie zainicjowana 0xc0150002).
    System XP SP2, biblioteka alleg42.dll w wersji 4.2.2.0.
    • 10: CommentAuthorilmenit
    • CommentTime22 Jan 2010
     
    Postaram się jeszcze dzisiaj podesłać wersję działającą + opis tworzenia gier.
    Udało się Wam przejść przykładową grę? :)
    • 11:
       
      CommentAuthorxeen
    • CommentTime22 Jan 2010
     
    no sprawdziłem sobie - pozytywny szok!
    • 12: CommentAuthorPiesiu
    • CommentTime22 Jan 2010
     
    Ilmenit - no gra ukończona, okazało się że Commodorowiec też człowiek i piwo lubi :).
    • 13:
       
      CommentAuthorDracon
    • CommentTime22 Jan 2010
     
    Brawo. Robi wrazenie.
    Jeszcze troche rozwoju programu (rok-dwa-trzy?) i moze doczekamy sie produkcji typu ELVIRA, ze wskaznikami wytrzymalosci itp. bohatera, a moze i walka? ;o
    • 14: CommentAuthorirwin
    • CommentTime22 Jan 2010 zmieniony
     
    Ja też pograłem i stwierdzam:
    Że dzisiejszego dnia pożegnaliśmy epokę tekstówek na Atari.
    Nastał czas panowania Point&Click ;)

    Ilmenit B R A W O !!!

    ps.przeszedłem całość, świetne, inventory rozwiązane znakomicie no i te teksty "We have NUFLI graphics" ;)
    Najlepsza gierka na Atari od lat! (jak dla mnie oczywiście, jestem maniakiem przygodówek)
    • 15: CommentAuthorGonzo
    • CommentTime22 Jan 2010
     
    Powiem tak... O ja p......! , nic lepszego nie przychodzi mi na myśl. Jakoś nigdy nie przepadałem zbytnio za tego typu grami, ale w takim wydaniu to sam miód. Grafika zrobiona Quantizatorem ma w sobie coś szczególnego, nie wiem co, ale przyciąga i tworzy klimat, tak samo jak rozmowa z prisoner'em, mogę z nim gadać i gadać :) Jak dla mnie to najwyższy poziom w tej kategorii gier.
    • 16: CommentAuthorilmenit
    • CommentTime22 Jan 2010
     
    Nie wiem jak będę stał z czasem w weekend, więc załączam framework w aktualnej postaci.
    W doc\readme.txt jest instrukcja jak używać.

    Jest to pierwsza publiczna wersja (przygotowana trochę na szybko) i tak naprawdę i instrukcję i sam framework będzie trzeba rozwijać/poprawiać gdy ktoś zdecyduje się coś w nim zrobić.

    Oczywiście służę pomocą :)

    Zachęcam do popróbowania i czekam na komentarze.
    • 17:
       
      CommentAuthorDracon
    • CommentTime22 Jan 2010
     
    Ilmenit na prezydenta! :)
    Przynajmniej nie da do konca zginac Atari 8-bit.
    • 18: CommentAuthorurborg
    • CommentTime22 Jan 2010
     
    Genialny program, ten framework jest sam w sobie ciekawą przygodówką. Aż korci żeby samemu coś stworzyć :). Tego co mi brakuje to możliwości prowadzenia dialogów z wyborem jednej z kilku opcji, choć może dałoby się to jakoś obejść. Ciekawy zaś jestem jak wyglądają kwestie pamięciowe? Ile to demko zajmuje pamięci? Mamy tutaj 3 lokacje i obawiam się, że dużo więcej nie da się już do podstawowej pamięci wcisnąć. Choć może się mylę.
    • 19:
       
      CommentAuthorxeen
    • CommentTime22 Jan 2010
     
    nowa jakość
    i tyle
    • 20: CommentAuthormono
    • CommentTime22 Jan 2010
     
    Świetny projekt!
    • 21: CommentAuthorirwin
    • CommentTime23 Jan 2010 zmieniony
     
    No cóż ja raczej programistą nie będę, Visual C++ nie zamierzam instalować (z wielu przyczyń, głównie sprzętowych), sam "program"? "api"? wydają mi się czarną magią...
    Tym niemniej podstawą dobrej przygodówki jest grafika i to jej zrobienie/namalowanie zajmuje mnóstwo czasu. Do tej pory nie było sensu nawet zaczynać - teraz gdy widze w działaniu twój engine, inventory, sposób wydawania komend, point&click to wiem że można zrobić przygodówkę w stylu bardziej przypominających te z platform 16bit niż C64. Tak więc nie wykluczam że zaczne malować i pisać scenariusz a o poskładanie tego w całość poproszę kogoś kto będzie wiedział o co się w tym co przygotowałeś rozchodzi. Bo póki co, jak sam zreszta piszesz osoba nie mająca styku z "C" nie da sobie z tym rady. AGS o którym wspominałem czy taki jeszcze prostszy w użyciu program:
    ->link<-

    Tutaj od 4 minuty
    ->link<-

    to niestety nie jest.
  1.  
    Ja rozumiem ze kazdy screen jest ladowany osobno z dysku?

    Potestuje w weekend co dam rade zrobic - podziele sie pod koniec.

    Ilmenit: Gratulacje! O to mi chodzilo gdy mowilem o prostym mechanizmie na poczatek.
    • 23: CommentAuthorpavros
    • CommentTime23 Jan 2010
     
    Ilmenit: To jest niesamowite! Brawo! Musisz koniecznie rozwijać ten projekt. Byłoby super, gdyby w takiej grze jak demonstrowana Lure of the Temptress można dodać animowane postaci i przedmioty.
  2.  
    Rozpakowalem plik 0001 i czuje sie jak uwsteczniony... zupelnie nie rozumiem...
    • 25:
       
      CommentAuthorKaz
    • CommentTime23 Jan 2010
     
    Systemik rewelacyjny, zasluguje na prawdziwy test w praktyce w postaci... kolejnej gierki! :D
    • 26: CommentAuthorilmenit
    • CommentTime25 Jan 2010
     
    Poczytałem Wasze komentarze i rzeczywiście na początek całość może wydawać się skomplikowana...
    Framework przygotowałem dla Was, więc aby się nie zmarnował, posiedziałem przez weekend i przygotowałem tutorial.
    Mam nadzieję, że pokazuje, że tworzenie gry jest naprawdę proste. Z kursu dowiesz się jak:
    - przygotować grafikę do gry
    - ustawić środowisko kompilacji (niezbędne jest jedynie CC65, ale Visual Studio ułatwia pracę, bo można kompilować wersję pod Windows, którą wygodnie się debuguje)
    - zdefiniować pomieszczenie i wyświetlić obrazek
    - tworzyć obszary i przypisać im akcje
    - zarządzać właściwościami obiektów
    - obsługiwać inwentarz i inne kontenery

    Uporządkowałem trochę kod i całość kursu jest przeznaczona dla najnowszej, załączonej wersji.

    Ponieważ nie udaje mi się dołączyć załącznika do posta, wrzuciłem tutaj: ->link<-

    Zachęcam do popróbowania i czekam na komentarze.
    • 27:
       
      CommentAuthorKaz
    • CommentTime25 Jan 2010
     

    Ilmenit:

    1. Przygotowanie środowiska do pracy
    1.1 Kompilator CC65
    1.2 Microsoft Visual C++
    2. Przykładowa gra
    3. Katalogi i pliki
    4. Terminologia
    5. Jak tworzyć grę
    5.1 Wstęp
    5.2 Budowa gry
    5.3 Pomieszczenia
    5.4 Obiekty i obszary
    5.4.1 Obszary
    5.4.2 Obiekty
    5.4.3 Referencje
    5.5. Akcje
    5.6. Kontenery
    5.7. Obrazki i palety
    6. Pamięć
    6.1 Manager pamięci
    6.2 Sprawdzanie ilości dostepnej pamięci
    7. Typy podstawowe i stałe
    8. API
    9. Narzędzia
    10.1 gfx_slicer


    1. Przygotowanie środowiska do pracy
    1.1 Kompilator CC65

    Środowiska opiera się na kompilatorze CC65.
    Podczas pisania tego tekstu aktualna wersja kompilatora to cc65-2.13.1-1
    Najprościej przygotować środowisko instalując je z pliku cc65-2.13.1-1.exe z domyślnymi opcjami instalacji (dodanie oczekiwanych przez kompilator zmiennych środowiskowych CC65_INC i CC65_LIB).

    Nowe wersje kompilatora są tworzone z uwzględnieniem wstecznej kompatybilności, ale zmianie często ulegają pliki konfiguracyjne dla platform.
    W przypadku problemów kompilacji w nowszych wersjach związanych z błędami w pliku CFG należy wykonać polecenie "ld65 --dump-config atari" i zobaczyć jakie są różnice w pliku CFG używanym przez Ciebie i oczekiwanym przez kompilator.

    1.2 Microsoft Visual C++

    Używanym przeze mnie IDE jest MS Visual Studio 2005 i dla tego środowiska przygotowany jest plik projektu. Środowisko to nie jest wymagane, ale ułatwia pracę i kompilację.
    Do kompilacji pod Windows potrzebna jest biblioteka graficzna Allegro. Wykorzystywana wersja to 4.2.
    Mam nadzieję, że chętni przygotują pliki projektów dla innych środowisk i systemów.

    2. Przykładowa gra

    Gra kompilowana przez framework znajduje się w katalogu "game".
    W tym katalogu domyślnie znajduje się przykładowa gra. Jeżeli chcesz zacząć pracę nad nową grą, to podmień go katalogiem "empty", który zawiera "minimalną grę" zawierającą jedno puste pomieszczenie.
    W przykładową grę warto zagrać i ją zachować, żeby przy tworzeniu własnej zobaczyć jak coś zostało zrobione.

    Przykładowa gra pokazuje jak:
    1. Definiować pokoje i przypisane im obszary
    2. Definiować obiekty i przypisane im akcje
    3. Zarządzać logiką akcji
    4. Tworzyć referencje na obiekty (tu: drzwi celi)
    5. Zarządzać kontenerami (tu: beczka, inwentarz)
    6. Używać obiektów na innych obiektach
    7. Obsługiwać grafikę
    8. Obsługiwać dźwięki i muzykę
    9. Obsługiwać kursor

    3. Katalogi i pliki

    W "engine" jest silnik gry, czyli pliki, których nie trzeba zmieniać przy projektowaniu gry.
    W "game" jest definicja struktury gry, czyli dokładnie to, co musisz edytować.
    Plikiem kompilującym jest "atari.bat", który jest wołany przez środowisko kompilacji, zaś plik wynikowy to "adventure.atr", czyli obraz dyskietki dla Atari.
    Opis pozostałych katalogów i plików:
    "build" - zawiera pliki potrzebne do budowy pliku ATR
    "debug" - tu generowane są pliki tymczasowe i wynikowe dla kompilacji pod Windows.
    "doc" - opis i schemat frameworku
    "tools" - narzędzia przydatne przy tworzeniu gry np. narzędzie do wycinania kawałków grafiki.
    "laoo.act" to domyślna paleta Atari używana przez kompilację dla Windows.

    4. Terminologia

    pomieszczenie (room) - pomieszczenie/scena/ekran gry.
    obszar (area) - miejsce w pomieszczeniu, które można wybrać kursorem.
    obiekt (object) - obiekt w grze. Każdy obszar jest automatycznie obiektem. Na obiekcie można wykonywać akcje.
    akcja (action) - podstawowa procedura, która jest wykonywana na obiekcie.
    kontener (container) - może zawierać w sobie kilka obiektów.
    obrazek (picture) - definicja obrazka, który jest potem wyświetlany
    paleta (palette) - definicja palety, która jest używana w obrazkach
    referencja na obiekt - kilka obszarów może odnosić sie do jednego obiektu. Można w ten sposób definiować różne kształty do wybrania obiektów, albo też wybierać ten sam obiekt z różnych pomieszczeń. W przykładowej grze takim obiektem są drzwi celi.

    Nie są wspierane aktualnie listy dialogowe i może zostaną dodane w przyszłości.

    5. Jak tworzyć grę
    5.1 Wstęp

    Tworzenie gry polega na stworzeniu definicji wszystkich elementów, które są wyszczególnione w sekcji "Terminologia".
    Aktualnie framework umożliwia tworzenie gier z grafiką, ale nic nie stoi na przeszkodzie, by przerobić go na obsługę gier czysto tekstowych.

    Tworzenie gry najlepiej zacząć od jej zaprojektowania (papier i długopis jest niezastąpiony). Gdy mamy rozpisane poszczególne pomieszczenia, przeniesienie ich na komputer będzie prostsze niż robienie tego metodą prób i błędów.

    Poniżej zakładam, że użytkownik zna w stopniu podstawowym język C.

    5.2 Budowa gry

    W katalogu "game" znajdują się pliki implementacji *.c i nagłówkowe *.h.
    Pliki *.h powinny zawierać deklaracje (typy wyliczeniowe i deklaracje akcji) używane w plikach *.c.
    Wszystkie pliki *.h są dołączane do plików *.c za pomocą #include "game/all_definitions.h". Ten plik należy zmodyfikować przy dodawaniu nowych plików *.h, ale dodawanie nowych nie jest potrzebne.

    Grę można tworzyć, testować i debugować na PC, bo funkcje wyświetlające grafikę, wypisujące tekst czy obsługujące kursor mają swoje odpowiedniki napisane z wykorzystaniem przenośnej biblioteki Allegro.
    Wersja na PC wykorzystuje te same elementy graficzne (MIC, DLI), co wersja dla Atari.

    5.3 Pomieszczenia

    Każde pomieszczenie może mieć przypisane kilka obszarów.
    Oprócz obszarów posiada też trzy zdarzenia, którym można przypisać akcje.
    Tymi zdarzeniami są:

    on_room_draw - akcja wywoływana przy wejściu do pomieszczenia lub przerysowywaniu go. W niej można np. narysować otwarte lub zamknięte drzwi po wejściu do pomieszczenia, w zależności od stanu drzwi.
    on_room_enter - akcja wywoływana po on_room_draw
    on_room_exit - akcja wywoływana przy opuszczaniu pomieszczenia

    5.4 Obiekty i obszary

    5.4.1 Obszary

    Obszary są zdefiniowane w pliku game\areas\areas_def.c jako
    {pozycja_x, pozycja_y, szerokość, wysokość}
    Aktualnie pozycję i wielkość obszarów trzeba wpisać ręcznie do tablicy na podstawie kompilacji Windowsowej.

    Każdy obszar ma przypisany obiekt. Jest tak, aby po kliknięciu w obszar pojawiło się menu kontekstowe obiektu.

    5.4.2 Obiekty

    Każdy obiekt jest określony nazwą i przypisanymi mu akcjami, które może wybrać gracz. Mogą one być zmienione dynamicznie podczas gry (np. po rozmowie z więźniem pojawia się opcja dania mu przedmiotu).
    Każdy obiekt posiada również stan, który można ustawić lub sprawdzić za pomocą API. Stan może być albo wartością liczbową z zakresu 0-127, albo flagami bitowymi (np. CLOSED|LOCKED). Podczas definiowania obiektu można ustawić jego początkowy stan.
    Stan obiektu jest liczbą od 0-127, gdyż jeden bit jest przeznaczony na informację, czy przypisany mu obszar jest aktywny, czy nie, co można ustawić i sprawdzić za pomocą API.

    W pliku game/objects/objects_def.c znajdują się definicje obiektów (g_objects).

    UWAGA:::
    Na początku tablicy g_objects znajdują się obiekty, które mają przypisane im obszary, później obiekty, które występują bez obszarów.
    Każdy obszar gry, który można wybrać kursorem ma swój odpowiednik będący obiektem!
    Ponieważ g_areas[i] odpowiada obiektowi g_objects[i], z tego powodu obszary i obiekty muszą być zdefiniowane w tej samej kolejności!
    :::UWAGA

    Otwórz plik przykładowej gry game/areas/areas_def.h
    Jak widzisz, są tam w kolejności wyliczone obiekty, mające swoje obszary.
    To wyliczenie odnosi się zarówno do obiektów w game\objects\objects_def.c jak i obszarów zdefinowanych w game\areas\areas_def.c

    Elementów w g_objects[] może być więcej niż elementów w g_areas[] - te obiekty są na przykład pochowane w kontenerach, a nie stanowią klikalnych obszarów pomieszczeń.

    Obiekty nie posiadające obszarów są wyliczone w game\objects\objects_def.h i numer pierwszego zaczyna się od AREA_LAST_AREA, czyli po obiektach "obszarowych".

    5.4.3 Referencje

    Jak zostało powiedziane wcześniej, każdy obszar ma przypisany obiekt. Jest tak, aby po kliknięciu w obszar pojawiło się menu kontekstowe obiektu.
    Co zrobić w przypadku, gdy jeden obiekt powinien mieć przypisane dwa obszary (lub więcej), aby był na przykład dostęp do tych samych drzwi z kilku pomieszczeń? Do tego zostały stworzone referencje.
    Jeżeli w definicji obiektu jego nazwę ustalimy na TEXT_NONE (inaczej NULL), to stan obiektu (variable) należy ustalić na obiekt, do którego ten obszar w rzeczywistości się odnosi.
    W przykładowej grze referencję na obiekt OBJECT_CELL_DOOR stanowi OBJECT_HALL_CELL_DOOR_REF.

    5.5 Akcje

    Wszystkie akcje są zadeklarowane w game\actions\actions.h i tam należy je dodawać w miarę potrzeby.
    Implementację najwygodniej podzielić według pomieszczeń (*.c), ponieważ akcji może być dużo. Jest to bardziej czytelne i przyspiesza kompilację, ale dodanie kolejnego pomieszczenia wymaga dodania kolejnego pliku do skryptu kompilacji.
    Jeżeli uważacie, że czytelniejsze jest wrzucenie wszystkiego do jednego pliku, to d ajcie znać.

    5.6 Kontenery

    Kontenery umożliwiają przechowywanie w nich obiektów.
    Każdy kontener ma swoją nazwę oraz tablicę obiektów, które ma w środku.
    Przykładowym kontenerem, jest inwentarz gracza.
    Na obiektach w kontenerze można wykonywać akcje.

    Ponieważ kontener zawiera obiekty posiadające reprezentację graficzną, konieczne jest zrobienie mapowania obiektów na obrazki. Służy do tego tablica g_picture_object_mapping w pliku game\pictures\pictures_def.c

    5.7 Obrazki i palety

    Adventure Studio obsługuje pliki MIC i DLI. Pliki MIC są standardowym zrzutem pamięci ekranu w gr. 15. Pliki DLI zawierają informację o kolorach w linii.
    Pliki DLI są generowane przez dołączone narzędzie gfx_slicer.

    Obrazki i palety należy zdefiniować w pliku game\pictures\pictures_def.c, najprościej na podstawie informacji wygenerowanych przez gfx_slicer.
    Jeżeli dla obrazka paleta jest zdefiniowana jako PALETTE_NONE, to nie jest ona zmieniana w liniach przy rysowaniu obrazka.

    6. Pamięć

    Silnik gry ma ~10KB, pamięć ekranu to 8KB.
    Na grę wraz z grafiką i dźwiękiem dostępne jest około 27KB pamięci, co w zależnoci od liczby tekstów pozwala na stworzenie gry mającej nawet kilkanaście pokoi.
    Obrazki wczytywane są do pamięci dynamicznie i zawsze musi być pozostawione co najmniej tyle bajtów wolnej pamięci, ile ma największy obrazek.
    Pamięć "pod ROMem" jest już w części wykorzystywana przez framework (duszki, paleta).

    Wielkość większości tablic jest ustalana dynamicznie podczas definiowania typów wyliczeniowych (XXXX_LAST_xxxx np. ROOM_LAST_ROOM), ale część trzeba ustalić w config.h (MAX_xxxx).
    Nie warto ustalać więcej niż potrzeba, bo zabiera to pamięć.

    W miarę możliwości należy ograniczyć używanie skomplikowanych funkcji języka C np. sprintf, ponieważ ich implementacja zabiera dużo pamięci.

    6.1 Manager pamięci

    W silniku występuje prosty manager pamięci, który zwalnia pamięć najdawniej wczytywanych obrazków i palet.
    Użytkownik nie musi zajmować się wczytywaniem obrazków czy ich palet, bo jest to robione automatycznie według definicji.

    6.2 Sprawdzanie ilości dostepnej pamięci

    Warto co jakiś czas sprawdzać ilość pozostałej pamięci.
    Najprościej dodać globalną tablicę:
    unsigned char mem_test[50000];
    Kompilator powinien wypisać coś w stylu:
    "Memory area overflow in `RAM', segment `BSS' (36847 bytes)""
    Znaczy to, że zostało Ci 50000 - 36847 = 13153 bajtów pamięci na program.

    Poczytaj o kompilatorze CC65, bo jest on specyficzny i ma różne ograniczenia.

    7. Typy podstawowe i stałe

    // Podstawowe
    typedef unsigned char byte;
    typedef unsigned int word;
    typedef unsigned char bool;
    #define true 1
    #define false 0

    // Akcje
    typedef void (*action_function)(void);
    #define ACTION_NONE 0

    // Obszary
    #define AREA_ACTIVE 0
    #define AREA_INACTIVE 0x80
    #define AREA_NONE 0xFF

    // Teksty
    #define TEXT_NONE 0

    // Kontenery
    typedef byte container_id;
    typedef byte container_iterator;
    #define CONTAINER_NONE 0xFF
    #define CONTAINER_ITERATOR_NPOS 0xFF

    // Obiekty
    typedef byte object_id;
    #define OBJECT_NONE 0xFF

    // Obrazki i palety
    typedef byte picture_id;
    typedef byte palette_id;
    #define PICTURE_NONE 0xFF
    #define PALETTE_NONE 0xFF

    // Pomieszczenia
    typedef byte room_id;
    #define ROOM_FIRST 0
    #define ROOM_NONE 0xFF

    8. API

    // Konsola

    void console_wait_for_fire(void);
    void console_clear(void);
    void console_print(unsigned char *s, bool wait);

    // Pomieszczenia

    room_id room_current_get(void);
    void room_current_set(room_id new_room);

    // Obiekty

    byte object_value_get(object_id obj);
    void object_value_set(object_id obj, byte value);
    bool object_flags_check (object_id obj, byte flags);
    void object_flags_set (object_id obj, byte flags);
    void object_flags_zero (object_id obj, byte flags);

    void object_action_replace(object_id obj, action_function old_function, action_function new_function, char *new_name);
    char *object_name_get(object_id obj);
    void object_name_set(object_id obj, char *new_name);

    object_id object_get_through_references(object_id obj);

    // Obszary

    void area_activity_on(object_id ar);
    void area_activity_off(object_id ar);
    bool area_activity_check(object_id ar);

    // Obrazki

    void picture_draw(picture_id pic, byte pos_x, byte pos_y);

    // Obrazki (dodatkowe, nie potrzebne raczej do wolania, bo robi wszystko picture_draw)
    bool picture_load(picture_id pic);
    picture_id picture_get_from_object(object_id obj);
    bool palette_load(palette_id);
    void palette_set(palette_id pal, byte pos_y);
    void palette_zero(byte start_y, byte end_y);
    void palette_generate_dli(void);

    // Akcje
    void action_call(action_function act); // można też wywołać po nazwie

    // Kontenery

    container_iterator container_find(container_id conatainer, object_id to_find);
    object_id container_get(container_id conatainer, container_iterator obj_number);
    object_id container_remove(container_id conatainer, container_iterator to_remove);
    container_iterator container_insert(container_id conatainer, object_id to_add);
    byte container_get_number_of_items(container_id conatainer);
    object_id container_object_move_with_choose(container_id source, container_id destination);
    object_id container_merge(container_id container, object_id to_remove1, object_id to_remove2, object_id new_object);

    9. Odczyt i zapis gry

    Aktualnie nie jest wspierany.

    Jeżeli tworząc grę będziesz wykorzystywał jedynie udostępnione API i nie będziesz definiował dodatkowych zmiennych, a operował na obiektach, to zapis i odczyt można zrobić banalnie zapisując i wczytując tablice definicji gry.

    10. Narzędzia
    10.1 gfx_slicer

    gfx_slicer to narzędzie do wycinania elementów grafiki. Pracuje na plikach MIC i COL, które obsługuje też Graph2Font.
    Ponieważ w tych plikach nie ma zapisanej ich wielkości, to trzeba jako parametry przy uruchomieniu podać szerokość i wysokość obrazka w pikselach. Dla plików MIC i COL wygenerowanych przez Graph2Font jest to 160 i 240.

    Po uruchomieniu obszar obrazka wybieramy lewym klawiszem, zaś prawym zrzucamy go do pliku. Wybieranie działa na siatce 4x1, ponieważ w 1 bajcie kodowane są 4 kolejne piksele.
    gfx_slicer tworzy dla zrzuconych obszarów pliki bmp (podgląd), MIC i DLI.
    Plik DLI to informacja o palecie, która jest wykorzystywana przez Adventure Studio. Paleta DLI jest zapisana w sposób bardziej zwięzły niż COL.

    Wygenerowane pliki graficzne mają nazwę:
    oryginalna_nazwa.pozycja_x,pozycja_y (szerokość, wysokość)
    Jest to przydatne do definiowania obrazków i obszarów.
    • 28: CommentAuthorilmenit
    • CommentTime25 Jan 2010
     
    Obawiam się, że info o nowej wersji ucieknie w natłoku całego readme, więc polecam zajrzeć dwa posty wyżej ;)
    • 29: CommentAuthorirwin
    • CommentTime25 Jan 2010
     
    Przejrzałem tutorial i chylę czoło, świetnie napisany, nawet taki dzięciął jak ja zaczyna coś kojarzyć. Tak więc mimo moich początkowych obaw że to tylko dla profi ;) zamierzam spróbować zrobić własną przygodówkę. Póki co zaczynam malować obrazki, potem będę w to co opisałeś dokładnie się zagłębiał ;)
    Dzięki.
    • 30: CommentAuthorilmenit
    • CommentTime25 Jan 2010
     
    Załączam małą poprawkę w tutorialu, Part4. Jest też w wersji do pobrania z linka powyżej.
    • 31:
       
      CommentAuthorKaz
    • CommentTime7 Feb 2010 zmieniony
     
    Irwin, jezeli szukasz prostszych systemow do tworzenia przygodowek to prosze, znalazlem ciekawy "The Slave". Warto tez wspomniec o "The Story Machine". Nie stworzylem w nich zadnej gry, wiec nie wiem jakie maja wady i zalety, ale pobiezny rzut oka pozwala stwierdzic, ze moze wystarcza na proste przygodowki. Chyba, ze koniecznie ma to byc point'n click.
    • 32: CommentAuthorirwin
    • CommentTime7 Feb 2010
     
    Dzięki za znaleziska, ale gdy ja skończe swoją to wymagać będzie jednak AdventureStudio i to w wersji Directors Cut ;)
    • 33: CommentAuthorilmenit
    • CommentTime8 Feb 2010
     
    Irwin, możesz napisać jakiej funkcjonalności potrzebujesz do swojej przygodówki?
    • 34: CommentAuthorirwin
    • CommentTime8 Feb 2010
     
    4 rzeczy a mianowicie:

    - czasu i zaparcia w malowaniu i obmyślaniu scenariusza
    - czasu i zaparcia w malowaniu i obmyślaniu scenariusza
    - czasu i zaparcia w malowaniu i obmyślaniu scenariusza
    oraz, kiedyś tam hen hen w przyszłości kiedy już będzie jakiś jeden epizod z gry na ukończeniu to wtedy przyda się kontakt z ilmenitem.

    Tak więc póki co nic mi nie brakuje, i narazie nie potrzebuje żadnych zmian.
    • 35: CommentAuthorilmenit
    • CommentTime8 Feb 2010
     
    :)
    • 36: CommentAuthorilmenit
    • CommentTime13 Jul 2010
     
    Polecam przygodówkę na Amstrada CPC "Orion Prime". Kawał świetnej i grywalnej roboty.
    ->link<-
    • 37:
       
      CommentAuthorKaz
    • CommentTime14 Jul 2010
     
    Gra zapowiada sie ciekawie, grales w nia moze?

    Poza tym pytanie: czy wiadomo, jak odebrano gre w srodowisku milosnikow Amstrada? Czy byl duzy popyt na platne wersje? Gra wymaga 128KB i stacji dyskow, wiec automatycznie nierozszerzone Amstrady 464, 472, 664 sie nie kwalifikuja. Czy podnosily sie glosy, tak jak u nas to bywa, ze to juz nie jest Amstrad? ;)
    • 38:
       
      CommentAuthorlarek
    • CommentTime14 Jul 2010
     

    Kaz:

    Czy podnosily sie glosy, tak jak u nas to bywa, ze to juz nie jest Amstrad? ;)

    Nie przesadzaj. Nikt nigdy nie powiedział, że Atari 130XE to już nie Atari... ;)
    • 39:
       
      CommentAuthorKaz
    • CommentTime14 Jul 2010 zmieniony
     
    O, przepraszam! Nie tylko, ze padalo stwierdzenie, ze standard to 64KB (zdaje sie przy "Crownland"), ale podwazano niekiedy i fakt, ze Atari 130XE jest standardowe :D - w sensie: ma rozszerzenie pamieci niezgodne ze standardem scenowym ;D
    • 40:
       
      CommentAuthorlarek
    • CommentTime14 Jul 2010
     
    A, skoro miałeś na myśli standardy scenowe, to ok. ;D
    • 41:
       
      CommentAuthorRastan
    • CommentTime14 Jul 2010
     
    Amstrad 6128 to jak najbardziej Amstrad :) To tak jak Atari 130XE ze stacją dysków. Rozszerzenie pamięci, czy dodatkowa stacja dyskietek nie świadczą o tym, czy to już jest Amstrad lub Atari czy też nie.
    • 42:
       
      CommentAuthorKaz
    • CommentTime14 Jul 2010
     
    Rastan - ale czemu mi tlumaczysz oczywistosci? :)
    • 43:
       
      CommentAuthorDracon
    • CommentTime15 Jul 2010
     
    ...bo komus jeszcze moze sie to przydac (jednemu z milinow czytelnikow maloatarowskich portali) ;P
    • 44:
       
      CommentAuthorjhusak
    • CommentTime8 Apr 2011
     
    @ilmenit, czy projekt idzie do przodu, czy poświęcasz czas na inne projekty?
    • 45: CommentAuthorilmenit
    • CommentTime8 Apr 2011 zmieniony
     
    Ogólnie z czasem u mnie krucho. Mam rozgrzebane dwa projekty a wolniejszej chwili kończyłem Reversi do GUI, które robi flashjazzcat ->link<-

    Ponieważ potrwa pewnie kilka lat nim GUI będzie gotowe, Reversi w aktualnej postaci w załączniku. AI ma ustalane wagi algorytmu oceny planszy algorytmem genetycznym i trzeba by uruchomić uczenie na kilka dni, żeby uzyskać mocnego przeciwnika. Ten z załącznika (wersja dla Atari) uczył się kilka godzin.

    Adventure Studio od ponad roku nie dotykałem - po pierwszych zachwytach i tutorialach, które przygotowałem nikt w PL ani za oceanem nie podjął się użycia frameworka do stworzenia przygodówki.
    • 46:
       
      CommentAuthorxeen
    • CommentTime8 Apr 2011
     
    algorytmy genetyczne, fiu fiu. W czym to było pisane?
    • 47:
       
      CommentAuthorjhusak
    • CommentTime8 Apr 2011
     
    Ze źródełek wynika, że w cc65 i w c++.
    • 48:
       
      CommentAuthorxeen
    • CommentTime8 Apr 2011
     
    tak, po prostu w robocie nie mogę ściągać niektórych plików i sprawdzić, stąd głupie pytanie:) myślałem że w środku nie ma źródeł....
    • 49:
       
      CommentAuthorKaz
    • CommentTime20 Apr 2012
     

    ilmenit:

    Adventure Studio od ponad roku nie dotykałem - po pierwszych zachwytach i tutorialach, które przygotowałem nikt w PL ani za oceanem nie podjął się użycia frameworka do stworzenia przygodówki.


    Spokojnie, wszystko w swoim czasie. Wiedza wsiaka w glebe, ale musi miec czas na wyrosniecie, dojrzewanie, zeby skonczylo sie powstaniem ziarna, nie mowiac juz o chlebie :D
    • 50:
       
      CommentAuthorjhusak
    • CommentTime1 Jun 2012 zmieniony
     

    Kaz:

    prosze, znalazlem ciekawy "The Slave"

    Tutaj pan Gary Francis "źdźiebko" zjechał tę produkcję.
    ->link<-

    The Slave is a dog of a program. The only feature it has is consistency. It is consistently bad! In fact, in my six years in the computer business, this is unquestionably the worst single piece of software that I've ever been unfortunate enough to encounter on ANY computer. It should never have been released. It is obviously a backyard product written by an amateur. It has the worst user interface and the worst human engineering that I've ever encountered and obviously has no regard at all for the end user. I doubt that it's even been tested. In fact, it strikes me as a half-finished product that's still in the experimental stages.