Eve-Centrala
Eve Online => Dyskusje ogólne => Wątek zaczęty przez: MightyBaz w Maj 08, 2007, 10:23:39
-
otworzylem nowy temat na eve online
jak macie jakies pomysly to moze warto cos przekazac CCP...
http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=517301
-
Narzekanie nic nie da, CCP wie ze jest zle.
Luzne pomysly tez pewnie niewiele dadza, bo CCP zapewne ma juz 3 miliony luznych pomyslow, a potrzebuje konkretnych koncepcji od ludzi ktorzy dokladnie znaja kod i swoje pomysly moga rozpisac na projekt. Jesli chcesz uratowac CCP przed lagami w bitwach, idz do nich pracowac i to zrób :)
/me re-uczy sie C++ :)
-
ten ktory zaproponowalem ad1 jest raczej banalny i napewno mozliwy do implementacji od zaraz
-
buzz moze juz powinienes tam cos odpisac altem bo maly ruch cos jest w topicu;]
-
moze i jest banalny ale w jaki sposob niby pomaga na lagi?
Przeciez efekty, i dzwieki nie przesyla ci z servera tylko generuje na kliencie przy strzale czy dmg ( a sadzac po tym jakie bugi sie przy tym robia to nie ma to zupelnie nic wspolnego z serverem )
Wiec z odciazaniem servera nie ma nic wspolnego.
A drugie jest po prostu glupie i niewykonalne. Jeszcze tylko hackow w eve brakuje. A przy peer to peer to dopiero byl by nowy poziom walki elektronicznej dodany do gry :2funny:
-
Ja myślę ze np wyłączenie detekcji kolizji przy większych bitwach bardzo by pomogło. Ale nie pisze o tym na forum, bo jako programista wiem ile są warte takie mądre rady od ludzi którzy nie maja tak naprawdę pojęcia o szczegółach technicznych projektu.
-
nie wiem ile sa warte , bo nie jestem system architectem ani programista. i chyba nie ma to zadnego znaczenia dla kogos kto na tym sie zna. bo jesli dana propozycja naprowadzi na cos innego to juz jest sukces
-
Ja tam niechce krakac ale wydaje mi sie ze oni o tym wszystkim wiedza... jakies tam teorie maja jak to pokonac ale narazie najprostsza dlanich chyba jest metoda dokupowania kolejnych sprzetow. Tak wiem juz niektorzy mowia o eve MMOL a nie MMO.
-
Proste rozwiazanie na teraz to ograniczenie ilości ludzi w systemie - np. jak jest ponad 500 to gate nie wpuszcza tylko wypuszcza i trzeba poczekac az ktoś wyskoczy.....
Liczba 500 jest z kosmosu wzieta i trzebaby bylo wziac taka jaka na dzien dzisiejszy uciagna serwy ccp.
Niby ograniczy to "wielkosc bitew" ale w praktyce i tak to bedzie max sprzetowy, a w miare udoskonalania sprzetu powiekszali by liczbe graczy mogacych byc w 1 systemie.
-
Nie do przyjecia bo prowadzi do calkowicie absurdalnych strategii;
"Dzisiaj bedziemy atakowali wroga stacje, nie chcemy zeby ktos nam przeszkadzal wiec prosze zeby kazdy zalogowal wszystkie swoje konta i polecial do systemu XYZ i sie wylogowal, a nastepnie jak najszybciej po downtime - zalogowal z powrotem - postawimy na wszelki wypadek POSa ktory bedzie chronil AFKujace shuttle w czasie oblezenia."
-
dzisiaj mozna tez wprowadzic ta strategię tylko inaczej - 300 orbitujących wokół siebie promów załatwi takiego laga atakującej armii że zanim odzyska panowanie nad fpsami obudzi sie na stacji w klonie....
Ale elaine masz racje - pomysł był głupi :). Zreszta jita traderzy by sie lekko wkurwilili :D
-
Ogolnie sa dwie drogi - optymalizacja i przekonanie ludzi do unikania wielkich bitew.
To drugie wymaga wprowadzenia elementow ktore ograniczaja wielkosc bloba i promuja male ilosci wiekszych statkow. CCP prze w tym kierynku od dawna, dali Doomsday weapon (jesli zrobicie bloba malych statkow, mozecie dostac DD) i przeprojektowali gangi tak by promowac male grupy o jasno okreslonych zadaniach taktycznych (chyba bez wiekszego skutku jesli idzie o walke z blobami). Tyle ze tak naprawde ciezko jest przekonac ludzi ze strategia "zbierz wiecej dobrze uzbrojonych statkow niz przeciwnik i koncentruj ogien" jest zla, bo jest dobra ;).
W kwestii optymalizacji CCP poprawial jakis czas temu swoje algorytmy do load balancing, ale nie przeskoczyli z tego co wiem bariery 1 system = 1 fizyczna maszyna, z dynamiczna alokacja tej mocy tez nie jest za dobrze.
Liczac razem z upgradem sprzetu przed Revelations, doszli od jakichs 300 statkow do 700 walczacych w jednym systemie i lagi sa chyba podobne.
Ogolnie jednak, albo przepisza porzadnie kawal kodu u podstaw mechanizmu eventow, sesji etc, albo ludzie beda robic itak bitwy tak duze jak tylko system pociagnie, i znow beda narzekac, ze bitwa sklada sie z 2 minutowych lagow i wybuchania po disconnect, tyle ze narzekajacych bedzie 1500 albo 3000.
A przepisanie podstawowych elementow silnika gry to operacja nie tylko duza, ale i niosaca wielki potencjal bolu i cierpienia - aktualny silnik byl poprawiany przez lata, nowy bedzie mial nowe bledy.
-
No ale droga optymalizacji jest ehmm.. bez sensu - zawsze zbierze sie banda iluśset frytek mogących zalagować każdy sprzet... Natomiast wpływ na zmniejszenie ilości uczestników w bitwie jest trudny do wykonania przy dobrze wykonanym zalozeniu w eve ze kazda nawet mala a dobrze wykorzystana jednostka sie liczy.
Jedno co jest łatwiejsze do zmiany to ograniczenie w graniu na kilka kont z jednego kompa na raz... Nie wiem jak to sie robi ale na pewno w innych onlinowkach np serii bf nie można było zalogować z kompa kilku kont na raz... W bitwach to wiele nie pomoże ale pewnie zmniejszy sztuczny tłok w niektórych systemach w empire.
-
Wiecie mowicie o zmniejszeniu przeliczanych rzeczy przez server ... mniejszych lagach.... a tu nam system HEAT dochodzi juz widze jaka to bedzie lagotworcza maszyna.... przeliczaj ile "Heata" wytwarza moje 8 x1400 3 hardnery 1 shield boster demage control itp itd itd normalnie jakby bylo 3000 shipow w jednym sys bedzie tak cos czuje...
-
Z moich doświadczeń wynika, że większym problemem jest lag po stronie klienta niż serwera. We wszystkich bitwach w jakich brałem udział moduły działały prawie normalnie za to FPS miałem na poziomie klatki na sekundę w najgorszych przypadkach a czasem kompletny zastój przez kilkanaście sekund. Deweloperzy twierdzą, że potrzebne jest przepisanie klienta od nowa i będzie to robione przy okazji nowego engine'u graficznego. Nie sądzę aby robili cokolwiek ze starym kodem do tego czasu.
Po stronie serwera CCP przechodzi z transmisji po TCP/IP pomiędzy nodami klastra na rozwiązania dedykowane dla klastrów. Powinno to pozwolić na zwiększenie limitu 700 osób na system, który został niedawno wprowadzony. Może uda im się podzielić system na kilka nodów ale na to bym specjalnie nie liczył.
-
Lag po stronie klienta swoją szosą, tego da się łatwo wyeliminować wykonując przed walką 3 kombinacje klawiszy: CTRL+SHIFT+F12, CTRL+SHIFT+T oraz CTRL+SHIFT+F (ale o tym większość pewnie wie). Kolejnym łatwym sposobem poprawienia sytuacji jest zakup RAMu. Możliwe, że przepisanie klienta może dać rezultaty, spec ze mnie żaden, ot laickie dywagacje. W kwestii likwidacji laga po stronie serwera wartałoby pamiętać, że możliwości modernizacji sieci nie są nieskończone i CCP jest w pewien sposób ograniczane możliwościami sprzętowymi.
-
Prawde mowiac mi lag po stronie klienta ciezko wyeliminowac na laptopie ze slaba grafa przy malych starciach, wiec przy duzych starciach jest to zapewne problem na kazdym sprzecie. Gram ogladajac czarny kawalek mapy galaktyki w rozdzielczosci minimalnej, bez milionow kolorow, bez z-buffera, a i tak FPS mam w okolicach 1 przy 20 statkach a przy 100 mam juz kilka FPM (frames per minute). Wystarczy wprowadzic opcje "turn off all 3D graphics, ALL, give me second overview table instead!". Mysle ze CCP nie wprowadza tej super opcji bojac sie ze wszyscy starzy gracze wlacza ja sobie na stale i wtedy jak ktos zobaczy przez ramie jak ktos inny gra w eve to nie pomysli "Oh jaka piekna gra o statkach walczacych w kosmosie" tylko "Oh to znowu ta glupia gra o kwadratach w tabelce".
Tak czy siak, po stronie klienta mozna sobie poradzic mocniejszym sprzetem, klienta relatywnie latwo jest poprawiac i testowac (mozna dac nowego klienta kilku setko ISD do testowania i nie zakluca to gry pozostalych graczy). Prawdziwy bol lezy na serwerach, bo CCP ma problem ze zwykla moca obliczeniowa w duzych bitwach. Jet to problem rozwiazywalny, tylko duzo trudniej;
Zapewne bardzo by pomoglo przepisanie samych podstaw na C++.
Mysle tez ze bardzo by pomoglo usuniecie zupelnie czesci obliczen kosztem "wiarygodnosci" bitwy. Np calkowite usuniecie bumpowania lub zamiana na tanszy algorytm. Z jednej strony - bedzie wygladalo glupio bo 100 statkow bedzie moglo znalezc sie i pozostac w jednym punkcie przestrzeni. Z drugiej strony colision detection to obliczenia o wykladniczej zlozonosci - musisz sprawdzic kazdy statek z kazdym innym w okolicy, czy sie nie zdazyly. IMHO glupi wyglad jest lepszy niz niemozliwosc grania.
Pogloby tez grupowanie broni. Jesli mialbym zgrupowane moje 8 laserow i strzelal z nich jednym guzikiem, i to zgrupowanie bylo zapisane na serwerze, szedl by 1 event ode mnie do serwera i od serwera do pozostalych klientow, a nie 8. W sumie cos takiego dzieje sie automagicznie jesli sie szybko odpali F1-F8 ale mechanizm nie powinien opierac sie na szybkim klikaniu graczy.
Pomogloby nie wysylanie czesci eventow do czesci graczy przy duzym obciazeniu - w sumie lepiej zeby dzialalo plynnie niz zeby kazdy widzial wszystkie kreski laserow, pociski, rakiety i wybuchy.
Ale CCP inwestuje glownie w rozwijanie mechanizmow load ballancing, przynajmniej tylko o tym mowia.
-
jak czytalam devblogi, chca ograniczyc liczbe statkow w bitwach duzych flot, za pomoca ... przywrocenia area damage torpedom ( pisxze OM bo z a glupio wyglada) i dodnie area niektorej amunicji artlyeryjskiej, i ogolnie kombinuja,m uzeby biuitwy byly bardziej falowe a nie ilosciowe ( jak masz 400 osob flote chca zeby bardziej sioe oplacalo atakowac 34 falami po 100 niz 1 blobem 400 osob)
-
jesli tak zrobia to bedzie do dupy...lepiej dac graczom mozliwosc wyboru opcji fleetbattle, ktora byc moze uprosci do minimum wymiane bitow, ale za to zwieksza grywalnosc na maxa....
btw boje sie myslec co bedzie jak wejdzie directx 10 pod viste...
-
Area damage torped jest akurat bardzo fajnym pomyslem :)
-
Raveny bedą siały pogrom :D 10 ravenow i masz mini DD odpalane co 10 sekund :) tylko jeszcze potrzebny bedzie patent na to aby wszyscy na widok ravenow nie rozlatywali sie po polu bitwy, np dictor z web sfera :D
-
Tempest 4, Apoc 2 , Megathron 2 missle sloty. W przypadku tempesta wstawienie 2 torp launcherow bedzie obowiazkowe. Wiec kazda rasa bedzie mogla sobie dodac area do ognia koncentrowanego (tyle ze bez bonusa 50% do predkosci torpedy).
-
wystarczy podleciec do ravena zeby przstal do ciebie strzelac? chcialbym zobaczyc killmaila gdzie gosc sam ma na sobie final blowa;]
-
Ech, kiedyś dawno temu rakiety miały spash dmg... Teraz tylko w opisie pozostał... Albo i tam nie. A zlikwidowali rzekomo z powodu laga z tego co pamiętam... Chociaż pewien nie jestem... Natomiast w najnowszym devblogu jest pare słów odnośnie wprowadzenia bomb (takie wybuchowe proby strzelane ze stealth bomberów), ograniczenia DDDDD, nerfnięcia fighterów, siege-podobnego trybu dla lotnisk, itp... Teoretycznie wszystko to ma zniechęcić do blobowania - czyli zmniejszyć laga...
-
gram juz chyba sporo ponad 3 lata... i splasha zadne misje nie mialy jak siegam pamieca....
-
Torpedy miały, do tej pory pozostał po nim efekt wizualny, rozchodzace sie halo
-
Torpedy miały, do tej pory pozostał po nim efekt wizualny, rozchodzace sie halo
A usunięty został nie z powodu laga ale nieużywalności w imperium. Zbyt łatwo było stracić statek przez Concord. To były czasy misji w bezpośrednim sąsiedztwie bram i stacji. Wyglądało to fajnie ale niestety było łatwo "exploitowalne".
-
Wiecie mowicie o zmniejszeniu przeliczanych rzeczy przez server ... mniejszych lagach.... a tu nam system HEAT dochodzi juz widze jaka to bedzie lagotworcza maszyna.... przeliczaj ile "Heata" wytwarza moje 8 x1400 3 hardnery 1 shield boster demage control itp itd itd normalnie jakby bylo 3000 shipow w jednym sys bedzie tak cos czuje...
bekocz, nie boj nic, przeliczy to wszystko podczas fitowania, jak wszystko.
a sam heat ma sluzyc zmniejszeniu lagow :)
taa, bo obie strony sie przegrzeja i powysiadaja im moduly, zanim dojdzie do bitwy ^^'
mogliby tez cos zrobic z dronami. nie wiem jak wam, ale mnie strasznie spowalniaja wczytywanie grida (a najprostrzy sposob na zlagowanie mnie to wywalanie i chowanie dron... umarl w butach, bo nic zrobic nie moge, mimo ze mam dronki niepokazane na over)
PS
Splash dmg? >:D
pora chyba zainwestowac w bpo na ravka i rurke ;]
-
taa, bo obie strony sie przegrzeja i powysiadaja im moduly, zanim dojdzie do bitwy ^^'
mogliby tez cos zrobic z dronami. nie wiem jak wam, ale mnie strasznie spowalniaja wczytywanie grida (a najprostrzy sposob na zlagowanie mnie to wywalanie i chowanie dron... umarl w butach, bo nic zrobic nie moge, mimo ze mam dronki niepokazane na over)
Tu akurat faktycznie mogliby poprawić, bo ostatnia poprawka (zamiana wyglądu dronek z obiektów podobnych statkom, na iksiki) zupełnie nie zmieniła nic w mechaniźmie. Dalej klient ładuje sobie wszystkie wielokąty dronek z tą drobą różnicą, że teraz musisz się "nieco" napracować żeby zobaczyć model dronki. Ja wiem, że zajebiście wyglądają te wszystkie efekty silników korekcyjnych na fighterach i dronki z superduper detalami, ale obliczenie tego wszystkiego przez klienta jednak zabiera sporo mocy.
-
Jeżeli chodzi o performance klienta to zmiana engine graficznego ma to zmienić.
Przepisują obecnie engine który został napisany na początku EvE i nowy ma być zajebiście wydajny.
Polecam posłuchać Dev-Chata
-
No tak ale póki co to sobie na nowy engine trochę poczekamy.
Oprócz wyłączenia szczegółów i dźwięku dowiedziałem się o innym sposobie zmniejszenia laga po stronie klienta. Jako, że za większość opóźnień odpowiedzialne jest overview (jak sam Hilmar stwierdził niepotrzebnie wielokrotnie przerysowywane) należy usunąć wszystkie oznaczenia - kolory i ikonki. Sprawdziłem to i faktycznie działa.
-
Mam nadzieje ze nowy lepszy klient nie bedzie dla DX10 only >:(
-
zgadza sie, sam mam ustawiona opcje fight, gdzie wywalilem ally, corp, gang i inne kolorowe iconki. Widze tylko shipy hostili - i to zalezy tez z czym bede walczyl...jesli jestem w bs/bc - to wywalam tez drones, frigates,
obowiazkowo tez wywalilem: wrecks, cans, wszystkie struktury, zostawiam tylko gates.
Dodatkowo mam odpalone i zminimalizowane people & places, bmki sa wtedy zaladowane.
-
Dodatkowo mam odpalone i zminimalizowane people & places, bmki sa wtedy zaladowane.
A to jakaś nowa teoria :o
Wydaje mi się jednak, że BMki są automatycznie ładowane z serwera, kiedykolwiek wlatujesz do nowego systemu (co łatwo sprawdzić, prawym klawiszem myszy)
-
Jemu chodziło o to, że lista bmek jest wtedy cały czas widoczna klikasz prawym i warp. W sumie dwa kliknięcia miej niż normalnie. MIałem tak tlyko w czasie walk w n-rael (kampienia w sumie) ale w czasie aga i tak nie pomaga ;)
Sam mam pare opcji ustawien overview zaleznie od walki. Szybki wybor malych shipow czy dron tez czesto uzywam. Ale rpzyznam, ze bardzo zradko mi sie zdarzalo, ze musialem komus tluc dronki...
-
Mam nadzieje ze nowy lepszy klient nie bedzie dla DX10 only >:(
Będą dwa. Jeden DX9 a drugi DX10 (Vista).
-
DX10 ma mieć ładniejsze efekty, ale nie będzie tam nic czego nie będzie w DX9
-
bardzo zradko mi sie zdarzalo, ze musialem komus tluc dronki...
bo latasz glownie w gangu
-
Wiecie co powinni zrobic z lagiem:
*** przerobic engine serwerowy gra tak zeby najmniejsza "jednostka" gry nie byl system tylko cos co umownie mozna by nazwac "game fileld" - obszar przestrzeni gdzie znajduje sie cos istotnego, np: brama, stacja, planeta, ale takze pojedynczy statek gracza wiszacy gdzies w przestrzeni, takie "game fieldy" powinny sie szybko i swobodnie laczyc i dzielic, np. gang skaczacy na kogos starujac z ss'a lecial by z wlasym "game fieldem" i wlatywal by do "game fielda" swoich ofiar, oczywiscie proces laczenia powinien zaczynac sie juz na poczatku skoku (ewentualnie opozniajac wyjscie z warp) tak zeby wszyscy gracze mieli rowne szanse (a nie gineli ci ktorzy maja pecha miec akurat wiekszego laga), jeden system oczywiscie mogl by wtedy byc podzieloby na wiele serwerow, do tego wszystkiego "game fieldy" powinny moc sie swobodnie przemieszczac miedzy serwerami, i tak na przyklad w czasie eskalacji bitwy jej "game field" mogl by "wypierac" z serwera inne "game fieldy" (gracze na nich dostawali by oczywiscie na kilka sekund komunikat o "czym tam" ale to raczej nie powinien byc problem) tak zeby miec dosc mocy i pamieci zeby bitwa mogla sie rozgrywac - wten sposob zniknal by problem walk w 0.0 kiedy systemy do tego "nie przystosowane" musza udzwignac jakas wieksza bitwe.
*** majac to wszystko co napisalem wyzej mozna by zrobic jeszcze jedna rzecz, ktora by moze nie tyle zlikwidowala laga co wyrownala szanse wszystkich graczy - w momencie kiedy serwer nie mogl by uradzic "game fielda" z bitwa lub pingi znacznej liczby graczy spadaly by ponizej jakiegos poziomu "przyzwoitosci" - "game field" mogl by spowalniac uplyw czasu o jakis wskaznik zlazeny od okolicznosci, interfejsy graczy dzialaly by zupelnie normlanie (skile tez by sie normalnie robily :) ) tylko wydluzal by sie czas kazdego zdarzenia, statki by lecialy relatywnie wolniej itp., mialo by to dodatkowa zalete wydluzenia czasu na reakcje graczy podczas bitwy, mniej prawdopodobne by bylo ze zginiesz zanim zorietujesz sie, ze zaczeli do ciebie strzelac, dodatkowo otworzylo by to niezle mozliwosci taktyczne dla graczy z "otoczenia" bitwy - oni znajdujac sie w innych "game fieldach" mieli by normalny uplyw czasu
P.S. Oczywiscie nie spodziewam sie zeby w EVE kiedykolwiek zrobili cos takiego, predzej ktos napisze taki system walki od nowa jako nowa gre, fajnie by bylo :)
-
zlikwidujcie dronki i nie bedzie takich algow:) oczywiscie wtedy wybijcie tez wszystkich gallente bo onisie na to nie zgodza
i mnie tez wybijcie bo tez sie na to nie zgodze
a lag i tak zostanie, jak niby ma go nie byc jak na servie jest 35k ludzi, a w systemie czesto jest po kilkaset osob?
-
adam tak właśnie jest te całe " game fieldy " już istnieją ( nie kturzy nazywają je gridami ). Co do twoich pomysłów no cóż...... większość w takiej czy inne formie już jest zaimplementowana pozostałe dobre by były ale zdajesz sobie sprawę z komplikacji?
Pozdrawiam
-
a lag i tak zostanie, jak niby ma go nie byc jak na servie jest 35k ludzi, a w systemie czesto jest po kilkaset osob?
Liczba ludzi na serwerze nie ma znaczenia. Nawet jeśli sięgnie miliona to CCP sobie z tym poradzi poprzez dołożenie więcej sprzętu. Akurat w tym wypadku serwer skaluje się bardzo łatwo.
Problem pojawia się gdy w jednym systemie jest zbyt wielu graczy. System zawsze jest obsługiwany przez jedną fizyczną maszynę i tu szybko osiągana jest granica możliwości.
Moim zdaniem przejście na Mironet i upgrade procesorów, o którym wspominało CCP niewiele da. Owszem lag przy 700 pilotach zniknie ale zaraz pojawi się z powrotem przy 1200. Ludzie po prostu zrobią większego bloba "bo się da".
Potrzebna jest fundamentalna zmiana w mechanice gry zniechęcająca do tworzenia blobów (mało prawdopodobne) albo całkowite przerobienie klastra tak aby dzielił system na wiele maszyn.
-
Cala nadzieja w mini doom devicach czyli bombach ze stelf bomberow :D moze to uratuje nas przed maxi blobami :D
-
Nazwa grid pochodzi ze starych gierek typu Ultima, gdzie ludzie chodzili po kwadracikach. Kazdy dostawal od serwera informacje o tych kwadracikach ktore mial na ekranie i ewentualnie ich najblizszym otoczeniu.
Nie widze za bardzo jak moglby zadzialac taki mechanizm w Eve i jak moglby pomoc.
Problem z dzialaniem jest taki, ze mozesz miec 3 statki oddalone o 900 km;
A ------900km------ B ------900km----- C
A widzi tylko B, B widzi A i C, C widzi tylko B
Ktory z nich "nosi" grida? Jaki zakres wlasciwie ma ten grid?
Wszystkie statki maja wspolrzedne okreslone dlugimi zmiennoprzecinkowymi liczbami. Szybko sie przemieszczaja i moga sie znalezc w praktycznie dowolnym punkcie przestrzeni. Przepisywanie statkow z grida do grida to idealna okazja do zrobienia 1500 trudnych do wylapania bledow.
Koniec koncow, trzeba by miec mechanizm kory potrafi rozproszyc jeden system rownomiernie na kilka maszyn w clusterze.
Do tego, co pomoga nam gridy na osobnych maszynach? Nico. Najbardziej boli i najwiekszy jest lag w czasie bitwy zasadniczej, w ktorej przez wiekszosc czasu 700 statkow znajduje sie w promieniu moze 2000km, ewentualnie wypadajac i wracajac z pobliskich safespotów. Wszystkie te statki w czasie walki generuja ciagle eventy (uzywaja modulow, zmieniaja kurs i predkosc). To wszystko w tym rozwiazaniu pozostanie na jednej maszynie, podczas gdy pozostale 4 maszyny przeznaczone na ten system na czas bitwy podliczaja carriera leczacego 2 BSy na safespocie i 3 kolesi AFKujacych w POSie.
DD juz dosc skutecznie przekonuje ludzi powoli do ostroznosci przy blobowaniu.
Edit:
Dobra, juz wyobrazam sobie algorytmy do wydzielania grup obiektow w przestrzeni i korzysci jakie mozna przez to odniesc.
-
mysle, ze najlepszym rozwiazaniem na laga byloby plynne przelaczanie zasobow.
Jesli jakis serwer w macierzy osiaga 99% obciazenia, automatycznie najblizsze serwery otrzymuja dawke informacji do obrobienia odciazajac serwer najbardziej obciazony. Oczywiscie moim zdaniem trzeba na to odciazanie nalozyc logike, gdzie sasiednie serwery beda otrzymywac prace nie zwiazana z walka, serwer glowny nadal zajmowal sie bedzie obliczeniami zwiazanymi z walka.
poza tym limit na systemie slonecznym = 1000 osob. Z tego 20% gwarantowane dla pilotow aliansu posiadajacego sovereignity w danym systemie. w przypadku braku sovereignity, zadnych ograniczen
Nie wiem czy nie gadam belkotu, nie znam sie do konca ;) ale tak mysle, tak kombinuje :)
-
po tym co piszecie to nalezy skupic na :
* zmniejszeniu ilosci operacji zmienoprzecinkowych na sec przez:
- zmniejszenia ilosci eventow w czasie i w systemie (ograniczenie liczby graczy/shipow, zamrozenie niektorych eventow na czas walki)
- zwiekszenie mocy obliczeniowej (zakup nowych serverow na farme, utworzenie lokalnych serverow-swiatow eve - podobnie jak w WoW)
mysle, ze najlepszym rozwiazaniem na laga byloby plynne przelaczanie zasobow.
Hastrabull - to jest twoje zdjecie? siem moze umowimy na lody? >:D
tak chyba dzialaja mainframy ..
btw niech oddadza to w oursourcing do IBM, tam maja takie pojecie performance on demand...z tego co wiem...maja spora nadyzke mocy obliczeniowej do zagospodarowania...w koncu jak radza sobie ze srodowiskiem transakcyjnym na codzien, to pewnie tutaj tez cos wymysla...zamiast od nich kupowac maszyny lepiej kupic wydajnosc
-
utworzenie lokalnych serverow-swiatow eve - podobnie jak w WoW
Wiesz co, z takimi pomysłami to moge ci tylko bajkę o wężu opowiedzieć... Sssssspier.....alaj.
-
Przelaczanie obciazen wlasnie ma pewne ograniczenia. Normalnie jedna maszyna obrabia jedna do kilku konstelacji, w przypadku duzych obciazen moze byc maksymalnie jedna maszyna na system.
Z tego wynika ze cluster nie dziala na wartstwie systemowej (wielki proces chodzacy na setkach maszyn i wybierajacy sobie masyzne do odpalenia kazdego watku) tylko na poziomie aplikacji (przelaczanie obciazen jest implementowane recznie w kodzie serwera Eve). Z tego co rozumiem wypowiedzi devow, nie bardzo przelacza sie to plynnie miedzy komputerami i oni recznie ustawiaja takie rzeczy w czasie downtime na serwerach w Londynie na podstawie statystyk obciazenia z poprzedniego dnia oraz zgloszen graczy - zgloszen graczy czyli gracz pisze petycje do GMow ze jego sojusz planuje ofensywe na system XYZ jutro i ten system bedzie potrzebowal mocy obliczeniowej. Slabo, ale chyba nie umieja tego przeskoczyc, przynajmniej nie umieli pol roku temu.
Lokalne serwery Eve (oprocz Chin) nie sa akceptowalne tak dla CCP jak i dla znacznej czesci graczy. Mi na lokalnym serwerze juz by sie nie chcialo grac. Jeden serwer to jeden z glownych atutiow ktore czynia Eve wyjatkowa gra, choc CCP placi za to technicznymi ograniczeniami bazy klientow.
A zmniejszanie ilosci eventow wyliczanych i wysylanych w czasie bitwy jest akurat dobrym pomyslem :)
-
adam tak właśnie jest te całe " game fieldy " już istnieją ( nie kturzy nazywają je gridami ). Co do twoich pomysłów no cóż...... większość w takiej czy inne formie już jest zaimplementowana pozostałe dobre by były ale zdajesz sobie sprawę z komplikacji?
No właśnie, gridy istnieja ale sa uwiazane do miejsc w przestrzeni i sa ograniczone (slyszalem kiedys o roznych jajach z tym zwiazanych), do tego sa zupelnie niedynamiczne pod wzgledem wykorzysatnia zasobow serwerow, ma to sie nijak do opisanych przezemnie koncepcji. I oczywiscie zdaje sobie sprawe, ze ich realizacja nie jest banalna dlatego nie oczekuje wcale, ze kiedys w EVE takie wynalazki zobaczymy.
W ogole jak sie tak zastanowic nad rozwiazaniami jakie w swiecie serwerow EVE funkcjonuja to mozna sie zalamac, np.: zeby kopiowanie BMow generowalo laga? Smiech, wszystko co nie jest bezposrednio zwiazane ze statkami w przestrzeni (nawet to co dzieje sie w stacjach) nie powinno byc robione przez te same serwery, ktore obsluguja mechanike gry. Np. tak jak market jest na zupelnie innych serwerach. Ostatnio tez mnie troche rozsmieszylo jak sluchalem wypowiedzi w devblogu (tym dzwiekowym) szefa CCP o technologiach 64 bitowych, ze sie przymierzaja zeby to na serwerach wykorzystac, szybko sie obudzili :-) EVE od poczatku powinno na 64 bitowych serwerach chodzic.
P.S. A tym ktorym sie wydaje, ze mozna dokladac sprzet w nieskonczonosc... no wiec nie mozna, chociazby dlatego, ze baza danych jest tylko jedna (oczywiscie moze byc tez przez jakis klaster obslugiwana, chociaz tu bardziej ograniczeniem sa macieze dyskowe - stad rozne wynalazki z rodzaju "maciezy RAM") i nie mozna jej w nieskoczonosc przyspieszac, a kazde istotne zdarzenie w EVE predzej czy pozniej w bazach danych ma swoje odbicie.
-
Ostatnio tez mnie troche rozsmieszylo jak sluchalem wypowiedzi w devblogu (tym dzwiekowym) szefa CCP o technologiach 64 bitowych, ze sie przymierzaja zeby to na serwerach wykorzystac, szybko sie obudzili :-) EVE od poczatku powinno na 64 bitowych serwerach chodzic.
Ja tam się dużo nie znam, ale prosta zmiana 32->64 zazwyczaj oznacza spadek wydajności. Na zwiększenia wielkości słowa zyskuje wszystko co zajmuje się multimediami itp pierdołami. A sam fakt że pointer zajmuje 8 zamiast 4 bajtów powoduje, że kod powiększa swoją objętość, mniejsze jego kawałki mieszczą się w cache, etc. Strzelam że po przejściu z 32->64 każdy program chodzi 2-3% wolniej.
A więc na co komu 64 bity? Żeby mieć więcej niż (bodajże to windziany limit) 3GB pamięci dla jednego procesu.
Ale w sumie też nie chce mi się wierzyć że EvE do tej pory nie hulało już na 64biowym sprzęcie.
-
64 bity moga sie przydac do dlugich zmiennoprzecinkowych wspolrzednych statku w systemie, mnozony, dzielonych, odejmowanych i dodawanych w jednej operacji procesora a nie kilku.
Wielkosc kodu czy pamieciorzernoc raczej nam powinna wisiec. Prote zaalokowanie powyzej 2 giga na proces moze sie przydac. No ale rewolucji to raczej nie ma. Rewolucja to byla przy przejsciu z 8 na 16 bitow :)
Serwery sa w stackless pythonie wiec programisci maja umiarkowana wladze nad takimi rzeczami jak wielkosc wskaznika, alokacja pamieci etc. "przejscie na 64 bity" moze tu oznaczac zainstalowanie innej wersji pythona i sprawdzenie czy dziala :)
-
hmm. No właśnie Vril się nie znasz, przejście na 64 bitową platformę jest istotne i może byc niezwykle istotne. Z punktu widzenia asemblera wykonanie jakiejś instrukcji na wskaźniku języka C++ ( naprzykład ) jest wykonaniem określonego rozkazu w określonym trybie adresowania. Wiem że mało kto pisze w asemblerze ale kompilacja kodu C++ do języka maszynowego i tak sprowadza go do takiej postaci ( nie dosłownie ale bardzo blisko ). Fakt 64 bity przydają się do spraw związanych z grafiką itd ( taka jest cecha rozwoju komputerów w ostatnich latach - wrost możliwości obliczeniowych głównie tam gdzie można go stosować w grafice itd. ) i fakt sa to głównie liczby zmiennoprzecinkowe z ich odmienną od stałoprzecinkowej arytmetyką, więc i jednostka zmiennoprzecinkowa ( FPU ) w procesorze ( CPU ) dostaje bonusa. Tak się jednak składa że 64 bitowe rejestry są w jednostce stałoprzecinkowej ( ALU ) i to dzięki nim procesor nazywa sie 64-bitowym. Są to rejestry ogólnego przeznaczenia w jaki sposób je wykorzystasz to akurat procesorowi wisi do operacji zmiennoprzecinkowych ma swoje własne rejestry 80-bitowe ( lub większe )................... Dobra nie ma sensu opisywać tego zbyt szczegółowo, faktem jest że spadek wydaności jeśli istnieje to spowodowany jest prostym przeniesieniem środowiska 32-bitowego na 64-bitowe ( takie środowisko po prostu nie wykorzystuje możliwości jakie daje nowa platforma ). Naprawdę 64-bity mają duże możliwości wystarczy uzmysłowić sobie na jak wielkiej bazie danych wykonuje się obliczenia, w nowym środowiski po prostu każdy rozkaz będzie mógł przerabiać dwa razy więcej danych chociażby były to bajty ( w 32 bitach 4*8 bit w 64 8*8bit )
Racje ma Albi pisząc ze sprowadzi się to do nowej 64-bitowej wersji pythona da to jakiś bonus ale aby wszystko działało jeszcze lepiej, CCP powinno po prostu przepisać całą EVkę i skompilować ponownie pod środowiskiem 64-bitowym właśnie.
adam000 nie dokońca tak jest, gridy też stosują pewną dynamikę. Wyobraźmy sobie taką sytuację: Stawiasz bańkę między bramami wpada na nią flota i ty ze swoimi ludkami warpujesz się na tą bańkę. W tym momencie okolica "staje sie pewnym gridem". Pewnie nie zaczyna jej obsługiwać oddzielny serwer czego jak myślę chciałbyś od CCP ale mimo wszystko. Zastanów się co by się stało gdyby jednak nad okolicą bańki przekazano innemu serverowi, pewnie mogłoby sie spotkać i 1000 statków w tym miejscu ale sam moment przekazywania innemu serverowi takej ilości danych to crash jeśli nie samego servera to połączeń może połowy tej floty. Pewnie można byłoby zastosować rozwiązania z współczesnej informatyki ( np. tablica skoków - to jakaś analogia pewne obiekty np. własnie bańki/posy w "obleganych" systemach są wyróżnione bo wokół nich może się coś dziać. W tym przypadku zaraz pojawiliby sie kumaci ludzie którzy odkryliby na co zwracać uwagę i po prostu wykorzystywali by błędy, niedoróbki w oprogramowaniu. Tak jak w przypadku zachowań goonsów z ich ukochanym logofski manewrem - vidae strata posa z podukowanym prez LV tytanem ) Piszesz że każde zdarzenie ma swoje odbicie w bazach danych i słusznie ale program nie może tego przewidzieć ze 100% pewnością dlatego idea ruchomych gridów o kturych ty piszesz może sie nie sprawdzić. Pewnie aby zrobic to z jak największa dokładnością i fachowścią trzebaby przeanalizować ogromna ilość danych może się wieć okazać że ewentualne zyski są zbyt małe w stosunku do kosztów.
p.s. Wielkość słowa jako taka się nie zmienia bo jest z góry określona ( to tak jak niuton w układzie SI ) i wynosi dwa bajty czyli 16 bitów a 64-bity to po prostu cztery słowa - choć fakt coraz częście słyszy się słowo procesora intel czy coś w tym stylu
p.s.2 Rewolucji nawet przy przejściu z 8 na 16 bitów nie było, współczense procesory nadal noszą twarz procesora 8086 a wszystko przez kompatybilnosc.
p.s.3 Dopiero teraz przyszło mi do głowy że mimo wszystko CCP robi cholernie dobrą robotę i byc może uczesniczymy w symulacji jaka nie miała miejsca w całej historii człowieka.
Sorki za urywane myśli ale na zajęcia mi śpieszno. Pozdrawiam
-
Przerzucanie miedzy serwerami wcale nie musi być takim problemem, przy skakania miedzy systemami się przecież odbywa, warp mógł by działać zupełnie podobnie. A gdyby jakiś "grid" zaczynał "puchnąć" od statków to właśnie nie on by się przerzucał gdzie indziej tylko "wypychał" inne mniej obciążone "gridy" ze swojego serwera, ludziom w nich na chwilę pojawiał by się komunikat o "jakiś zakłuceniach przestrzeni" czy coś równie "kosmicznego" :-) i było by OK
P.S. Piszecie, że serwerowa strona EVE jest napisana w pythonie... trudno mi w to uwierzyć, jeżeli tak jest to tym bardziej nie ma się co dziwić, że to wszystko nie wrabia i po każdej większej zmianie w kodzie wyłazi pełno błędów. Nie wiem czy próbowaliście pisać coś niebanalnego w języku bez statycznej kontroli typów, ja spróbowałem raz i to nawet nic specjalnie wielkiego i można się na prawdę zdziwić. Na początek trzeba się nazgadywać jakich typów (klas) parametrów oczekują jakieś "obce" funkcje/metody, a na koniec się okazuje, że jak coś jest nie tak to wyjdzie to w najmniej odpowiednim momencie kiedy akurat wykona się (i wywali) kod, który zazwyczaj się nie wykonuje. W momencie kiedy projekt ma kilka lat i pracuje nad nim wiele osób a dokumentacja pewnie jest taka jak to zazwyczaj jest :-) to tylko współczuć im można i podziwiać, że jakoś to działa.
P.S.2 A na myki z logowaniem też jest prosty sposób - nie wydaje wam się, że znikające w przestrzeni po wylogowaniu pilota statki to lekkie "przegięcie" rzeczywistości. A można by to załatwić tak prosto, statki nie powinny znikać tylko sobie jak teraz odwarpować gdzieś w przestrzeń, oczywiście gdyby tak sobie wisiały w przestrzeni to były by banalnym łupem więc powinny mieć możliwość bronienia się same, tak jak NPCe ale nie jak NPCe powinny dysponować całym swym ogniowym i obronnym potencjałem i powinny mieć przynajmniej tyle "inteligencji" żeby uciekać jeżeli nie mają szans na wygraną, a może lepiej żeby w ogóle zawsze najpierw uciekały do dopiero złapane walczyły. Do tego można by dołożyć jakiś prosty system wydawania im poleceń przez członków gangu/corpa żeby w wypadkach awaryjnych (ich pilot nie może wrócić do gry) można je było odeskortować do stacji.
-
Eve to nie portal w php, gdyby dokumentacja byla tam taka jak zazwyczaj jest, to bysmy teraz grali co najwyzej w karcianke :)
Stackless Python to dosc egzotyczny jezyk w ktorym Eve jest najwiekszym istniejacym projektem. Moze sie roznic od oryginalu w roznych miejscach, bo AFAIK, ktos go napisal od zera.
-
P.S. Piszecie, że serwerowa strona EVE jest napisana w pythonie... trudno mi w to uwierzyć, jeżeli tak jest to tym bardziej nie ma się co dziwić, że to wszystko nie wrabia i po każdej większej zmianie w kodzie wyłazi pełno błędów. Nie wiem czy próbowaliście pisać coś niebanalnego w języku bez statycznej kontroli typów, ja spróbowałem raz i to nawet nic specjalnie wielkiego i można się na prawdę zdziwić. Na początek trzeba się nazgadywać jakich typów (klas) parametrów oczekują jakieś "obce" funkcje/metody, a na koniec się okazuje, że jak coś jest nie tak to wyjdzie to w najmniej odpowiednim momencie kiedy akurat wykona się (i wywali) kod, który zazwyczaj się nie wykonuje. W momencie kiedy projekt ma kilka lat i pracuje nad nim wiele osób a dokumentacja pewnie jest taka jak to zazwyczaj jest :-) to tylko współczuć im można i podziwiać, że jakoś to działa.
Nie wiem w czym pisałeś, że miałeś takie problemy - i nie wiem, w czym programowałeś wcześniej. Ale właśnie python jest jednym z lepiej zaprojektowanych i nadających się do dużych projektów językiem programowania. Faktem jest, że większość dokumentacji jest po angielsku - ale tak niestety jest z większością języków programowania. Eve jest napisana w specjalnej wersji pythona (tzw. bezstosowa) i żeby było ciekawiej działa to po stronie serwera, a także klient też z tego korzysta. Oczywiście język programowania to nie wszystko - Jest duże prawdopodobieństwo, że błędy popełniono podczas projektowania systemu... ale na to już żaden język programowania nie pomoże :). Poniżej wycinek z FAQ ze strony EVE:
How is the game logic implemented in EVE?
EVE uses a special Stackless version of Python for both the server and the client. This makes for a much simpler creation of game logic than what was available in the past. The control structures provided by Stackless allow for a more “procedural syncronous” model, rather than an “event driven asynchronous,” or thread pooling.
In more simplified terms, this means that a large number of actors can perform tiny tasks without the added complexity or overhead of the other two execution models. Our game logic scripters are thereby freed from many of the mundane tasks associated with models that don’t benefit from the control structures provided by Stackless. The creative process of writing interesting game behavior is no longer bogged down by software or system limitations.
This approach also means that making changes to the game is much easier than it has been historically. Many improvements or tweaks can be added even when the world is online and going strong without the need to reboot the servers. This process is called a hot fix.
-
To jest bardzo stary tekst, nic w nim zreszta zaskakujacego, pisali go ludzi ktorzy wybrali te technologie.
Pare lat pozniej Oveur w jakims wywiadzie przyznal sie, ze Stackless Python, a przede wszystkim - jakies tam pierwotne zalozenia projektowe, bardzo ograniczaja i utrudniaja optymalizacje i rozwoj na pewnym poziomie i wogole nie jest lekko. I ze Stackless Python jest trudny dla prostych skrypciarzy projektujacych misje.
-
I ze Stackless Python jest trudny dla prostych skrypciarzy projektujacych misje.
Pewne jest, ze najszybszy kod pisze się w kodzie maszyny docelowej (assembler) tylko kto to by zrobił - a co gorsza później poprawiał :)
A co do projektowania misji, to chyba nie robią tego koderzy? :) Trzeba rozróżniać formę od treści ;)
-
Wystarczający jest C++. Nawet bez wstawek assemblerowych, masz panowanie nad tym jak rzeczy są trzymane w pamięci, alokowane i zwalniane itd itp. A przy tym masz, przynajmniej w microsoftowym, opcje współczesnego zarządzania wyjątkami, zdarzeniami i użycia automagicznie zarządzanej pamięci (gcnew i programujemy jak w Javie). Czyli - tam gdzie Cie to nie boli, programujesz wygodnie jak w językach całkiem współczesnych, a tam gdzie chcesz wycisnąć szczyty wydajności, jesteś bliższy assemblerowi.
Te wszystkie "mundane tasks" którymi nie muszą zajmować programiści w Stackless Pythonie, to jednocześnie miejsca, gdzie można optymalizować aplikację.
Jeśli idzie o skrypterów - chyba w Revelations, CCP oglosilo, ze wprowadzili nowy, prostszy język skryptowy dla ludzi którzy robią misje, bo wlasnie mieli oni zwykle problem z językiem.
Nie robią tego developerzy silnika tylko content designerzy, którzy niestety oprócz edytorka do ustawiania stateczków nauczyc pisac skrypty
-
Nie wiem w czym pisałeś, że miałeś takie problemy - i nie wiem, w czym programowałeś wcześniej. Ale właśnie python jest jednym z lepiej zaprojektowanych i nadających się do dużych projektów językiem programowania. Faktem jest, że większość dokumentacji jest po angielsku - ale tak niestety jest z większością języków programowania.
Piszę w różnych "dziwnych" językach (raczej niepopularnych) a poza tym jestem "zatwardziałym" programistą C++ :-) To o czym pisałem było właśnie w Pythonie :-) Ja wcale nie przeczę, że Python jest niezłym językiem i wiele rzeczy jest dla niego zrobione. Chodziło mi o ogólną koncepcję stosowania języków bez statycznej kontroli typów do "dużych projektów"... zresztą projekt może i być duży, tylko obawiam się jakie schody się zaczynają jak takie coś trzeba potem przerabiać i rozbudowywać latami, zwłaszcza w zespołach programistów. Problem jest nawet kiedy kompilator wychwytuje Ci podstawowe błędy, cuda mogą się dziać kiedy nawet tych podstawowych błędów nie wychwytuje, a wychodzą na wierz po miesiącach czy latach.
A wracając do EVE to Pythona nie jest raczej "jądrem" ich systemu tylko raczej językiem skryptowym "wbudowanym" a aplikacje właśnie do takich rzeczy jak programowanie misji itp. I do takich rzeczy może się sprawdzać idealnie. Coś sobie przypominam z devblogów (ale mogę się mylić), że wspominali o przepisywaniu niektórych "newralgicznych" procedur z Pythona na C++, czyli właśnie przenoszeniu ich do "jądra" aplikacji.
-
A wracając do EVE to Pythona nie jest raczej "jądrem" ich systemu tylko raczej językiem skryptowym "wbudowanym" a aplikacje właśnie do takich rzeczy jak programowanie misji itp. I do takich rzeczy może się sprawdzać idealnie. Coś sobie przypominam z devblogów (ale mogę się mylić), że wspominali o przepisywaniu niektórych "newralgicznych" procedur z Pythona na C++, czyli właśnie przenoszeniu ich do "jądra" aplikacji.
Tak masz rację.
Pewne jest, ze najszybszy kod pisze się w kodzie maszyny docelowej (assembler) tylko kto to by zrobił - a co gorsza później poprawiał
" kodem maszyny docelowej " nie jest asembler a język maszynowy, asembler jest językiem wyższego poziomu lub też translatorem kodu z asemblera na język maszynowy. Wybacz ale jestem purystą, po prostu mało osób zna ten język jeszcze mniej go docenia i to jako fanatyka takiego kodzenia smuci :( .
Albi podczas tworzenia tak dużych projektów często tworzy się własne środowiska programistyczne więc o ile C++ powinien być jakąś bazą to wokół niego powinien byc zbudowany bardzo uniwersalny język skryptowy, całkowicie niepodobny do wszystkiego co znamy i ściśle odpowiadający wymaganiom a jednocześnie łatwo rozbudowywalny. Napewno nie wystarczy C++ bez wstawek asemblerowych, na poziomie kompilatora i tak wszystko jest zamieniane na język maszynowy ale kompilatory języków wysokiego poziomu robią to nieefektywnie ( czasami nawet bardzo nieefektywnie nawet banalne procedury sortowania są często przekładane na postać która nie umywa sie pod względem efektywności odpowiednich napisanych w asemblerze ). Ten microsoftowym ma to do siebie ze stara sie byc jak najbardziej uniwersalny i to właśnie go gubi. ( traci na wydajności ). Słusznie napisałeś chcesz możesz być bliższy asemblerowi ale co za rużnica czy będąc w odległości 100km od domu zbliżysz się do niego na metr czy też na ten metr sie od niego oddalisz??.
Po mojemu sprawa jest prosta przy budowie tak wielkiego projektu konieczne jest stworzenie środowiska ( języka programowania ? ) które bedąc jednocześnie maksymalnie otwartym ( gotowym na ewentualną rozbudowę ) wykorzysta możliwości sprzętowe. Powstanie środowisko można myśleć o tworzeniu rozrywki dla kilkuset tysięcy graczy na jednym serwerze. W przeciwnym wypadku zawsze gdzieś pomiędzy uniwersalnością a wydajnością będzie istnieć konflikt.
p.s.1 Nadal będę się upierał że ta "polityka" gridowa o której piszesz już jest stosowana ( przynajmniej w jakiejś części ).
p.s.2 co do znikających szipów juz teraz możesz sobie to wytłumaczyć np. w ten sposób: wylogowujesz się co znaczy tyle ze na twoim szipie przestały funkcjonować wszystkie systemy oprócz systemów podtrzymywania życia. Cała energia jaką udało się zmagazynować w zapasowych systemach mocy wykorzystywana jest na zrobienie ostatniego skoku. Niedziała system nawigacji więc warpujesz się w losowym kierunku. Przez jakiś czas działają jescze jakieś podstawowe urządzenia w stylu elektryczny czajnik czy odkurzacz więc można cię namierzyć ale gdy i one się wyłączą lipa nic nie możesz zrobić i wtedy znika całkowicie możliwość znalezienia cię. Jesteś po prostu wrakiem szybującym gdzieś tam dla inych po prostu zniknołeś, nawet bateria w ręcznej bateryje wylała więc nie mżesz migać. Siedzisz w kajucie nad paprotką ( aby mieć więcej tlenu ). I tyle. Fakt ta teoria ma w sobie całkiem sporo nieścisłości ale cóż ta gra to jedna wielka bajka na resorach.