pseudo 3d ASCII

Szkic gry/symulacji.

Pomysł jest taki żeby na podstawie prostej mapy znaków w trybie testowym ( wymyślonej lub generowanej losowo ) wyświetlał się widok pseudo 3d.
To samo ma dotyczyć wszystkich obiektów które na takiej mapie będą żyć.

Krótki film:

Repo:

https://github.com/goostaw/pseudo3d_ascii/tree/master

Jeśli to ma znaczenie:

1. Celem jest zabawa. Nie mam aspiracji bycia (zawodowym)programistą.
2. Lubię stare komputery, a moje zabawy uskuteczniam na 486 pod DOS-em. Wymyśliłem sobie że programy mają działać na najstarszym PC jaki znalazłem w szafie: IBM Portable 5155 ( PC XT ).
3. Archaizmy są trochę zamierzone, a trochę wynikają z 2, a trochę ze zwykłej niewiedzy, braku doświadczenia i lenistwa.
4. A ponieważ 2. to głowne narzędzia to Open Watcom i vi. Dodatkowo na potrzeby przesłania tego na githuba użyłem g++ pod starym Debianem. Obie wersje bin w repo.

Pomimo tego proszę o poświęcenie czasu i opinie gdzie jest największa dupa, gdzie jest mniejsza dupa, co poprawić w pierwszej kolejności , co przeczytać itd. Jedyna moja wiedza to kilka książek więc każda rada będzie cenna.
Pewnie nie wszystko zrozumiem ale na pewno się postaram i bedę wdzięczny.

Nie mój język, więc nie będę mędrkował, ale od wizualnej strony super – świeży powiew ”rogalików”. ;)

Fajnie by jednak było, gdyby mapa w 3D była renderowana nie skokowo, a płynnie, na zasadzie starego dobrego ray castingu. Gdyby więc poruszanie się po labiryncie było płynne, dawałoby więcej frajdy. Oczywiście wprowadzenie płynnego ruchu po labiryncie nie sprawi automatycznie, że dwuwymiarowy podgląd mapki (rzut z góry) nie będzie możliwy do wyświetlenia. W dalszym ciągu będzie mógł być renderowany, tyle że w formie przybliżonej, jeśli chodzi o pozycję gracza i innych ruchomych obiektów. Do tego dodać kolorowanie znaków zgodnie z oświetleniem i masz świetny silnik do gry.

Mimo wszystko bardzo fajny projekt i dobrze by było, gdybyś przekuł go w poważną grę.

Dzięki.

Pewnie tak. Płynne przejścia to byłyby coś!
Być może dałoby się to zrobić w trybie textowym bez tego ray castingu. Pomyślę.

U mnie jest prosto. Dla każdego obiektu w zasięgu w zależności od „punktu widzenia” jest odpalany odpowiedni sprite. Tyle.
Mi to pasuje, bo lubię stare dosowe rpgi w stylu „Eye of the Beholder” czy „Might & Magic”.

Tego się właśnie obawiałem. ;)

Jeśli chciałbyś zaimplementować płynne chodzenie po labiryncie, to bez ray castingu lub pełnej matematyki dla 3D się nie obejdzie. Tego nie da się załatwić statycznymi kafelkami czy sprajtami – za dużo by tego było.

Tego się właśnie obawiam. :)
Za trudne póki co.

Moment, o ile pełne 3D jest dość skomplikowane do wykonania (w zależności od wymaganej jakości/szczegółowości renderowanego obrazu), tak raycasting jest znacznie, znacznie prostszy. Tym bardziej, jeśli labirynt jest płaski, a silnik gry nie obsługuje schodów/wind.

Polecam zapoznać się z artykułem Lode's Computer Graphics Tutorial – znajdziesz w nim szczegółowy opis działania, a także kod źródłowy w C++ generujący nieoteksturowany i oteksturowany labirynt, z możliwością dowolnego chodzenia po nim. Różnica polega na tym, że zamiast renderować rastrowy obraz klatki, Ty układasz go ze znaków o odpowiednich kształtach i kolorach (będzie ich znacznie mniej niż pikseli).

Nie będę Cię na siłę przekonywał do raycastingu – po prostu taki mi pomysł wpadł do głowy. ;)

Super . Dzięki. :)

Ps. Gdyby ktoś biegły w piśmie znalazłby chwilę byłaby radość.

Wow trafiasz do teleexpressowej galerii Ludzi Pozytywnie Zakręconych :D naprawdę fajny projekt i fajna robota!

Gratulacje! Jestem pod wrażeniem pomysłu. Zwrócę uwagę, że OpenGL pozwala na przełączenie w tryb szkieletowy (piszę o starym OGL, chyba 2 ileś). Nie wiem, jakie możliwości ma ten komputer i czy są implementacje OGL na DOS-a, ale mógłbyś renderować labirynt w OGL-u, pobierać render z GPU do pamięci, dopasowywać render do wzorca (np. jakimś algorytmem podobnym do algorytmu wykrywania krawędzi; czyli jak mamy linię pod takim kątem, to wyświetlamy taki znak, itd.), a następnie wyświetlać. Takie marzenie.

Szacun :)

https://asciinema.org/

Javid zrobił coś podobnego z podstawowym ray castingiem. Na filmie masz pokazane od zera krok po kroku
Repo https://github.com/OneLoneCoder/CommandLineFPS

Wygląda to fajnie i jest na pewno dużo mądrzejsze od tej mojej metody „na chłopski rozum”. :)

Nie jestem tylko pewien czy przy moim śladowym doświadczeniu (ok. 1,5 roku samokształcenia ) rozwijanie technik wyświetlania jest mi potrzebne w pierwszej kolejności i chociaż pewnie nie zaszkodzi, to podejrzliwie podejrzewam że w porównaniu do innych elementów programu może to być najmniejszy problem.

Chcę się nauczyć solidnych podstaw języka i umiejętności projektowania większej aplikacji.

Załóżmy na chwilę, że powieszę poprzeczkę zbyt wysoko i pomyślę tak:

1. Na mapach miałyby „żyć” w miarę inteligentne obiekty.
   Mogłyby zachowywać się w zależności od swoich potrzeb( tu np. przypomina mi się genialny Dungeon Keeper ( ten pierwszy pod DOS’a ) )
   Pewnie trzeba by było pomyśleć o :

• systemie potrzeb
• systemie poruszania się po mapie
• systemie interakcji z innymi obiektami
• systemie podstawowej komunikacji hero z w/w.
• systemie „uczenia się” obiektów
  etc.

1. Musiałaby być możliwość zapisywania stanu gry/programu. Już teraz widzę że trzeba o tym myśleć teraz i w taki sposób projektować, żeby dało się prosto zapisywać i odtwarzać obiekty do/z pliku.
2. Gdyby miały pojawić się elementy przygodówki/RPG musiałby istnieć jakiś system który kontroluje przebieg rozmów/zadań
3. Być może jakiś system konstruowania przedmiotów z innych przedmiotów.

I tak dalej i tak dalej.

Nie wiem czy używam dobrego słowa ‚system’ ale myślę że takie właśnie „systemy” musiałyby być autonomiczne, wymienne i łatwo kontrolowane.

Czy dobrze myślę że pomogą wzorce projektowe.

P.S.
Zdaje sobie sprawę że poprzeczka jest za wysoko, ale traktuje tę zabawę jako długoterminową, więc oprócz doraźnych potrzebuję takiego dalszego celu.

Ambitnie. Jesli moglbym doradzic to proponowalbym zrobienie dwoch mniejszych projektow wczesniej. Zrobienie Snake'a potem klon Pacmana.

Dlaczego te?
Snake jest dobrym projektem na start, mozna zapoznac sie z programowaniem gier, jezyka, obslugi IDE, prosta logike - zbieranie owocow, smierc przy zjedzenie wlasnego siebie itp.

Pacman jest rozszerzeniem poprzedniego projektu - nie od razu Rzym zbudowano. Tutaj masz np tropienie gracza przez duszki, moglbys tez dodac inne funkcjonalnosci np strzelanie, rzucanie zaklec, inne bonusy.

Dzięki.

Zdecydowanie bardzo chętnie porobię takie mniejsze symultanicznie.
Nawet na pewno porobię.
W żadnym wypadku nie będę się uchylał ani migał.

Snake i jakieś takie inne układanki robiłem zeszłej zimy ( w Borlandzie 3.1 I chyba z BGI )
Teraz chcę pójść mały krok do przodu.

goostaw napisał(a):

Teraz chcę pójść mały krok do przodu.

Z BGI do ASCII to mały krok do tyłu. Może jakaś biblioteka graficzna i graficzne symulowanie konsoli? ;)

Też się bawiłem kiedyś raycastingiem i choć efekt był lichy, bo programista ze mnie żaden (też jestem samoukiem, a z wykształcenia humanistą ;d), to udało mi się coś tam sklecić. Całość była bardzo prymitywnie napisana w Delphi (framerate to była tragedia, mimo rozdzielczości 320x200), a wyświetlanie grafiki oparte było na wbudowanych bibliotekach VCL. Wyglądało to tak:

Teksturki ścian są z Wolfensteina 3D :].

W rzeczywistości jest to dużo prostsze, niż się wydaje (gdyby było inaczej, to bym tego nie napisał ;p). Polecam skorzystanie z tego:

https://permadi.com/1996/05/ray-casting-tutorial-table-of-contents/
https://lodev.org/cgtutor/raycasting.html#Introduction

Doskonale opisane i wyłożone krok po kroku, ze wskazaniem co, jak i dlaczego działa, nie tylko suchy kod.