Autor Wątek: Podejście Entity component system (ECS) w celu unikniecia BLOBa  (Przeczytany 3967 razy)

Offline Adam B

  • Użytkownik

# Sierpień 12, 2015, 21:14:36
Cytuj
ad 1) zależy to od implementacji, prawdopodobnie szukanie drogi nie działa dla mobilnych jednostek - dla nich są tylko proste obliczenia niewchodzenia na siebie i poruszania się w grupie.

 - Zgadza się ale pytalem o potencjalna przyczynę.


Cytuj
ad 2) fuzzy-logic ku pomocy :) załóż, że jeśli mob jest w odległości X jednostek od celu i np. jest w otoczeniu kilku innych z własnej grupy, to uznaje, że dotarł na miejsce i nie próbuje osiągnąć punktowo x.y.z. celu

 - tyle to wiem - liczyłem na jakies opracowanie tematu lub link, w kórym jest wyjasnione teoretycznie jak takie rzeczy się robi - sam mialem problem zeby wyszukac.. a pewnie są takie materiały w sieci

Cytuj
ad 3) jak odp. wyżej - zależy od tego czy akceptowalny jest efekt przenikania się graficznych reprezentacji mobów.

 - bardziej chodziło mi o to czy taki algorytm jest w ogóle potrzebny, czy sam mechanizm pathfindingu powinien być na tyle dobry, żeby zapobiegać takiej sytuacji - jak to jest w praktyce ? Bo ja to widzę tak - jeżeli pathfinding jest niewystarczający to w łatwy sposób odpychanie się jednostek może zrekompensować tę niesodkonałość algorytmu wyszukiwania drogi.. szczególnie ważne gdy np. przez wąskie przejście ma się przedostać 200 jednostek. Albo po 1-- jednostek.. ale jedne idą z lewej strony, a drugie z prawej :)

Cytuj
ad 4) musisz stosować tutaj algorytmy poszukiwania drogi dla formacji - wtedy drogi nie szuka każda z jednostek oddzielnie tylko arbitralnie założony "środek ciężkości" grupy, a reszta podąża za nim, zachowując formację.

 - to zaobserwowałem, ze logika poruszania się często dotyczy grupy jednostek i środka ciężkości tej grupy. Bardziej chodziło mi o to, ze układamy jednostki w kowadło.. i gdy te kowadło nie jest zbyt duże to i tak powinno się dać z niego wyjść.. samo omijanie jednostek stojących w miejscu na zasadzie idź tą drogą (wektorem), której kąt pomiędzy wektorem do celu ma mniejszy kąt nie wystarczy..


Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Adam B

  • Użytkownik

# Sierpień 13, 2015, 01:18:55
Popracowalem trochę i można zobaczyć na stronce efekt.
Chwilkę trzeba poczekać aż wszyscy przeciwnicy pojawią się na mapie.

Efekt wymaga jeszcze poprawek/optymalizacji/dopieszczenia ale na teraz jest na tyle zadowalający, że mogę zająć się kolejnymi aspektami gierki.

Pozdrawiam i dzięki wszystkim za odpowiedzi.

Offline Adam B

  • Użytkownik

# Wrzesień 09, 2015, 19:30:48
Zastanawiam sie jak zrobic wydajnie kontrolke minimapy, ktora jest osobna kontrolka i nie jest mocno powiazana z projektem (zeby byla przenosna).


Doszedlem do podejscia wstrzykniacia do MinimapView obiektu o interfajsie jakiego potrzebuje minimapa. Konkretnie chodzi o to ze MinimapView wspolpracuje z interfejsem IMinimapElement lub IMinimapList.
Jest to interface, ktory okresla metody getX(), getY(), getColor() i getRadius().
Podstawowe Entity w grze implementuje ten interfejs aby moglo byc wyswietlony na widoku minimapy.

I teraz w sumie dochodze do wniosku ze wszystkie wlasciwosci widoku mozna przekazywac przez tak zdefiniowany interfejs np. viewport, ktory tez wyswietlamy na minimapie.

Dzieki temu w ogole nie bede musial updatowac danych w Widokach - beda one jedynie przerysowywac model, z ktorym sa powiazane dzieki interfejsowi, ktory definiuje widok.

Z drugiej strony nie zawsze model gry moze dostarczyc idealnych danych dla kontrolek np. widok moze miec width i heigth np. okreslone jako FILL_PARENT i wtedy juz musi być przeliczony layout wedle wewnetrznej logiki GUI.

Wychodzi mi na to ze:
 - wszystko co jest wewnetrz widoku moze byc przekazane przez interfejs jak pisalem, (np. elementy wewnetrz minimapy)
 - same dane opisujace kontrolek w drzewie widokow powinno byc okreslane jako wartosci i poddane do obliczen przez "silnik" GUI. Takie dane to glownie dane layoutu np. align, relacyjne ulozenie elementow pomiedzy soba itp.

Dobrze mysle ?