Panowie, miała być dyskusja o grze na Atari, a wyszedł z tego filozoficzno-religijny spin-off. ;) AI może być narzędziem, ale nadal trzeba samemu wymyślić projekt, podjąć decyzje, testować, optymalizować i poskładać wszystko do kupy. Dungeon Walker na Atari nie zrobił się sam — ktoś musiał poświęcić na to sporo czasu. A czy grafika się komuś podoba, czy nie, to już kwestia gustu. Najważniejsze, że powstaje coś nowego i że autor ma z tego frajdę.
To taki lokalny folklor. Cieszyłbym się, że jakiś lokalny złośliwiec nie rozwinął wątku w stronę uboju rytualnego, jak to kiedyś miało miejsce – to była dopiero kołomyja. Ogólnie jest szansa, że wpadnie admin i usunie off-topy albo że off-top umrze śmiercią naturalną. Ja bym się nie przejmował i kontunował pracę nad grą która wygląda super. Po ukońceniu nie zapomnij jej zgłosić do fujicupa.
Doszedł pasek siły który wpływa na siłę ciosu. Wypełnia się, gdy wybijemy wszystko na danym levelu i znajdziemy klejnot. Jest również fajna grafika na pokonanie finalnego moba, na ostatnim poziomie, koło wyjścia. Niebieski potion zmieniłem na błyskawicę, lepiej oddaje jego działanie (niszczy wszystko w komnacie). Final boss jest na niego niewrażliwy żeby nie było za łatwo. Wciąż nie rozwiązałem zadowalająco problemu wyświetlania wysokich mobów, pracuję nad tym. Myślę, że obecna czcionka jest najlepszą z jak dotąd zastosowanych. W RAMie zrobiło się dość wąsko. Pozostawiłem jeszcze parę klawiszy (i kombinacji) do debugowania ;)
następne plany: animacja ataku wykonywanego przez wrogów (engine jest na to gotowy, zerowy koszt w RAMie, tylko... assetów brak ;)) symulacja excelowa przejścia gry - sprawdzenie czy matematyczny model zmian parametrów postaci i wrogów w ogóle pozwala to zrobić tiery bohatera - wygląd zależny od poziomu siły na muzykę chyba po prostu nie wystarczy już miejsca, nawet na symboliczną. Cały czas trzymam się jakichś 1,5KB wolnego RAMU, gdzieś odzyskuję pojedyncze bajty, ale założenia głównego nie złamię - gra musi działać w 64KB. Co najwyżej wzbogacę efekty dźwiękowe o jakieś dodatkowe (np przy podnoszeniu itemu, przejściu do następnej komnaty itp) coraz poważniej zaczynam się zastanawiać nad zakupem jakiegoś assetu z itchio. Nie są to wielkie koszty.
VBXE tutaj nie pomaga, bo to nie jest normalnie adresowalny RAM, nie da się z niego wykonać kodu. Można by próbować jakoś strumieniować dane modułu przez okno komunikacji z VBXE, ale to już wyższa półka dla mnie, trzeba by pewnie podziałać w czystym asemblerze. Może kiedyś Wszystko co potrafiłem i można było, przeniosłem do VBXE - dwa obrazki, sprajty, kafelki, czcionkę, tablice z mapami 15 leveli. Ale nie powiedziałem jeszcze ostatniego słowa, prosty moduł i jakiś sekwencer do pokeya, mniejszy niż RMT player, potrzebowałyby jakieś 4-5 kilobajtów. Będę próbował. Właśnie.... kuźwa przecież ja wciąż includuję rmtplayer ;) może jednak te parę KB się znajdzie
ok, wrócę do tematu kiedy ogarnę wszystkie zaplanowane mechaniki oraz gdy wszystkie assety będą się poprawnie wyświetlały
na ten moment z dzisiejszego planu: - symulacja w arkuszu wykonana - z wstępnych ustawień wychodziło, że gra robiła się ciężka na 7-8 levelu, potem na 11 oraz przy samym bossie; postanowiłem zwiększyć liczbę slotów w ekwipunku o 1 i dzięki temu prawdopodobieństwo przejścia mocno wzrosło, trzeba mieć pecha że mob w ostatniej komnacie trafi 4 razy pod rząd, co doprowadzi do śmierci - im większa siła bohatera, tym jaśniejszą ma obwódkę wokół siebie - symboliczne przedstawienie tierów. Z dedykowanymi assetami będzie fajniej - mały dodatek: kratka na której stoi hero/mob jest zaznaczona podświetleniem.
Update: projekt przeszedł już do wersji 0.8 Co nowego: - duże optymalizacje w kodzie, o wiele szybsza animacja. Konstrukcja engine jest jednak taka, że gra nieco spowalnia gdy mobów jest więcej. Nie przeszkadza to mocno, ale jest widoczne. Być może kiedyś przebuduję engine jeśli o to chodzi. - weszło parę taktów muzyki ;) narazie dosłownie 4 akordy na krzyż i plumkanie, ale może uda się coś więcej. - wreszcie poprawiona pozycja wysokich mobów (wychodziły za swoje kratki) - wstęp przed grą opowiadający historię, oraz możliwe dwa zakończenia ze swoimi osobnymi grafikami - zlikwidowane tiery bohatera, do tej koncepcji może jeszcze wrócę
aktualnie pracuję nad końcową komnatą w której rozgrywa się mini zakończenie gry... a poza tym.. jeszcze spoooorooo do poprawy, a w sieci już kilka filmów jest. Tego się nie spodziewałem ;)
zrobiłem mini forka - demo, specjalnie poucinane tak, żeby nawet nie udało się wydłubać assetów z zakończenia ;)
Projekt odjeżdża od oryginału jeśli chodzi o zastosowane mechaniki ;) w drodze wersja 0.8.1_demo, gdzie mamy trochę poprawek grafiki, wciąż nierozstrzygnięty problem z psuciem się ścian przy przechodzeniu przez przejście oraz całkowicie naprawione nęcenie mobów w pułapki ;) Nawiązałem kontakt z grafikiem 2.5D, może coś z tego będzie
bardzo fajnie rozpisane, dzięki ;) aż sobie zajrzałem do książki Jordana Mechnera żeby zobaczyć czy to opisywał ;) Tak, podczas eksperymentowania już we wczesnych wersjach szybko sobie uświadomiłem że kolejność rysowania jest kluczowa. U mnie kafle są rysowane od samej góry i leci przekątnymi od lewej do prawej, najpierw podstawa a potem uzupełnienie kafelka o akcenty typu znajdźki/pole z niebezpieczeństwem/akcent przejścia/mur,drzewko,kamienie (dlatego że te elementy są wyższe więc naturalnie przy tej kolejności rysowania przesłoni to, co powinno być przesłonięte). Ten sposób się sprawdza w zasadzie od samego początku. Malarz kafelków w odpowiedniej kolejności maluje, a potem do gry wchodzi pętla iterująca po tablicy wszystkich postaci na ekranie - rysuje je i ewentualnie aktualizuje otoczenie w odległości 1 kafelka (czyli 9 kafli) żeby zrealizować zasłanianie postaci przez wyższe elementy otoczenia. Na koniec najwyższa warstwa niezależna od izometrii, czyli mapka, ekwipunek, teksty. Co do buforowania klatki animacji - na początku chciałem zrobić dwa bufory, do jednego rysować a drugi pokazywać ale było to bezsensownie powolne. Dlatego komnatę rysuję raz, a potem traktuję ją jako źródło danych dla blittera, żeby odtwarzać grafikę miejsca w którym przed chwilą stała postać a teraz jej tam nie ma. Czyli mam gotowy, nietykalny wzór komnaty bez bohaterów cały czas w pamięci. Robię tylko gdzieś jakiś głupi błąd i sprawa się psuje w momencie przechodzenia przez przejście - w niedalekiej odległości od bohatera jest podmieniany jeden klocek na inny. Ale znajdę to, za parę dni będzie kolejna nasiadówka z kodem i poszukiwanie buga. Tak czy inaczej podrzucam zapowiadane wcześniej demo z wieloma malutkimi poprawkami.
@zbylu dzięki! jestem zaszczycony :) Jak tak patrzę na tęrozgrywkę i wiem jakie trudności przygotowałem ale narazie ukryłem - to sądzę że Ci się spodoba pełna wersja :) szkoda tylko, że na stałe przykleiła się do gry łatka AI. Jakoś mi to mocno nie przeszkadza, chociaż wiem ile samodzielnej pracy kosztował mnie cały projekt.
Niestety, wiele osób wrzuca wszystko robione z pomocą AI do "jednego worka", niezależnie czy to slop wygenerowany trzema promptami bez przetestowania, czy dziesiątki godzin poświęcone na to, aby osiągnąć zamierzoną wizję i grywalność.
Próbuję wypracować jakiś sensowny opis do filmów wspomaganych/tworzonych wraz z pomocą AI. Nie upieram się przy takim opisie, jestem gotów go zmienić. Czy macie może pomysł dotyczący takich oznaczeń? Jest on sensowny, nie jest stygmatujący? Może być odbierany negatywnie, czy też jedynie dla niektórych osób - jako informacja?
A, to jest Twój kanał? Dobra, teraz wszystko jasne.
Mimo wszystko myślę, że dobrze, że jest oznaczenie informujące, że przy materiale wykorzystano AI. Często nie oddaje ono całej sytuacji, ale z drugiej strony developerzy robiący Rekinka Tesli, którego ostatnio ogarniają na bank (CETAC? tak to się nazywało?), bez AI też zasługują na jakieś odróżnienie ich pracy od materiałów wygenerowanych praktycznie w całości przez AI. Dla mnie niesamowita robota.
Nadałoby się tu jakieś zróżnicowanie, bo sam udział AI jest jednak wart zaznaczenia. U mnie tego udziału nie było wiele, ale jednak był.
Z drugiej strony bez AI, przy tak skąpej dokumentacji VBXE, pewnie nie wychodziłoby dziś aż tyle gier wykorzystujących ten sprzęt. AI potrafi tu po prostu obniżyć próg wejścia i umożliwić ludziom zrobienie rzeczy, do których wcześniej trudno było znaleźć informacje.
Jak już gdzieś pisałem, życie leci i nie potrzebuję nikomu udowadniać, że całkowicie sam potrafię kodzić. Lata w temacie, choć w innej dziedzinie, ale jednak lata, są dla mnie samego wystarczającym dowodem.
Widziałem gdzieś tu na forum albo na sąsiednim wątek o oznaczeniu "made with AI". Temat jest naprawdę godny pociagnięcia. Można by zrobić rozróżnienie między "made with AI" oraz "supported by AI"
Jak z "ta strona używa Cookies" - albo będzie wszędzie zaśmiecać, albo wielu oleje i się nie przyzna. Btw, wspomniany projekt CETAS jest "wspierany AI".
Wrzucam nowe demo. Znowu dużo drobnych poprawek. Było od zarąbania roboty:
- Nowy ekran wyboru poziomu trudności po intro, przed pierwszym poziomem. EASY lub HARD wybierasz joystickiem albo strzałkami i zatwierdzasz FIRE. EASY jest domyślnie zaznaczone. Wybrana opcja jest wyróżniona ramką i nawiasami > <. Każda nowa gra pyta o poziom trudności ponownie. - Poprawiono menu trudności. Przełączanie EASY / HARD zmienia wyłącznie zaznaczenie i napisy, bez migotania całego menu.
ROZGRYWKA I BALANS - Na HARD moby trafiają bohatera częściej i zadają trafienia krytyczne mniej więcej dwa razy częściej. - Możliwość upuszczania kluczy. - Przedmioty można upuszczać wyłącznie na puste pole podłogi. Próba upuszczenia ich na przedmiocie, pułapce, w przejściu, na klapie lub na zajętym polu wyświetla "Cannot drop here" i nie zużywa tury. - Po opuszczeniu komnaty i powrocie zastaniesz te same moby, z zachowanym rodzajem i poziomem zdrowia. Mogą zmienić pozycję, ale nie zostają zastąpione innymi przeciwnikami ani nie odzyskują pełnego zdrowia.
MINIMAPA - Podpowiedzi w trybie EASY. W odkrytych komnatach żółta kropka oznacza klucz, a zielona klapę prowadzącą na następny poziom. HARD nie pokazuje podpowiedzi. - W trybie EASY minimapa pokazuje również upuszczone klucze. - Znaczniki kluczy znikają z minimapy w ciągu kilku klatek po ich podniesieniu.
GRAFIKA, OŚWIETLENIE I ANIMACJE - Pochodnie wiszą na środku widocznej ściany, dzięki czemu ich płomienie nie są przecinane przez sąsiednie bloki muru. Usunięto również cienkie paski pochodni widoczne w narożnikach wewnętrznych. - Animowane pochodnie - Światło pochodni sięga podłogi - Lawa obok bohatera lub mobów animuje się z pełną prędkością, niezależnie od wolniejszego rytmu animacji postaci. - Poprawiono animację sąsiednich pól lawy. Pola zachowują wspólny rytm, bez pozostawiania starej klatki obok mobów. Naprawiono również ciemnoczerwone bloki i szare kliny pojawiające się między animowanymi polami. - Bohater i moby błyskają na czerwono po otrzymaniu obrażeń, zarówno w walce, jak i po kontakcie z pułapką, np. lawą. - Zabite moby błyskają na czerwono, a następnie rozpadają się na drobne kawałki
POPRAWKI BŁĘDÓW - Naprawiono zbieranie klejnotu znajdującego się na polu, na którym upuszczono klucz. Klejnot jest teraz zbierany w tym samym kroku co podniesienie klucza. - Naprawiono znikanie lub obcinanie ikon klejnotów i kluczy leżących na sąsiednich polach podczas podnoszenia mikstur. - Naprawiono pozostawanie fragmentów ikon na pustych polach przy krawędzi komnaty po podniesieniu niektórych mikstur.
