🚀 go-pugleaf

Googie napisał(a):
> Wojciech Kocjan wrote:
> 
> 
>>No dokładnie też nie wiem - wolę pomyśleć dłużej niż potem pisać, że
>>jest "odrobinę procesożerne" :-).
> Z projektowaniem jest taki problem, że dopóki jest to sfera teorii, to
> wszystko wydaje się "do zrobienia"i oczywiste, ale gdy przychodzi
> praktyka, to jednak wiele faktów wypływa na wierzch i okazuje się że
> "tak się nie da", lub "nie jest to zbyt udane rozwiązanie". Tak było
> właśnie w moim przypadku. Choć oczywiście nie jest to reguła.

Wiem. Dlatego przy większych projektach dawniej siedziałem miesiąc nad 
bawieniem sie wszystkimi detalami i próbowaniem robienia z nimi tego co 
chciałem. Pomagało tego unikać.

>>Ja myślę albo o zdarzeniowości - bo 
>>na logikę to albo w momencie jak np dojdzie do celu albo jak coś się
>>wydarzy to zmieni plan działania.
> No u mnie w gruncie rzeczy jest to zdarzeniowość - w końco
> zaimplementowałem własną pętlę zdarzeń i dla każdego cyklu tej pętli
> każdy z obiektów na mapie wykonuje swój cykl (ruch, obrót,
> strzał, ...). Procesorożerność wynika raczej ze stosunkowo
> zaawansowanej (jak na Tcl) grafiki i krótkich odstępów pomiędzy
> cyklami pętli zdarzeń (boda 50ms), a gdy np jeden z botów zaczyna
> naparzać z MachineGuna (gdzie każdy pocisk to obiekt ITcl) to nagle na
> mapie liczba obietków rośnie z (np.) 3 do 15 :) Dochodzi sprawdzanie
> kolizji dla każdego z nich, itd, itd...

Ja właśnie wolałbym uniknąć Itcl do tego. Zostałbym przy zmiennej np
::objects::spaceship1234 i w niej pamiętać wszystko. A jakieś pseudoapi 
byłoby na zasadzie

interp alias ... spaceship1234 \
     {} ::objects::handle_spaceship ::objects::spaceship1234

Jeszcze nie wiem, dlatego się bawię w testy.

> Nie wiem jak sobie poradzisz z setkami, a nawet tysiącami obiektów (jak
> to pisałeś na początku). Chyba że to ma być gra ASCII-Art?

Planowałem na wyrost, żeby potem nie klnąć na design kilku rzeczy. Sam 
jeszcze nie wiem.

> Jak Ty chciałbyś takie problemy ominąć? Chyba że nie planujesz
> "Real-Time Figting" (to takie wymyślone określenie, tu i teraz) ?

Ja myślałem o strategii, dostosowanej do realiów siedzenia w firmie. Nie 
wiem co z trzymaniem mapy - bo do jej renderowania pewnie musiałbym na 
canvas wrzucić ok 30000 obiektów. Sadze, ze skonczy sie na wygenerowaniu 
na sztywno mapy do obrazka - wtedy pamiętanie tego zajmie 30MB, ale 
będzie śmigało. Można też to potem pociąć (np na kawałki 200x200). 
Zobaczymy.

>>Może jakaś prostsza maszyna stanów 
>>ze zdarzeniami i implementacjami stanów - wtedy sam edytor stanów
>>mógłby być graficzny i wypasiony nawet ;-)
> A tego już nie kumam ;)

Klikacz kodu :D

>>Skoro już robisz jakieś gry to może połączymy jakoś siły? :-)
> Zawsze jestem chętny. Ostatnio niestety jednak cierpię na brak czasu.
> Kiedy nieco się rozluźni, to dam znać, o ile będziesz nadal
> zainteresowany współpracą.

> Się tak nie uśmiechaj :) Znasz jakiś? Podziel się :)

Właśnie się koduje w C. Nie szuka optymalnej, ale w miare dobrą i robi 
to szybko. Tylko jest minus - to trwa ok 1 sekundy na planszy 200x100 
(0,0 do 199,99). Aha i nie przewiduje, ze planety sa okragle i mozna 
przesmigac z prawej strony do lewej - ale i do tego dojdę.

-- 
WK