Autor Wątek: LAGFIELD vs battlefield  (Przeczytany 15088 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

ArchenTheGreat

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #35 dnia: Maj 15, 2007, 13:13:26 »
Mam nadzieje ze nowy lepszy klient nie bedzie dla DX10 only  >:(

Będą dwa. Jeden DX9 a drugi DX10 (Vista).

piotrqs_quendi

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #36 dnia: Maj 15, 2007, 14:03:50 »
DX10 ma mieć ładniejsze efekty, ale nie będzie tam nic czego nie będzie w DX9

LordJohny

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #37 dnia: Maj 15, 2007, 17:35:50 »
bardzo zradko mi sie zdarzalo, ze musialem komus tluc dronki...

bo latasz glownie w gangu

adam000

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #38 dnia: Maj 15, 2007, 20:03:31 »
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 :)

manticore

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #39 dnia: Maj 16, 2007, 01:15:19 »
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?

Fizyk

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #40 dnia: Maj 16, 2007, 05:23:05 »
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

ArchenTheGreat

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #41 dnia: Maj 16, 2007, 09:58:46 »
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.

LosBekoczoS

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #42 dnia: Maj 16, 2007, 10:46:58 »
Cala nadzieja w mini doom devicach czyli bombach ze stelf bomberow :D moze to uratuje nas przed maxi blobami :D

Ellaine

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #43 dnia: Maj 16, 2007, 11:00:56 »
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.
« Ostatnia zmiana: Maj 16, 2007, 11:23:15 wysłana przez Albi (była Ellaine) »

Hastrabull

  • Administrator
  • Użyszkodnik
  • Wiadomości: 2 060
    • Zobacz profil
Odp: LAGFIELD vs battlefield
« Odpowiedź #44 dnia: Maj 16, 2007, 12:47:13 »
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 :)

Jak masz się tu kogoś bać, to mnie...
buahahaha <- demoniczny śmiech

MightyBaz

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #45 dnia: Maj 16, 2007, 12:50:08 »
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
« Ostatnia zmiana: Maj 16, 2007, 13:00:22 wysłana przez Mighty Baz »

Xarthias

  • Użyszkodnik
  • *
  • Wiadomości: 6 512
  • Spamin' the World
    • Zobacz profil
  • Imię postaci: Xarthias
  • Korporacja: GoonWaffe
  • Sojusz: Goonswarm Federation
Odp: LAGFIELD vs battlefield
« Odpowiedź #46 dnia: Maj 16, 2007, 13:02:05 »
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.
Przedwieczny.

Ellaine

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #47 dnia: Maj 16, 2007, 13:07:29 »
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 :)

adam000

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #48 dnia: Maj 16, 2007, 18:16:22 »
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.

litestep

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #49 dnia: Maj 17, 2007, 01:34:39 »
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.

Ellaine

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #50 dnia: Maj 17, 2007, 07:29:51 »
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 :)

Fizyk

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #51 dnia: Maj 17, 2007, 11:15:24 »
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

adam000

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #52 dnia: Maj 17, 2007, 12:02:30 »
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.

Ellaine

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #53 dnia: Maj 17, 2007, 12:40:35 »
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.

marcoos

  • Użyszkodnik
  • Wiadomości: 630
    • Zobacz profil
Odp: LAGFIELD vs battlefield
« Odpowiedź #54 dnia: Maj 17, 2007, 12:51:05 »
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.
Bermuda Syndrome [BAS-3]

Ellaine

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #55 dnia: Maj 17, 2007, 13:09:02 »
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.

marcoos

  • Użyszkodnik
  • Wiadomości: 630
    • Zobacz profil
Odp: LAGFIELD vs battlefield
« Odpowiedź #56 dnia: Maj 17, 2007, 13:23:02 »
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 ;)
Bermuda Syndrome [BAS-3]

Ellaine

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #57 dnia: Maj 17, 2007, 13:51:25 »
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

adam000

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #58 dnia: Maj 17, 2007, 14:55:19 »
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.

Fizyk

  • Gość
Odp: LAGFIELD vs battlefield
« Odpowiedź #59 dnia: Maj 17, 2007, 15:56:53 »
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.