Jump to content

Statki - bug?


1miko1
 Share

Recommended Posts

Ponieważ nie jestem w 100% pewien czy jest to bug, umieszczam temat w dziale pytania.

 

Mianowicie chodzi mi o to, że, przynajmniej na oficjalnym ogame, jeżeli np. 100 LM walczy ze 100 CM, to mimo że w oczywisty sposób CM mają przewagę, to możliwy jest nawet remis w którym LM mają przewagę, ponieważ na ogame występuje element losowości, tzn wszystkie CM mogą strzelić w tego samego LM, więc tylko 1 LM ulegnie zniszczeniu. Tutaj z tego co mi wiadomo ten element losowości nie występuje.

 

To co napisałem w poprzednim akapicie nie jest aż tak ważne jak, to o czym powiem teraz. Jeżeli zrobimy symulacje walki 1.000.000.000 auror z 1.000.000.000 CM, aurory oczywiście wygrają. I jak już wcześniej powiedziałem, ponieważ nie ma tu elementu losowości wszystkie CM zostaną zniszczone w pierwszej rundzie. I jak również wspomniałem nie jest to aż tak ważne, ALE aurory nie mają szybkich dział przeciwko CM. Znaczy to mniej więcej tyle, że w jednej rundzie jedna aurora może zniszczyć tylko jednego CM!

 

Jednak, mimo to jeżeli zrobimy symulację walki 17.500.000.000 CM i 1.000.000.000 auror, wszystkie CM nadal giną w pierwszej rundzie! Przy aż tak ogromnych wielkościach, oznacza to, że aurory mimo, że powinny zniszczyć tylko 1.000.000.000 CM, w magiczny sposób otrzymały szybkie działa i każda zniszczyła ich po 17.5. Innymi słowy prawdopodobnie system walk jest na ogam inaczej napisany niż na ogame, jednak nie jestem pewien czy jest to efekt zamierzony, czy może błąd.

Link to comment
Share on other sites

Odp. jest prosta - pociski przebijające ;)

 

A tak poważnie to właśnie robię sys. walk i skoro już o tym wspomniałeś to skieruję tu też właśnie to pytanie, czy koniecznie musi być te pochrzanione ograniczenie dla dużych statków? (bo małe i tak dużego nie zniszczą:P )

 

Bez tego ograniczenia obliczenia są proste jest ich niewiele, a dokładniej wszystkie statki strzelają do każdego statku przeciwnika po kolei, jesli mam dodać to ograniczenie to każdy statek będzie strzelał do każdego statku, a więc ilość obliczeń rośnie ok. 20x + do tego jeszcze dochodzi 6 tabelek zamiast 2. (w Excelu - w PHP pewnie zajmie to mniej)

 

Robię to ograniczenie i mi mózg wysiada, a jak deus będzie miał to przepisać to zajmie mu to wieczność, chyba że wykorzysta jedynie zasadę działania i zrobi sys. walk na swój sposób.

 

 

Dla przykładu ilość pozostałych LMów po ataku LM'ami wylicza się wzorem:

=JEŻELI(JEŻELI($K29-$J$15

 

Następnie oblicza się siłę jaką zużyto na ten atak, żeby było wiadomo ile jeszcze ataku można przeprowadzić na pozostałe statki przeciwnika:

=JEŻELI(K29-((H15-B39)*$L$2+($K$2*(H15)))

 

I tak 400x <_>

 

 

 

PS: Wymyśliłem już drobne rozwiązanie tego dużego problemu ale najwcześniej wieczorem sprawdzę czy będzie działać.

Link to comment
Share on other sites

Ponieważ nie jestem w 100% pewien czy jest to bug, umieszczam temat w dziale pytania.

 

Mianowicie chodzi mi o to, że, przynajmniej na oficjalnym ogame, jeżeli np. 100 LM walczy ze 100 CM, to mimo że w oczywisty sposób CM mają przewagę, to możliwy jest nawet remis w którym LM mają przewagę, ponieważ na ogame występuje element losowości, tzn wszystkie CM mogą strzelić w tego samego LM, więc tylko 1 LM ulegnie zniszczeniu. Tutaj z tego co mi wiadomo ten element losowości nie występuje.

 

To co napisałem w poprzednim akapicie nie jest aż tak ważne jak, to o czym powiem teraz. Jeżeli zrobimy symulacje walki 1.000.000.000 auror z 1.000.000.000 CM, aurory oczywiście wygrają. I jak już wcześniej powiedziałem, ponieważ nie ma tu elementu losowości wszystkie CM zostaną zniszczone w pierwszej rundzie. I jak również wspomniałem nie jest to aż tak ważne, ALE aurory nie mają szybkich dział przeciwko CM. Znaczy to mniej więcej tyle, że w jednej rundzie jedna aurora może zniszczyć tylko jednego CM!

 

Jednak, mimo to jeżeli zrobimy symulację walki 17.500.000.000 CM i 1.000.000.000 auror, wszystkie CM nadal giną w pierwszej rundzie! Przy aż tak ogromnych wielkościach, oznacza to, że aurory mimo, że powinny zniszczyć tylko 1.000.000.000 CM, w magiczny sposób otrzymały szybkie działa i każda zniszczyła ich po 17.5. Innymi słowy prawdopodobnie system walk jest na ogam inaczej napisany niż na ogame, jednak nie jestem pewien czy jest to efekt zamierzony, czy może błąd.

 

Tylko w gś i aurorach ten problem występuje. Blisko nie określony jest błąd. Nawał pracy, silnik walk nie jest może idealny, ale dla takich dużych sum statków ten z ogame nie może być.

Link to comment
Share on other sites

Właśnie to o czym piszecie, czyli ograniczenie ilości niszczonych statków jest bardzo potrzebne i chyba wykonalne ?

 

Z Nerielem myślimy nad systemem (teraz raczej on myśli ja mam sesje :P) no i wyszło te kilka problemów przy systemie , czy ma rozkładać atak po

a)wartości* ilość

b) ilości statków (ja jestem za tym )

 

Potem problemem jest to jeżeli Gś/Aurora/aż do KR/ wali w LM'y - tak naprawdę tutaj musi być jakiś test jeżeli, np:

jeżeli wartość(dla pojedyńczego statku) Atak>struktura+tarcza to wtedy

jeżeli sumujemy siłę ataku to dostajemy za dużo.

 

Fix -> 2 pętle 1) dla atak

atak=atak*szansa*sd*ilość

2) atak >= hp statku przeciwnika

atak=hp statku*szansa*sd*ilość

 

To akurat byłoby proste do zrobienia, tworząc np. dodatkowe 2 tablice na początku - dla każdego typu statku uwzględniając technologie - sprawdzić czy atak>hp danego typu statku jak tak to 1 jak nie to 0 .

 

Speed sim losował po kolei, ale przy dużych liczbach to się nie uda, więc zostaje prawdopodobieństwo jako np. 20000ow/20000000 statków w sumie (agresora np.). = 0.02 .. przy ataku gś z 30sd = 30*0.02*ilość gś*atak gś

(lub raczej w tym wypadku atak>struktura+tarcza ,więc

Ow spadnie 30*0.02*ilość gś)

 

 

Przy takim systemie jedynym problemem będzie zaniżanie ataku przy małych wartościach ~0 ,ale nie powinno to mieć dużego wpływu na walkę (1%?).

 

Pytanie ode mnie : co jest lepsze dla PHP(czy czegośtam w czym to działa) - więcej odejmowań i nowa tablica dla strzałów np. czy dzielenie/mnożenie dużych liczb ?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.