Będzie możliwość donacji dla chętnych :). Prolog to nie jest pełna gra jeszcze - tylko 8 map, tylko 1 planeta. Z pełną grą jeszcze trochę zejdzie dlatego wypuszczamy demko w formie mini-gry, aby zebrać feedback i zobaczyc jakie jest zainteresowanie :).
Jhusak - no i masz, nie chciałeś za darmoszkę to teraz wszyscy płacić bedo. Pazur - na podstawie reakcji na demo nie ma co badać rynku. Ja przykładowo nie gram w dema i unikam wszystkiego, co ma ograniczoną funkcjonalność. :-)
@Konstantyn - tu nic nie jest ograniczone :). Prolog to kompletna gra, nawet z zakończeniem (kilkoma). Tyle, że jest krótsza. Możesz to potraktowac jako epizod z dłuższej całości. Zależy nam głównie na opiniach odnośnie gameplay'a, zwłaszcza w kwestii poziomu trudności.
a ja się pytam dlaczego gra się nagle znalazła w archiwum skoro oficjalnie jest do pobrania przez : ->link<- , z możliwością wpierania autorów przez donejty ;) przecież takie działanie to jawne sabotowanie naszego projektu .... zwłaszcza że na itch jest cała historia , instrukcja obsługi gry oraz możliwość ściągnięcia gry nieodpłątnie
Gra ma niesamowity klimat i mnie osobiście najbardziej ujmuje właśnie to. Oczywiście technicznie wszystko pięknie i poprawnie, nie będę się tu rozsładzał, wiadomo że tak powinny wyglądać gry na Atari:-) Ale właśnie za klimat cenię ją szczególnie. Gratuluję Panowie!
@Mq - piękne dzięki, dla mnie klimat też jest zawsze bardzo ważny w grach, więc tym bardziej się cieszę z takiego feedbacku!
@MaW - Zanim powstała gra w assemblerze praktycznie kompletny prototyp gry został przygotowany w Unity. Edytor map do gry jest częścią prototypu. Mapy tworzymy na PC używając tego edytora. Można je też od razu w prototypie testowac bez potrzeby przerzucania na Atari. Kiedy mapa jest gotowa eksportujemy ją w formie binarnej i Święty jeszcze dokonuje optymalizacji i kompresji swoimi narzędziami, ale do większości playtestów możemy używac prototypu - to bardzo usprawnia projektowanie leveli.
no troszkę pograłem i widzę zarówno plusy i minusy plusy to że nie ma takiej klaustrofobii jak w jedynce(chociaż na tym też opierało się sporo zagadek z jedynki jeden raz coś źle przesuniesz i kaplica)no i gra żywsza dynamiczniejsza oprawa graficzna i muzyczna bardzo dobra na minus brak checkpointów niektóre poziomy są dłuższe jest kilka zagadek pod rząd i jak popsujesz jedno to czasem musisz się wracać do początku(wiadomo można skorzystać z savestatów) nie ogarniam też za bardzo działek i widzę że można się zaciąć bo niszczą one klocki elementy planszy dlatego jakaś możliwość chechkpointa czy coś czy możliwość cofnięcia do stanu sprzed początku zagadki byłaby dobra widzę że są też jakieś sekrety poukrywane dobrze byłoby jakieś statystyki wprowadzić żeby czegoś nie ominąć(mam wrażenie że już ze dwa ominąłem no trudno póki co chcę tę gierkę po prostu przejść) i chociaż gra na samym początku wydawała się prosta to już wiem że będzie wredna i ciężka(ale to akurat dobrze)
Z checkpointami nie jest prosta sprawa, bo wymagałoby to zapisywania stanu mapy co jakiś czas. Nie sądzę żebyśmy mieli na to pamięc. To co możemy zrobic to podzielic mapy na mniejsze, aby było mniej wyzwań w każdej. Te mapy z wieloma zagadkami to są te początkowe, "tutorialowe", gdzie chodzi o zapoznanie się mechanikami. Późniejsze mapy będą raczej miec jedną, większą zagadkę złożoną z kilku elementów i tych podzielic się już nie da. Ale te pierwsze są do rozważenia.
Będą sytuacje nieodwracalne, wtedy trzeba niestety ESC i zaczynac mapę od nowa.
Statystki planujemy miec w pełnej grze pod klawiszem czy jakimś skrótem typu 2x fire szybko. Rozważamy też opcję zagrania w dowolną, ograną już mapę ponownie np. w celu znalezienia sekreta.
Mi chodzi po głowie pomysł potraktowania sekretów jako tryb hard gry, tzn. najtrudniejsze zagadki mogą byc jako sekret. Wtedy gracze, którym nie zależy tak bardzo na znalezieniu wszystkiego mogą również grę przejśc, ponieważ sekrety są opcjonalne.
Pamiętaj, że poziom trudności w prologu rośnie dużo szybciej niż będzie to miało miejsce w pełnej grze. Chcieliśmy żeby prolog, pomimo tylko 8 map, posiadał strukturę pełnej gry, a więc miał wyzwanie na końcu - stąd nieco przyspieszony challenge.
Dodatkowo pilnujemy żeby mapy, znając rozwiązanie, dało się przejśc w maksymalnie 3-4 minuty z sekretami, a początkowe mapy dużo szybciej.
Prolog da się przejśc poniżej 17 minut z wszystkimi sekretami, stąd uznaliśmy, że brak zapisu stanu gry czy statsów nie jest jeszcze tak bolesny.
No to jak będą statystyki i możliwość powtórzenia poziomu dla sekretu to myśle że to w zupełności wystarczy bo ciurkiem to to by było bardzo trudno przejść coś się zawsze przeoczy ja na przykład szukam teraz tych sekretów i też w 5 levelu go nie widzę Na 8 poziomów w jednym lekko zajrzałem do solucji(nie przyszło mi do głowy że można działko pchające podłączyć) a jeden poziom mam wrażenie że przeszedłem strasznie topornie Gra się bardzo przyjemnie a to chyba najważniejsze:)
Przeszedłem z wszystkimi sekretami, bez sekretów oraz z kilkoma zdobytymi Widocznie nie zwróciłem uwagi że tekst się zmienił przydałaby się jakaś mała graficzka do tych zakończeń:) Udało mi się też znaleźć "kulturalny" sposób na poziom siódmy wykorzystujący działka przepychające Świetna to gierka jest Czyli z moich uwag to w sumie zostaje tylko jakaś statystyka żeby gracz wiedział ile tych sekretów już zdobył i możliwość wybierania leveli w celu zdobycia pominiętych sekretów To będzie hit jak wyjdzie pełniak
Co do wersji NTSC - nie ma takiej opcji , chodzi o to że gra jest tak wyżyłowana że nawet w PAL-u były problemy żeby wszystko się wyrabiało - chodzi generalnie o to że cała logika gry, animacje, obsługa spritów czy parallaxy gwiazdek (same gwiazdki muszą być liczone oraz kasowane i umieszczane na planszy co ramkę) , obsługa ruchomych obiektów jak lasery, wyrzutnie, zderzaki itp wszystko jest podczas VBLANKU i tego nie da się przeskoczyć - na vblanku również są rysowane pierwsze 2 linie wyświetlanego obrazu , później ekran skłąda się z przerwań DLI co 1 linie znakową (8 linii) i tam są przełączane generatory znaków a w pozostałym czasie renderowane kolejne linie wyświetlanej grafiki - chodzi o konwersję plansz z 1 bajtu na 2 znaki, więc podczas wyświetlania obrazu w zasadzie nic się nie da zrobić , to co mi się udało upchać to jeszcze muzyka odtwarzana 2x ramka - gdzie jeden raz player odtwarza muzykę a drugi raz buforuje rejestry , przepisywane zaraz po zakończeniu rysowania ekranu - tak że technicznie jest to nierealne .... Przykładowe wykorzystanie procesora - pierwszy screen to player do muzyki lzss, drugi - renderowanie bufora ramki , trzeci to pełnny ekran z pokazanym pełnym vblankiem z emulatora - jeśli pojawią się lasery , promienie itp to ten czas będzie dochodził do muzyki , musi być trochę rezerwy że gdyby engine wszedl czasowo w obszar muzyki to jakaś rezerwa zostaje na to żeby się gra nie wysypała ...
What I got from the preview, this game is one of the best, I've seen for the Atari (particular when it comes to the ambient and how all fits together) . So I never wanted to argue here.
miała być opcja odgłosy gry vs muzyka, zresztą problem jest taki że Foster pewnie bawi się 15khz i 1.79 Mhz , więc musiałbym mieć jakieś sloty na jednym kanale, generalnie do ogarnięcia w czasie pod muzą , ale jeszcze to bardziej komplikuje engine gry
@jakubp1985 - a był pomysł żeby dorzucic grafikę do tego zakończenia, które jest kiedy przejdziesz wszystko z wszystkimi sekretami. Nawet szkice powstały, ale ostatecznie z braku czasu już odpuściłem. Zrobienie grafiki kosztuje mnie dośc dużo czasu i zdecydowaliśmy, że wykorzystamy ten czas do pracy nad pełną wersją gry. Druga sprawa jest taka, że im bardziej efektowne zakończenie prologu tym lepsze musi byc zakończenie pełnej gry ;).
@tebe - musisz podpiąc akumulator do jednej bariery, odpalic ja, nastepnie "zassac" energie z powrotem do akumulatora i potem użyc drugiego akumulatora żeby zassac energię z pierwszego i wtedy podpiąc ten drugi do drugiej bariery (w środkowej części mapy, tam gdzie są 2 akumulatory). W razie czego zobacz video walkthrough Sabermana linkowane wyżej.
How about a proposal, to have different speeds at any channel ? In theory, only low sounds need faster updates. Imagine a Tracker that allows 3 channels at 1 VBI and on channel at 2x. 3x. oder even faster updates. Some instruments don't even need an update every VBI...
@emkay - this all does not matter - you relay on the _longest_ replay procedure execution, which occurs when you update all the channels at once and process next notes for the channels, interpreting commands and parameters etc.
jhusak If channels were played once in a VBI, the handling for FX gets easier. Updating channel 4 even for digitizing won't interfere with channel 1 for FX playback at 50Hz ...
Have you seen "Goat Tracker" for the C64 ? The software is also able to reduce data by the amount of writes of a second.... not writing to a channel, when the notes need to get played at a lower speed. Let's say you have a patternlength of 64 and there were only 4 notes on the pattern. It stores and plays the pattern at the speed to have 4 notes and 4 pattern steps. Jumping over the rest of unneeded pattern parts. At the end that one channel with 4 notes needs 16 bytes, instead of 64 bytes. Some detection in LZSS to NOT set unchanged values, would help a lot. Not sure, how far the compression has been updated, as it was planned to re-use repeated patterns in the decompression, to save memory. The "low speed" channel could be used in a shadow register. If FX is played, the decompression can still work, without interfering the FX. If no FX is played, a simple copy routine could set POKEY's registers for the music replay.
@święty, czy ten cały mechanizm generowania danych dla pokeya w locie jest niezbędny? Czy to raczej taki proof of concept, dla większych plansz dla przyszłych gier? Jaka jest największa plansza (źródłowa bajtmapa) w CH2?
Bo normalnie plansza 1kb (jak w boulder dash) rozwija się w 2 kB (powtarza się linie) i to chyba nie jest problem pamięci, tylko… no właśnie. Wydajności animacji?
Lzss jest najbardziej wydajnym systemem dekompresji czasowo , dla innych rozwiązań trzeba by było napisać specjalny dekompresor/player więc kolejna rzeźba, której nie chciałem robić a mamy własny player napisany do rewindów itp. Apropo systemu renderingu - plansze mamy 64 x 64 bajty x 2 warstwy umieszczone co stronę pamięci żeby szybciej aderesować X/Y , cienie nakładane dynamicznie muszą być na dolnej warstwie ale przenoszone na góną żeby na jej podstawie wyrenderować planszę , gdzie mamy do dyspozycji 256 różnych obiekótw, zakodowanych cieni itp, więc to jest co ramkę rozbijane na kafelki 2x2 znaki , ale na zasadzie 2 znaki poziomo i 2 przełączane generatory , mając mapę kafelków więc każdy z obiektów może się składać z 2 dowolnych znaków np z dodatkowym kolorem z inversu, w ten sposób mogę mieć kilka tak samo wyglądających np laserów, barier itp ale mających rózne kody na planszy co pozwala na łatwiejszą obsługę/interakcję między obiektami , do tego jest kamera 50 fps więc odświeżanie planszy też musi być wszystko odświeżane co ramkę ... do tego nie mamy klasycznego bufora ekranu ale to już inna historia
Plansza źródłowa 64x64 bajty to 4 kB (x2). Bez wyrównania do strony pamięci docelowa dla Antica zajmie też 8 kB (2 x 1 bajt źródła -> 1 x 2 bajty pamięci ekranu, czyli 128 bajtów). Ale trzeba dodać margines 48 bajtów, czyli i tak wyjdzie z wyrównaniem 16kB. To jest ten dodatkowy narzut, którego teraz nie masz.
Czy rzeczywiście, te animacje nie zmieszczą się we vblanku, jeśli damy anticowi po prostu pobierać dane z tego obszaru 16kB? (z dokładnością do flipowania zestawu/ów znaków)
Skoro gra operuje na planszy źródłowej, to odpowiednio ścigając się z beamem można by uzyskać ten sam efekt animując "offline" - wtedy wypełnisz egzekucją kodu te wszystkie luki w rastrze i masz więcej czasu (nie?).
Traktuj to jako rozmowę teoretyczną, bo na pewno nie ma co zmieniać. Chociaż... Ostatnio bawiłem się Problemem Jasia (wiem, nie ma co porównywać złożoności), i zaczął jednak działać pod NTSC :) Jeśli by się dało animowanie planszy przerzucić do vblanka (chociażby na 2 cykle rozłożoną, ja to tak robiłem w StarBallu na Amigę, tam były animacje co 4 ramki, ale w jednej ramce kolumny/4=0, w drugiej kolumny%4=1 etc, nawet spoko to wyglądało), to na NTSC by poszło.
Ale może te 16 kilobajtów jest krytyczne... Ale z drugiej strony i tak piszesz, że używasz 16 kilobajtów (64x256) na pamięć źródłowej planszy. Więc ...
Piszę to tylko tak, bo wiem, że czasem człowiek uchwyci się jakiejś myśli i sie jej trzyma. Jeśli jest dobry powód - ok. Ale zawsze warto pogadać, bo człowiek się czegoś nauczy (ten czy tamten) :)
jhusak - ucinam dywagacje bo one i tak do niczego dobrego nie doprowadzą , w zasadzie gra używa przestrzeni pamięci od $400-$900 - player LZSS, od $900 do od $3e00 sam engine gry , $4000-$7fff - plansze 64 x 64 x 2 plany plus definicje spritów pomiędzy , od $8000- $bfff - bankowanie cartridge z mapami animacji znaków oraz danymi LZSS dla kilku muzyk, więc tutaj ciężko już coś upchać dodatkowego, po za tym są tam też skompresowane plansze , od $c100-$c900 , $cb00-$cf00 - obszar wyświetlania spritów, $d800-$dfff- 2 generatory znaków animowane , $ef00-$ffff - jakieś mapy,tablice itp więc generalnie nie przewidywałem tego w wersji dyskietkowej itp , a robiąc tą grę na rozszerzenie pamięci zaraz będzie gadanie że nie działa na 64k , od początku było założenie PAL i CART , więc teraz pogaduchy o tym że powinno działać na każdym atari w 10 wersjach jest totalnie bez sensu , CART jest z punktu fizycznego najlepszym nośnikiem i w wersji pudełkowej idealnym rozwiązaniem. Gra jest pewnym kompromisem pod względem że ma być komercyjna , wykorzystywać na ile się da możliwości sprzętu oraz pójść na nierozszerzonych atari z 64kb. Więc przerabianie teraz wszystkiego dla kilku osób , które nie wiadomo czy zapłacą za moją dodatkową pracę jest totalnie bez sensu
