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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorrav
   • CommentTime3 Mar 2010

    
   Witajcie!
   
   Z kilku źródeł otrzymałem sygnały, że dobrze byłoby założyć oddzielny wątek dedykowany dyskusji na temat mechaniki rozgrywki w RobboNG (a co za tym idzie - również w oryginalnej wersji Robbo). Dla mnie byłoby bardzo wygodne aby wszelkie dyskusje na ten temat zebrane były w jednym miejscu. Chętnie poczytałbym również o Waszych pomysłach odnośnie rozszerzenia mechaniki gry o nowe elementy.
   
   Na początek kilka kwestii z mojej strony. Otóż w trakcie tworzenia silnika RobboNG natrafiłem na kilka zagadek, na które do dziś nie znam odpowiedzi. Być może ktoś z Was mógłby mi pomóc je rozwiązać...
   
   1. Fala śmierci kontra laser/blaster.
   
   Czy ktoś z Was wie, w jaki sposób zachowuje się wiązka lasera (bądź blastera) wpadając w falę śmierci? W oryginalnym Robbo na żadnej z plansz nie występuje taki scenariusz. Problem polega na tym, że fala śmierci (w opisie Robbo zamieszonym w Tajemnicach Atari nazwana "gumą") wymazuje to co pod nią wpadnie. O ile wiązka lasera\blastera uderzy w falę, to nie ma problemu - w przypadku wiązki lasera zacznie się ona cofać, a w przypadku blastera - zatrzyma się w tym miejscu. Za to jeśli wiązka taka wpadnie w dziurę pomiędzy elementami fali i fala na nią "wjedzie" to... No właśnie - co wtedy? Zakładam, że wiązka lasera nie może być przerwana w połowie... Czy ktoś zna jakąś planszę w którejkolwiek z wersji Robbo, gdzie takie zjawisko występuje?
   
   2. Niszczenie lasera (działa) z "wypuszczoną" wiązką
   
   Da się to zrobić za pomocą bomby. Pomimo zniszczenia działa, wiązka pozostaje. Co więcej, po tym jak zostanie ona "zwinięta", zamienia się w... pojedynczy strzał, który leci w kierunku odwrotnym do kierunku wiązki. W RobboNG ten pojedynczy strzał sobie (na razie) odpuściłem - wydaje mi się bardzo dziwaczny. Czy znacie jakieś plansze, które wykorzystują ten efekt? Czy uważacie że element ten powinien pojawić się w RobboNG?
   
   3. Kilka robocików na jednej planszy
   
   Ponoć da się to zrobić i są plansze korzystające z tego "efektu". Czy ktoś wie dokładnie na czym to polega? Czy oryginalny silnik Robbo to obsługuje? Co sądzicie o sensowności tego?
   
   4. Różnice pomiędzy silnikami Robbo i Robbo Konstruktora
   
   Najbardziej fundamentalna różnica to oczywiście stworki. Oprócz tego zauważyłem, że w oryginalny Robbo jest nieco inna sekwencja wybuchu bomby. Również zasady teleportacji wydają się nieco inne (chodzi konkretnie o sytuację gdy docelowe pole jest zajęte). Czy ktoś z Was zna jakieś inne różnice?
   
   5. Algorytm ruchu stworków
   
   Ten temat do dziś spędza mi sen z powiek...;) W dużej mierze udało mi się odtworzyć mechanikę ruchu stworków, ale jest jeszcze kilka otwartych kwestii. Przede wszystkim chodzi mi o a) opóźnienia w ruchu stworków - w jakich sytuacjach powinny występują; b) interakcja stworków z innymi stworkami - jak powinny zachowywać się dwa stworki wpadające na siebie, tudzież stworek wpadający na ptaka, itd. Mam wrażenie, że to co zaimplementowałem w RobboNG nie do końca pokrywa się z oryginałem... Chętnie poczytałbym przemyślenia twórców innych portów Robbo w tym temacie.
   
   Ufff, na razie to tyle. Będę wdzięczny za wszelkie odpowiedzi.
2. • 2: CommentAuthorneurocyp
   • CommentTime3 Mar 2010

    
   Nie wiem, jak w oryginalnym Robbo, ale w GNU Robbo, gdy działo z ciągłym laserem zostanie przesunięte(bo w GNU RObbo każdy typ działa może być ruchomy w każdym kierunku)/obróci się(co nie powinno się zdarzyć, bo zaimplementowana jest blokada obracania podczas strzalu)/zostanie zniszczone, to cały promień jest niszczony.
   nie badaliśmy problemu bariery/gumy/rzeki ostrzeliwanej z blastera, jednak podejrzewam,ze to jest tak, że jeśli pocisk jest na płaszczyźnie natarcia bariery, to bariera go kasuje, ale tego nie sprawdzałem.
   co do potworków, to w oryginalnym Robbo jest taki nieprzyjemny bład, który powodował, ze potworki mogły się kręcić w kółko "w powietrzu", to chyba lepiej byłoby w Robbo NG poprawić.
3. • 3:
      
     CommentAuthorKaz
   • CommentTime3 Mar 2010

    

   neurocyp:

   taki nieprzyjemny bład, który powodował, ze potworki mogły się kręcić w kółko "w powietrzu", to chyba lepiej byłoby w Robbo NG poprawić.

   
   
   Ja bym tego nie poprawial, ewentualnie tylko jako opcja (do nowych plansz). Czasami tylko dzieki temu zapetleniu dawalo sie dana plansze przejsc.
4. • 4: CommentAuthorgieniowski
   • CommentTime3 Mar 2010

    
   No i ja się trochę tutaj wypowiem, bo jak najbardziej problem dotyczy także mojej wersji robbo.
   
   Ad. 1.
   Moje domysły na podstawie własnej znajomości oryginalnego silnika:
   Co do blastera to wydaje mi się, że bariera|fala przejdzie przez niego bez problemu, przód blastera poleci dalej jak gdyby nic się nie stało, a tył po prostu zniknie w normalny sposób (animacja wybuchu dobiegnie końca).
   Laser jest bardziej skomplikowany. Tutaj będę miał niesamowitą teorię, ale wydaje mi się, że laser za barierą będzie poruszał się w normalny sposób i w drodze powrotnej wygeneruje strzał na wysokości bariery. Laser przed barierą zrobi jedno z dwóch: albo zachowa się jak normalny laser i po prostu wróci (czyli cały laser zostanie zamieniony na dwa lasery) lub będzie to bug w grze i na mapie pozostanie statyczna animacja lasera :)
   Oczywiście wszystko można sprawdzić generując odpowiednie mapy w konstruktorze Poklika.
   Ad. 2.
   Według mnie jest to jak najbardziej pożądany efekt.
   Ad. 3.
   W etapach które ostatnio dodałem do swojej gry już ten motyw występuje. Nawet nie sprawdzałem co się stanie... Mimo wszystko zacząłem się zastanawiać jak rozwiązać ten problem i również wydaje mi się, że należy to zaimplementować.
   Ad. 4.
   Co do stworków to z tego co zauważyłem różnica jest tylko przy ustaleniu początkowego ruchu. W oryginalnym Robbo każdy stworek na mapie posiada już przypisany kierunek w którym będzie starał się iść.
   Proszę powiedz coś więcej na temat teleportów i wybuchów bomb. Nie zwracałem na to uwagi, ale też nie widziałem różnic.
   Ad. 5.
   Wydaje mi się, że ruch stworków udało mi się dość dokładnie odtworzyć. Opiszę przykładowo na czym to polega na przykładzie stworka leworęcznego.
   -Stworek ma określony kierunek w którym się porusza, na przykład do góry.
   -Na początek sprawdzam czy może poruszyć się w lewo
   --tak - idź w lewo, ustaw kierunek ruchu w lewo
   --nie - idź do góry, sprawdzenie czy mogę
   ---tak - idź
   ---nie - sprawdź czy drogę blokuje stworek tego samego typu
   ----tak poczekaj jedną turę (tylko jedną, drugi raz nie można czekać)
   ----nie - ustaw kierunek w prawo, ale nie idź (czyli jedna klatka opóźnienia)
   
   To co dla mnie jest największym problemem i gdzie nie chcę dążyć do zachowania idealnego z oryginałem to sposób w jaki postępuje update całej planszy w oryginale. Całość polega na update każdego pola planszy począwszy od lewego górnego rogu do prawego dolnego rogu. Wynika z tego, że niszcząc coś strzałem lecącym z lewej na prawo lub z góry na dół animacja zniszczenia jest o jedną klatkę krótsza przez to, że w tej samej turze następuje jej update do kolejnej pozycji. Z tego też wynika, że barierę łatwiej jest minąć Robbo idąc z dołu do góry, niż z góry do dołu :) Podobnie mają się tutaj kolizje ptaków czy strzałów poruszających się prostopadle do siebie. W jednym przypadku mogą się po prostu zamienić miejscami i kontynuować ruch, w drugim odbić się|zniszczyć. Pomimo tego, że jest to łatwe w implementacji uważam, że jest to zachowaniem niepożądanym a współczesne programowanie obiektowe pozwala w naturalny sposób to wyeliminować.
5. • 5:
      
     CommentAuthorgolem14
   • CommentTime3 Mar 2010 zmieniony

    
   Nie trzymał bym się tak sztywno oryginału, który powstał na ograniczoną platformę, przez co pewnie nie wszystko dało się "oskryptować".
   Jeśli zaś chodzi o nowinki, to wpadły mi dziś do głowy dwa pomysły:
   1. Możliwość ustalania zawartości niespodzianek przez twórcę planszy. W oryginale niespodzianka losowana jest z pewnego zbioru elementów, który jest spory ale niezbyt "ciekawy" z fabularnego punktu gry. Można by pomyśleć nad sytuacją, gdy twórca zestawu planet definiuje kilka zbiorów niespodzianek (np. same "złe", jednoelementowe itp.) po czym do danego znaku zapytania na mapie przypisuje konkretny zbiór niespodzianek. Silnik nie losuje wtedy niespodzianek ze standardowego zbioru, lecz innego. I tak zaskoczony gracz strzelając do jakiejś niespodzianki zawsze dostaje np. oczy ;-)
   2. Power-upy! Robbo mimo, że robot, to słaby jest np. może przesunąć tylko jedną kratkę (sic!). A gdyby dodać jakiegoś "energy shot'a" ;-), który trzeba zdobyć, aby móc np. przesunąć dwie kratki lub np wytrzymać chwilowe zetknięcie z wrogiem (pojedynczy strzał z lasera itp.).
6. • 6: CommentAuthorhlipoz
   • CommentTime3 Mar 2010

    
   Witam wszystkich tu obecnych. Fajnie znaleźć się wśród Robbo-maniakalnej ekipy :-)
   
   golem 14:
   Co do pkt1 moim zdaniem fajna propozycja. Wtedy możliwe byłoby przypisanie do konkretnego znaku zapytania np. klucza lub naboi i gracz musiałby "otworzyć" ten (?) bo inaczej nie mógłby przejść planszy. Pytajniki stałyby się bardziej istotnym elementem rozgrywki.
   
   Co do pkt2 to jakoś nie jestem przekonany do przesuwania grupy bloczków (dwóch lub więcej). Może jestem po prostu zbytnim Robbo-tradycjonalistą chociaż poniżej zamieszczam swoje propozycje nowych elementów.
   
   1.Magnesy poziome i pionowe:
   W związku z rozbudową pola gry proponuję wprowadzić coś takiego jak zasięg działania magnesów. Normalnie w Robbo mamy tylko magnesy poziome. Ich zasięg jest oczywiście niewiększy niż szerokość planszy minus jeden (15 pól). Z chwilą wprowadzenia szerszych plansz wydaję mi się, że grywalność może zostać znacznie ograniczona przez magnes poziomy, który przyciągnie robocika z odległości np.100 pól. W związku z tym moja propozycja to ograniczenie działania magnesów pionowych i poziomych do 15 pól.
   Oznaczałoby to dla gracza, że takie pole można bezpiecznie obejść w pewnej odległości, ale oczywiście to „obejście” trzeba będzie sobie wypracować. Oprócz tego pozostaje znana możliwość zasłonięcia magnesu jakimś dostępnym elementem.
   
   2.Działka przesuwne:
   Każdy zna działka, które można przesuwać strzelające do góry. Proponuję dodać działka przesuwne, które strzelają w lewo lub w prawo samoczynnie poruszające się w pionie oraz działka strzelające w dół samoczynnie przesuwające się w poziomie.
   
   3.Dmuchawy (poziome i pionowe):
   Działanie podobne do magnesów, ale z pewnymi istotnymi różnicami. Jeśli robocik wszedłby w linię oddziaływania dmuchawy to prąd „powietrza” spychałby go na odległość 15 pól od dmuchawy. W przypadku dmuchawy poziomej ruch poziomy byłby wymuszony (jednak w każdej chwili byłaby możliwa ucieczka ze strumienia powietrza w górę lub dół).
   Analogicznie w przypadku dmuchawy pionowej ruch w pionie byłby wymuszony (w każdej chwili byłaby możliwa ucieczka w lewo lub w prawo).
   Jak widać oddziaływanie dmuchawy na robocika nie kończyłoby się jego zniszczeniem jak w przypadku magnesów, ale byłoby istotnym logicznym utrudnieniem.
   Czyli mielibyśmy przyciągające magnesy i odpychające dmuchawy.
   Dmuchawa podobnie jak magnes powinna przetrwać eksplozję bomby. Jeżeli pomiędzy robocikiem a dmuchawą zostałby umieszczony jakiś element dmuchawa nie aktywuje się (nie zdmuchuje ani elementu ani robocika).
   
   4.Śluzy jednokierunkowe:
   Działanie: przejście tylko w jedną stronę (bez potrzeby używania klucza albo innych gadżetów). Powrót niemożliwy. Śluza podobnie jak teleport powinna ulegać zniszczeniu w wyniku eksplozji bomby.
   
   5.Oczywiście warto skorzystać ze strzelającej bomby rodem z Alex’a.
7. • 7:
      
     CommentAuthorgolem14
   • CommentTime3 Mar 2010 zmieniony

    
   @hlipoz
   Skoro rav robi silnik kompatybilny wstecz, to lepiej by miał on więcej w zanadrzu, niż mniej. Zawsze można zbudować takie planety, które będą działały z "klasyczną" mechaniką.
   Moim zdaniem słabość Robbo i podatność na strzały, magnesy itp. jest śmieszna - w końcu to robot a nie istota biologiczna. Takie magnesy np. nie zabijają innych stworków, jak i one nie zabijają się wzajem (poza ptaszkami, które "plują" kwasem). Może to i dobrze ale taki power-up uodparniający Robbo, jednorazowo lub czasowo np. na magnesy, strzały itp. jest lepszy niż np. ograniczone pole działania magnesu (przecież wystarczy dać jakąkolwiek przeszkodę, by nie oddziaływał na Robbo). Co więcej, taki power-up to kolejny element możliwy do zdobycia! Wyobraź sobie planetę, którą można przejść bez power-upa lub z nim ile tu możliwości do kombinowania.
8. • 8: CommentAuthorhlipoz
   • CommentTime4 Mar 2010

    
   @golem14
   Hmm, rzeczywiście zawsze można stworzyć planszę, która zachowuje klasyczną mechanikę Robbo… no i szkoda podcinać skrzydła rav’owi skoro ma taki zapał (lepiej żeby silnik pozwalał na więcej niż zbyt mało).
9. • 9: CommentAuthorrav
   • CommentTime5 Mar 2010 zmieniony

    
   @all:
   
   Dzięki wszystkim za odpowiedzi na moje pytania i propozycje nowych elementów! Zapowiada się fajna dyskusja! :)
   
   
   @neurocyp:
   
   Mi też się wydaje, że kręcące się "w powietrzu" stworki to nie błąd, tylko celowe zamierzenie autora Robbo. W tym względzie raczej pozostanę przy wersji oryginalnej.
   
   
   @gieniowski:
   
   

   Oczywiście wszystko można sprawdzić generując odpowiednie mapy w konstruktorze Poklika.

   
   
   To dobry pomysł! Może by się znalazł ktoś chętny zrobić taki eksperyment? U mnie z czasem ostatnio bardzo kiepsko. Jak by ktoś posprawdzał i opisał te scenariusze to by była bardzo duża pomoc dla mnie. Btw. można by przy okazji sprawdzić scenariusz z kilkoma robocikami na planszy.
   
   Dzięki za dokładny opis Twojego algorytmu ruchu stworków. Jest on w dużej mierze podobny do mojego, ale są pewne różnice. Może dzięki temu uda mi się wyeliminować otwarte kwestie, o których wspominałem w pierwszym poście.
   
   

   Proszę powiedz coś więcej na temat teleportów i wybuchów bomb. Nie zwracałem na to uwagi, ale też nie widziałem różnic.

   
   
   W przypadku bomb, w oryginalnym Robbo, wybuch jest zaimplementowany w dwóch fazach. Najpierw pojawiają się cztery eksplozje na dole, a - o krok gry później - pięć na górze. Za to w Robbo Konstruktorze wszystkie dziewięć eksplozji pojawia się jednocześnie. Rzuć okiem na zrzuty ekranu z załącznika to zobaczysz o co chodzi. Na początku zacząłem implementować tę dwu-fazową opcję, ale miałem z tym spore problemy w przypadku wybuchów wielokrotnych. I w końcu zaimplementowałem wersję z RK :) Ta różnica nie wpływa chyba na przebieg rozgrywki...
   
   Co do teleportów, to chodziło mi o reguły przechodzenia. Np. Robbo wchodzi w teleport z lewej strony - więc powinien wyjść z prawej strony docelowego teleportu. Ale tam jest np. ściana. Więc pojawia się w innym, wolnym miejscu. W Robbo Konstruktorze sprawdziłem wszystkie dostępne kombinacje i na tej podstawie zrobiłem sobie tablicę przejść. No a potem, testując levele w oryginalnym Robbo widziałem, że w niektórych przypadkach trochę inaczej się to zachowuje. Przykładem może być tu planeta nr. 16 (jak spróbujesz przejść tę planetę w RobboNG to zobaczysz o co chodzi :)). Co gorsza - te różnice mają wpływ na rozgrywkę.
   
   

   To co dla mnie jest największym problemem i gdzie nie chcę dążyć do zachowania idealnego z oryginałem to sposób w jaki postępuje update całej planszy w oryginale. ... Pomimo tego, że jest to łatwe w implementacji uważam, że jest to zachowaniem niepożądanym a współczesne programowanie obiektowe pozwala w naturalny sposób to wyeliminować.

   
   
   No, ja raczej zostanę tutaj przy klasycznym - zgodnym z oryginałem podejściu. A swoją drogą to trochę mnie zaintrygowałeś... - jak zamierzasz ten problem wyeliminować? Elementy planszy tak czy siak musisz przetwarzać sekwencyjnie - niezależnie od tego czy są one w jednej tablicy czy zgrupowane w kontenerach...

   • bomby.zip
10. • 10: CommentAuthorrav
    • CommentTime5 Mar 2010

     
    Jeszcze jedno pytanie: gdzieś czytałem, że przy zniszczeniu niespodzianki jest możliwość, że zniszczone będą wszystkie stworki i drzwi na całej planszy. Grając w oryginalne Robbo nigdy się z tym nie spotkałem. Czy takie zachowanie rzeczywiście występuje? Czy ktoś mógłby je dokładnie opisać?
11. • 11: CommentAuthorgieniowski
    • CommentTime5 Mar 2010 zmieniony

     
    @rav
    Jeśli chodzi o bomby, okazuje się że za dużo ostatnio pracowałem z konstruktorem, bo po prostu o tym zapomniałem... Kiedyś na pewno widziałem takie zachowanie :)
    

    A swoją drogą to trochę mnie zaintrygowałeś... - jak zamierzasz ten problem wyeliminować? Elementy planszy tak czy siak musisz przetwarzać sekwencyjnie - niezależnie od tego czy są one w jednej tablicy czy zgrupowane w kontenerach...

    
    W takim razie nic nie stoi na przeszkodzie aby dany element planszy zawierał pole isUpdated. Przy wstawieniu nowego wybuchu wartość jest ustawiona na true, kiedy nadejdzie pora jego update to po prostu nic się nie dzieje :) W ten sposób działa moja wersja robbo.
    A co do teleportów to muszę się temu przyjrzeć dokładniej.
12. • 12:
       
      CommentAuthorgolem14
    • CommentTime5 Mar 2010

     
    @rav
    Zaskoczonym bardzo! Nie spotkać tego efektu??? Lepsze jest chyba tylko dostanie statku gotowego do startu!
    Po strzale w "?" dostajesz życie na miejscu niespodzianki, słychać odgłos wybuchu(bodajże - niech mnie ktoś poprawi) i niszczone są wszystkie stworki oraz drzwi (efekt ja przy zniszczeniu Robbo dla każdego elementu). Nie pamiętam tylko, czy przed zniszczeniem stworki są zatrzymywane.
    Zgodnie z testami Beliala
    ->link<-
    prawdopodobieństwo takiego zajścia jest około:
    "życie* - 7,7%"
13. • 13: CommentAuthorhlipoz
    • CommentTime5 Mar 2010

     
    @rav
    Golem14 ma rację jeśli chodzi o niespodziankę powodującą zabicie wszystkich stworków i zniszczenie drzwi. Zdarzyło mi się to kilka razy w Robbo, Robbo II i chyba w Alex’ie (chociaż szczerze mówiąc wczytywałem wtedy ostatniego save’a stanu emulatora, bo zbyt mocno ułatwia to rozgrywkę).
    Odbywa się to następująco: pytajnik znika a w jego miejsce dostajesz bonusowe życie, następuje błysk ekranu i dźwięk identyczny z tym po zebraniu wszystkich śrubek, stworki i drzwi znikają. Nie pamiętam czy jest to „natychmiastowe” zniknięcie czy towarzyszy temu dymek jak po wybuchu bomby, ale raczej to drugie.
    
    Co do różnic między oryginalnym silnikiem a silnikiem RobboNG.
    Jest drobna różnica chociaż nie ma absolutnie żadnego wpływu na rozgrywkę, ale sprawia że Robbo pomimo że porusza się skokowo wydaję się bardziej „animowany”. W RobboNG jest tak, że np. idąc w dół Robbo ma na przemian antenki na głowie raz w górze raz w dole. Kiedy gracz kończy ruch Robbo po prostu zatrzymuje się a pozycja antenek zależy od tego na której klatce ruch się zakończył.
    
    W oryginale jest inaczej. Gdy ruch się kończy np. z antenkami w górze to po ułamku sekundy antenki opadają. Dotyczy to właściwie ruchu w każdą stronę. Zawsze po zatrzymaniu Robbo następuje jeszcze jedna klatka animacji.
14. • 14:
       
      CommentAuthorgolem14
    • CommentTime5 Mar 2010

     
    Wylosowanie ekstra życia wygląda tak jak na zamieszczonym niżej filmie (na samym końcu):
    

    
    Jak widać znikają wszelkie "żywe" stworki, drzwi oraz magnesy. Nie znikają armatki.
    Samo wylosowanie ekstra życia nie jest tak trudne, w kilka minut zdarzyło mi się to dwa razy na testowej planecie (pierwszego nie nagrałem).
15. • 15: CommentAuthorBelial
    • CommentTime5 Mar 2010

     
    W oryginalnym silniku magnesy zamieniają się w ściany. IMO jest to lepsze rozwiązanie bo nie pojawiają się niezaplanowane przez autora przejścia.
16. • 16: CommentAuthorrav
    • CommentTime7 Mar 2010

     
    @golem14:
    
    Dzięki serdecznie za szczegółowy opis mechanizmu niszczenia stworków\drzwi\magnesów przez niespodziankę. Sam się zastanawiam jak to się mogło stać, że nigdy nie zauważyłem tego w trakcie gry :O Aczkolwiek teraz wiem już dokładnie o co chodzi i postaram się odwzorować to w RobboNG.
    
    

    Lepsze jest chyba tylko dostanie statku gotowego do startu!

    
    
    A to akurat w RobboNG jest zaimplementowane! :)
    
    
    @hlipoz:
    
    Hihi, zastanawiałem się kto pierwszy zauważy tę różnicę :) Rzeczywiście, animacja głównego bohatera w RobboNG różni się troszkę od tej oryginalnej. Jest jeszcze jedna ciekawostka z tym związana. Otóż po każdym ruchu, który wymaga zmiany kierunku Robbo, kiedy bohater przechodzi na kolejne pole to przez chwilę jest reprezentowany przez tą samą klatkę animacji. W rezultacie gdy Robbo zmienia kierunek to wygląda to tak, jak by robił krok stojąc tyłem, a dopiero potem (na nowym polu) się odwracał... Najlepiej da się to zaobserwować w zwolnionym tempie pod emulatorem. Dzieje się tak tylko w oryginalnej wersji Robbo; w RK animacja bohatera działa już "normalnie" - tak jak w RobboNG. Pojawia się pytanie: co z tym zrobić? Mi osobiście wydaje się, że animacja w oryginalnym Robbo jest troszkę... udziwniona. Zastanawiam się, czy był to celowy zabieg autora czy może wynik jakiegoś dziwnego ograniczenia. Oczywiście - mogę to zaimplementować. Nie wiem tylko czy warto się w to bawić... W tym przypadku skłaniam się raczej ku temu aby (tak jak w przypadku wybuchów bomb) zachować kompatybilność z RK. Co sądzicie?
    
    @Belial:
    
    

    W oryginalnym silniku magnesy zamieniają się w ściany. IMO jest to lepsze rozwiązanie bo nie pojawiają się niezaplanowane przez autora przejścia.

    
    
    Zgadzam się z Twoją opinią. Tak właśnie planuję zaimplementować to w RobboNG.
    
    
    @all:
    
    Czy komuś udało się może sprawdzić scenariusz laser\blaster vs. fala śmierci?
17. • 17: CommentAuthorrav
    • CommentTime7 Mar 2010

     
    @hlipoz, golem14:
    
    Serdeczne dzięki za fajne pomysły odnośnie nowych elementów silnika. Poniżej moje komentarze:
    
    1. Magnesy poziome i pionowe
    
    Pomysł z ograniczeniem zakresu działania magnesów nie do końca do mnie przemawia. Złapanie Robbo przez daleki magnes to rzeczywiście problem, ale IMHO - za unikanie tego typu niestosownych pułapek odpowiadać powinien raczej projektant planszy, a nie silnik gry. Wpadł mi kiedyś do głowy pomysł, że w momencie gdy magnes oddziaływający na pola znajdujące się w oknie gry jest niewidoczny, to można by jakoś to zaznaczyć (np. linią umieszczoną z boku okna gry, na wysokości tegoż magnesu), tak żeby gracz wiedział gdzie czai się niebezpieczeństwo. Na mocniejszych platformach można by użyć jakiegoś fajnego efektu post-processing'owego (np. heat haze, czy coś w tym guście...) do oznaczania obszarów na które wpływa magnes.
    
    2. Działka przesuwne
    
    W tym przypadku mam dobrą wiadomość! :) Opisane wyżej działka są już w RobboNG zaimplementowane. Nie widać ich tylko, bo na razie upubliczniłem wersję gry z etapami z oryginalnego Robbo. Podobnie zaimplementowałem wszystkie kombinacje strzelających ptaków.
    
    Prace nad RobboNG powoli, aczkolwiek systematycznie idą do przodu i moment w którym będę w stanie udostępnić wersję z możliwością edycji własnych plansz zbliża się. Wtedy będzie można to wszystko przetestować. Proszę o jeszcze trochę cierpliwości :)
    
    3. Dmuchawy
    
    Według mnie - super pomysł: naturalne przeciwieństwo magnesów. Nie jestem może do końca przekonany czy ich zasięg powinien być ograniczony (IMHO: raczej nie), ale - sama koncepcja bardzo mi się podoba. Implementacja tego nie powinna być trudna...
    
    4. Śluzy jednokierunkowe
    
    Też fajny pomysł (przyznam się, że sam o tym myślałem).
    
    5. Bomba a'la Alex
    
    Jak najbardziej! Btw. czy ktoś wie jakie jeszcze rozszerzenia wprowadza Alex? Czytałem gdzieś niedawno wzmiankę o ptakach plujących kwasem... O co w tym chodzi?
    
    6. Możliwość ustalania zawartości niespodzianek przez twórcę planszy
    
    Pomysł dość ciekawy... Widzę tylko pewien problem związany z opisywaniem definicji planszy. Zastanawiam się po prostu jak miałby wyglądać mechanizm do zarządzania tym z poziomu planowanego przez mnie edytora plansz (coś a'la Robbo Konstruktor). Na pewno da się to zrobić, ale kosztem dodatkowej roboty i zwiększenia stopnia komplikacji edytora. Zastanawiam się czy gra jest w tym przypadku warta świeczki...
    
    7. Power-upy
    
    Pomysł bardzo mi się podoba, tylko wymaga uszczegółowienia. Pierwsze co mi przychodzi do głowy to po prostu czasowa nietykalność Robbo (pytanie tylko czy aktywowana od razu po zebraniu power-up'a, czy później - na żądanie...). Tutaj widzę całkiem sporo fajnych możliwości fabularnych (np. power-up wymagany do przejścia fragmentu planety, którego w normalnych warunkach nie da się przejść, itp.). Co więcej - mechanizm "nieśmiertelności" jest już zaimplementowany w RobboNG (na razie tylko jako ułatwienie dla testerów), więc dodanie takich power-up'ów byłoby bardzo proste. Oczywiście można rozważyć więcej typów power-up'ów.
18. • 18: CommentAuthorBelial
    • CommentTime8 Mar 2010 zmieniony

     
    Fala i laser: teoria gieniowskiego (post 4 na stronie) sprawdziła się.
    Laser trafia w falę - efekt normalny, trafione pole fali znika.
    Fala kasuje pierwsze pole promienia - laser zatrzymuje się, promień pozostaje bez końca (bug opisany przez gieniowskiego).
    Fala kasuje środek promienia - to co za falą zachowuje się jak po wysadzeniu lasera (leci normalnie, po powrocie do ostatniego pola pojawia się strzał z działka), to co przed falą jak wyżej.
    
    Fala i blaster: trafienie w falę - trafione pole znika, wiązka leci dalej jeśli za trafionym polem była przerwa, jeśli nie to następne pole fali kasuje pierwsze pole wiązki która zatrzymuje się jak na ścianie.
    Fala kasuje pierwsze pole wiązki - fala nienaruszona, reszta wiązki jak wyżej.
    Fala kasuje środek wiązki - fala nienaruszona, *cała* wiązka leci dalej.
19. • 19: CommentAuthorrav
    • CommentTime8 Mar 2010 zmieniony

     
    @Belial:
    
    Serdeczne dzięki za szczegółowy opis wszystkich możliwych scenariuszy laser\blaster vs. fala śmierci!
    
    @all:
    
    W tej sytuacji nasuwa mi się kolejne pytanie: jak to powinno działać *poprawnie*? Zakładam, że autor oryginału założył, że taki scenariusz nie wystąpi i dlatego nie przejmował się błędami. O ile zachowanie wiązki blastera można jeszcze uznać za akceptowalne, o tyle zachowanie lasera to IMHO ewidentny bug. Być może właśnie z tego też powodu w RK nie są dostępne fale śmierci...
    
    Co sądzicie o takim rozwiązaniu, że po tym jak fala uderza w laser\blaster (pierwsze pole bądź środek wiązki) to cała wiązka jest niszczona? Wydaje mi się, że jest to dość rozsądne podejście...
    
    Może macie jakieś fajne pomysły jak by to można rozwiązać?
20. • 20:
       
      CommentAuthorgolem14
    • CommentTime8 Mar 2010 zmieniony

     
    @rav
    3. Dmuchawy
    OK, pod warunkiem, że nie zabijają Robbo a jedynie spychają z drogi. Jeśli zabijają (np poprzez zepchnięcie Robbo na ścianę), to robią to samo co magnes.
    
    6. Możliwość ustalania zawartości niespodzianek przez twórcę planszy
    Na sztywno definiujesz 5 tablic po X elemetów (najlepiej tyle, ile niespodzianek w oryginalnym Robbo). Tablica SECRT0 zawsze zapełniona jest oryginalnym zestawem z Robbo, SECRT 1-4 mogą być edytowane (ale zawsze na początku są wypełnione pustymi polami). W edytorze posługujesz się patentem z luster. Robisz 5 ikonek niespodzianki z numerkami od 0-4, które można sobie ustawić na planszy. Pod polem wyboru ikonek, albo na osobnej planszy dostępnej po kliknięciu przycisku (Edytuj zestawy niespodzianek) dajesz 4 rzędy pustych kratek do których twórca może sobie ściągnąć ikonkę odpowiedniego elementu. Twoja sprawa, czy będą to wszystkie elementy czy wybrane (ja uważam, że nie powinno być tam dostępnego Robbo - nie toleruje gier z większą ilością Robbo na planszy).
    Zapisując planetę, zestawy są zapisywane w formie wyedytowanej albo jako wartość "puste pole". Ponieważ niespodzianka "Zero" działa jak w prawdziwym Robbo - nie ma problemu. W przypadku, gdy na planszy jest niespodzianka np. "Trzy" a jej autor nie wyedytował - po każdym strzale ikona "?" znika i zostaje puste pole (prosta metoda na uniknięcie bugów).
    Moim zdaniem 4 edytowalne zestawy niespodzianek to wystarczająca ilość. Osobny problem, to prawdopodobieństwo losowania danego elementu. Można to zrealizować na zasadzie dodatkowych tabel z zapisanym prawdopodobieństwem - metoda brzydka albo równego prawdopodobieństwa dla każdego elementu. Mechanizm losujący wybiera element X z tabeli. Aby zwiększyć prawdopodobieństwo wylosowania danego elementu, trzeba go wstawić do tabeli więcej razy. Dla niespodzianki jednoelementowej cała tabela musi być wypełniona tym elementem.
    
    7. Power-upy
    Uważam, że Robbo powinien dostawać rodzaj tarczy od razu, która znika po pierwszej kolizji z "zabijaczem". Nie czasowo i nie na żądanie. Zbiera Power-Upa, zmienia się jego ikonka a jakaś zmienna np. RbbShield przyjmuje wartość 1. W momencie kolizji z jakimkolwiek "zabijaczem" (nawet polem magnesu) sprawdzana jest wartość RbbShield jeśli jest równa 0 Robbo ginie, jeśli równa 1 nie dzieje się nic, ale RbbShield jest zerowana i od tego momentu ochrona przestaje działać (zmienia się wygląd etc.) Można dodać do tego jakiś efekt graficzny - oczywiście.
    Teoretycznie to jedna dodatkowa pętla sprawdzająca dodana do mechanizmu detekcji kolizji w praktyce może być gorzej. Dotknięcie przez stworka to jeden moment ale pole magnesu działa cały czas. Jak to rozwiązać? Jeśli Robbo szybko przebiegnie przez pole to mu nic nie jest - czy też, może on stać dowolnie długo na polu działania magnesu a ochrona znika po jakimkolwiek ruchu.
    Ponadto jak rozwiązać problem oddziaływania ochrony z falą śmierci, która zjada wszystko? IMO ochrona nie powinna oddziaływać z falą śmierci, tzn Robbo ginie.
    
    Można też rozważyć 2 power upy - opisany wyżej tj. tarcza, która chroni przed stworkami i działkami na takich zasadach jak opisałem ale nie działająca z magnesami i dmuchawami.
    Drugi power up to siła, która np. pozwala na: przesuwanie dwóch kratek, chodzenie po polu magnesu lub dmuchawy, zwiększa siłę strzału który działa jak Bomba (np. rozsadza drzwi). Taki power up może być czasowy lub na na żądanie (z czasowym ogranicznikiem - jak w Quake'u) choć ja preferuje rozwiązania z Dooma - bierzesz power-upa zaczyna tykać zegar! ;-)
    
    

    Co sądzicie o takim rozwiązaniu, że po tym jak fala uderza w laser\blaster (pierwsze pole bądź środek wiązki) to cała wiązka jest niszczona? Wydaje mi się, że jest to dość rozsądne podejście...

    
    Bardzo rozsądne.
21. • 21: CommentAuthorhlipoz
    • CommentTime8 Mar 2010

     
    Sądzę, że ruch Robbo powinien być kompatybilny z RK (wcześniej nie zdawałem sobie sprawy, że jest jakaś różnica między oryginalnym Robbo a RK).
    
    1. Magnesy poziome i pionowe
    Zastosowanie jakiegoś dodatkowego znacznika w celu informacji dla gracza, że za chwilę wejdzie w obszar działania magnesu lub dmuchawy przekonuje mnie. W tej sytuacji ograniczanie działania tych elementów nie jest potrzebne.
    BTW: Warto pomyśleć o opcji płynnego zoom +/- dla całej planszy. Dałoby to graczowi możliwość lepszego planowania strategii przejścia planety zwłaszcza przy dużych planszach.
    
    3. Dmuchawy
    Fajnie, że pomysł wzbudził akceptację jako naturalne przeciwieństwo magnesów. Tyle, że teraz pozostaje do rozpatrzenia kwestia interakcji dmuchaw. Na przykład jeśli Robbo jest spychany przez pionową dmuchawę i dostanie się w obszar działania poziomej dmuchawy. Co wtedy? Czy priorytet ma pierwsza dmuchawa czy też Robbo ma zostać „przejęty” przez prąd powietrza z drugiej dmuchawy? Wykluczam możliwość wypadkowego działania dwóch dmuchaw czyli spychania Robbo ukośnie pod kątem 45 stopni.
    W przypadku magnesów pionowych i poziomych też pojawi się nowe zjawisko interakcji, ale tu sprawa jest prostsza. Magnesy zawsze zabijają - dmuchawy nie.
    
    5. Elementy z Alex’a
    Kurczę doszedłem w Alex’ie do 36 planety i oprócz strzelającej bomby, która bardzo mi się podoba i często jest kluczowa dla rozgrywki, nic nowego nie zauważyłem. Nie doszedłem jeszcze do etapów gdzie jest podwójny Robbo więc nie mogę ocenić merytorycznie czy uatrakcyjnia to rozgrywkę. Póki co IMO to jest koncepcyjnie dość dziwne rozwiązanie.
    
    6. Zaplanowane niespodzianki (zwłaszcza te dające w wyniku tylko jeden konkretny element).
    Jestem za. Bardzo łatwo wyobrazić sobie sytuację gdzie pod pytajnikiem będzie ukryta bomba a’la Alex niezbędna w dalszej części rozgrywki.
    
    
    7. Power-up’y
    Podoba mi się bardzo pierwszy rodzaj Power-up’a tzn. działający od razu, bez ograniczeń czasowych (IMHO jeden z największych atutów gry to to że J.Pelc nie zastosował ograniczeń czasowych) i do pierwszego kontaktu z „zabijaczem”. Jestem za tym aby Robbo musiał szybko przebiec przez obszar działania dmuchawy/magnesu jeśli chce się uchronić przed odepchnięciem/przyciągnięciem.
    Wyjątek: power-up nie chroni przed falą śmierci.
    
    Kontakt fala z laser/blaster.
    Słusznie. Cała wiązka powinna ulec zniszczeniu.
22. • 22:
       
      CommentAuthorgolem14
    • CommentTime8 Mar 2010

     
    Sprawdziłem działanie niespodzianek na oryginalnym silniku Robbo. Na zamieszczonym poniżej filmie widać, iż rzeczywiście po wylosowaniu Ekstra Życia magnesy zamieniają się w murki.
    

    
    (film bez dźwięku).
    Widać też, że na silniku z RK i oryginalnym nie znikają armatki.
    Swoją drogą czy ktoś ma zestawienie różnic pomiędzy tymi silnikami.
23. • 23: CommentAuthorrav
    • CommentTime9 Mar 2010

     
    @golem14:
    
    

    Swoją drogą czy ktoś ma zestawienie różnic pomiędzy tymi silnikami.

    
    
    Ja mam trochę luźnych notatek, które robiłem sukcesywnie pracując nad grą. Ale one są w bardzo roboczej formie - nie nadającej się raczej do pokazywania komukolwiek. A tak swoją drogą, to myślałem kiedyś o tym, żeby zrobić dla RobboNG porządny GDD (Game Design Document), który opisywałby szczegółowo wszystkie mechanizmy gry. Taki dokument powinno się w zasadzie stworzyć *przed* rozpoczęciem implementacji gry, a nie w trakcie, tudzież po - ale w przypadku robienia remake'a sytuacja jest nieco inna... :) Wiele rzeczy powychodziło mi dopiero "w praniu". Bardzo przydatny byłby taki dokument - przede wszystkim dla wszystkich tych, którzy pracują nad remake'ami Robbo. No i wręcz bezcenny dla potomności :)
    
    Niestety, z powodu braku czasu pomysł ten odłożyłem na nieokreśloną przyszłość. Aczkolwiek, może jakoś zbiorowym wysiłkiem dałoby się coś takiego opracować... Gdyby ktoś był chętny poświęcić na to czas, to ja chętnie służę swoimi notatkami i spostrzeżeniami.
24. • 24:
       
      CommentAuthorgolem14
    • CommentTime9 Mar 2010

     
    @rav
    Jakieś wiki może? Wspólnymi siłami wiele tu już zdziałano!
    
    @znawcy
    Jak tam wygląda sprawa z Atariki? Mamy tam jakieś wpływy? Może by na tej bazie?
25. • 25:
       
      CommentAuthorKaz
    • CommentTime9 Mar 2010 zmieniony

     
    Zarejestruj sie w Atariki to sam bedziesz mogl dodawac informacje. To dziala jak Wikipedia.
26. • 26: CommentAuthorhlipoz
    • CommentTime9 Mar 2010

     
    A co z teleportowaniem? Sprawdziłem etap16 w RobboNG i rzeczywiście przy tak działających teleportach nie da się przejść. Sprawdziłem to samo w NewRobbo gieniowskiego na komórce i tam teleportacje są jak w oryginale. On mógłby coś tu pomóc, bo prawidłowo zaimplementował to do swojej wersji.
27. • 27: CommentAuthorneurocyp
    • CommentTime9 Mar 2010

     
    kiedyś spędziłem chwilkę na eksperymentach z teleportami w konstruktorze i doszedłem do takiej tabelki:
    Rd Rb Tb1 Tb2 Tb3 Tb4 /|\
    --+--+----+----+-----+----+ kierunki : 3
    0 00|0 00 3 11 1 01 2 10
    1 01|1 01 2 10 0 00 3 11 <-2- -0->
    2 10|2 10 1 01 3 11 0 00 1
    3 11|3 11 0 00 2 10 1 01 \|/
    Rd - kierunek w którym Robbo wchodzi do teleportu
    Tb1 - kierunek wyjścia z niezablokowanego teleportu
    Tb2 - kierunek, gdy Tb1 zablokowane
    Tb3 - kierunek, gdy Tb1 i Tb2 zablokowane
    Tb4 - kierunek, gdy Tb1,Tb2 i Tb3 zablokowane
    
    nie wiem, jak to jest zaimplementowane w Robbo, ale w Robbo konstruktorze jest tak:)
    co ciekawe tak skonstruowane kierunki pozwalają na ciekawe uproszczenie procedury sprawdzającej, gdzie ma Robbo wyjść, doszedłem do czegoś takiego:
    Rb=Tb1
    Tb2=Tb1 xor 11
    Tb3=Tb2 xor 10
    Tb4=Tb3 xor 11
28. • 28: CommentAuthorneurocyp
    • CommentTime9 Mar 2010

     
    trochę rozjechało mi kierunki:)
    powinno być góra->3, prawo ->0, dół ->1, prawo ->2
29. • 29:
       
      CommentAuthorKaz
    • CommentTime9 Mar 2010 zmieniony

     
    Jezeli chcesz zachowac oryginalne formatowanie to warto uzyc znacznikow [ code ] i [ /code]:
    
    

    Rd Rb Tb1  Tb2   Tb3   Tb4                           /|\
    --+--+----+----+-----+----+           kierunki  :     3   
    0  00|0 00 3 11 1 01  2 10
    1  01|1 01 2 10 0 00  3 11                      <-2-    -0->
    2  10|2 10 1 01 3 11  0 00                            1
    3  11|3 11 0 00 2 10  1 01                           \|/
    Rd - kierunek w którym Robbo wchodzi do teleportu
    Tb1 - kierunek wyjścia z niezablokowanego teleportu
    Tb2 - kierunek, gdy Tb1 zablokowane
    Tb3 - kierunek, gdy Tb1 i Tb2 zablokowane
    Tb4 - kierunek, gdy Tb1,Tb2 i Tb3 zablokowane
30. • 30: CommentAuthorrav
    • CommentTime10 Mar 2010 zmieniony

     
    @golem14:
    
    Wiki to fajny pomysł! Ja jestem jak najbardziej za!
    
    
    @hlipoz:
    
    Naprawienie problemu z teleportacją (w kontekście planety 16 z oryginalnego Robbo) nie będzie raczej problemem... Boję się tylko, czy się nie okaże, że po naniesieniu poprawki jakieś inne plansze (robione dla odmiany pod RK) nie "popsują się" w podobny sposób. Pytanie za 100 punktów: czy zasady teleportacji rzeczywiście są różne w Robbo i RK, czy to ja coś skopałem :) Jeśli rzeczywiści się różnią to będzie problem ze wszystkimi planetami w których "fabuła" zależy od tych zasad.
    
    Btw. etap 16 raz udało mi się przejść z tym niepoprawnym teleportem :) Chociaż nie było łatwo...
    
    
    @neurocyp:
    
    Dzięki za tabelkę! Bardzo się przyda - porównam to ze swoją wersją. No i ciekawa ta procedura sprawdzająca.
31. • 31:
       
      CommentAuthorKaz
    • CommentTime10 Mar 2010

     
    Jeden z kolegow dyskutantow poprosil o odpalenie stronki dla milosnikow Robbo w domenie atarionline.pl. Tak tez sie stalo - czekamy na efekty w postaci tresci strony. Trzymam kciuki jako milosnik Robbo (ale nie taki totalny maniak jak Wy :D).
32. • 32:
       
      CommentAuthorMaW
    • CommentTime10 Mar 2010

     
    Co do teleportu: zróbcie także wersję II działającą jak w supaplexie - wejście z prawej to wyjście w innym z lewej, jeżeli lewa strona docelowego była zablokowana, to teleport po prostu nie działał.
33. • 33: CommentAuthorneurocyp
    • CommentTime10 Mar 2010

     
    MaW: w takim razie np. pierwszy poziom z Robbo Forever byłby nie do przejścia bez przeróbek.
    chyba jednak przydałoby się teleporty mieć jak najbliżej oryginału, a to stąd, że dobrze by było mieć jak najwięcej poziomów.
34. • 34: CommentAuthorhlipoz
    • CommentTime10 Mar 2010

     
    @MaW, neurocyp (ad. teleport supaplex)
    
    Wcześniej golem14 przekonywał mnie, że skoro RobboNG będzie kompatybilny wstecz to tego typu elementy nie stanowią problemu (wszak zawsze można zaprojektować planszę, która ich nie zawiera). No i rzeczywiście tak jest chociaż ten drugi typ teleportów musiałby mieć inną ikonę, żeby gracz wiedział z jakim teleportem ma do czynienia.
    
    Pomimo tego co napisałem wyżej jestem zdania, że te supaplexowe teleporty to tylko zubożona wersja oryginalnych. Oryginalne też można w rozmaity sposób blokować aby wymusić teleportowanie w odpowiednim kierunku. Po prostu oryginalne dają więcej możliwości fabularnych.
35. • 35: CommentAuthorneurocyp
    • CommentTime10 Mar 2010

     
    ja się zgadzam z tym, że oryginalne teleporty są najlepsze:)
36. • 36: CommentAuthorhlipoz
    • CommentTime11 Mar 2010

     
    Sprawdziłem na przykładzie etapu43 oryginalnego Robbo wszystkie możliwe konfiguracje przechodzenia przez teleporty. To samo zrobiłem używając Robbo Konstruktora.
    Wynik --> w Robbo i RK teleportowanie odbywa się identycznie i jest z godne z tabelą podaną przez neurocypa.
37. • 37:
       
      CommentAuthorMaW
    • CommentTime11 Mar 2010

     
    nie widzę problemu, żeby w dodatkowym zestawie znalazł się dodatkowy teleport inaczej rysowany (np. |X| zamiast []) - dało by to możliwość zmuszenia gracza do zmiany taktyki (gdy zły ruch zablokuje teleport) i jeszcze mocniejszego ruszenia głową; nie dość tego, docelowy teleport mógłby być startowym (czyli typowa śluza)
38. • 38: CommentAuthorhlipoz
    • CommentTime12 Mar 2010

     
    Skoro mielibyśmy mieć dwa rodzaje teleportów (classic, supaplex) to mam propozycję żeby śluzę jednokierunkową (i jej działanie) zaprojektować nieco inaczej niż tylko jednokierunkowe teleportowanie (de facto).
    
    Wyobrażam to sobie tak: śluza miałaby swoją własną ikonę z zaznaczonym (niekoniecznie strzałką) kierunkiem, w którym przepuszcza. Kiedy Robbo znalazłby się obok niej i gracz wykona ruch w jej stronę to widać jak śluza się otwiera (np.dwie klatki animacji) i po przejściu się zamyka (oczywiście w drugą stronę nie przepuszcza).
    Pozwoli to na uniknięcie „dymkowej” animacji charakterystycznej dla teleportowania. W przeciwnym razie śluza jednokierunkowa (jak byśmy jej nie nazwali) stanie się trzecim rodzajem teleportu o określonym (czyt. jednokierunkowym) sposobie działania.
39. • 39:
       
      CommentAuthorgolem14
    • CommentTime12 Mar 2010

     

    kaz:

    Jeden z kolegow dyskutantow poprosil o odpalenie stronki dla milosnikow Robbo w domenie atarionline.pl. Tak tez sie stalo - czekamy na efekty w postaci tresci strony. Trzymam kciuki jako milosnik Robbo (ale nie taki totalny maniak jak Wy :D).

    
    Jakiś team wokół tego jest?
    Jak rozumiem:
    

    Robbo is here! Please wait...
40. • 40:
       
      CommentAuthorKaz
    • CommentTime12 Mar 2010

     
    Nie wiem, czy jest team, poprosze jednak Miro (bo to on zalozyl) o wypowiedzenie sie w kwestii... :)
41. • 41: CommentAuthorprzyjazn
    • CommentTime12 Mar 2010

     
    Trochę mi się pomieszało z tymi loginami na różne strony i na atarionline.pl mam mój podstawowy.
    Wracając do sedna sprawy, obecnie tylko ja pracuję nad tą stronką, niemniej jestem bardzo chętny na współpracę.
    Ba, zapewne będzie potrzebna - jak widać na forum - wiele osób sprawdza mechanizm działania poszczególnych elementów.
    W zamierzeniu ma być to strona opisująca wszystkie wersje i wariacje na temat Robbo niezależnie od platformy, opisy poszczególnych elementów w grze i zapewne trochę linków do wywiadów, artykułów, itp. - wszystkie mające związek z grą Robbo.
    Postaram się przygotować wstępną wersję strony jak najszybciej. Proszę się przygotować na prostotę formy z porządną treścią.
42. • 42: CommentAuthorhlipoz
    • CommentTime13 Mar 2010

     
    @przyjazn, rav
    
    Stronka to świetny pomysł zwłaszcza, że rav ma w założeniach możliwośc up- i download'u plansz do RobboNG (wraz z możliwością ich oceniania).
    
    @all
    Wcześniej na forum zaproponowałem dmuchawy jako nowy element. Proponowałem tam aby spychany przez prąd powietrza Robbo mógł uciec w dowolnej chwili w kierunku poprzecznym do podmuchu. No i teraz… zmieniłem zdanie po przemyśleniach :-)
    
    Myślę, że ciekawsze jest rozwiązanie gdy Robbo będzie spychany aż do napotkania bariery (ściana, klocek, drzwi, laser). Dopiero wtedy mógłby opuścić strumień powietrza.
    
    W załączniku jest ilustracja do nieco sadystycznego przykładu :-) (uwaga: zastosowałem działko dla wizualizacji dmuchawy dmuchającej w prawo).
    
    Opis: Robbo popycha samobieżny klocek i rozpoczyna się reakcja łańcuchowa eksplozji bomb. Robbo biegnie do góry i musi w odpowiednim momencie poddać się działaniu dmuchawy. Jeżeli zrobi to zbyt szybko zostanie wepchnięty do pola przy bombie i tam czeka go koniec. Musi to zrobić w takim momencie, aby zatrzymać się na dymku eksplodującej bomby. Wtedy może szybko uciec do góry aby zebrać śrubkę.
    
    Przy okazji rozwiązuje to problem (przynajmniej częściowo) interakcji dmuchaw. Robbo po prostu jest spychany aż do napotkania bariery i inne dmuchawy nie mają na niego wpływu tak długo aż nie zostanie zepchnięty do końca (czyli do pola sąsiadującego z barierą). Wyjątek stanowiłyby tu magnesy, które IMO powinny mieć działanie nadrzędne tzn. byłyby w stanie wyciągnąć Robbo z prądu powietrza i przyciągnąć do siebie.
    
    Inna sprawa to możliwość oddawania strzału w polu działania dmuchawy. Aby dmuchawa nie oddziaływała na Robbo można ją zasłonić (jak magnes) jakimś elementem, ale można też strzelić w jej kierunku i biec za własnym strzałem (ten patent nie raz pewnie wykorzystywaliście w celu ochrony przed śmiercionośnym magnesem).
    
    Należy pamiętać o tym, że strzał w kierunku magnesu właściwie nie jest możliwy gdy na Robbo działa już pole magnetyczne lecz wcześniej gdy pomiędzy nim a magnesem znajduję się np. wypuszczony laser --> IMO ta sama zasada powinna obowiązywać w przypadku dmuchawy.
    
    PS. Z tymi dmuchawami to jest jeszcze kilka innych ciekawych problemów, które trzeba będzie rozstrzygnąć. Cholera, nie miała baba kłopotu… :-)

    • dmuchawa.jpg
      
      
      
      
43. • 43: CommentAuthorprzyjazn
    • CommentTime14 Mar 2010

     
    @golem14, rav, hlipoz
    
    To może ustalimy co ze stronką? Żeby się nie dublować, a stronka miała sens, chciałbym by jak najwięcej osób uczesticzyło w tworzeniu. Może więc zamiast zwykłej stronki, wrzucę tam jakieś wiki i każdy z nas będzie mógł opisywać nie tylko gry, ale mechanizmy, etc. Co wy na to?
44. • 44:
       
      CommentAuthorKaz
    • CommentTime15 Mar 2010

     
    No, ale na wikipedii czy atariki trzeba utrzymywac pewna konwencje i ograniczac sie do informowania, podczas gdy na wlasnej stronie mozna zrobic duzo wiecej.
    
    Tak wiec jestem za korzystaniem ze struktury wiki, ale jesli chodzi o to czy miescic sie w ramach gotowego serwisu (wikipedia, atariki) - to zalezy od tego, co ma byc na stronie. Jezeli tylko same suche informacje - to wystarcza, jesli cos wiecej - to dedykowana strona.
45. • 45:
       
      CommentAuthorMaW
    • CommentTime15 Mar 2010

     
    Kaz, na wiki możesz uruchomić panel dyskusyjny dla każdego artykułu
46. • 46:
       
      CommentAuthorKaz
    • CommentTime15 Mar 2010

     
    No i?
    
    Bedziesz tam na przyklad umieszczal artki fanow na temat Robbo? Zamiescisz tam pliki? Zamiescisz kopie gier z Robbo Konstruktora, ktorych status w swietle prawa nie jest znany? Oglosisz w razie czego konkurs?
47. • 47: CommentAuthorprzyjazn
    • CommentTime15 Mar 2010

     
    By nie zaśmiecać wątku o RobboNG przenosimy dyskusję o stronie Robbo na nowy wątek.
48. • 48: CommentAuthorhlipoz
    • CommentTime1 Apr 2010

     
    @rav
    
    Jeżeli lista nowych elementów nie jest jeszcze zamknięta to dorzuciłbym jeszcze cosik do świątecznego koszyczka ;-)
    Każdy oczywiście zna nieruchomy element gry, który jest rozmaicie nazywany: pajęczyna, ruchome piaski itp. Można go zniszczyć strzałem albo wysadzić bombą.
    
    Fajnie byłoby mieć element o identycznych właściwościach, ale przesuwny tzn. trochę taki Pengo-klocek.
    
    Charakterystyka:
    - klocek przesuwny
    - ulega zniszczeniu od strzału
    - ulega zniszczeniu od bomby
    - ulega zniszczeniu od uderzenia klockiem samobieżnym
    
    @all
    
    Tradycyjnie wesołych świąt, smacznego jajka i mokrego dyngusa.
49. • 49: CommentAuthorhlipoz
    • CommentTime20 May 2010

     
    Wcześniej na forum napisałem na temat Alex’a
    
    

    Nie doszedłem jeszcze do etapów gdzie jest podwójny Robbo więc nie mogę ocenić merytorycznie czy uatrakcyjnia to rozgrywkę. Póki co IMO to jest koncepcyjnie dość dziwne rozwiązanie.

    
    
    Nadal twierdzę, że koncepcyjnie jest to dość dziwne, …ale jednak cholernie uatrakcyjnia rozgrywkę (oczywiście gdy planeta jest fajowo zaprojektowana tak jak w tym przypadku). Zamieszczam save’a etapu 88 od początku – oceńcie sami. Poniżej też solucja do niego jeśli komuś nie starczy cierpliwości ;-)
    
    

    
    
    PS. Wielkie uznanie dla BoKo za Alex’a. Niektóre planety to prawdziwe majstersztyki !!!

    • alex_88.a8s
50. • 50:
       
      CommentAuthorKaz
    • CommentTime20 May 2010

     
    Ha ha - te Robbowe blizniaki wygladaja czadersko!