Wojownik, libGdx i kolejna gra

To już ponad miesiąc od ostatniego wpisu! Patrząc na moją dotychczasową aktywność trzeba przyznać, że się opuściłem. Główną przyczyną takiego stanu rzeczy jest (powoli przechodzące) przemęczenie spowodowane pisaniem Wojownika Autostrady i nauką Angulara. Każdy ma pewien próg, powyżej którego głowa przestaje przyjmować wiadomości i potrzebuje odpoczynku.


 
Chciałbym pokazać wam statystyki użycia strony zawierającej Wojownika Autostrady (po prawej). Oczywiście największy pik zainteresowania nastąpiłwraz z pojawieniem się gry w Internecie i informacji o niej na stronie Kryształów Czasu oraz na profilu fb portalu czy tu na blogu. Z upływem czasu zainteresowanie znacząco spadło, ale jest to zrozumiałem. Po prostu ci - którzy mieli pograć - pograli :).

Podejrzewam też, że nikt nie dotarł do ostatniego - 350 - paragrafu ponieważ gra jest po prostu morderczo trudna. Nie zrobiłem niestety zapisu statystyk odwiedzin poszczególnych paragrafów, a powrót do programowania w PHP, co byłoby nieodzowne,  aby uzyskać te dane, uważam za średnie rozwiązanie. Wystarczy rzeźba w javascript.
Trzeba by (sugestia czegoja) wprowadzić tryb łatwy lub ogólnie możliwość wyboru poziomu trudności. 


A jakie mam plany?
Atakuje Androida oraz bibliotekę graficzną libGdx! I mam już pierwszy mały sukces. Poniżej zrzut z tworzonego na bazie książki prostego rpg-a. Na razie jako aplikacja desktopowa, którą docelowo będę chciał zportować do Androida. Zrzut jest statyczny (może w końcu nauczę się robić gify...) ale spieszę powiedzieć, że widoczny tam wojownik reaguje na naciśnięcie klawiszy kierunkowych i posiada animację kierunkowego ruchu.  I na razie nie wiem dlaczego mapa ładuje się podwójnie :P

Naukę libGdx i pisania gier opartych na tej bibliotece opieram o książki: Mastering LibGDX Game Development, Android Game Programming by Example oraz Killer Game Programming in Java. I wszystko oczywiście w javie. Normalnej javie :)
Generalnie czeka mnie trochę nauki, ale efekty są zachęcające.
p.s.
A moglibyście spytać dlaczego nie skorzystam z Unity? Przecież niemal 80% gier dostępnych na Androida powstałą w tym języku. Cóż nie znam C# :P I nie chce mi się go uczyć :P

Angularowy Wojownik Autostrady cd

Oj sporo czasu minęło od ostatniego wpisu. Spieszę powiedzieć że nie był to czas stracony. Angularowy Wojownik Autostrady powstaje i to bardzo intensywnie. Udało mi się wyrobić nawyk programowania na komputerze dzięki czemu nawet 15 minutowe posiadówki za klawiaturą pozwalają napisać kilka linii kodu.

A sam projekt?

Cóż :-) przerobiłem niemal wszystkie paragrafy na wersję interaktywną. Z 350 paragrafów jeszcze 7 nie zachowuje się jak trzeba.
Powstał nowy, błyszczący silnik zarządzający grą. Jego poziom komplikacji jest nieporównywalnie większy od tego co zrobiłem dla Sladuma (wybacz stary :) ) i jednocześnie otrzymał sporo nowych możliwości.
Wykorzystuje sporo z tego co daje angular - w efekcie, aby wszystko działało tak jak potrzebuję musiałem podnieść używaną wersję z 1.3 do 1.5. Wreszcie pojawiły się dialogi, korzystam z angularowych eventów, local storage i canvasów. Ogólnie zastosowane rozwiązania zasługują na osobny wpis (a może nawet kilka). Postaram się je w miarę możliwości zrobić.

A jak to teraz wygląda?
Tak wyglądało z miesiąc temu:

A tak wygląda teraz:

Rogalik - grafika cd

W weekend poprawiłem trochę kod, znalazłem kilka miejsc, w których nadmiernie zapychałem pamięć grafiką i pewnie jeszcze wiele takich miejsc zostało.
Ale.
W tej chwili połączyłem generator mapy (ten z kwadracików widoczny kilka postów temu) z główną pętlą graficzną rysującą mapę. Pokoje planszy generowane są w momencie wejścia z wszystkim elementami składowymi jak pułapki/potwory/skarby - tylko nie ma to jeszcze przełożenia na wygląd pomieszczeń. Może do końca tygodnia się to zmieni, problemem jest przygotowanie odpowiedniej ilości plików opisujących cięte na potrzeby gry obrazków.

Szybkość odświeżania grafiki to 60 klatek / sekunda - i to ze względu na to iż przewijanie mapy przy mniejszej ilości klatek generowało uciążliwy lag.
Sama mapa nie jest jeszcze generowana tylko w widocznym dla gracza obszarze, ale już przygotowuję kod, który jest gotowy na takie zadanie. Właściwi w tym co widać poniżej brakuje tylko wyświetlenia pozycji drużyny tak, aby było wiadomo w którym klocku jesteśmy i mogę dalej wrócić do rzeźbienia mechaniki gry oraz poprawienia błędów w animowaniu poklatkowym (niestey kilka dziwnych błędów się wdarło)

W międzyczasie znalazłem coś takiego:

Jest to jakieś przykładowe (chyba- nie mam pewności|) gui "plecaka postaci" jakiegoś rogalika. W ten deseń chciałbym zrobić to w swojej gierce.
Trzeba przyznać że to co ludzie linkują do Pinteresta jest inspirujące:)


Aktualizacja
Poziom wygenerowany z animującymi się potworami.

ps.
Spojrzałem ile pamięci zjada moja "gierka" - w skrócie tak z 10x za dużo w stosunku do tego co oferuje ...

Rogalik - grafika!

Ostatnie dni miałem uciążliwie męczące i po powrocie do domu niebardzo miałem ochotę na jakiekolwiek prace przy grze. Nie znaczy to jednak, że zarzuciłem jakikolwiek jej rozwój. Poświęciłem kilka godzin na napisanie podstawowego mechanizmu animującego aktorów na ekranie. Oczywiście wiązało się to z przeczytaniem masy dokumentów, kilku rozdziałów książki Killer Java Game Programming, kilku wątków na StackOverflow, czegoś o javiefx, paru (nastu?) wpisów z blogów o programowaniu...

Pierwsza wersja aplikacji rysującej (gdy zaczęła cokolwiek rysować) psuła się dosyć poważanie ponieważ zjadała nieograniczone ilości pamięci. Szukając rozwiązania problemu (rosnący w nieskończoność GrowableBuffer w obiekcie Canvas) ściągnąłem przykłady z sieci dotyczące animowania w javieFX. Te zaś zjadały kosmiczne ilości czasu procesora (jedna animująca gwiazdki
w ekranie 400x600px zjadała ... 25% czasu procka CoreI5!) lub zatrzymywały się po kilkunastu minutach pracy.

Moja pętla rysująca zawierała błąd, który powodował, że animacja zatrzymywała się samoczynnie po kilku minutach. Aktualnie  mam problem z tym, że animacja działa, ale spowalnia po ok 10 minutach pracy.  Spaliłem duuużo czasu na znalezienie prawidłowego sposobu animowania klatek z użyciem komponentów javyfx tak, aby ciężar rysowanego obrazu nie rósł w nieskończoność. Przy okazji przypomniałem sobie trochę o obsłudze wątków i grafiki.
No i  udało  się - przynajmniej w ramach ograniczonego testu jaki wykonuję.  W tej chwili aplikacja animuje i rysuje to co trzeba, a poniżej zrzut z efektu jej działania.

Z technicznego punktu widzenia na ekranie gry będzie sześć warstw (w tej chwili rysowane są 3)

• tło (jest)
• podłoga (aktualnie połączona z warstwą ścian)
• ściany
• dodatki do pomieszczeń (np. skrzynie)
• aktorzy (jest)
• efekty specjalne

Warstwy, które są odświeżane dynamicznie (co klatkę) to tylko aktorzy. W niektórych momentach dojdzie odświeżanie dodatków do pomieszczeń - np. pochodni oraz w miarę potrzeb animacje na warstwie efektów specjalnych. Zaoszczędza
to duużo czasu i obliczeń komputera.


Napisany kod nie jest w 100% optymalny i da się jeszcze ograniczyć ilość wykonywanych przy grafice obliczeń. Widoczne obok okienko "zjada" na stałe ~100 MB pamięci - nie udało mi się zejść poniżej tej liczby. Taka już chyba uroda javyfx połączonego z moim kodem.
Niestety z czasem (> 20 minut) animka zwalnia znacząco i jednocześnie zaczyna zjadać więcej pamięci. Coś z moim kodem jest jeszcze poważnie nie tak...


Nie zrobiłem jeszcze pełnego opisu wszystkich rysunków używanych w grze stąd brak jakichś upiększaczy na załączonym zrzucie - w tej chwili mam opisanych 16 bohaterów i ich dwuklatkową :) animację, niebieską podłogę oraz ściany, tło oraz drzwi.

Rogalik, pułapki

Małymi kroczkami do przodu. Pojawiły się drobne moduły:
- możliwość wylosowania (predefiniowanych) bohaterów i wejście na mapę. Niestety nie ma jeszcze możliwości dobrania czarów do postaci ale to już niedługo się zmieni.
- pułapki. Jest to pierwsza rzecz jaka jest sprawdzana po wejściu do nowego pomieszczenia. W tej chwili można wybrać postać która spróbuje - jeśli ma odpowiednią umiejętność - rozbroić pułapkę i efekty tego działania - czyli rozbrojenie i przejście do kolejnej fazy lub uwolnienie pułapki i otrzymanie obrażeń. Wersja mocno 'beta' ale działa nawet sprawnie. Postać może nawet zginąć!

Rogalik cd. :)

Projekt toczy się powoli do przodu.
Program (bo daleko mu jeszcze do jakiejkolwiek gry) rozrasta się i zyskuje kolejne moduły. Proces jest czasochłonny, ale z mojego punktu widzenia dosyć ciekawy. Pokazuje inne podejście do programowania i wymaga zmiany niektórych przyzwyczajeń.

Ekran gry. W pasku widać wylosowane potwory.

Sama gra - z punktu widzenia osoby patrzącej z zewnątrz - zmienia się niewiele. Od ponad tygodnia nadal mam tylko główne okno gry, które generuje labirynt. Z tą różnicą ze klocki są większe niż ostatnio - w oczekiwanej przeze mnie wielkości 112x112 px. Wynika to z tego, że krawędź pola pokoju będzie składała się z 6 grafik ścian i jednej grafiki drzwi. Tak ja widać poniżej - pole typu pokój. Wersja ASCI:


            ╔══─══╗
            ║               ║
            ║               ║
            │               │
            ║               ║
            ║               ║
            ╚══─══╝

Korytarze będą oczywiście węższe i opakowane grafiką. :).
Napisałem też pierwsze elementy, które wiążą rozsypany kod gry ze sobą. W efekcie rośnie poziom komplikacji i pojawiają się trudne w stworzeniu moduły - np. zarządzanie fazami gry czy główna pętla graficzna. Ale do rzeczy.

 W tej chwili jest (i działa - dodałem testy w JUnit :) ) :
- losowania zdefiniowanych przez grę bohaterów
- wstępny projekt gui dla statystyk i ekwipunku bohaterów (wzorowany na tym z Diablo / Torchligt ale bez grafiki)

Ekran bohatera

- moduł określający fazę gry (to chyba będzie, poza walką i rozpatrywaniem czarów, jeden z najbardziej skomplikowanych elementów gry)
- wyświetlanie okien wykrywania pułapek, przekupstwa, napotkania potworów, ekwipunku i statystyk postaci
- pełny mechanizm generujący labirynt (na tę chwilę 1 poziomowy)
- wylosowane w ramach labiryntu pomieszczenia otrzymują w pełni funkcjonalne wyposażenie w postaci pułapek/potworów/skarbów
- mechanizm generowania potworów i ich cech
- mechanizm generowania skarbów i cech skarbów
- wstępne mechanizmy dotyczące bufora grafiki i cięcia grafiki na klocki (będą w wielkości 16x16 pixeli)
- wstępny mechanizm silnika graficznego do animacji

Posiedziałem przy generatorze mapy (właściwie to główne okienko gry), tak aby był przyjazny użytkownikowi - np. poprzez centrowanie obszaru na klocku, w którym znajduje się drużyna czy też umożliwienie przeglądania obszaru z pomocą myszy. Jednak po zmarnowanych na to kilku godzinkach doszedłem do wniosku, że za wcześnie na ten element i powinna nim zarządzać pętla generująca grafikę, a nie z poziomu javaFX.
Zrezygnowałem też z włączenia wcześniej wykonanego generatora podziemi do gry bo efekt końcowy nie był tak fajny jak zastosowanie znalezionej grafiki.

Ale jeszcze go wykorzystam!

W tej chwili (nie liczę grafiki) gra "zbudowana" jest z ok. 68 klas, a pewnie dojdzie drugie tyle. Tak właśnie wygląd ta prostota :].

Ehh siadając przy tym nie sądziłem, że tyle tego wyjdzie, a nie oszukując się - to dopiero początek.

A może roguelike?

Idę za ciosem.

Zachęcony efektem działania generatora podziemi stwierdziłem, że użyję go w większym projekcie. Generator ma stać się częścią prostej (tak wydawało się na początku) gry roguelike.
Żeby nie wymyślać koła i zasad gry od zera wykopałem starą planszówkę znaną na zachodzie jako Citadel of Blood, a w Polsce skopiowaną (zpiraconą przez Encore) i znaną pod nazwą Labirynt Śmierci. Generator będzie odpowiedzialny za tworzenie wyglądu poszczególnych klocków z których będą się składać podziemia, tak aby nie korzystać z niezbyt pięknych kafelków z których składała się oryginalna plansza.
W tej chwili wersja 0,0001 beta tworzy planszę z możliwymi połączeniami oraz ustala typ pomieszczenia, do którego trafia drużyna. W tle dzieje się trochę magii programistycznej
i  staram się robić te elementy gry, które nie sprawiają mi kłopotów programistycznych. W tej chwili dostępne są pierwsze wersje maszyny losującej potwory i skarby oraz mechanizm zarządzający turami gry.

Poniżej widać przykładowy działania generatora.

Kwadracik zielony to aktualna pozycja „drużyny” zwiedzającej podziemi. Podziemia tworzone są na bieżąco przy przechodzeniu między klockami (niebieskie kwadratowe pola) i na bieżąco określana jest liczba dostępnych wyjść/wejść z pomieszczeń. Czarne ramki to oczywście nieprzekraczalne „ściany”.

A tu widać w pełni wygenerowany poziom podziemi.

W tej chwili kwadraciki mają 64x64 px wielkości a sama plansza to 8x8 kwadratów (docelowo nie będzie tak skalowana).

Dla każdego z kafelków – w oparciu o ilość wejść – chcę wygenerować z pomocą już napisanego generatora wygląd. I tak do obszaru o 3 wejściach kafelek będzie wyglądał tak:

A tak dwa połączone klocki – jeden z 3 wejściami i drugi z jednym.

Taki przynajmniej jest plan. Na razie jestem jeszcze parę kroków przed połączeniem generatorów ze sobą.


Rzeczy wymagające dużo pracy idą w tej chwili na później – min. obsługa walki, grafika, ekrany i sensowne gui. Co do grafiki - będzie pixelartowa (oczywiście). Znalazłem w międzyczasie komplet grafik, które w 100% pokrywają moje zapotrzebowanie na elementy składające się na gry. Chcę wykorzystać DawnLike - 16x16 Universal Rogue-like tileset v1.81



Wygląda tak:

Będę mógł przećwiczyć obsługę grafiki i tworzenie animacji.

Mądrzy ludzie mówią, że najtrudniej napisać swoją pierwszą grę. Cóż – zobaczymy czy uda mi się ją zrobić i doprowadzić do grywalnej wersji. W miarę postępów (widocznych) będę dodawał kolejne wpisy.

Jeśli kogoś interesuje kod i co wykorzystuję - to także mogę go wrzucać. Piszę oczywiście w javie ze wsparciem javyfx  i kilku zewnętrznych bibliotek użytkowych.

Generator map lekcje 5 / 6

Kolejny krok to zapewnieniu połączeń pomiędzy oderwanymi od siebie obszarami map. Lekcje zawierają się w ramach wpisów:  Connecting Rooms oraz Ensuring Connectivity

Lekcję dotyczącą tworzenia połączeń między oderwanymi do tej pory pomieszczeniami przerobiłem wraz z tutorialem. Jednak kolejną, w której zapewniamy połączenia pomiędzy wszystkimi obszarami mapy zrobiłem już samodzielnie bez zaglądania do tutoriala. W oparciu o zdobytą już wiedzę i własne umiejętności udało mi się to dosyć sprawnie zrobić. Ciężko mi ocenić czy mój kod jest tak dobry jak ten z tutoriala, czy może wręcz lepszy, ale działa i jestem z niego zadowolony bo jest mój :D.


Poniżej efekt pracy bez uruchomionego dodatkowo łączenia (lekcja Connecting Rooms):

i z łączeniem oderwanych obszarów (samodzielny kod):

Jak widać pojawił się nowy korytarz łączący oderwane strefy.


Teraz wyznaczone ścieżki trzeba przekształcić w korytarze. Czyli: Passageways.

Generator map lekcja 4

Przerobiłem lekcję 4 Detecting Regions , w ramach której mapka była sprawdzenia pod obecność artefaktów w postaci zbyt małych obszarów pustych lub zbyt małych obszarów wypełnionych.
Przykładowo :

Mapka z dosyć dużą krawędzią dla kwadratu ściany (wartość Długość boku) z regionem o zdecydowanie zbyt małej wielkości. Powinien on zostać usunięty (wypełniony ścianą). Oczywiście w efekcie mapka będzie w 100% niegrywalna, ponieważ w całości zostanie wypełniona ścianami. 

Poniżej mapka przepuszczona przez filtr, z której usunięto dwa (musicie uwierzyć na słowo :) ) zbyt małe obszary puste. Algorytm usuwa także zbyt małe ściany.

  

W poniższej mapce widać zbyt mały obszar ściany, który powinien zniknąć z naszej mapy:

 Lekcja poszła dosyć szybko. Nie ustrzegłem się kilku błędów, ale udało się je w miarę szybko ogarnąć (nie pamiętam kiedy ostatnio używałem w javowego PriotytyQueue!)

Generator map lekcja 3

Dzisiaj dzień bogaty we wpisy!

Jako, że miałem troszkę czasu skończyłem 3 lekcję dotyczącą generowania map czyli Creating Meshes.
Muszę powiedzieć, że z powodu niezbyt dobrego zrozumienia tego co się dzieje w tutorialu (jak i słabego tłumaczenia) zrobiłem kilka poważnych błędów w kodzie i mapki wyglądały niebałdzo:

 Problemem ponownie były wbudowane w Unity funkcje, które musiałem napisać samodzielnie w java od zera.

Po kilku zmianach jest już jednak dużo lepiej:

Jak widać są jednak jeszcze jakieś błędy - całe zielone pole powinno być zabudowane mapą, ale efekt jest zachęcający.
Poszukam, poprawię i się pochwal.

HA! Znalazłem błąd. Generator tworzy teraz takie oto mapki.

Kolejny krok - usuwanie błędnych (zbyt małych) obszarów oraz ustalanie powiązań pomiędzy rozdzielonymi na mapie obszarami.

Rysunek Głowomeba

Od ostatniego wpisu o głowomebie minęło już trochę czasu, a gdy odkłada się rzeczy na później coraz ciężej zakończyć rozpoczętą pracę.

Głowomeba czekała i czekała, aż się w końcu doczekała.  Efekt poniżej, wiele lepiej nie będzie bo nie pozwalają na to moje umiejętności.
 
Poniżej umieszczam aktualne foto.

 

W tej chwili oceniam kompletność rysunku potwora na 95% - nie ma dorysowanej "podłogi" i jakiegoś sensownego tła portalu, z którego wychodzi. 

Rysunek wykonany jest ołówkami na kartce w formacie A4.

Generator map lekcja 2

Miałem chwilę na przerobienie kolejnego rozdziału tutoriala czyli Marching Squares. Teraz mój kod generuje mapę węzłów, z których będzie można przejść do wygładzania krawędzi pikselowej mapy.

Zrzutów ekranowych nie daję ze względu na to, że wizualnie nic się nie zmieniło. Siadam do części trzeciej.

Tuts+

Przeglądając neta znalazłem świetną stronę: http://gamedevelopment.tutsplus.com/ i tak się zacząłem zastanawiać - ile czasu zajmie mi przeczytanie, nie mówiąc o wykorzystaniu, interesujących mnie tematów, które tam znalazłem...

Kowboj

Aktualnie pracuje nad rysunkiem kowboja. Niestety nie mam kiedy go skończyć. W tej chwili mijają ok. 2 tyg od chwili gdy zacząłem go rysować, a nadal jestem w przysłowiowym lesie.

Po tym czasie powstał sam kontur. Poniżej rysunek w wersji zaraz po zbudowaniu postaci i kolejny - po poprawieniu krawędzi.
Czeka mnie jeszcze sporo pracy.

Pierwsza wersja postaci. Zdjęcie robiłem pod dużym kątem stąd taki dziwny układ.

Aktualny stan rysunku. Masa do poprawiania i dorysowania (chociażby muszę użyć linijki żeby broń nie wyglądała fatalnie)

Eva

Minęło kilka dni i udało mi się narysować kolejny rysunek. Tym razem trafiłem na zdjęcie Evy Green i z użyciem moich umiejętności mozolnie przeniosłem je na papier. Oczywiście cudów się nie spodziewałem.

Minusy

Moja Eva wyszła szersza w barkach i w głowie. Rozsypały mi się ramiona i nie wyglądają tak dobrze jak powinny. Twarz (gdyby była węższa) w miarę przypominałaby oryginał. Ponownie uciekły mi oczy. Nie wiem dlaczego, ale nie mogę znaleźć złotego środka, który pozwoli mi na poprawienie tego elementu. Część cieni jest zbyt delikatna - nie widać ich dobrze na zdjęciu.
Tak po prawdzie większość błędów widać dobrze dopiero po zestawieniu zdjęcia i obrazku ze sobą. Jak mam przed sobą oryginał nie jest tak źle :).

Plusy

Powoli wiem co to cieniowanie (poza tym kopiując ze zdjęcia widać od razu co i gdzie cieniować). W porównaniu z poprzednimi rysunkami lepiej wyszły proporcje twarzy i ciała. Jednak rewelacji nadal nie ma.
Tak czy inaczej - ćwiczę dalej.

Wasut wrzucił kilka, nad wyraz słusznych, uwag do rysunku i pewną drobną pomoc, która pokazuje jak bardzo rysunek rozjechał się z rzeczywistością. Dzięki!

Ranrir

Kim jest Ranrir? Napiszę jak będę miał chwilę

Ranrir

 

Gerhard

Kim jest Gerhard?

Napisze później :)

Gerhard

Miała być Penelope Cruz....

Kolejne dni i kolejny rysunek. Idzie mi trochę wolniej. Powodów jest kilka, ale główny z nich to taki, iż nad każdym rysunkiem spędzam dużo więcej czasu. Ćwiczę cieniowanie i najlepiej robi się to rysując:
a) gołą głowę z zaznaczonymi płaszczyznami + określenie kierunku padania światła
 b) rysując głowy z czarno-białych zdjęć.
 Po chwili poświęconej punktami a) poszedłem do punkut b) (tak na skróty). I tak oto padło na czarno-białe zdjęcie Penelope Cruze.

Minusy

Oczy, oczy, OCZY! Ciągle rysuję je za duże. Gdybym narysował je tak o 1/4 mniejsze byłoby super.
Schrzaniłem robotę przy włosach.
Znowu posypała mi się perspektywa :]
Przy rysowaniu włosów powinienem zmienić ołówek na jakieś B2-B4. To samo tyczy się cieniowania.

Plusy

Cieniowanie wychodzi mi troszkę lepiej. I gdybym narysował trochę mniejsze oczy byłaby nawet do siebie podobna :)

p.s. Gdy na rysunku dociemniłem włosy to bardziej wyszła Lena Headey niż Penelope Cruz. :)

Głowa

Dzisiaj mały rysunek - głowa krasnoluda ( :) ). Ćwiczyłem na nim rysowanie włosów oraz  cieniowanie płaszczyzn. Wyszło poprawnie.

Minusy

Nie dokończyłem rysowania dymu, a powinienem. Jeszcze szwankuje cieniowanie, ale powoli zaczynam rozumieć o co chodzi (jest to 4-5 głowa narysowana w tym tygodniu i pocieniowana). Znowu oczy wyszły za duże.
Sama głowa powinna być trochę szersza, ew. twarz leciutko mniejsza - mam problem z dobraniem proporcji. Skóra jest nieskazitelna - przydało by się jeszcze kilka zmarszczek.

Plusy

Mimo niedoróbek rysunek podoba mi się (tak jak i kilku osobom, które widziały proces jego powstawania). Fajnie wyszły włosy dookoła opaski.

Syrio i Arya

Zeszły tydzień zszedł mi na rysowaniu poniżej załączonej sceny pochodzącej z Gry o tron, w której Syrio uczy walki na miecze Arya Stark. Chciałem narysować więcej niż jedną osobę na scenie w skomplikowanym układzie ciał.
Poległem na kilku frontach, ale przynajmniej wiem na czym się skupić po zakończeniu tej pracy.

Rysunek powstawał za długo - prawie cały tydzień. Nie miałem czasu rysować i w efekcie znudziłem się tematem oraz mocno zabrudziłem kartkę, która leżał w tym czasie pod klawiaturą. To cud, że nie ma na niej jakiegoś kółka z kawy lub kawałka przylepionego jabłka.

Minusy

Miałem problem z poprawnym narysowaniem układu ciał i miejsc, w których na siebie zachodzą.
Spędziłem na tym dużo czasu wielokrotnie gumując obrazek. Mimo tego Arya ma tendencje do wywracania się na plecy, a nie powinna.
Kłopotliwe okazało się narysowanie butów dziewczyny (wiele razy wycierane) oraz jej twarzy (kilkanaście prób). Generalnie wcale nie jest do siebie podobna. Pierwsza wersja twarzy wyszła okropnie – jakaś stara baba z ciałem dziecka. Samo rysowanie osoby w wieku 10-14 lat zacząłem od dupy strony -powinienem więcej poczytać o proporcjach ciała i twarzy w tym wieku.
Syrio zresztą także wyszedł tak sobie – podobieństwo twarzy do oryginału jest bliskie zeru.
Nadal leży cieniowanie, źródło światła jest nie wiadomo gdzie – tym bardziej, cienie bohaterów pojechały mi nie tam gdzie trzeba (inaczej układają się na schodach, a inaczej z sylwetek). Znów - bez cieniowania rysunek wyglądał gorzej.
W czasie rysowania schodów źle obliczyłem ilość stopni i z prawej strony (za Arią) było 5 stopni, a z lewej, za Syriem , miałem ich 6. Zorientowałem się w tym dopiero przy zgrubnym cieniowaniu tła.
No i nie powinienem ostrzyć krawędzi ołówka na tym samym kartonie, na którym rysuje. To samo tyczy się wprawek do narysowania niektórych elementów (np. nie do końca dający się wytrzeć but straszy z posadzki).
A na koniec - zmęczony rysunkiem - zepsułem tło. 

Plusy

Zaczynam rozumieć jak rysować zagięcia na ubraniach i cienie do nich. Powoli buty przypominają buty, a nie dziwne opakowania, równie koślawych, stóp (pomógł tutorial na pinterescie). Coraz lepiej idzie mi rysowanie rąk. Nie są idealne, ale zaczynają wyglądać dosyć dobrze. Cieniowanie na twarzy Syria wyszło fajnie – twarz jest czytelna, ale jednak w cieniu. Właściwie to jestem zadowolony z tego rysunku - nie przypuszczałem, że będę potrafił tak rysować kiedy zaczynałem naukę w sierpniu.

Szkielety, z których wyszedłem.

Tutaj już dosyć zaawansowany stan, postacie maja ciała i zarysy ubrań, po ubraniami widać jeszcze szkielety.

Problem z narysowaniem buta.

Dziwna twarz Aryi.

Troszkę lepsza.

Koniec.

Referencja.