Przepraszam, że się tak wtrącam, ale co byście chcieli dodać, czego jeszcze nie ma?
Liczba przeciwników pozostałych przy życiu, siła ostatniego ciosu przeciwnika, siła najmocniejszego ciosu przeciwnika, sprawdzenie, czy w ostatnim ruchu przeciwnik nie zadał na double'a, ... Możliwości jest wiele W każdym razie nie chodzi o rozbudowanie możliwych akcji, a o rozbudowanie możliwych warunków.
Ku_Zi napisał/a:
Poza tym gracze musieliby opanować składnię takiego języka, co dla niektórych byłoby ciężkie. Nawet najprostszy język może być dla kogoś trudny (biorąc pod uwagę to, że teraz niektórzy nie mogą sobie poradzić z wybieraniem poleceń...)
Nic nie stoi na przeszkodzie, żeby dać graczom wybór - albo obecny sposób, albo okienko, w którym każdy mógłby bezpośrednio edytować skrypt...
No to tutaj walnąłeś byka. Złożoność obliczeniowa jest związana z tym jak się zmienia ilość wykonanych instrukcji w zależności od ilości danych wejściowych. Nie ma to nic wspólnego z ilością wykonanych operacji (a przynajmniej nie strikte bezpośrednio). Dlatego w prawdziwe jest wyrażenie.
O(n) + 1000 = O(n)
To, o czym piszesz, to asymptotyczne oszacowanie złożoności obliczeniowej. Złożoność obliczeniowa to ilość zasobów potrzebnych do wykonania programu, czyli dokładnie to, o czym obaj piszemy.
Czyli używaliśmy jednej nazwy do dwóch różnych rzeczy Wiedziałem że o to się robije cała dyskusja.
Pitazboras napisał/a:
crk napisał/a:
Jasne że nie jest potrzebna. Mówiłem o bardziej ogólnym przypadku.
A ja pisałem o przypadku, który jest omawiany w tym temacie, czyli inteligencja gracza. Nie widzę sensu rozważania ogólniejszych przypadków, przynajmniej tutaj.
I dlatego zacząłeś pisać o czasie wykonania poszczególnych instrukcji
Pitazboras napisał/a:
crk napisał/a:
Meriutum moich wypowiedzi jest takie że więcej instrukcji wydłuży działanie kodu (jeżeli tak nie jest to znaczy że dodany kod jest zbędny, bo nie jest wykonywany) a nie to czy jedne wykonują się dłużej a inne krócej.
1. Więcej instrukcji nie musi wydłużyć działania kodu, po prostu niektóre nie będą wykonywane przy danym obrocie pętli...
2. ... ale będą wykonywane przy następnym, więc dodany kod wcale nie jest zbędny.
Prosty przykład, bo chyba cały czas nie rozumiesz...
Kod:
for i = 1 to 100 do
if i < 50 then
blok instrukcji 1
else
blok instrukcji 2
Kod:
for i = 1 to 100 do
if i < 50 then
blok instrukcji 1
else if i < 75 then
blok instrukcji 2
else
blok instrukcji 3
Kod 2. jest dłuższy, natomiast jeśli bloki 2 i 3 są tak samo "skomplikowane" (cokolwiek by to miało oznaczać), to program będzie działał tak samo długo (ok, będzie jedno porównanie "if i < 75" więcej, ale jest to nakład marginalny), mimo że żaden fragment kodu w drugim przykładzie nie jest nadmiarowy.
Wszystko fajnie tylko że ty zakładasz że pętla wykona się w obu przypadkach 100 razy, a w naszym przypadku tak nie będzie, bo pojawią się IF'y w skrypcie (tak jak mówiłem zakładam że jeżeli jest możliwość ich użycia to będę używane przez graczy).
Pitazboras napisał/a:
crk napisał/a:
To faktycznie albo ktoś się uleczy, albo zaatakuje, ale zanim do tego dojdzie musi przejść przez nową funkcjonalność.
Ale przecież tej nowej funkcjonalności nie wykonuje. Przyznam, że nie wiem, w jaki sposób PHP przechodzi do else z niespełnionego ifa (wspomniana przez Ciebie Java radzi sobie z tym doskonale, instrukcjami skoku, jak w C czy assemblerze), ale nawet jeśli czyta cały kod wewnątrz bloku if, to samo czytanie kodu, bez wykonywania go, nie powinno zwiększyć nakładu czasowego. Zwłaszcza, że problem można bardzo prosto rozwiązać, tworząc odwołania do funkcji.
[/quote]
Jak nie jak tak. Program przeszukuje skrypt i co widzi na wstępie? instrukcję IF, więc musi ją jakoś zinterpretować, co to jest i jakie powinny zostać podjęte akcje, a to już jest zadanie nowego kodu.
Pitazboras napisał/a:
Ku_Zi napisał/a:
Przepraszam, że się tak wtrącam, ale co byście chcieli dodać, czego jeszcze nie ma?
Liczba przeciwników pozostałych przy życiu, siła ostatniego ciosu przeciwnika, siła najmocniejszego ciosu przeciwnika, sprawdzenie, czy w ostatnim ruchu przeciwnik nie zadał na double'a, ... Możliwości jest wiele W każdym razie nie chodzi o rozbudowanie możliwych akcji, a o rozbudowanie możliwych warunków.
Ku_Zi napisał/a:
Poza tym gracze musieliby opanować składnię takiego języka, co dla niektórych byłoby ciężkie. Nawet najprostszy język może być dla kogoś trudny (biorąc pod uwagę to, że teraz niektórzy nie mogą sobie poradzić z wybieraniem poleceń...)
Nic nie stoi na przeszkodzie, żeby dać graczom wybór - albo obecny sposób, albo okienko, w którym każdy mógłby bezpośrednio edytować skrypt...
Wszystko fajnie tylko że ty zakładasz że pętla wykona się w obu przypadkach 100 razy, a w naszym przypadku tak nie będzie, bo pojawią się IF'y w skrypcie (tak jak mówiłem zakładam że jeżeli jest możliwość ich użycia to będę używane przez graczy).
Ify to nie pętle Owszem, dodatkowe warunki mogą zmienić (zwiększyć, ale też zmniejszyć) liczbę wykonań pętli (czyli liczbę rund w walce), ale wątpię, żeby to były duże zmiany (o wiele większe są np. przy dodaniu nowego eq), poza tym walki mają ograniczoną liczbę tur.
crk napisał/a:
Program przeszukuje skrypt i co widzi na wstępie? instrukcję IF, więc musi ją jakoś zinterpretować, co to jest i jakie powinny zostać podjęte akcje, a to już jest zadanie nowego kodu.
Program natrafiając na ifa i stwierdzając, że jego warunek jest niespełniony, pomija cały blok zawarty w jego wnętrzu. Nie musi interpretować, jakie zostałyby podjęte akcje, gdyby if był spełniony. W każdym obrocie pętli tylko jeden if jest spełniony (bo gracz wykonuje tylko jedną akcję w ciągu tury), więc niezależnie od propozycji, nad którą teraz dyskutujemy, interpreter zagłębi się w tylko jednego ifa, resztę pominie, sprawdzając co najwyżej warunki wejścia. Na pewno jednak nie będzie interpretował zawartości bloku dla każdego ifa.
Level: 194
Wiek: 33 Dołączył: 18 Maj 2007 Skąd: Częstochowa
Wysłany: 23-12-2008, 16:09
Pitazboras napisał/a:
Liczba przeciwników pozostałych przy życiu, siła ostatniego ciosu przeciwnika, siła najmocniejszego ciosu przeciwnika, sprawdzenie, czy w ostatnim ruchu przeciwnik nie zadał na double'a
No fakt, przydałyby się takie warunki, musiałem źle zrozumieć poprzednie posty.
crk napisał/a:
Program przeszukuje skrypt i co widzi na wstępie? instrukcję IF, więc musi ją jakoś zinterpretować, co to jest i jakie powinny zostać podjęte akcje, a to już jest zadanie nowego kodu.
Tyle, że to co mamy teraz _też_ musi interpretować i jakoś nie wychodzi mu to strasznie wolno. Dodanie obsługi kilku nowych wyrażeń raczej też by go nie spowolniło. Mamy trzy światy, każdy na osobnym serwerze (ś1 chyba na dwóch), na każdym świecie rzadko kiedy jest ponad 600 graczy, z czego nie każdy w danym momencie walczy. Sugerujesz, że serwery by sobie z tym nie poradziły?
Nie rozumiem tylko jednego - po co nam język skryptowy, skoro to co jest teraz jest imho wygodniejsze od pisania kodu, w którym można przypadkowo strzelić literówkę lub napisać coś, co wykrzaczy cały interpreter.
Nie rozumiem tylko jednego - po co nam język skryptowy, skoro to co jest teraz jest imho wygodniejsze od pisania kodu, w którym można przypadkowo strzelić literówkę lub napisać coś, co wykrzaczy cały interpreter.
Wszystko fajnie tylko że ty zakładasz że pętla wykona się w obu przypadkach 100 razy, a w naszym przypadku tak nie będzie, bo pojawią się IF'y w skrypcie (tak jak mówiłem zakładam że jeżeli jest możliwość ich użycia to będę używane przez graczy).
Ify to nie pętle Owszem, dodatkowe warunki mogą zmienić (zwiększyć, ale też zmniejszyć) liczbę wykonań pętli (czyli liczbę rund w walce), ale wątpię, żeby to były duże zmiany (o wiele większe są np. przy dodaniu nowego eq), poza tym walki mają ograniczoną liczbę tur.
Innymi słowy wszystko sprowadza się do przeprowadzenia testów, ale ja dalej obstaję przy swoim Sądzę że to admini musieli by się wypowiedzieć.
Pitazboras napisał/a:
crk napisał/a:
Program przeszukuje skrypt i co widzi na wstępie? instrukcję IF, więc musi ją jakoś zinterpretować, co to jest i jakie powinny zostać podjęte akcje, a to już jest zadanie nowego kodu.
Program natrafiając na ifa i stwierdzając, że jego warunek jest niespełniony, pomija cały blok zawarty w jego wnętrzu. Nie musi interpretować, jakie zostałyby podjęte akcje, gdyby if był spełniony. W każdym obrocie pętli tylko jeden if jest spełniony (bo gracz wykonuje tylko jedną akcję w ciągu tury), więc niezależnie od propozycji, nad którą teraz dyskutujemy, interpreter zagłębi się w tylko jednego ifa, resztę pominie, sprawdzając co najwyżej warunki wejścia. Na pewno jednak nie będzie interpretował zawartości bloku dla każdego ifa.
Ale ja nie napisałem nic o zaglądaniu to wnętrza warunku tylko o zinterpretowaniu samej instrukcji jaką jest IF, a to już jest dodatkowa akcja, a w kodzie który wykonywany jest przez 80% czasu gry jest to dosyć istotne.
Ku_Zi napisał/a:
Sugerujesz, że serwery by sobie z tym nie poradziły?
Ku_Zi napisał/a:
(ś1 chyba na dwóch)
Jeżel to prawda to tym samym sam sobie odpowiedziałeś na swoje pytanie Czemu najstarszy świat jest na dwóch serwerach, a nie na jednym? No chyba że pomiędzy światami jest jakaś różnica w kodzie gry, a ja o tym nie wiem.
Ku_Zi napisał/a:
Nie rozumiem tylko jednego - po co nam język skryptowy, skoro to co jest teraz jest imho wygodniejsze od pisania kodu, w którym można przypadkowo strzelić literówkę lub napisać coś, co wykrzaczy cały interpreter.
Sorry ale jeżeli interpreter się wywala na pierwszym lepszym błędzie to trochę kiepski ten interpreter, zwłaszcza że nie mówimy tu o drugim interpreterze Javy. No chyba że masz na myśli złoszenie błędu składni przez interpreter. W takim razie sprawdzenie kodu przed jego zapisaniem rozwiązało by problem, jak sądzę
Po co nam taki język? Jeżeli możnaby było go w całości 'wyklikać' to żeby móc spojrzeć z góry na tych co nie umią Po prostu narzędzia z którymi miałem przyjemność obcować, w przypadku klikania były dosyć ograniczone w stosunku do wersji pisanej, stąd rzuciłem takim hasłem.
Sugerujesz, że serwery by sobie z tym nie poradziły?
Ku_Zi napisał/a:
(ś1 chyba na dwóch)
Jeżel to prawda to tym samym sam sobie odpowiedziałeś na swoje pytanie Czemu najstarszy świat jest na dwóch serwerach, a nie na jednym? No chyba że pomiędzy światami jest jakaś różnica w kodzie gry, a ja o tym nie wiem.
Każdy świat to jeden osobny serwer plus dodatkowy serwer z grafikami dla wszystkich światów.
_________________ Dopóki nie skorzystałem z Internetu, nie wiedziałem, że na świecie jest tylu idiotów. S. Lem
Level: 194
Wiek: 33 Dołączył: 18 Maj 2007 Skąd: Częstochowa
Wysłany: 23-12-2008, 21:37
crk napisał/a:
Sorry ale jeżeli interpreter się wywala na pierwszym lepszym błędzie to trochę kiepski ten interpreter, zwłaszcza że nie mówimy tu o drugim interpreterze Javy. No chyba że masz na myśli złoszenie błędu składni przez interpreter. W takim razie sprawdzenie kodu przed jego zapisaniem rozwiązało by problem, jak sądzę
Chyba nie doceniasz społeczności MFO ;p Któremuś z graczy na pewno prędzej czy później udałoby się spowodować crasha. Poza tym nie chodziło mi tak bardzo o crashe a o zbędność języka. Naprawdę nie widzę w czym taki język mógłby być lepszy od tego co jest teraz. Wystarczy dodać więcej warunków do listy i zwiększyć ilość możliwych poleceń (no, może dodałbym jeszcze jedno - zmienianie warunków na bieżąco, bez potrzeby ich usuwania i tworzenia od nowa). Mów co chcesz, ale to jest przede wszystkim wygodniejsze od klepania. To nie terminal Linuksa, gdzie wpiszesz paręnaście literek i system zrobi wszystko w czasie dużo krótszym niż byś to wyklikał
Ale ja nie napisałem nic o zaglądaniu to wnętrza warunku tylko o zinterpretowaniu samej instrukcji jaką jest IF, a to już jest dodatkowa akcja, a w kodzie który wykonywany jest przez 80% czasu gry jest to dosyć istotne.
Ta, tylko że wykonanie jednego, dwóch czy nawet 10 ifów więcej w trakcie obrotu pętli spowalnia w niemal takim samym stopniu wykonywanie programu, co pisanie "i++" zamiast "++i" ;> Innymi słowy tym na prawdę bym się nie przejmował, bo dodatkowy nakład czasowy jest w takim wypadku śmiesznie mały, nawet przy kilku tysiącach wykonań na sekundę.
Ku_Zi napisał/a:
Mów co chcesz, ale to jest przede wszystkim wygodniejsze od klepania.
Eee, to zależy... Dla mnie wygodniej byłoby wpisać na przykład "HP > 50%" niż klikać 6 razy (czy ile tam) myszką w różne menu rozwijane
Ku_Zi napisał/a:
To nie terminal Linuksa, gdzie wpiszesz paręnaście literek i system zrobi wszystko w czasie dużo krótszym niż byś to wyklikał
Właśnie nieświadomie podsunąłeś mi kolejną zaletę języku skryptowego - łatwo można by było zapisać sobie całą inteligencję na dysku. Po co? Jeśli testujesz różne inteligencje, to prawdopodobnie będziesz chciał kiedyś wrócić do poprzedniej. Tylko jak ją odtworzyć?
@wykrzaczanie
każde nieznane słowo byłoby traktowane jako komentarz chyba że przy deklaracji zmiennej uczyłby się słowa
błąd wykonania (w sposobie działania, nie w zapisie), skutkowałby wybraniem domyślnej akcji
@czas wykonania
można by wprowadzić ograniczenie że jeśli czyjś skrypt podejmie się zdecydowanie zbyt czasochłonnej pracy (np. takie 100ms na decyzję) to wyskakiwałby w logu warning "kod jest zbyt skomplikowany" i wykonałby domyślną akcję
@skrypt vs interfejs
skrypt jest bardziej "giętki". jak wyobrażasz sobie zagnieżdżanie warunków w interfejsie list
poza tym przydałby się system wyboru przeciwnika do ataku, wyważenia podjętego kroku zależnie czy np. wybrany do ataku ma 1nnnn hp czy 1nn hp mag mógłby użyć runy lub zwykłego ataku aby dobić (wszystko w walkach z więcej niż 1 przeciwnikiem)
poza tym można byłoby wybrać skryptem taki atak jaki najbardziej pasuje do danego gracza np. do gracza z ogień +50 i lód 0 (albo -25) użyć gemu lodu a nie gemu ognia
++ proponuje możliwość wyboru atakowanego w walce manualnej
Koleś mi jakoś inta daje radę.Pomyśl popytaj o dobra intę i twój problem z głowy.Wiem że to propozycja ale na co komu ona skoro wystarczy dobre ustwienie tej co masz i tyle
Jakby w ogóle nie było inteligencji też jakoś byśmy "dawali radę"... Ale przecież chodzi o to, żeby walki były jak najbardziej urozmaicone, a gra powinna stwarzać pole do stosowania jak największej liczby strategii.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach
Regulamin Forum
W każdym razie nie chodzi o rozbudowanie możliwych akcji, a o rozbudowanie możliwych warunków.
Po prostu narzędzia z którymi miałem przyjemność obcować, w przypadku klikania były dosyć ograniczone w stosunku do wersji pisanej, stąd rzuciłem takim hasłem.
