🚀 go-pugleaf

> najwazniejsze, to zeby mierzyc swoje sily na zamiary... nie zabieraj sie
za
> pisanie dooma 4 jesli nigdy nie pisales pacmana...

Link, który Wam podałem jest właśnie do "pacmana".

> jesli juz to zmierzysz dobrze i stwierdzisz, ze mozes sie zabrac za
pisanie
> gry... to zastanow sie jak mozesz to napisac... czy strukturalnie czy
> obiektowo...

Obiektowo. Użyłem słowa "struktura" w sensie budowy aplikacji a nie sposobu
programowania. Wychowałem się na C++ lecz nigdy nie  pisałem prostych gier.
Specjalizowałem się w systemach czasu rzeczywistego i oprogramowywaniu
urządzeń telekomunikacyjnych oraz aplikacji dla Windows.

> potem wez sie za projekt, to najwazniejsza (i najtrudniejsza) czesc
procesu
> programowania (programowanie != kodowanie... trzeba o tym pamietac)...
> zajmuje zwykle spora czesc calego procesu (w kazdym razie powinna)...
> popelnione bledy na tym etapie beda Cie kosztowaly mase pracy przy
> poprawianiu, jesli dojdziesz juz do kodowania...

Tyle to ja wiem. Pytałem już o konkrety.

> no a pozniej juz kodowanie... czyli przeniesienie w sposob naturalny
Twojego
> projektu na jezyk (w naszym przypadku AS)...
>
> proste prawda? :)

He, he - wcale nie :) Tu zaczyna się dopiero mój problem. Nie wiem bowiem
jak najwygodniej jest sterować dużą ilością obiektów na scenie. Np. pauza:
proste a za razem trudne wyzwanie. Przypuszczam, że musiałbym założyć jakiś
obiekt, w którym każdy graficzny obiekt mógłby zapamiętać swój stan. Do tego
musiałbym stworzyć jakiś model zdarzeń i np. puścić broadcasta "wszystko
stop". Ja to potrafię zrobić lecz potem może sie okazać, ża AS jest tak
wolny, że musiałbym używać nowego komputera  TASKu, żeby zagrać w Tetrisa.

> a jak projektowac???? to temat rzeka ;) na kursie flash mx 2004 na
> flashroom.com staramy sie pokazac jak projektowac "male" fragmenty
> programow, czyli klasy... zajrzyj tam i sprobuj sie przylaczyc, ale
> ostrzegam, to co bylo omawiane na kursie flasha mx musisz miec w malym
> paluszku ;)

Zerknę sobie na to z pewnością. Nie wiem czemu temat jest "rzeką" bo wydaje
mi się, że jeśli zdecydujemy się na jakiś model to potem możemy stosować go
w każdym typie gry. Czyż nie jest tak ? Problem w tym, że taki model
narzucony jest funkcjonalnością języka. Np. aby wykonać hitTest() danego
obiektu to muszę co klatkę w pętli sprawdzać czy nie koliduje on z innymi i
robić to dla każdego z nich (!!!)zamiast zlecić to "enginowi". Mając to na
uwadze boję się, że zginę tak postępując. Niemniej jednak to narzuca mi
model aplikacji propagujący zdarzenia "w górę". Czyli MC przesyła zdarzenie
"zderzyłem się" do nadrzędnego MC itd. Taka struktura programu jest właśnie
przykładową odpowiedzią na moje pytanie. Ja nie chciałem sugerować
odpowiedzi i dlatego zadałem pytanie ogólnie.

-- 
Pozdrawiam,
Marek Szopiński
(z adresu email usuń "spam.")