Tym razem od innej strony, aby nie było, że cały czas idzie świetnie.

Tym razem od innej strony, aby nie było, że cały czas idzie świetnie.
Programowanie ma to do siebie, że można napisać pięknie działający kod, wizualnie perfekcyjny a i tak nie działa.

Tak jest i tym razem, jak poprzednio kilkaset razy, stworzyłem coś co w zamyśle miało działać poprawnie, bo tak wygląda z kodu, kolejne kroki są poprawne ale tylko dla mnie, bo system widzi to inaczej, jeden błąd, jedno przeoczenie, jedna zmienna, którą ustawiłem w innym pliku, która jest jak widać znacząca.

A co się dzieje w tym przypadku?
A to jest bardzo proste, kończę pisać przedostatni typ przeciwnika, a ten ma bardzo proste zadania.
Iść aż nie uderzy w ścianę
Iść aż nie dojdzie na skraj podłoża

Podbiec do gracza, gdy ten jets w zasięgu, jeb... uderzyć go kosą, odskoczyć do tyłu, żeby nie dostać strzała od gracza.
I sprawdzić czy gracz wciąż jest w zasięgu, jeżeli jest ma do niego znów biec i uderzyć i powtórzyć całą akcję aż gracz
Nie umrze albo nie będzie go już w zasięgu bo uciekł.

Zadanie proste jak się wydaje, ale tylko wydaje.
W praktyce trzeba obliczyć pozycję gracza, przenieść tam przeciwnika, zatrzymać go w odpowiednim miejscu, wywołać 3 animacje, potem uderzyć, sprawdzić czy uderzyło się gracza, potem odskoczyć, ustawić przeciwnika twarzą do gracza i nakazać mu iść w odpowiednim kierunku aby nie szedł do tyłu (co się już zdarzyło).

No i w tym natłoku prostego zadania pojawia się błąd.
Przeciwnik skacze wokół gracza jak królik, raz atakuje go od przodu, raz skacze za niego by mu w plecy wbić kosę.
Raz biegnie a raz idzie, mimo tego samego kodu.

Dlatego też, czasem najprostsze zadania zajmują długie dni.
Naprawa bugów, tak aby działały to najgorsza raca, bo w naszym mniemaniu kod jest poprawny, więc nie ma co poprawiać, a według systemu jesteśmy głupi i nie potrafimy poprawnie napisać tego co chcemy.
Naprawienie tego jednego prostego blędu potrafi zając.
A mi zajęło to już 7 godzinę.

#rhr #programowanie #zalesie #chwalesie #pcmasterrace