Elementy programowania – struktury, algorytmy i programy gotowe

Szablon: Fort Quest 04–01 ‚2015 beta


Opis elementów szablonu przygodowki w Atari BASIC (starsza wersja szablonu – jednoplikowa).

1. Linia w Atari BASIC: 230 IF INV(3)=1 AND LOCITEMX(1)=10 AND LOCITEMY(1)=4 AND INV(5)=1 THEN GOTO6499

odpowiednik w Turbo Pascalu: IF (INV[3 ]=1) AND (LOCITEMX[1]=10) AND (LOCITEMY[1]=4) AND (IN V[5]=1) THEN end_check:=true;

jest sprawdzeniem warunku ukończenia Questu zadanego na wstępie gry.

W powyższym queście przykładowym gracz musi posiadać przy sobie (w inwentarzu) sznurek i patyk, a kamień musi leżeć w lokacji o współrzędnych (10,4) – czyli w jednym z najdalszych rogów (lub ‚kątów’) jaskini.

Jeśli gracz znalazł wyjście z lasu (znalazł się w lokacji wyjścia z lasu) ze spełnionym warunkiem ukończenia questu, to GRATULACJE i Koniec Gry, w przeciwnym wypadku gra trwa aż do zakończenia.

2. Mapa gry może być dowolnie modyfikowana z zachowaniem muru dookoła mapy (wartości 1) – w wersjach prezentowanych szablonu nie jest sprawdzana krawędź mapy. Będzie uwzględnione w szablonie skończonym pełnym.

3. Początkowe rozmieszczenie przedmiotów w grze (na mapie) polega na przypisaniu odpowiednich wartości odpowiednim zmiennym dotyczących elementów gry, analogicznie rozpoczęcie gry z przygotowanym inwentarzem, etc. (wyposażenie bohatera, przedmioty w lokacjach, quest – warunek wyjścia z gry, itp. – jest to jedynie ustawienie odpowiednich zmiennych lub stałych programu w odpowiednich miejscach programu w wartościach zgodnych z założeniem autora), np. warunek wyjścia z lasu polegający na sprawdzeniu posiadania jedynie patyka wygląda jak w linii poniżej:

230 IF INV(3)=1 THEN GOTO 6499

odpowiednik w Turbo Pascalu: IF INV[3 ]=1 THEN end_check:=true;

4. Funkcja lub instrukcja pokazująca mapę gry jest analogiczna do instrukcji pokazywania każdej lokacji gry z osobna, np. po każdym wejściu do nowej lokacji:

FOR Y=1 TO 80: FOR X=1 TO 120: READ C: COLOR C: PLOT X,Y:NEXT X:NEXT Y

rysuje bitmap w rozdzielczości 120×80 pikseli o kolorze C czytanym z kolejnych wartości np. umieszczonych w liniach DATA.

5. Muzyka w grze analogicznie jak grafiki lokacji z ułatwieniem, że muzykę uruchamia się na przerwaniach lub w inny sposób, żeby nie musiała być obsługiwana podczas rozgrywki => muzyka gra samodzielnie, rozgrywka toczy się niezależnie. Przy sprawdzeniu rodzaju aktualnej lokacji, np. las lub jaskinia lub labirynt podziemny, etc. – muzyka może się zmieniać (wystarczy zamienić zestaw muzycznych dźwięków na inny i uruchomić granie dźwięków od nowa z nowym zestawem dźwięków).

Dźwięki związane z danymi czynnościami wykonywanymi w grze przez gracza lub w zależności od zdarzeń i lokacji są wykonywane analogicznie jak w przykładzie dotyczącym rysowania grafik lokacji, czyli sprawdzenie warunku i granie dźwięku lub nie (w zależności czy trzeba, czy nie – w zależności od zdarzenia zaistniałego w grze).

Przykładowo w Zorro firmy Datasoft muzyczka w grze zmieniała się na zestaw innych dźwięków po wejściu do podziemnego labiryntu pod cmentarzem. Dźwięki grające w zależności od zdarzenia ‚dzwonią dzwony’ są grane dodatkowo, kiedy warunek jest spełniony, że dzwony mają dzwonić (po ukończeniu questu dotyczącego uruchomienia dzwonów).

6. Inne elementy wkrótce w przykładach (wiele questów, wiele scenariuszy, wielu bohaterów grających jednocześnie w tej samej lub w różnych grach, spotykających się w lokacjach, wiele przedmiotów, tworzenie przedmiotów, używanie przedmiotów, itp. etc.)

[..]


[..]

[opis kodu programu w wersji jednoplikowej]

Przed zamieszczeniem skryptu ogólnego do przenoszenia programów działających i napisanych w Atari BASIC na kody źródłowe w Turbo Pascal, HTML, PHP, inne dowolne, opis ogólny kodu Fort Quest 04–01 dla tych, którzy chcieliby samodzielnie zrobić własne konwertery skryptowe kodów źródłowych:

Linie 1 do 13: deklaracja zmiennych i przypisanie/zdefiniowanie stałych

Linie 50 do 71 – informacja wstępna dla gracza (w trybie tekstowym i oczekiwanie na rozpoczęcie gry)

Linie 80 do 99 Przypisanie wartości do zmiennych na potrzeby gry (umieszczenie / rozlokowanie przedmiotów w świecie gry, określenie stanu początkowego elementów gry, np. drzwi zamknięte/otwarte, wypełnienie inwentarza gracza przedmiotami posiadanymi na początku rozgrywki, itp., oraz narysowanie gotowych map lokacji w pamięci ekranu niewidocznej dla gracza, żeby mieć gotowe do wyświetlenia na polecenie gracza MAP)

Linie 100 do 135 – GŁÓWNY KOD PROGRAMU – cała gra wykonuje się w tych liniach od 100 do 135 sekwencyjnie w pętli skoku do początku i od nowa po kolei (135 GOTO 100)

Linie 198 do 203 – rysowanie map w pamięci ekranu

Linie 203 do 6480 – podprogramy (obsługa słownika poleceń, inne podprogramy do obsługi zdarzeń w grze – wywoływane w bloku głównym programu (w liniach od 100 do 135))

Linie 6499 do 6501 – zakończenie działania programu i wyjście z programu (gry)

Linia 6504 – lista przedmiotów wykorzystywanych w grze

Linie 6530 do 6547 – mapy gry zapisane w postaci znaków 1 lub 0 (mur / przejście) – można dowolnie modyfikować w kodze programu – program powinien teoretycznie obsłużyć każdą dowolną mapę zbudowaną z 1 i 0

Można eksperymentować i sprawdzać.

Koniec programu.

Reszta to zabawa.

Kod łatwo przenosi się skryptowo na dowolne kody źródłowe wykonywalne dowolnych interpreterów, kompilatorów, skryptów, platform komputerowych, systemów, etc. – bez znaczenia.

Liczy się możliwość realizowania funkcji programu w sposób widoczny dla użytkownika, czyli musi być to samo, bez znaczenia gdzie i jak uruchomiono.

Oczywiste.

Dobrej zabawy.

DS`.
DEC.25.2015.


[..]

[opis kodu programu w wersji jednoplikowej – starsza wersja gry – przed wprowadzeniem omawianych aktualizacji kodu]

Zanim kod pełnego szablonu przygodówki w Atari BASIC będzie udostępniony do użytku dla zainteresowanych w wersji skończonej, gotowej do przeniesienia kodu wprost po linii (skryptowo) => na Turbo Pascal, PHP lub HTML, etc. – zadanie treningowe dla programistów Atari BASIC.

Proszę sobie eksperymentować ze sposobami korzystania lub przetwarzania i pamiętania mapy w grze.

W wersji aktualnej szablonu mapa zapisana jest w liniach DATA programu w Atari BASIC.

Przykładowe metody czytania mapy:

1. RESTORE i sekwencyjnie po znakach, obsługując lub przetwarzając mapę do czytania.

2. Korzystając z miejsca pamięci, gdzie znajdują się linie DATA programu Atari BASIC (czytanie / zapisywanie / modyfikacja mapy w liniach DATA)

3. Przepisując do zmiennej lub do pamięci obojętne gdzie, np. od adresu 1536 z linii DATA przed rozpoczęciem korzystania z mapy.

4. Nie korzystając z linii DATA, np. wpisując do zmiennej tablicowej jako stałe wartości elementów mapy gotowej w treści programu.

5. Wczytując do zmiennej mapę gotową z pliku z mapą (wiele map).

6. Losując elementy mapy przed rozpoczęciem rozgrywki – z zachowaniem logiki i sensowności wylosowanych pozycji na mapie (mur / przejście) – żeby gra dla gracza była sensowna – questy i wędrówka musi być możliwa, oczywiste.

Szablon gry powinien radzić sobie automatycznie zgodnie z algorytmami zaimplementowanymi z dowolnym rodzajem mapy obsługiwanej. Można na próbę wpisać sobie elementy mapy ‚ręcznie’ w postaci 1 lub 0 (mur lub przejście) w liniach DATA programu, teoretycznie szablon powinien podołać z każdym możliwym rozkładem elementów 1 lub 0 – z zachowaniem muru dookoła mapy oraz muru na linii 5 lub 6 w pionie (00 do MAPY).

Powinien działać zarówno podgląd schematyczny labiryntu (VIEW) jak i mapy.

Potem sprawdzę, na razie nie jest to istotne.

Proszę sobie znaleźć najszybszą i najefektywniejszą i najbardziej elastyczną metodę obsługiwania potencjalnie wielu dowolnych map w grze o rozmiarach zadanych dowolnych MAPX, MAPY (zakres zmiennych 64–bit lub dowolna wartość).

Przy zoptymalizowaniu elementów szablonu do wersji najprostszych, gra jest zawsze szybka i ‚natychmiastowa’ w wykonaniu dowolnych elementów gry – dla użytkownika, czyli użytkownik nie widzi i nie zauważa, że gra ‚musi coś robić wolno lub długo’. Wszystko, co otrzymuje użytkownik jest natychmiastowe.

Ciekawej zabawy.

Powodzenia.

Szablon gotowy najprostszy w wersji skończonej w standardzie nie do poprawienia na lepszy pod jakimkolwiek względem będzie dostępny oficjalnie, jeśli będzie zapotrzebowanie ze strony zainteresowanych korzystaniem.

Każdy programista samodzielnie powinien umieć wykorzystać szablon do robienia najefektywniejszych i najszybszych programów jakie są możliwe do zrealizowania w zakresie realnym.

[..]

Kod programu jest nieuporządkowany, pisany na potrzeby działającego programu. Po uporządkowaniu i zoptymalizowaniu wszystkich osobnych fragmentów programu, szablon powinien być perfekcyjnie szybki i przenoszony automatycznie na dowolne platformy i kody źródłowe dowolnych języków wykonujących / interpretujących / przetwarzających kod programu w Atari BASIC.

Można sobie zapuścić jakiś benchmark na kod główny programu (linie od 100 do 135) i sprawdzać, czy jest szybki, bardzo szybki, czy genialnie najszybszy, że szybciej się nie da – warto poprawiać podprogramy wywoływane z programu głównego, żeby benchmark był maksymalnie możliwie szybki na testowaniu wszystkich możliwych dróg w grze automatem dla dowolnych losowych zmiennych aktualizowanych przy wykonywaniu bloku od 100 do 135. Hmm… mam nadzieję, że blok od 100 do 135 nie zawiesza się lub nie zwraca błędów dla 100% dowolnych wartości możliwych w grze wrzucanych na zmienne w tym bloku – jeśli tak jest, to kod jest dobry i sprawny. Można usprawniać i optymalizować podprogramy, żeby więcej nie było możliwe realnie usprawnianie i powinien wyjść Standard ISO. Amen. fajne…

ITD. Każdy blok i podblok programu automatycznie wprost przenosi się na dowolne języki programowania skryptowo, powinno działać w dowolnym języku programowania istniejącym, na dowolnej platformie komputerowej / elektronicznej – bez znaczenia – liczy się wykonanie funkcji programu zgodnie z pierwowzorem w Atari BASIC. Nic więcej, oczywiste. Proste jest programowanie – musi być proste i najprostsze, oczywiste… i musi działać. Inne sposoby programowania nie istnieją, oczywiste, nie byłyby sposobami sensownymi, czyli bez sensu, czyli niepotrzebne bo gruz.

Miłej zabawy i poznawania światów oraz tworzenia własnych. [DS`].DEC.25.2015.

Kiedyś to dokończę… najpierw Online dla wielu graczy, pogram sobie z kimś na internecie, może wtyczka Java 8.66 nie będzie mi potrzebna, wait… trzeba dopisać blok obsługi sygnałów z internetu między grami (wymiana raportów stanów gier między graczami), czyli przesłanie zestawu zmiennych i stałych z linii od 01 do 13 z aktualnymi wartościami i to chyba wystarczy. Proste. Kilka dodatkowych linii… będzie Online. Emotikon smile

Przygodówki – szablony – Fort Quest 04–01 – przykłady…

[..]

I dodatkowo polecenie w słowniku: SEND [message], żeby gracze mogli sobie rozmawiać w grze…

Jedna linia więcej.

OK. Działa… kiedyś się pobawię. REM Koniec… priorytety. Najpierw kawa… to działa, to już nie trzeba się zajmować… Amen.

Przy okazji warto dodać do nowej wersji szablonu polecenie słownikowe ‚SAVE’ – możliwe, że się przyda, szczególnie przy grach online. SAVE zapisuje wspomniany zestaw aktualnych wartości zmiennych i stałych z linii od 01 do 13 w pliku np. fort.sav i można ten plik przesłać komuś z aktualnego momentu rozgrywki, żeby sobie kontynuował w miejscu, w którym skończył poprzedni gracz, wystarczy wpisać polecenie LOAD [nazwa pliku sav] i gra rozpoczyna się od momentu zakończenia przez gracza, który zgrał zrzut stanu poleceniem SAVE. Jedna linia więcej – a przydaje się gotowy plik sav do przesyłania między graczami, żeby mogli sobie grać jednocześnie w swoich grach wiedząc, co u drugiego i wymieniać się przedmiotami, zadaniami, rozmawiać, kierować się w odpowiednie miejsca, żeby sobie pomagać, itp. etc. – według pomysłu autora… uruchomienie gry ze stanem aktualnym gry i kontynuowanie polega jedynie na wpisaniu wartości w zmienne z bloku 01 do 13 i uruchomieniu kontynuowania gry w bloku głównym programu, tj. GOTO 100 – skok do następnego ruchu gracza… i to tyle a propos saveów na Atari. Można grac online, można sobie grać jak w biegu z przekazywaniem pałeczki, w maratonie przykładowo… jeden gracz się zmęczy, to przekazuje plik save z aktualnym stanem gry i inny gracz kontynuuje grę – wystarczy aktualizować blok 00 do 13 i GOTO 100. Emotikon smile RUN[];

Polecenie LOOK trzeba uzupełnić pewnie o informację ‚Tu jest inny gracz.” i wtedy wiadomo, że ktoś się kreci po labiryncie oprócz Gracza głównego… można sobie powymieniać przedmioty, pobiegać, bawić się w przygody własne po labiryntach, fajne… można się umawiać na spotkania w kazamatach, w różnych lokacjach i np; przynosić zdobyte rzeczy i wymieniać się, albo informować co gdzie leży, żeby ta iść i przynieść, bo ktoś ma mało siły na przykład, różne, dowolne… fajne. Działa. Lubię to. Można robić przygody… jeszcze ładne grafiki się przydadzą, żeby sceneria była ciekawa, wait… i potwory jakieś,żeby przeszkadzały graczom…

To by już wyszedł szablon Ultima Online po dodaniu kilku linii do kodu programu… hmm…

[..]

DEC.25.2015.