anketa fajna ale mam dla Ciebie lepszi pomysł - versione lekko modificata time wizarda, która wysyła po fujiniecie twarde dane na temat czasu przejścia leveli, użycia rewindu, itp. :) zeby zachęcić bractwo to jeszcze tabela nalepszych wyniczków. żeby zaoszczędzić pamięć levele też możesz wczytywać z fujinieta i teraz najlepszi: nowe levele jak Ty czy ktoś doda to od razu będziesz zbierał DANE DANE DANE DANE DANE DANE.
nie zapomnij zapytać o pesel / SSN i nazwisko panieńskie mamy usera.
W sieci natknąłem się na recenzję gry Time Wizard. Dziękuję bardzo autorowi za przygotowanie opisu oraz gratuluję przejścia całej gry. Po przeczytaniu takiego artykułu sam bym sobie zagrał :D ->link<-
Przy okazji chciałbym podziękować za pierwsze wpisy w ankiecie. Mam w tym momencie 8 odpowiedzi. Jak zbierze się więcej wyników to zapewne podzielę się z Wami komentarzami oraz ocenami poszczególnych poziomów.
Jeśli jeszcze ktoś z Was chciałby poświęcić swoje cenne 5-10 minut, to będę niezmiernie wdzięczny za wypełnienie ankiety, która jest anonimowa i nie zbiera żadnych Waszych danych osobowych, bo są mi one zupełnie niepotrzebne :)
Przerwa międzyświąteczna pozwoliła mi na przygotowanie filmu z powstawania gry Time Wizard.
Przejrzałem całą historię z repozytorium i Wybrałem najbardziej charakterystyczne momenty z rozwoju gry. Wyciągnąłem z archiwum historyczne obrazy dyskietek i na ich podstawie nagrałem krótkie sekwencje wideo. Pomiędzy nimi umieściłem plansze z informacjami o kluczowych zmianach dla danego dnia. Są tam również dostępne informacje dotyczące chwilowej ilości linii kodu oraz rozmiaru gry. Do filmu dodałem również napisy w języku polskim, można je włączyć lub wyłączyć w ustawieniach odtwarzacza.
Bardzo fajny pomysł z tym filmikiem. Fajnie zmontowany. Najważniejsza wartość jaką w tym widzę (poza oczywiście historyczną), to jest pokazanie krok po kroku zwłaszcza początków - od czego zaczyna się robić taką grę. Ludzie, którzy nigdy gry nie pisali, a widzą gotową produkcję, często nie wiedzą, że to się tak tworzy małymi kroczkami i zaczyna od najprostszych rzeczy, dokładając kolejne elementy, mechanikę, grafikę, dźwięk itd. Często ludzie widzą więcej magii w gotowej grze, niż tak na prawdę jej tam jest. Myślę, że takie pokazanie ma wartość dla tych osób, które może i by coś napisały samodzielnie, ale nie wiedzą jak się za to zabrać. Dużo lepsze jest pokazywanie takich metod niż np. publikowanie kodów źródłowych, z których po pierwsze nikt nic i tak nie rozumie, a po drugie nie ma sensu kopiować kodów gotowych, lepiej posłużyć się do nauki metodyką tworzenia, a tworzyć jednak nowe rzeczy samodzielnie.
Edit: wyrzuciłem słowa krytyki i wysłałem prywatnie autorowi:-)
Jeśli przebrnęliście przez cały materiał to chylę czoła, że poświęciliście mu tyle czasu. Jeśli nie, to nic straconego - to tylko kolejny filmik, których ogląda się tysiące na YT.
@jhusak >Po tym można poznać prawdziwego mężczyznę. Nie jak zaczął, tylko jak skończył :D Hehe, ale ja się jeszcze niczego nie kończę - ja dopiero zaczynam :D
@Mq >Dużo lepsze jest pokazywanie takich metod niż np. publikowanie kodów źródłowych... Zgadzam się, grunt to wygodny i niezobowiązujący przekaz. Wszyscy jesteśmy zabiegani i zajęci różnymi sprawami i prawie nikt nie ma czasu czy chęci na zgłębianie tajników kodów źródłowych. Jeśli ten filmik kogoś zainspiruje, żeby coś stworzyć to będę miał osobistą satysfakcję :D
@VLX >Świetny filmik. Jak tak się ogląda, to wszystko wydaje się takie proste. :D Tak, bo to w cale nie jest kosmiczna technologia - programowanie jak każde inne. Jedynie co należy uwzględnić to specyfika sprzętu. Mnie osobiście pomogło to, że przed jakimkolwiek kodowaniem przygotowałęm sobie dokument ze specyfikacją (24 strony!). Żeby go stworzyć musiałem wiele rzeczy przemyśleć, zgłębić i poszperać w sieci. Potem konsekwentnie i kaizenowo brnąłem do przodu. Poza tym to nie jest mój pierwszy projekt na Atari, więc było trochę łatwiej - wiedziałem już co można zepsuć a co nie :)
@krzysztofk_atari >super sprawa! Wszystkiego dobrego w nowym roku i jeszcze wielu świetnych gier! Dzięki za życzenia! Tobie i pozostałym również życzę wszystkiego dobrego i spełniania się w tematyce retrokomputerów :)
A, to jak już tak, to ja się też przyłączam do wszystkich życzeń:-) I róbcie gry w nowym roku, ja już mam plany na kolejną, ale nie zdradzę jaką:-) Mam nadzieję @amarok, że też coś kolejnego wymyślasz już:-)
@Amarok, potwierdź proszę tutaj albo na AtariAge, że Time Wizard już jest w wersji finalnej, inaczej jako "gra w produkcji" nie będzie brany pod uwagę w głosowaniu Atari Homebrew Awards za 2023 rok.
To samo zresztą dotyczy wielu innych gier, które domyślnie oznaczone zostały przez organizatorów konkursu jako WIP. Chodzi o listę z wątku ->link<-
Z przyjemnością chciałbym poinformować, że przygotowałem edytor poziomów do gry Time Wizard. :)
Starałem się stworzyć program, który jest w miarę intuicyjny i wygodny w użyciu. Poprzedni, który używałem podczas tworzenia gry był całkowicie niepraktyczny.
Ten nowy edytor będzie służył tworzeniu dodatkowych poziomów do gry, którą planuję wydać na kardridżu. Prace nad przenoszeniem gry na kardridż właśnie rozpoczynam i myślę, że może zająć mi to kilka miesięcy. Głównym wyzwaniem będzie takie przeorganizowanie kodu, żeby udało się uruchamiać grę na komputerze z 64kB pamięci RAM.
W międzyczasie chciałbym przygotować dodatkowe poziomy, żeby pudełkowa wersja gry była o nie wzbogacona. Jeśli ktoś z Was chciałby się pobawić i spróbować stworzyć jakiś poziom to z chęcią rozważę dołączenie go do gry. W takiej sytuacji umieściłbym w grze informację o autorze danego poziomu jeśli byłoby takie życzenie. Zastrzegam sobie, że nie każdy zaproponowany poziom zostanie dołączony. Możliwe też, że będę chciał wprowadzić jakieś korekty.
Wracając do edytora - jest to wczesna wersja programu i nie mam pewności czy będzie działać na innych systemach niż Windows 11, który posiadam. Jeśli będzie taka prośba, mogę rozważyć przygotowanie również wersji pod Linuksa np. Ubuntu. Powinno to być w miarę łatwe, tylko musiałbym zainstalować sobie taki system na komputerze.
Sam edytor napisałem w Pythonie i użyłem biblioteki PyQt6 na licencji GPL v3. Z tego względu taka też jest licencja całego edytora. Link do kodów źródłowych oraz programu z przykładowymi poziomami znajduje sie poniżej.
W międzyczasie mogę przygotować krótką instrukcję do edytora, żeby ułatwić jego używanie. Jednak wiem, że wiele osób lubi eksplorować na własną ręke i nie specjalnie lubi czytać instrukcje.
W razie czego jestem do Waszej dyspozycji jeśli będziecie mieli jakieś pytania.
Niestety nie mogę załączyć edytora bezpośrednio tutaj, bo zajmuje za dużo miejsca. Można go pobrać z poniższego linku
@amarok: świetna sprawa, bardzo dobry ruch z tym edytorem:-) Jest dużo osób, które na forach twierdziły, że gra posiada wystarczająco dużo elementów i mechaniki, żeby dało się wymyśleć do niej nowe ciekawe etapy w oparciu o to co już jest dostępne. Zobaczymy czy rzeczywiście tak jest i czy faktycznie ludzie coś ciekawego teraz pokażą:-) Trzymam kciuki, bo gra jest świetna, a z większą ilością etapów dostarczy graczom zabawy na kolejne godziny:-)
@amarok - świetna sprawa! Od razu przychodzi mi do głowy taki myk - serwis i jakiś front, gdzie możesz sobie wrzucić takiego dżejsona, tam kompilacja gry na podstawie podesłanych poziomów a potem cyk - gotową grę pobierasz przez Fujinet ;) Pozdrawiam serdecznie!!!
albo lepi - wrzucasz level na serwer, odpalasz fujinetową wersję giery i ci się wyszfietla lista leleweli do ogrania z serwerka. gra czyta lelewele z serwera a nie z dysku. boskie, bo amaroque może sobie sztatystyki porobić, któren level jak długo się przechodzi i takie tam.
Panowie, dzięki za miły odbiór edytora! Widzę, że od razu macie bardzo interesujące pomysły. Grunt to kreatywność i dobra zabawa. W końcu tym się tutaj zajmujemy, czyż nie? :)
@George, wybrałem Pythona ze względu na wieloplatformowość, szybkość tworzenia kodu i osobistą chęć zgłębienia technologii.
@Mq, nie będę ukrywał, że presja ze strony społeczności związana z fizycznym wydaniem gry i zwiększeniem liczby poziomów była dla mnie decydującym czynnikiem motywującym. Teraz już nie ma odwrotu, trzeba zakasać rękawy i do roboty, do roboty... :D
Z testowaniem nowych poziomów w grze to nie taka łatwa sprawa. Należałoby podmienić odpowiednie pliki i przekompilować grę. To raczej byłoby niewygodne i czasochłonne zadanie. Bo trzeba byłoby postawić sobie całe środowisko deweloperskie do takiej zabawy.
Ale myślę właśnie nad specjalną wersją gry Time Wizard, do testowania poziomów. Nazwijmy ją roboczo "Time Wizard Tester". :D
Mogłoby to wyglądać w taki sposób, że umieszamy pliki z poziomami *.level i *.thumb na dyskietce a ta specjalna wersja gry doczytywałaby poziomy z zewnętrznych plików i pozwalała na ich uruchamianie. Time Wizard Tester mógłby być nawet okrojony o pewne elementy, bo to nie była to regularna gra a środowisko testowe. Poza tym wszystkie poziomy byłyby zawsze dostępne.
Chwilę zajęłoby mi czasu na przygotowanie takiego programu, ale jeśli byłoby spore zainteresowanie takim softem to mógłbym w to wejść i ułatwić/zachęcić więcej osób w zaangażowanie się w tworzenie poziomów :)
zdajesz sobie sprawe ze ludzie chcieliby sie dzielic tymi nowymi poziomami. Takze ten tester stalby sie i tak osobna krazaca gra.
A moze daloby sie "sklejac" binarnie dane o ile levele w skompilowanej wersji sa w tym samym miejscu? Wtedy taki edytor moglby po prostu podmieniac "bebechy dla leveli"
Nie chciałbym, żeby powstały dziesiątki klonów gry tak jak to jest w przypadku Boulder Dasha czy Robbo. Jest wersja oryginalna, którą już znacie i powstanie wersja "Deluxe" na kartdridżu zawierająca więcej poziomów i jakieś tam "ekstrasy".
Tester do poziomów służyłby tylko do testowania poziomów, jak nazwa wskazuje, i świadomie okroiłbym go o pewne elementy, żeby nie stał się konkurencją dla oficjalnej gry.
Mam nadzieję, że rozumiecie mój punkt widzenia... :)
Myślę, że nawet powstawanie "klonów" jak w przypadku Robbo, tylko może przedłużyć życie gry. Zresztą jakiego sposobu byś nie wymyślił, to ktoś zdeterminowany i tak może takiego bootlega zrobić, zwłaszcza jak wypuścisz testowy silnik. Ale to też już nie czasy piractwa i raczej nikt przy zdrowych zmysłach nie udawałby, że zrobił inną grę, czy próbował przypisać sobie jej autorstwo. Chociaż po ostatnich "jajach" na forum można spodziewać się wszystkiego. Z drugiej strony "poklik" dla Robbo generujący gotowe xexy (albo atry, nie pamiętam) z grą na pewno paru "noobom programistycznym, ale z zacięciem do tworzenia" przysporzyła sporo radości i jest szansa, że też znaleźli się ludzie, którzy w to grali :)
Jestem przynajmniej za tym, by spróbować stworzyć taką testową wersję gry, która może "głośno krzyczeć" o tym, że jest grą testową ;)
Aczkolwiek najlepiej by było, gdyby np. edytor od razu "gotował" xexa do testowania. Może nawet tylko z aktualnym levelem, a nie całym zbiorem. Do testowania w zupełności wystarczy a z drugiej strony może pomóc w zabezpieczeniu wydania "pełnej" gry.
Podoba mi się pomysł generowania gry bezpośrednio z edytora, dzięki :)
Myślę, że mógłbym przygotować funkcjonalność, która tworzy plik atr zawierający grę wraz z edytowanym poziomem. Można byłoby nawet ustawić w edytorze ścieżkę/polecenie systemowe do uruchomienia emulatora, np. Altirrę, z generowanym plikiem atr.
Mogłoby to przyspieszyć proces edytowania/testowania poziomów. Czyli tak - edytuję poziom i w każdej chwili klikam funkcję uruchom, która odpala emulator z moim poziomem. Testuję i ewentualnie wprowadzam poprawki i ponawiam proces, itd.
Time Wizard Tester byłby na tyle uproszczonym programem, że od razu uruchamiałby poziom, żeby ograniczyć czas pomiędzy edycją a testowaniem. :D
Edit. Chcociaż z plikiem xex pewnie też dałbym radę to zrobić.
Jeśli się nie mylę, to "poklik" właśnie generował xexa i po prostu systemowo odpalał program skojarzony z nim. Więc jak ktoś już miał Altirrę/Atari800 powiązaną, to samo się robiło :)
Przygotowałem nowszą wersję edytora poziomów v1.1. :)
W tej wersji jest możliwość uruchomienia testu poziomu z użyciem emulatora Atari. Służy do tego ikonka pada oraz opcja w menu Test -> Przetestuj poziom.
Edytor najpierw sprawdza czy poziom posiada błędy i jeśli tak to wyświetla stosowny komunikat. W przeciwnym przypadku przygotowywany jest plik xex będący okrojoną wersją gry Time Wizard zawierający aktualnie edytowany poziom. Utworzony plik time_wizard_tester.xex jest zapisywany w katalogu edytora a następnie uruchamiana jest aplikacja skojarzona w sytemie operacyjnym z plikiem xex.
W ten sposób można błyskawicznie przetestować edytowany poziom. :D
Link do edytora jest ten sam jak poprzednio: ->link<-
Świetna robota! @Amaroku - u mnie w robocie robimy (jak w wielu miejscach na pewno) review kodu, siedziałem nad tym od rana to i Tobie zrobiłem ;) Masz literówkę w nazwach funkcji: checkForToManyButtons i checkForToManyStates. Powinny być odpowiednio checkForTooManyButtons i checkForTooManyStates ;) Pozdrawiam i jeszcze raz gratuluję super edytora!
@krzysztofk_atari, dzięki za CR, poprawione :) Przy okazji zrobiłem wersję 1.2, która ma udogodnienie w postaci menu kontekstowego. Dzięki temu można kliknąć prawym przyciskiem myszy w dowolnym miejscu na planszy i wybrać co chce się tam umieścić, jak na dołączonym obrazku.
@mav, w pełni się z Tobą zgadzam.
@rafaldudek, chyba piszesz o Tonym, bo to jest dopiero dzieło :) Trzymam kciuki za ten projekt i czekam na oficjalne wydanie!
Dla tych, którzy nie przepadają za systemem Microsoftu przygotowałem edytor działający pod kontrolą systemu Linux. Program skompilowałem i przetestowałem na Ubuntu 22.04.3.
Zastanawiam się, czy to bug czy feature, że mur z góry/dołu czasem mi znika obiekt nad nim/pod nim (na mapie). Zmiana kolejności na liście obiektów pomaga - ale to dziwne.
Drugie pytanie. Chcę zrobić włączaną platformę na stan oraz pole siłowe. Ustawiam "stan" na nieodporność czasową, platformę tak samo, natomiast polu dodaję odporność czasową, ale po przewinięciu czasu pole się wyłącza razem z platformą - a teoretycznie samo pole powinno być odporne. Robię coś źle, czy to tak ma być? W takim razie to ustawianie odporności dla poszczególnych elementów "stanu" nic nie daje. Zerknij do mapki. Pole 3 i platforma 2 mogłyby być na tym samym włączniku - byłoby bardziej elegancko i przełącznik 3 byłby niepotrzebny.
Menu kontekstowe jest git. Ale oczywiście można byłoby iść dalej i dodać: 1) łapanie za brzegi elementów by od razu mieć możliwość skurczania / rozszerzania elementów ;) 2) zaznaczanie obszaru, który zaznaczy wiele elementów, by móc je przesunąć w całej grupie 3) usuwanie obiektów deletem 4) przesuwanie obiektów strzałkami klawiatury 5) wizualną listę obiektów, zamiast rozwijanej listy 6) kopiowanie obiektów (np. platformę z gotowym rozmiarem)
7) bonus - przełącznik, który ZMIENIA stan, a nie ustawia na włączony/wyłączony :)
Wiem, trochę popłynąłem, ale lubię sobie sam robić takie wyzwania ;) nawet jeśli jestem jedyną osobą, która z tego skorzysta. Duży plus za wizualne przedstawienie stanów, on/off - to pomaga, choć tylda też spoko :D
W załączniku taka tam mapka na zapoznanie się z edytorem. Ogólnie - świetna zabawa i dobra robota! Jestem fanem!
@jhusak, o proszę a skąd masz edytor poziomów na Macu? Widzę, że nie widzę głównego menu aplikacji, który powinien być między belką tytułową a paskiem z narzędziami. Nie mam doświadczenia z tym systemem, ale domyślam się, że menu pojawia się na górze ekranu. Zgadłem? To, że program potrzebuje czasu do uruchomienia nie specjalnie mnie dziwi to w końcu Python. Najważniejsze jest to, żeby program działał sprawnie i nie był zasobożerny. Mam nadzieję, że nie odczuwasz takich problemów.
@mav, dziękuję bardzo za podesłanie pierszego poziomu. Już sobie go przetestowałem. Dziękuję także za wszystkie pytania i uwagi, które podesłałeś. Spróbuję po kolei odpowiedzieć na każde z nich.
W kwestii pierwszego pytania o znikanie obiektów na planszy wyjaśnienie jest banalne. Niektóre obiekty rysują delikatny jednopikselowy cień pod spodem. Przykładowo platformy i murki tak mają. To daje fajny efekt wizualny, troszkę jakby przestrzenny. Jak się przyjrzysz to zobaczysz, że znak zawierający cień składa się z ciemniejszej linii poziomej u samej góry a cała reszta to powietrze. Jeśli taki obiekt jest rysowany na wierzchu, to zasłania obiekty, które są pod spodem. Tp może wydawać się nie do końca logiczne, że powietrze zamalowuje inne obiekty, ale w Time Wizard powietrze nie jest przezroczyste. Na szczęście można zawsze manipulować kolejnością rysowania obiektów. Im niższy numer na liście tym wcześniejsze rysowanie. Ja zwyczajowo projektowałem poziomy w ten sposób, że obiekty widoczne u góry poziomu są rysowane wcześniej.
W kwestii pytania drugiego o odporność czasową stanów oraz obiektów takich jak przyciski czy pola siłowe i znikające platformy. Generalna zasada powinna być taka, że wszyskie obiekty związane z danym stanem powinny mieć takie samo ustawienie odporności czasowej. Albo wszystkie są odporne albo wszystnie nie są. W przyciwnym przypadku może dojść do dziwnych sytuacji. Ja to wiem, bo projektowałem mechanikę gry, ale dla pozostałych osób to wiedza tajemna. Żeby uniknąć problemów mogę dodać kolejne reguły walidujące i ewentualne niezgodności będą pojawiały się w oknie problemów. Alternatywnie mogę przemyśleć synchronizowanie flagi odporność czasowa ze wszystkimi obiektami podpiętymi do tego samego stanu. Dzięki temu nie będzie rozbieżności. Załóżmy, że użytkownik przestawi tą flagę np. w przycisku, to i stan, i wszystkie obiekty sterowane tym stanem zmienią swoją odporność czasową.
To teraz kolejne punkty...
Ad 1) Zmiana rozmiarów obiektów poprzez łapanie za brzegi. Generalnie jestem za, większość obiektów powinna dać się łatwo kontrolować. Mam wątpliwości np. co do ruchomych platform co takie rozciąganie by mogło zmieniać - szerokość platformy czy zakres jej ruchu. Temat na pewno do przemyślenia i ostatecznie do zaimplementowania tam gdzie się da.
Ad 2) Zaznaczanie grupy obiektów i wspólne manipulacje. To może być większe zadanie, ponieważ obecnie nie ma możliwości zaznaczania więcej niż jednego obiektu na raz. Musiałbym to najpierw przemyśleć i ewentualnie przeprojektować.
Ad 3) Powinno być w miarę łatwe do zrobienia. Jedyny problem widziałbym w sytuacji gdy fokus jest na kontrolce z tekstem, wtedy delete obsługiwałby edycję tekstu a nie usuwanie obiektu.
Ad 4) Tutaj podobnie jak w punkcie 3 - wszystko zależy od fokusu. Dodaktowo można byłoby rozważyć zmianę rozmiaru zaznaczonego obiektu. poprzez np. Shift + strzałki.
Ad 5) Nie jestem pewny czy dobrze rozumiem. Czy chodzi o listę dotyczącą rodzaju elementu planszy jak pustka, powietrze itp? Jeśli tak to czy masz na myśli dodanie ikonek do elementów listy rozwijanych czy zastąpienie jej grupą przycisków z odpowiadającymi ikonkami?
Ad 6) Rozumiem, że chodzi o operację kopiuj wklej? Teraz duplikat można zrobić naciskająć przycisk "Dodaj nowy" ponad listą obiektów np. elemetów planszy. Rozumiem, że z klawiatury byłoby to łatwiejsze do obsłużenia.
Ad 7) Czy chodzi o chwilową zmianę stanu, żeby sprawdzić jak będzie wyglądać plansza czy masz coś innego na myśli? Jakbyś mógł rozwinąć pytanie byłoby mi łatwiej odpowiedzieć.
W kwestii tyldy przy obiektach - służy ona do oznaczenia, że dany obiekt reaguje odwrotnie na stan. W przypadku pól siłowych oraz znikających platform oznacza czy wybrano "Odwróconą aktywację". Czyli jeśli stan jest na "Prawda" to obiekt jest nieaktywny. W przypadku przycików tylda pojawia się jeśli rodzaj przycisku jest "Wyłącza". To oznacza, że wcisnięcie przycisku ustawia stan na "Fałsz". Program nie pokazuje na planszy aktualnej wartości stanu tylko jego numer. Rozumiem jednak, że przydałaby się taka wizualizacja - generalnie do przemyślenia.
Mam nadzieję, że udało mi się odpowiedzieć na większość pytań. Jakby co to można śmiało pisać i dalej dopytywać o wątpliwości oraz sugerować zmiany.
Zasadę tyldy rozumiem :) tak jak mówiłem, fajnie, że jest :) To pozwolę sobie rozwinąć punkty: 1) Wiadomo, że wszystko zależy od obiektu. Murki i platformy - sprawa jasna. Przykładowo łapię za pionowy murek od dołu - mogę go wydłużyć. Łapię od góry - jednocześnie wydłużam i przesuwam do góry :) (czyli niby rozciągam do góry) analogicznie poziomy. Potworki mogą mieć rozciągany zakres ruchu na brzegu, oraz łapiąc za niego można mu zmienić offset itd. 3 i 4) tak, zależy oczywiście od focusa, ale wydaje się, że to byłoby intuicyjne. 5) chodzi faktycznie o jakieś dodatkowe menu z listą obiektów, tyle że od razu z ich wyglądem, imo będzie to od razu bardziej czytelne. Przy czym mogłoby to działać na zasadzie drag&drop. Czyli klikam w ikonkę i przeciągam na planszę tam, gdzie chcę to postawić. 6) Tak, kopiuj wklej, lub często spotykane "duplikuj". 7) Chodzi o operację zmiany stanu na przeciwny. Obecnie przycisk może tylko WŁĄCZAĆ lub WYŁĄCZAC, niezależnie ile razy go nadepniesz. Przycisk zmiany zmieniłby go na przeciwny do obecnego. czyli stan = !stan, albo jak kto lubi stan ^= true :D
Ad 1) Myślę, że jest to do zrobienia. Wstępnie nawet przymierzałem się do tego po tym jak wprowadziłem przesuwanie obiektów przez przeciąganie po planszy. Z platformami i robotami byłaby to bardziej kontekstowa manipulacja, ale też sobie to wyobrażam. Troszkę więcej byłoby zabawy z zakodowaniem takiej logiki, ale nie jest to rocket science.
Ad 3,4) Prawdopodobnie wystaczy dodać możliwość fokusowania na obiekcie planszy i tym samym przejąć obsługę klawiatury. Powinno być łatwe do wykonania.
Ad 5) Rozumiem, że motywacja do zmiany jest taka, że jest zbyt dużo obiektów do wyboru i chodzi o usprawnienie w procesie wyboru tego właściwego. Wiadomo, że pismo obrazkowe ma przewagę nad tekstami.
Ad 6) Da się zrobić.
Ad 7) Teraz rozumiem, że chodzi o zmianę mechaniki w grze. Obecnie przyciski albo tylko włączają albo tylko wyłączają stan a nie przestawiają go naprzemiennie. Co ciekawe we wczesnej fazie rozwoju gry przyciski właśnie tak działały jak wspomniałeś - czyli przestawiały stan na przeciwny. Można to nawet zobaczyć w filmiku "Making of Time Wizard". To jednak nie dawało możliwości projektowania pewnego rodzaju zagadek na planszy, w których należy przejść do konkretnego przycisku, żeby uaktywnić lub zdezaktywować dany obiekt a potem przejść do innego miejsca, żeby odwrócić efekt. Oczywiście mógłbym przywrócić przyciski przełączające stan jednak dobrze byłoby rozważyć inny wygląd takowych, żeby odróżniały się od obecnych. W przeciwnym przypadku używanie tak samo wyglądających obiektów zupełnie inaczej działających byłoby mylące dla gracza. Muszę to na spokojnie przemyśleć.
Ogólnie rzecz biorąc chciałbym skupić się na przenoszeniu gry na kardridż i tym samym przygotować się do fizycznego wydania. W międzyczasie przygotowałem edytor poziomów, żeby dać szansę pobawienia się innym i tym samym dodania poziomów nie tylko ode mnie ale także od graczy. Pewne poprawki i usprawnienia do edytora na pewno przygotuję pod warunkiem, że nie zajmą mi zbyt dużo czasu. Co do zmiany mechaniki gry, w tym dodanie nowych elementów (o których też intensywnie myślę), to zostawiam na czas po przeniesieniu gry na kardridż. Dla mnie teraz największym priorytetem jest takie przerobienie gry, żeby działała m.in. na stockowym Atari z 64kB RAMu.
