Zwodzenie młodzieży na manowce kodoklepstwa

@Koncereyra tylko dużo w klawisze klepał ale tekstu o programowaniu jakoś się nie doczekałem. Popchnę ten wóz w interesującym nas kierunku.

Ponieważ nazbierało nam się ojców z zasady robiących w kodoklepstwie i pochodnych to pozostaje kwestia jak wkręcić latorośl w te kognitywne zabawy.
Zacznę od środka, a jak mi się kiedyś uwidzi to dopiszę tekst o prerequisites żeby do tego usiąść bo to się musi dodawać, żeby dziecko w ogóle miało do czego siadać.
Omawiane zwierzę testowe to osobnik homo rzekomo sapiens w wieku lat ponoć dwunastu.

Młodego najpierw wkręciłem w arduino i na wyświetlaczu kazałem mu zrobić ruchy ludzikiem, po wstępnym okazaniu że działa (jak twierdzi @impeer nic nigdy nie działa i nikt nie wie dlaczego, co jest pewną bolączką przy pokazywaniu dzieciom, że jednak da się wszystkie te problemy rozwiązać myśleniem) postawiłem kwestię czy jakbym mu dał większy wyświetlacz i więcej możliwości obróbki danych to by coś tam sobie ogarniał. A że na arduino jest dość restrykcyjne C i mimo to rozumiał o co się czepia kompilator odnośnie składni (dla mnie jest po prostu czepialski i wymaga zbędnych oczywistości) to pozostało wybrać środki.

Warunkiem wciągnięcia dzieciaka w cokolwiek jest pokazanie czegoś co działa oraz serii prostych, szybko osiągalnych pierwszych kroków żeby kropki się łączyły. No bo jak się nie łączą to po kiego je łączyć? Takie rzeczy może dopiero poukładać sobie w głowie dorosły, który już wie że rezultaty wiedzą i naklepie kilkaset linijek kodu żeby się dowiedzieć gdzie mu się coś uwidziało, ale nie dzieciak, który musi testować każdą dopisaną fantazję i nie jest na tyle ustrukturyzowany żeby po rezultatach wychwycić gdzie w setkach linii szukać niewłaściwego przypisania. Dlatego musi być to krótkie.
Z powodu nienawistnie pędzącego kalendarza <8bitowe komputery wyszły i C64 raczej się pod biurkiem nie wala. Zresztą basic C64 to było utrapienie, a Musku na VIC musiał mieć większe zgryzy. Zły basic boli przez całe życie.

Po pierwsze wybieramy platformę i to nie jest reklama (ale tylko dlatego że mi nie zapłacili). Musi ona spełniać następujące warunki. Być C podobna (wszystko jest C podobne, z punktu widzenia podstaw różnice między językami C podobnymi są nieistotne). Mieć biblioteki do wyświetlania grafiki (co oznacza że część naszych platform przeznaczonych do obsługi elektroniki czy baz danych mających na sucho serial i command line odpada), jakieś I/O i w ogóle już sobie nawymyślałem. Oczywiście można od razu wsiadać na unity, ale tam będzie więcej nauki obsługi narzędzi, których dzieciak nie miał okazji poznać, więc nie dojdziemy do meritum przez miesiąc.
Skupiamy się na proceduralnym języku ogólnego przeznaczenia bo na bazie matematyki z jaką taki dzieciak ma do czynienia trzeba go będzie nauczyć operowania z OBOE na fencepost errors, które będą zmorą pierwszych piętnastu minut. Oczywiście ujmiemy tam struktury imperatywne, ale że nie operujemy bezpośrednio na rejestrach jak w arduino to mamy warstwę interpretacji, która chroni nas informując: “w tej linii wyszło tak, że jesteś głupi”.

Od razu odwiodę naszych czytelników od scratcha (i podobnych) czy pytonga. Tak jak Żyrynowski z pochodzenia jest prawnikiem tak większość czytelników z pochodzenia jest techniczna. To znaczy że jesteście po wielopokoleniowej selekcji łbów w krainie gdzie nawet Smoka pokonywano zmyślnym fortelem, a nie nabijano na kopię i przemysł jest w tych krzakach tak stary, że pierwsze króle reintegratory miały go w imieniu. Czyli Wasze dzieci też mają takie wskazania i to zapewne bardziej uwypuklone środowiskiem niż kiedykolwiek było możliwe. A to oznacza, że łażenie wkoło tematu jakimś symbolicznym przedstawianiem zbiorów liczb nie jest im ani potrzebne, ani czemukolwiek nie służy. Dlatego w uproszczony sposób można im pokazać pracę na fejkowych rejestrach bez wprowadzania w szpeję ich adresowania i tworzenia procesorów. Będziemy więc działać na arraych, względnie na ich uczesanej wersji struktur danych. Tyle że wyłącznie w jednej formie – listy. I na takim klocku oprzemy całą zabawę.

Z wielu dostępnych opcji wybrałem za 39$ rocznie (później dadzą Wam na stałe żebyście się odczepili) GMS2 https://www.yoyogames.com/en/get
choć i jedynka była niczego sobie (i do tego miała otwartą możliwość odpalenia d3d na directX żeby dzieci kłopotać real+i+j+k ). Dla niezorientowanych w nawiasie:

Istotne jest to, że nie trzeba wczytywać bibliotek i całego certolenia ze specyficznymi funkcjami potrzebnymi do danych zastosowań – całość uproszczeń operacyjnych do zaciekawienia dziecka już tam jest. Nauczy się porządku i składni to go dociśniemy tworzeniem takich uproszczeń w skryptach samodzielnie. Tylko że i tak będą wolniejsze od takich gotowych.

W tym narzędziu prawie z niczego nie korzystamy – tworzymy room pasujący do naszej rozdzielczości (nie ma to później większego znaczenia ze względu na sposób w jaki będziemy się bawili, ponieważ będziemy operowali bezpośrednio na wyświetlaczu i aspect ratio nas nie pokąsa), na nim stawiamy jeden obiekt, i w nim tworzymy setup (create event) czyli dane ładowane na dzień dobry, loop (step event) czyli pętlę wykonawczą oraz rysowanie (draw event). Następnie bez zabawy w jakieś uproszczenia abstrakcyjne z gatunku obiektów i związanych z nimi kropek, with, self i innych dupereli jedziemy bezpośrednio na strukturach danych. Dla zabawy wczytywanych do zmiennych ustalonych w setupie (dopóki nie przesadzimy z fantazją), żeby wyjaśnić dziecku jak działa akumulator danych i ilość pomyślanych na początku zmiennych zarezerwowanych w pamięci będzie miała znaczenia jak się zabierze do układów scalonych – tam jest limit statyczny.

Sprity są, kod jest gdzie wklepać, eventy I/O odczytywane i jedziemy.
Zaczniemy od czegoś prostego (firsttry):

Ma być tak – zabawa tylko w ramach jednego ekranu, ruszamy się po kratkach (nie komplikujemy dziecku ruchem diagonalnym, forward step checkiem i kierunkami na początek), eventy w programie oraz I/O odczytujemy w warunku czas mod wartość, dzięki czemu będzie i pozór płynności i wewnętrzna turowość.

Najpierw robimy żeby nam się “ludzik” ruszał po ekranie w te kratki. Następnie wrzucamy boundary żeby za ekran nie wylazł. Po tym dodajemy na strukturę danych przeszkody na które się nie da wtargnąć (mury, jak w bombermanie) i pokazujemy pierwszą pętlę generującą to do listy losowo po ekranie.
Dzięki temu pokażemy jak się przypisuje dużą ilość obiektów kilkoma zmiennymi zapisanymi jedna za drugą w formacie i+0 to położenie x, i+1 położenie y, i+2 rodzaj obiektu, po porównaniu zwiększ i o wrapa (liczbę komórek danych). Czy coś w ten deseń. To samo robimy w wyświetlaniu i można sobie połazić po “labiryncie”.
Ponieważ to się losowo na siebie nakłada pokazujemy jak listę porównywać w loopie do siebie samej i powycinać duplikaty pozycji.

Dodajemy pierwszego potworka, który rusza się nam losowo i też nie włazi na mury.
Dodajemy event że jak nas złapie to koniec. Dzieciakowi w tym momencie włącza się myślenie bo jest interakcja i zaczyna stawiać racjonalne pytania. One brzmią mniej więcej tak “czy jakbyśmy, czy możemy?”. Wszystko możemy – sformułuj co będziemy do czego porównywać i jedziemy.

Następnie dorzucamy stworka z algorytmem greed który ludzika gania i dochodzimy do kwestii tego czas mod wartość testując na dziecku ilu loopów mu się podoba, żeby to w ogóle było grywalne (no bo przy ustaleniu 100 loopów na sekundę gra się kończy po włączeniu – stwory Cię dopadły, więc trzeba żeby one tylko co którąś pętlę wykonywały czynności i ta sama historia z I/O).

Całkiem możliwe że po takim wieczorze załapie. I siądzie dłubać sam. Dowie się czego nie wie, ale szybko będzie się uczył. Macie więc do następnego weekendu czas żeby wieczorami wydłubać “grę” z takimi restrykcjami jak powyżej tylko już bez tego z jednym ekranem.
Wygląda to tak (grisjaggare):

Czyli mamy:
-duże mapy ładowane w kawałkach do plików (więc i obrót plikami);
-losowe mury i komnaty;
-znajdźki wspierające postać;
-zasięg widoku (pochodnia);
-zdolność walki (pochodnią im mocniej świeci tym mocniej bijemy);
-możliwość niszczenia murów (z wyłączeniem granicy mapy) znajdźkami (kilofy und łopaty);
-cel gry (zebranie wszystkich świń przerzuca na następny level);
-menu startowe (z możliwością przełączania z okna na fullscreeen i z powrotem);
-pauzę (p);
-helpa (jeszcze niewypełnionego treścią);
-tryb wyjścia i restartu gry;

-przeciwnika ruszającego się losowo (mumię);
-przeciwnika ruszającego się w kierunku gracza i w razie gdyby greed wpadł w jakąś pułapkę rekurencji na ścianach zmieniającego się na jakiś czas w tryb losowy (moinotaura);
-przeciwnika ruszającego się losowo i gaszącego pochodnię (ducha);

-przeciwnika zadającego rany (mumię);
-przeciwnika zadającego rany gdy rusza się losowo i szarżującego (multipler ran) greed alg (minotaur);
-przeciwnika niezadającego ran, ale wkurzającego gaszeniem pochodni (duch);

-automatycznie rozstrzyganą walkę w cyklach I/O;
-efekty walki (obrażenia gracza na czerwono, potworów na niebiesko);
-efekty znajdziek;
-efekty interakcji potworów (minotaur krzyczy gdy szarżuje, świnie kwiczą gdy walną w mur, mumia i minotaur też rzuca swoje teksty);
-efekty wyświetlane w pozycji ekranu więc można do nich na żywca podpiąć przestrzenny dźwięk;

-następne levele generowane tak samo losowo tylko już na losowym rozmiarze mapy;
-mocniejsze parametry potworów co level;
-modyfikację liczby znajdziek co level;
-modyfikację prędkości spalania pochodni od któregoś levelu (i tak nigdy nie doszliśmy poza pierwszy);
-hiscore (jeszcze nie przetestowany w praktyce);

I stawiamy młodzieży zasadnicze pytanie czy ludzik mógłby się ruszać padem? Co by chciał dodać, jakie parametry trzeba przechowywać by realizować jego pomysły?
Więc w następny weekend dajemy mu do skonfigurowania pada, żeby czytał z niego I/O po czym pokazujemy mu jak jego setki linii kodu można zamienić w kilka linii pętli czytających to wszystko i wyświetlających.


//pad info display
for(iii = 0; iii < gamepad_get_device_count(); iii++)
{
kkk = 0;
gpic = gamepad_is_connected(iii);
if gpic = 0 {break};
gaxc = gamepad_axis_count(iii);

draw_text(iii*256,kkk * nxtline, “pad number: ” + string(pad_num)) ;kkk++;
draw_text(iii*256,kkk * nxtline, “conected: ” + string(gpic)) ;kkk++;
draw_text(iii*256,kkk * nxtline, “axis: ” + string(gaxc)) ;kkk++;

for(jjj = 0; jjj < gaxc; jjj++)
{
draw_text(iii*256,kkk * nxtline, “axis: ” + string(jjj) + ” read: ” + string(gamepad_axis_value(iii, jjj)));kkk++;
}
bcnt = gamepad_button_count(iii);
draw_text(iii*256,kkk * nxtline, “buttons: ” + string(jjj));kkk++;
for(jjj = 0; jjj < bcnt; jjj++)
{
draw_text(iii*256,kkk * nxtline, “button: ” + string(jjj) + ” read: ” + string(gamepad_button_value(iii, jjj)));kkk++;
}
}

I bawimy się dalej w ruchy na kierunkach, podpowiadamy że na padzie są dwa sticki więc jednym ruszasz postać, a drugim obracasz wieżyczkę co prowadzi nas do oczywistej konkluzji co dalej.

Pliki (wszystko natywnie jest dla 1920×1080, grissjagare odpala się w oknie i można dać fullscreen, firsttry nie ma takich luksusów):
firsttry projekt do GMS2:
https://zarobmy.se/wp-content/uploads/2021/04/first_try.yyz_.zip

 

firsttry executable zip:
https://zarobmy.se/wp-content/uploads/2021/04/firsttry_executable_zip.zip

(wersja końcowa, 5 stworów, działający highscore etc)
grissjaggare projekt do GMS2:
https://zarobmy.se/wp-content/uploads/2021/05/grisjaggare.yyz_.zip

grissjaggare executable zip:
https://zarobmy.se/wp-content/uploads/2021/05/grisjaggare.zip