Trochę oddalam się od tej koncepcji Zeldy, ale nie od koncepcji gry. Postać oznacza masę kłopotów z animacją i to nie natury programistycznej, a raczej mmm... artystycznej. Znaczy ktoś te wszystkie kolorowe obrazki przebierającego nóżkami ludka musi narysować. Pomnożone przez 20, bo przeciwnicy też nie mogą być sztywnymi kołkami.
A może jednak mogą? Gdyby wymienić ich na jakieś pojazdy, roboty, pospolite sprzęty? Na razie testuję koncepcję wymiany na figurę geometryczną. I różne koncepcje ruchu. To jest właściwie główna treść tego testu. Jak powinna poruszać się postać? No tak, jasne, klawisze kursora i mysz do strzelania. Tyle ustaliłem na początku. Ale co właściwie robi klawisz "Up"? Gdzie ma iść postać? W gorę ekranu? Przed siebie? W kierunku kursora? Co robi "Left"? Postać obraca się w lewo? Czy może raczej zaczyna strafować?
Zamiast czczych rozważań, lepiej napisać test - oto więc jest. Na dole są radiobuttony do trzech opcji, można potestować. Póki co, wychodzi mi jednak, że pierwsze rozwiązanie było najlepsze. Jakoś tak najłatwiej ogarnąć gdzie postać idzie, a gdzie ma iść. Ale jeszcze sprawdzę co się stanie, gdy ruch postaci wymienię na ruch tła pod postacią (tak przecież ma wyglądać to docelowo - postać na środku ekranu, a świat przewija się jej pod stopami).
Kolejny krok to będzie zatem dodanie tego świata, który mógłby się przewijać.
Link do obadania:
http://gramowanie.blox.pl/resource/SilverlightApplication2TestPage.html
sobota, 18 czerwca 2011
niedziela, 12 czerwca 2011
Podróbka Zeldy w Silverlight
Obijałem się strasznie ostatnio i w ogóle nie dotknąłem palcem mojego Bouldera. Ale za to, zachęcony nieopatrznym komentarzem torq314, rzuciłem się na Silverlighta niczym wilk na owieczkę. O, jakże łatwiej jest chwycić się nowego projektu (i nowej technologii), niż dociągnąć coś starego do końca. Pocieszam się myślą, że jak rozgrzebię 3 czy 5 projektów, to może powolutku-powolutku uda się któryś dopchać do poziomu przyzwoitości (o poziomie zajebistości na razie nie myślę).
W sumie to pomysł był na flashową Zeldę, ale... Ale póki co zamiast flasha jest silverlight. Co do Zeldy, to też nie jestem do końca przekonany. Może Linka zastąpię czołgiem lub - jeszcze lepiej - latającym spodkiem. Mniej zabaw z animacją.
Zaś Mario? Mario odkładam na później. Może jak najdzie mię ochotą zrobić coś w XNA.
To co jest teraz można zobaczyć tutaj:
http://gramowanie.blox.pl/resource/SilverlightApplication1TestPage.html
(Mam nadzieję, że działa nie tylko u mnie, nie wiem czy zrzuciłem na serwer wszystko co trzeba.)
A co jest? Jest animowana postać, którą poruszamy klawiszami strzałek (lub WSADem), myszką możemy strzelać. Strzałami. Celów nie ma, nie ma kolizji, nie ma mapy. Animacja jest tylko w jedną stronę, bo nie chciało mi się więcej rysować obrazków.
Jeszcze nie zrobiłem solidnego riserczu jeśli idzie o tworzenie gier w SL, więc parę rzeczy jest wykonanych po omacku. Sprajty to Image wrzucane na Canvas. Aktualizacja stanu gry jest w DispatcherTimer. Animacja ludka - podmiana Source w Image. Nie wiem, czy to jest najwłaściwsza ścieżka, ale (póki co) działa.
Jeśli nie opuści mnie zapał, to następne w kolejności będzie dodanie jakiejś mapy i kolizji (w tym zabijania przeciwników). Waham się, czy robić wielką scrollowaną mapę (tricky), czy osobne plansze jak w oryginalne (mowa o Zeldach 2D).
Fota jest na wypadek, gdyby były wątpliwości, czy wygląda tak jak ma wyglądać. Ma wyglądać tak:
W sumie to pomysł był na flashową Zeldę, ale... Ale póki co zamiast flasha jest silverlight. Co do Zeldy, to też nie jestem do końca przekonany. Może Linka zastąpię czołgiem lub - jeszcze lepiej - latającym spodkiem. Mniej zabaw z animacją.
Zaś Mario? Mario odkładam na później. Może jak najdzie mię ochotą zrobić coś w XNA.
To co jest teraz można zobaczyć tutaj:
http://gramowanie.blox.pl/resource/SilverlightApplication1TestPage.html
(Mam nadzieję, że działa nie tylko u mnie, nie wiem czy zrzuciłem na serwer wszystko co trzeba.)
A co jest? Jest animowana postać, którą poruszamy klawiszami strzałek (lub WSADem), myszką możemy strzelać. Strzałami. Celów nie ma, nie ma kolizji, nie ma mapy. Animacja jest tylko w jedną stronę, bo nie chciało mi się więcej rysować obrazków.
Jeszcze nie zrobiłem solidnego riserczu jeśli idzie o tworzenie gier w SL, więc parę rzeczy jest wykonanych po omacku. Sprajty to Image wrzucane na Canvas. Aktualizacja stanu gry jest w DispatcherTimer. Animacja ludka - podmiana Source w Image. Nie wiem, czy to jest najwłaściwsza ścieżka, ale (póki co) działa.
Jeśli nie opuści mnie zapał, to następne w kolejności będzie dodanie jakiejś mapy i kolizji (w tym zabijania przeciwników). Waham się, czy robić wielką scrollowaną mapę (tricky), czy osobne plansze jak w oryginalne (mowa o Zeldach 2D).
Fota jest na wypadek, gdyby były wątpliwości, czy wygląda tak jak ma wyglądać. Ma wyglądać tak:
niedziela, 22 maja 2011
Bowlder, ver. 0.7
Wrzucam źródła i binarkę do Bowldera. Błędy znalezione i poprawione, interakcja działa jak należy. Jeszcze przyjrzę się ruchom przeszkadzajek, ale to przy okazji dodawania nowych gatunków (ruch tylko w poziomie, ruch tylko w pionie, ruchome działko, śledzenie gracza, ruch losowy, etc.)
Parę elementów wymaga dopieszczenia graficznego, np. dlaczego zjadanie "trawy" sprowadza się do jej zniknięcia? Nie przeszkadzało to przy ruchu krokowym, ale przy płynnym wygląda słabo. Czy nie przydałaby się tu jakaś animacja? Muszę też dodać możliwość zdefiniowania innej liczby kamieni koniecznych do ukończenia poziomu.
Do zwalczenia: pierdzenie dźwięku w Windowsie. A może to wina plików muzycznych?
Windowsowa binarka: https://rapidshare.com/files/2816660835/Bowlder_07.zip
Źródła: https://rapidshare.com/files/1190000989/Bowlder_07_src.zip
Parę elementów wymaga dopieszczenia graficznego, np. dlaczego zjadanie "trawy" sprowadza się do jej zniknięcia? Nie przeszkadzało to przy ruchu krokowym, ale przy płynnym wygląda słabo. Czy nie przydałaby się tu jakaś animacja? Muszę też dodać możliwość zdefiniowania innej liczby kamieni koniecznych do ukończenia poziomu.
Do zwalczenia: pierdzenie dźwięku w Windowsie. A może to wina plików muzycznych?
Windowsowa binarka: https://rapidshare.com/files/2816660835/Bowlder_07.zip
Źródła: https://rapidshare.com/files/1190000989/Bowlder_07_src.zip
100 Bowlderów na sekundę
Chyba za dużo ostatnio czasu spędzam w GIMPie et consortes, tracąc czas na zabawę grafikami, zamiast programować. A i tak nic bardzo pięknego nie udaje mi się uzyskać. Tworzenie to ciężki kawałek chleba...
Uporałem się już za to z wydajnością (wreszcie śmiga na słowniku - teraz ta wielka plansza, która ostatnio zmulała do 20 klatek, teraz szumi w 100fps w trybie oszczędnym lapka, hell yeah), ruch płynny też już wszędzie chodzi tak jak bym chciał. No, może jeszcze ruch "potworów" (ostatnio przerobiłem je na wirujące ostrza) wymaga dopatrzenia, a nawet nie tyle ruch co ich interakcja (wciąż zdarza im się uniknąć zmiażdżenia przez kamień). Dodałem też beczki i skrzynki, które potrafią wybuchnąć w różnych okolicznościach i różnym promieniu (skrzynki docelowo mają eksplodować w klejnoty) oraz działko (to te fioletowe coś podobne do krzyża na obrazku) strzelajace w czterech kierunkach pociskami. Co zostało? Naprawić co wymaga naprawienia, a potem już tylko dodawać kolejne elementy. No i wreszcie zacząć projektować jakieś sensowne plansze. Z tym pewnie będzie najwięcej roboty.
Kody i binaria wrzucę później, bo mam jeszcze parę błędów.
Uporałem się już za to z wydajnością (wreszcie śmiga na słowniku - teraz ta wielka plansza, która ostatnio zmulała do 20 klatek, teraz szumi w 100fps w trybie oszczędnym lapka, hell yeah), ruch płynny też już wszędzie chodzi tak jak bym chciał. No, może jeszcze ruch "potworów" (ostatnio przerobiłem je na wirujące ostrza) wymaga dopatrzenia, a nawet nie tyle ruch co ich interakcja (wciąż zdarza im się uniknąć zmiażdżenia przez kamień). Dodałem też beczki i skrzynki, które potrafią wybuchnąć w różnych okolicznościach i różnym promieniu (skrzynki docelowo mają eksplodować w klejnoty) oraz działko (to te fioletowe coś podobne do krzyża na obrazku) strzelajace w czterech kierunkach pociskami. Co zostało? Naprawić co wymaga naprawienia, a potem już tylko dodawać kolejne elementy. No i wreszcie zacząć projektować jakieś sensowne plansze. Z tym pewnie będzie najwięcej roboty.
Kody i binaria wrzucę później, bo mam jeszcze parę błędów.
I na dobranoc obrazek:
wtorek, 17 maja 2011
Bowlder - walka o fps
Dodanie płynnego ruchu ujawniło problem, który wcześniej nie występował - przy planszy o rozmiarze 43x25 wydajność znacznie spadała (w okolice 20fps). Nie spodziewałem się, że w dzisiejszych czasach trzeba myśleć o optymalizacji jakiegoś dwuwymiarowego shitu rodem z lat osiemdziesiątych. Dłubałem, dłubałem i chyba się dodłubałem - największy problem sprawia chyba iteracja przez listę klocków (miałem tam listę wszystkich elementów budujących labirynt i wędrowałem przez nią przy rysowaniu i liczeniu "fizyki"). Zamiana tego na słownik (gdzie kluczem jest tuple z pozycją) daje solidnego kopa.
W sumie to dziwne. Sądziłem, że najkosztowniejsze jest rysowanie (a i tak nie rysowałem niewidocznych elementów), a nie jakaś głupia iteracja przez 1000 elementów. Jak widać nie dla Pythona. A może to powtarzanie testów widoczności było zbyt kosztowne? Zobaczę, jak się to sprawdzi (chwilowo mam to wygrzebane poza główny program). Jak się nie sprawdzi, to przesiadam się na C++. Bua cha cha cha.
Domyślam się, że część winy leży w tym, że uruchamiałem to na VirtualBoksie pod Ubuntu, z wyłączoną akceleracją 2D, na karcie Intela i w trybie "wydajnym" lapka. Ale celuję w to, aby działało to nawet na ciut słabszym sprzęcie (przykładowo moim stacjonarnym staruszku).
Za to fizyka i przeciwnicy działają już jak należy (no a w każdym razie tak, aby nie dawać mi powodów do narzekań).
W ramach testów wklepałem parę plansz z Heartlight ((c) Janusz Pelc). Efekt nie jest taki jak w oryginale, a zatem nie mogę pochwalić się w pełni funkcjonalną podróbką, ale chyba nie będę dopasowywać się na siłę. Podoba mi się, jak to działa teraz. No, chyba że skończę już wszystko inne.
W sumie to dziwne. Sądziłem, że najkosztowniejsze jest rysowanie (a i tak nie rysowałem niewidocznych elementów), a nie jakaś głupia iteracja przez 1000 elementów. Jak widać nie dla Pythona. A może to powtarzanie testów widoczności było zbyt kosztowne? Zobaczę, jak się to sprawdzi (chwilowo mam to wygrzebane poza główny program). Jak się nie sprawdzi, to przesiadam się na C++. Bua cha cha cha.
Domyślam się, że część winy leży w tym, że uruchamiałem to na VirtualBoksie pod Ubuntu, z wyłączoną akceleracją 2D, na karcie Intela i w trybie "wydajnym" lapka. Ale celuję w to, aby działało to nawet na ciut słabszym sprzęcie (przykładowo moim stacjonarnym staruszku).
Za to fizyka i przeciwnicy działają już jak należy (no a w każdym razie tak, aby nie dawać mi powodów do narzekań).
W ramach testów wklepałem parę plansz z Heartlight ((c) Janusz Pelc). Efekt nie jest taki jak w oryginale, a zatem nie mogę pochwalić się w pełni funkcjonalną podróbką, ale chyba nie będę dopasowywać się na siłę. Podoba mi się, jak to działa teraz. No, chyba że skończę już wszystko inne.
niedziela, 15 maja 2011
Bowlder nadal żyje!
Wcale się nie obijałem przez ostatni tydzień. To znaczy oczywiście, że się obijałem - dlaczegóż by nie? Ale nie tylko obijałem. Parę chwil poświęciłem na pieszczenie Bowldera. Bo tak to chyba można już tylko nazwać. Niby ma wszystko, co mieć powinien, ale jest brzydki, w paru miejscach mógłby zachowywać się lepiej niż zachowuje, kod jest popstrzony starymi rzeczami schowanymi w komentarzach, ale... działa. Co dalej? Trochę sprzątania, drobne poprawki, może parę godzin w GIMPie, aby wreszcie dać jakieś przytomne ikony przeciwników.
Tego jeszcze nie zrobiłem. Ale już mam "płynny ruch". Wygląda całkiem fajnie. Posiedziałem też nad wydajnością (na większej planszy spadała w okolice 20 ramek - fatalnie, fatalnie). To zupełnie zmieniło koncepcję "renderera" (i dobrze, tamta była słaba). Upłynniając ruch, rozsynchronizowałem fizykę - teraz każdy kamień (i przeciwnik) może sobie działać we własnych fazach. Rodzi to jeszcze pewne problemy, ale do opanowania.
Nim umieszczę nową wersję, chcę jeszcze dodać parę elementów (bomby, działka, może klucze lub teleporty).
Tego jeszcze nie zrobiłem. Ale już mam "płynny ruch". Wygląda całkiem fajnie. Posiedziałem też nad wydajnością (na większej planszy spadała w okolice 20 ramek - fatalnie, fatalnie). To zupełnie zmieniło koncepcję "renderera" (i dobrze, tamta była słaba). Upłynniając ruch, rozsynchronizowałem fizykę - teraz każdy kamień (i przeciwnik) może sobie działać we własnych fazach. Rodzi to jeszcze pewne problemy, ale do opanowania.
Nim umieszczę nową wersję, chcę jeszcze dodać parę elementów (bomby, działka, może klucze lub teleporty).
sobota, 7 maja 2011
Bowlder Smash video
Wrzuciłem filmik z rozgrywki na youtuba. Nie wiem skąd problemy z nagraniem dźwięku - tak pod Windą jak i Ubuntu. Spróbuję z innym programem.
Bowlder Smash
No, jest już wersja z większością funkcjonalności, jaką zamierzałem zrobić. Porzuciłem pomysły na nowe rodzaje elementów, poprzestając na najprostszych. Ale można już zginąć od wszystkiego, od czego powinno się móc zginąć, gra ma początek i koniec (no, prawie), można kończyć kolejne mapy, jest trochę dźwięków i trochę animacji (dodanie większej ich liczby to kwestia przygotowania zasobów).
Jako poziomy używane są mapy zapisane w bieżącym katalogu (pliki map*.txt - w kolejności alfabetycznej). Z nowych znaków: 'X' oznacza wyjście (dostępne tylko po zebraniu wszystkich klejnotów). Jeśli gdzieś się zablokujemy, ważnym klawiszem może okazać się "R" - resetuje on dany poziom.
Kod w wielu miejscach wygląda całkiem porządnie, choć w paru nadal mam chaos, który będę musiał opanować (renderer przestał mi się podobać, wczytywanie mapy też wymaga przemyślenia, może jeszcze kwestia ładowania nowych leveli).
Zaobserwowane problemy: pod Win7 po pewnym czasie muzyka zaczyna pierdzieć, nie wiem czy to wina pliku, czy moja.
TODO: poza przygotowaniem bogatszego zestawu grafik i dźwięków i wprowadzeniem kolejnych typów elementów gry będę musiał posiedzieć nad zaimplementowaniem płynnego ruchu.
Muzyka w tle: Royalty free production music by JewelBeat.
Efekty dźwiękowe: Freesound.
Źródła: https://rapidshare.com/files/461080079/Bowlder_04_src.zip
Exe: https://rapidshare.com/files/461080481/Bowlder_04.zip
Jako poziomy używane są mapy zapisane w bieżącym katalogu (pliki map*.txt - w kolejności alfabetycznej). Z nowych znaków: 'X' oznacza wyjście (dostępne tylko po zebraniu wszystkich klejnotów). Jeśli gdzieś się zablokujemy, ważnym klawiszem może okazać się "R" - resetuje on dany poziom.
Kod w wielu miejscach wygląda całkiem porządnie, choć w paru nadal mam chaos, który będę musiał opanować (renderer przestał mi się podobać, wczytywanie mapy też wymaga przemyślenia, może jeszcze kwestia ładowania nowych leveli).
Zaobserwowane problemy: pod Win7 po pewnym czasie muzyka zaczyna pierdzieć, nie wiem czy to wina pliku, czy moja.
TODO: poza przygotowaniem bogatszego zestawu grafik i dźwięków i wprowadzeniem kolejnych typów elementów gry będę musiał posiedzieć nad zaimplementowaniem płynnego ruchu.
Muzyka w tle: Royalty free production music by JewelBeat.
Efekty dźwiękowe: Freesound.
Źródła: https://rapidshare.com/files/461080079/Bowlder_04_src.zip
Exe: https://rapidshare.com/files/461080481/Bowlder_04.zip
czwartek, 5 maja 2011
Boulder Robbo
Ufff... sporo zmian w kodzie, choć niewiele w samym wyglądzie i działaniu aplikacji. Wreszcie wyrzuciłem starą procedurę fizyczną i zastąpiłem reprezentacją obiektową. Od razu projekt nabrał wyrazu i od razu wysypał się szereg możliwości rozbudowy: przeciwnicy innych typów, inne zasady ruchu, bomby, miny, teleporty. Najchętniej zaimplementowałbym wszystko, co było dostępne w Boulder dashu, Robbo, Supapleksie i może jeszcze Saperze (tym z małego Atari, a nie windowsowym). Lista pożądanych ficzerów rośnie. Ale to raczej oddala projekt od wersji finalnej.
Z poważnych zmian - eksplozje (gdy gracz zetknie się z potworem lub złapie kamień na głowę). Jest to pierwszy animowany sprite, na jego wzór dodam inne - chciałbym animować przynajmniej przeciwnika (myślałem o obracających się ostrzach) i kryształy (jakieś błyski, odblaski). Widzę też, że z obecnej postaci nie będzie tak ciężko przejść na płynny ruch. To może być fajny dodatek, bo ruch skokowy (dotyczy to zwłaszcza bohatera) bywa męczący.
Lista "TODO" się rozszerza, zamiast kurczyć: rzeczy, które wybuchają po upadku, rzeczy które wybuchają po wejściu, rzeczy które wybuchają po pchnięciu, rzeczy, które wybuchają gdy zrzucić na nie kamień, strzelanie, działka, lasery, ruchome bramy, teleporty, lód, zmiana grawitacji, pola siłowe, magnesy, ...
Kod wrzucę później, póki co - obrazek ze złapaną eksplozją:
Z poważnych zmian - eksplozje (gdy gracz zetknie się z potworem lub złapie kamień na głowę). Jest to pierwszy animowany sprite, na jego wzór dodam inne - chciałbym animować przynajmniej przeciwnika (myślałem o obracających się ostrzach) i kryształy (jakieś błyski, odblaski). Widzę też, że z obecnej postaci nie będzie tak ciężko przejść na płynny ruch. To może być fajny dodatek, bo ruch skokowy (dotyczy to zwłaszcza bohatera) bywa męczący.
Lista "TODO" się rozszerza, zamiast kurczyć: rzeczy, które wybuchają po upadku, rzeczy które wybuchają po wejściu, rzeczy które wybuchają po pchnięciu, rzeczy, które wybuchają gdy zrzucić na nie kamień, strzelanie, działka, lasery, ruchome bramy, teleporty, lód, zmiana grawitacji, pola siłowe, magnesy, ...
Kod wrzucę później, póki co - obrazek ze złapaną eksplozją:
poniedziałek, 2 maja 2011
Boulder Dash - jeszcze trochę
Niewiele nowości, bo sporo dłubałem przy porządkowaniu kodu, bawiłem się różnymi koncepcjami, dodałem parę klas do rzeczy które dotąd działały i bez tego. Ale jakaś tam nowa funkcjonalność jest. Jest ekran startowy i końcowy (bo wreszcie można zginąć lub wygrać). Śmierć mogą nam zadać, póki co, jedynie wrogowie-przeszkadzajki. Z kamieniami trochę próbowałem, niekiedy udaje im się zabić przeszkadzajkę. Zidentyfikowałem problem, ale wykonanie zostawiam sobie na "następny raz".
Podobają mi się klasy GameIntro, Game, GameOver, choć trochę jeszcze je wygładzę, kamienie będą zrobione jak przeciwnicy lub wyjście, postaram się też jeszcze zrobić coś sensownego z mapą. A tak poza tym jest OK.
Do zrobienia: zapomniałem o odczytywaniu wyjścia z mapy (teraz ma lokację wpisaną na stałe w kodzie). W przyszłości będzie tez trzeba odczytywać liczbę kamieni koniecznych do skończenia mapy (teraz konieczne są wszystkie). No i gra kończy się gratulacjami po przejściu jednego (jedynego) poziomu - trzeba dodać wczytywanie kolejnych z plików.
Wywaliłem też zmianę rozmiaru okna, aby nie walczyć z błędami w Windowsie. No i spróbowałem namalować ładniejsze kafelki (do ściany). Nie wiem, czy warto na to tracić czas (nie licząc niewątpliwego waloru edukacyjnego, lol).
Fizyka czasem ma problemy, ale wiem co jest nie tak - naprawię wszystko przy zabawie z kamieniami. To będzie kolejny krok. Potem już tylko upiększanie.
Źródła: https://rapidshare.com/files/460169323/Boulder_03_src.zip
Exe: https://rapidshare.com/files/460169371/Boulder_03.zip
Podobają mi się klasy GameIntro, Game, GameOver, choć trochę jeszcze je wygładzę, kamienie będą zrobione jak przeciwnicy lub wyjście, postaram się też jeszcze zrobić coś sensownego z mapą. A tak poza tym jest OK.
Do zrobienia: zapomniałem o odczytywaniu wyjścia z mapy (teraz ma lokację wpisaną na stałe w kodzie). W przyszłości będzie tez trzeba odczytywać liczbę kamieni koniecznych do skończenia mapy (teraz konieczne są wszystkie). No i gra kończy się gratulacjami po przejściu jednego (jedynego) poziomu - trzeba dodać wczytywanie kolejnych z plików.
Wywaliłem też zmianę rozmiaru okna, aby nie walczyć z błędami w Windowsie. No i spróbowałem namalować ładniejsze kafelki (do ściany). Nie wiem, czy warto na to tracić czas (nie licząc niewątpliwego waloru edukacyjnego, lol).
Fizyka czasem ma problemy, ale wiem co jest nie tak - naprawię wszystko przy zabawie z kamieniami. To będzie kolejny krok. Potem już tylko upiększanie.
Źródła: https://rapidshare.com/files/460169323/Boulder_03_src.zip
Exe: https://rapidshare.com/files/460169371/Boulder_03.zip
piątek, 29 kwietnia 2011
Boulder Dash - ciąg dalszy
Trochę się ociągałem z kolejnym etapem (brak czasu, a mówiąc dokładniej: Might and Magic 4, Borderlands, Savage Worlds), ale parę rzeczy udało mi się dodać.
Przede wszystkim - ruch "przeciwników". Było z tym więcej roboty, niż z kamieniami, choć wcześniej zdawało mi się, że będzie na odwrót. Przeciwnicy mogą być prawo- lub leworęczni (gdy napotkają ścianę, idą przy niej trzymając jej prawą lub lewą ręką). Jeszcze nie mogą zabić gracza, ani zginąć od kamienia, ale reagują na elementy otoczenia. Przeciwnicy są obiektami, zastanawiałem się, czy kamieni nie zrobić tak samo, ale nie widzę korzyści, które usprawiedliwiałyby poświęcanie na to dodatkowego czasu. I tak taki obiekt nie będzie zawierał wiele więcej ponad informację, że jest kamieniem, fizyka będzie wyglądać tak samo, a że powinna odbywać się "z dołu do góry" (przynajmniej na razie nie widzę innych możliwości), to będą musiały siedzieć w mapie zamiast znaków. Zobaczymy.
Kolejna zmiana to grafika. Wywaliłem te nieszczęsne procedury rysujące i zastąpiłem je obrazkami z pliku PNG. Na razie są niezbyt urodziwe (5 minut w GIMPie), ale mogą wypięknieć (w przypadku procedur byłoby to bolesne). Dałem też możliwość zmiany rozmiaru okna i parę skomplikowanych rachunków, które upewniają się, że zawsze widać tę część planszy, którą trzeba (jestem z tego szczególnie zadowolony - no a przynajmniej z tego jak to działa, bo co do wykonania, to żałuję że nie wpadłem na jakieś bardziej eleganckie rozwiązanie).
Doszła też interakcja gracza z kamieniami i klejnotami - zatrzymują mu się na głowie, kamienie może przesuwać (tylko w poziomie), a klejnoty zbierać. Ale jeszcze nie może zginąć. ;)
W związku z dodanymi elementami otoczenia, pojawiło się parę nowych literek w pliku mapy:
Przede wszystkim - ruch "przeciwników". Było z tym więcej roboty, niż z kamieniami, choć wcześniej zdawało mi się, że będzie na odwrót. Przeciwnicy mogą być prawo- lub leworęczni (gdy napotkają ścianę, idą przy niej trzymając jej prawą lub lewą ręką). Jeszcze nie mogą zabić gracza, ani zginąć od kamienia, ale reagują na elementy otoczenia. Przeciwnicy są obiektami, zastanawiałem się, czy kamieni nie zrobić tak samo, ale nie widzę korzyści, które usprawiedliwiałyby poświęcanie na to dodatkowego czasu. I tak taki obiekt nie będzie zawierał wiele więcej ponad informację, że jest kamieniem, fizyka będzie wyglądać tak samo, a że powinna odbywać się "z dołu do góry" (przynajmniej na razie nie widzę innych możliwości), to będą musiały siedzieć w mapie zamiast znaków. Zobaczymy.
Kolejna zmiana to grafika. Wywaliłem te nieszczęsne procedury rysujące i zastąpiłem je obrazkami z pliku PNG. Na razie są niezbyt urodziwe (5 minut w GIMPie), ale mogą wypięknieć (w przypadku procedur byłoby to bolesne). Dałem też możliwość zmiany rozmiaru okna i parę skomplikowanych rachunków, które upewniają się, że zawsze widać tę część planszy, którą trzeba (jestem z tego szczególnie zadowolony - no a przynajmniej z tego jak to działa, bo co do wykonania, to żałuję że nie wpadłem na jakieś bardziej eleganckie rozwiązanie).
Doszła też interakcja gracza z kamieniami i klejnotami - zatrzymują mu się na głowie, kamienie może przesuwać (tylko w poziomie), a klejnoty zbierać. Ale jeszcze nie może zginąć. ;)
W związku z dodanymi elementami otoczenia, pojawiło się parę nowych literek w pliku mapy:
- '$' to klejnot do zebrania
- '@' to początkowa pozycja gracza
- 'n', 'e', 's', 'w' - to przeciwnicy. Litera oznacza początkowy kierunek ruchu. Duży znak to stwor praworęczny, mały - leworęczny. Potwory w grze są reprezentowani przez te paskudne strzałki, aby było widać który gdzie jest zwrócony i której ściany się trzyma - ale pewnie zastąpię te wszystkie warianty jedną ikoną, tak samo jak u bohatera.
Do zrobienia: najważniejsze, co przychodzi mi do głowy, to punkty (za klejnoty), wyjście (czyli możliwość skończenia poziomu) no i oczywiście: "życia" (a zatem i możliwość zgonu). To chyba uczyni tę grę umiarkowanie grywalną, reszta to będą ozdobniki.
Zaobserwowane błędy: pod Windows 7 próba powiększenia okienka wywala aplikację (pod Windows XP i Ubuntu jest ok) - może to jakiś problem tej wersji Pygame, z której korzystam? Powalczę z tym później.
Zaobserwowane błędy: pod Windows 7 próba powiększenia okienka wywala aplikację (pod Windows XP i Ubuntu jest ok) - może to jakiś problem tej wersji Pygame, z której korzystam? Powalczę z tym później.
środa, 27 kwietnia 2011
Boulder Dash
Zamiast rozwijać roguelika, zabrałem się za klasycznego Boulder Dasha. Opierając się na tym skrawku, który powstał na potrzeby rogala, dodałem wczytywanie mapy z pliku tekstowego ("#" to ściana, "=" to ziemia do zjadania, "O" (a także "o" oraz "0") to kamień), zaimplementowałem zjadanie ziemi, jakąś prostą fizykę kamieni i już coś się dzieje. Starałem się, aby kamienie spadały tak, jak to działało w oryginale (czyli tak). Nie ma interakcji ludka z kamieniami - ani ich nie przesuwa, ani nie blokuje, ani od nich nie ginie.
Nie ma też animacji ani płynnego ruchu i zastanawiam się, czy warto w to się bawić, czy pierwszą wersję wypuścić z "ruchem skokowym". Nie ma przewijania, a więc mapa nie może być większa niż jest (bo nie zmieści się w oknie).
Jeszcze nie do końca jestem zadowolony z fizyki, bo gdy zrobimy ścianę z kamieni, najpierw wysuwają się te spod spodu, zamiast lecieć te z góry.
Do zrobienia: wywalić wreszcie to proceduralne rysowanie i dać jakieś kafle. I mapę rozwiązać inaczej, niż tablicę napisów (niby fajne, ale za dużo dłubaniny w wymianie znaków) - pewnie kamienie, etc. staną się obiektami, ale jakieś flagi do mapy (typu: zajęty, zarezerwowany) trzeba będzie zachować, żeby fizyka działała jak należy. No a potem reszta ficzerów, których można się spodziewać po boulderze.
Klawiszologia: strzałki to wiadomo, a poza tym:
R - resetuje mapę (znaczy - wczytuje ją jeszcze raz z pliku)
S - zatrzymuje fizykę, można ją wówczas uruchamiać spacją "krok po kroku" - dobre do obserwacji czy wszystko leci gdzie powinno
Q - wyjście z programu
źródła: https://rapidshare.com/files/459356388/Boulder_01_src.zip
exe: https://rapidshare.com/files/459353979/Boulder_01.zip
(w zipach siedzi "domyślna" mapa, którą można edytować)
Nie ma też animacji ani płynnego ruchu i zastanawiam się, czy warto w to się bawić, czy pierwszą wersję wypuścić z "ruchem skokowym". Nie ma przewijania, a więc mapa nie może być większa niż jest (bo nie zmieści się w oknie).
Jeszcze nie do końca jestem zadowolony z fizyki, bo gdy zrobimy ścianę z kamieni, najpierw wysuwają się te spod spodu, zamiast lecieć te z góry.
Do zrobienia: wywalić wreszcie to proceduralne rysowanie i dać jakieś kafle. I mapę rozwiązać inaczej, niż tablicę napisów (niby fajne, ale za dużo dłubaniny w wymianie znaków) - pewnie kamienie, etc. staną się obiektami, ale jakieś flagi do mapy (typu: zajęty, zarezerwowany) trzeba będzie zachować, żeby fizyka działała jak należy. No a potem reszta ficzerów, których można się spodziewać po boulderze.
Klawiszologia: strzałki to wiadomo, a poza tym:
R - resetuje mapę (znaczy - wczytuje ją jeszcze raz z pliku)
S - zatrzymuje fizykę, można ją wówczas uruchamiać spacją "krok po kroku" - dobre do obserwacji czy wszystko leci gdzie powinno
Q - wyjście z programu
źródła: https://rapidshare.com/files/459356388/Boulder_01_src.zip
exe: https://rapidshare.com/files/459353979/Boulder_01.zip
(w zipach siedzi "domyślna" mapa, którą można edytować)
wtorek, 26 kwietnia 2011
Rogalik - start
Ok, czas na rogala, czyli to, dla czego powstał ten blog.
Co jest: bardzo mało - chodzenie i... nic ponadto. Labirynt na stałe zaszyty w kodzie. Ale jest szkic, z którego można startować.
Do zrobienia: he, he, he - wszystko. Przede wszystkim: losowe podziemia, AI, walka, itemy, levelowanie. Z rzeczy ważnych: walka dystansowa.
Z ciekawostek: rysowanie obiektów jest proceduralne, ma to swój urok, ale docelowo będzie zastąpione przez normalne kafle z png. Bowiem (póki co) zamiar jest taki, aby Rogal był tilesowy. Ale - kto wie, kto wie - może nastąpi powrót do ASCII.
Źródła: http://sites.google.com/site/gramowanie/rogal.0.0.1.0.py
Exe: http://rapidshare.com/files/459169421/Rogal_0.0.1.0.zip
Screenshot:
Co jest: bardzo mało - chodzenie i... nic ponadto. Labirynt na stałe zaszyty w kodzie. Ale jest szkic, z którego można startować.
Do zrobienia: he, he, he - wszystko. Przede wszystkim: losowe podziemia, AI, walka, itemy, levelowanie. Z rzeczy ważnych: walka dystansowa.
Z ciekawostek: rysowanie obiektów jest proceduralne, ma to swój urok, ale docelowo będzie zastąpione przez normalne kafle z png. Bowiem (póki co) zamiar jest taki, aby Rogal był tilesowy. Ale - kto wie, kto wie - może nastąpi powrót do ASCII.
Źródła: http://sites.google.com/site/gramowanie/rogal.0.0.1.0.py
Exe: http://rapidshare.com/files/459169421/Rogal_0.0.1.0.zip
Screenshot:
Tetris
I - póki motywacja nie zgasła - moje najświeższe dokonanie: Tetris. Kod dużo ładniejszy i mądrzejszy, choć parę rzeczy pewnie dałoby się zrobić lepiej. To co mnie cieszy - zaledwie 150 linijek.
Braki: nie ma licznika punktów (co czyni grę mało grywalną), ani rosnącego stopnia trudności. Rzeczy typu ekran tytułowy, lista rekordów czy podgląd kolejnego klocka, to też byłby pewnie miłe dodatki.
Atuty: kolorowe klocki. :)
Uwagi: dużo czasu zmarnowałem na (nieudolne!) próby napisania procedury do obracania klocków. W końcu poprzestałem na zdefiniowaniu dla każdego klocka jego "obróconych" wersji.
Sterowanie: klawisze strzałek (lewo i prawo to przesuwanie, dół to przyśpieszenie spadania, góra - obrót klocka).
Źródła: https://rapidshare.com/files/459033724/gra_tetris.py
Exe: https://rapidshare.com/files/459069984/Tetriiis.zip
I obrazek:
Braki: nie ma licznika punktów (co czyni grę mało grywalną), ani rosnącego stopnia trudności. Rzeczy typu ekran tytułowy, lista rekordów czy podgląd kolejnego klocka, to też byłby pewnie miłe dodatki.
Atuty: kolorowe klocki. :)
Uwagi: dużo czasu zmarnowałem na (nieudolne!) próby napisania procedury do obracania klocków. W końcu poprzestałem na zdefiniowaniu dla każdego klocka jego "obróconych" wersji.
Sterowanie: klawisze strzałek (lewo i prawo to przesuwanie, dół to przyśpieszenie spadania, góra - obrót klocka).
Źródła: https://rapidshare.com/files/459033724/gra_tetris.py
Exe: https://rapidshare.com/files/459069984/Tetriiis.zip
I obrazek:
Strzelanka
I oto - jako wpis inauguracyjny - prościuteńka strzelanka, jaka powstała kilka dni temu w trakcie nauki Pythona. Stworzona bez jakiegoś głębszego przemyślenia, czy konkretnego projektu. Kod jest raczej chaotyczny i przypadkowy. Powstawała na zasadzie "o, to tak można poruszać obiektem w pygame?" i "no to teraz spróbujmy dodać strzelanie". Nie było konceptu ani planowania. Gdybym robił to teraz, NA PEWNO zrobiłbym to inaczej. Ale działa, da się grać i, niech mnie szlag, to JEST grywalne (mój rekord to 6800).
Pojazdem sterujemy klawiszami strzałek lewo-prawo, strzelamy spacją. Reszty można się domyśleć.
Źródła: http://rapidshare.com/files/457507454/gra02.py
Exe: http://rapidshare.com/files/457467717/gra.zip
I obrazek:
Pojazdem sterujemy klawiszami strzałek lewo-prawo, strzelamy spacją. Reszty można się domyśleć.
Źródła: http://rapidshare.com/files/457507454/gra02.py
Exe: http://rapidshare.com/files/457467717/gra.zip
I obrazek:
poniedziałek, 25 kwietnia 2011
Próba mikrofonu
Zgodnie z tym, co w tytule - ma być to blog o graniu i programowaniu. Przeważnie o programowaniu gier (raczej hobbystycznym i amatorskim). Choć może też się zdarzyć trochę programowania bez grania, tudzież grania bez programowania. Naszło mnie bowiem niedawno, aby nauczyć się Pythona, a jakiż jest lepszy sposób nauczenia się czegokolwiek, jeśli nie przez grę?
Po przejrzeniu paru tutoriali, połowy jakiejś książki i wklepaniu kilku wprawek, postanowiłem pisać na blogu o tym, co z tego mojego programowania wyjdzie. Głównie po to, aby motywować się do dalszej pracy i mieć dziennik postępów.
W tej chwili punktem docelowym jest stworzenie rogalika, ale odstępstwa na pewno będą. Narzędzia: Python (w tej chwili w wersji 2.6.6, bo takiego mam w Ubuntu) i Pygame (w wersji 1.9.1).
Po przejrzeniu paru tutoriali, połowy jakiejś książki i wklepaniu kilku wprawek, postanowiłem pisać na blogu o tym, co z tego mojego programowania wyjdzie. Głównie po to, aby motywować się do dalszej pracy i mieć dziennik postępów.
W tej chwili punktem docelowym jest stworzenie rogalika, ale odstępstwa na pewno będą. Narzędzia: Python (w tej chwili w wersji 2.6.6, bo takiego mam w Ubuntu) i Pygame (w wersji 1.9.1).
Subskrybuj:
Posty (Atom)