Sponsoring 50mb dysk, 2gb transferu

[Utilaft 14]

Witam. Czy mógłby ktoś mi zaproponować za darmo konto hostingowe 50mb dysku oraz 2gb transferu? Potrzebuję ogarniętego serwera do testów ; )

 Mój aktualny hosting, jakoś dziwnie działa.

 

Hosting wirtualny

[www.mzone.uk 1200]

Na jak długo potrzebujesz serwera?

[Utilaft 14]

Myślę, że miesiąc by starczył. Miesiąc to będzie maks.

 

Bo patrzyłem localhost, obrazek płynnie porusza się w ajaxie, a jak wrzucę na mintshost, są lagi.

Edytowano Kwiecień 20, 2013 przez Utilaft (zobacz historię edycji)

[Gość sixwishlist.com]

Dwie lokalizacja USA lub Francja. Najmniejszy pakiet to niestety 1GB transfer nielimitowany. Napisz do nas na adres team(at)sixwishlist.com w tytule "WHT". Przez 3 miesiące za darmo.

[Utilaft 14]

Kurczę, Francja - daleko, Usa - jeszcze dalej. Obawiam się, że mogło by przycinać chyba jeszcze bardziej niż na mintshost

[t4t4v4 3]

Utilaft poszły dane na priv.

[Gość]

Edytowano Marzec 26, 2018 przez Gość (zobacz historię edycji)

[Utilaft 14]

http://utilaft.pl/test2/index.php

 

Login: Beta

haslo: beta

 

Na localhoscie po przytrzymaniu strzalki idzie spoko, tutaj nie.

 

A tutaj drugi link (dziękuje bardzo za udostępnienie mi kawałka serwera

Avatat

)

 

http://utilaft.avatat.pl/index.php

 

Login: Beta

hasło: beta

 

I widzę różnicę, na avatacie idzie ok - jak na localhoscie

 

 

Kurcze, nie ma to jak masa doświadczonych ludzi na WHT

 

 

Musiałem zmniejszyć ilość pixeli do poruszania by to fajnie chodziło, ale dzięki temu zwiększyła się ilość zapytań.

Edytowano Kwiecień 21, 2013 przez Utilaft (zobacz historię edycji)

[clubowepl 8]

Z mojej strony mogę polecić jedynie OVH

[Gość Kamikadze]

Haha dobra giera ;D

 

Będziesz szukał jeszcze to coś mogę ci udostępnić

[Kszysiu 136]

szkoda tylko, że postać łazi z lekkim opóźnieniem a do tego jak się przytrzyma strzałkę to postać zrobi krok, a po sekundzie dopiero zacznie iść... Przynajmniej tak jest w operze

[t4t4v4 3]

Krzysiu, Utilaft juz pracuje nad poprawka Postac nie ma chodzic plynnie tylko krok > krok > krok..

[Utilaft 14]

Że tak powiem.. "work in progress"

 

Chodzenie płynne nie jest moim priorytetem, zajmę się tym, gdy ogarnę choć po części multiplayer ; )

[Gość Kamikadze]

Jak będziesz chciał potestować to mam serwery w Polsce, Niemczech, Francji i USA to mogę ci FTP udostępnić nawet na każdym

[Utilaft 14]

Ok, bardzo dziękuje za propozycję - doceniam to. W takim razie, jak będę potrzebował, dam znać

[Gość]

Edytowano Marzec 26, 2018 przez Gość (zobacz historię edycji)

[FrozenShade 18]

Najlepiej, w przypadku gier stosować tzw grubego klienta, czyli większość logiki trzymać po stronie aplikacji klienckiej, regularnie wysyłać dane do serwera w celu weryfikacji. Upraszczasz w tym momencie całą komunikację, gracz nie widzi, lub w większości przypadków nie jest świadomy występowania tzw. laga, przy większej ilości graczy serwer nie jest aż tak obciążony jak w przypadku innych rozwiązań.

 

Kolejna sprawa to używanie POST przy każdej akcji. Coś takiego możesz sobie robić w grze na kilka(naście) osób online. Jeśli będziesz chciał mieć większą grupę graczy to weź pod uwagę wydajność. Czym obsługujesz tego POSTa po stronie serwera? Jakiś PHP? Tego się nie robi w ten sposób, to dobre dla gierek w których nie ma dynamicznej akcji, gdzie tak naprawdę nie zależy na czasie. Samo PHP to już ogromny narzut operacji, dodatkowo debugowanie PHP to ... no właśnie, jakie debugowanie? Obsługą akcji graczy powinien zajmować się dedykowany proces po stronie serwera, najlepiej jeśli wszystko oprzesz o sockety, będziesz miał wtedy 2-kierunkową komunikację klient serwer, da Ci to np. możliwość wysyłania do gracza informacji o zdarzeniach.

 

Najlepsze imho rozwiązanie na dzien dzisiejszy to: klient jako aplikacja flash/java uruchamiana w oknie przeglądarki, serwer jako proces javy.

 

Jeśli będziesz miał jakieś pytania odnośnie samej javy lub rozwiązań które opisałem, zapraszam na PM. Sam w tym momencie tworzę grę przeglądarkową i jakiś czas temu miałem właśnie dylemat, jaką technologię wybrać.

Edytowano Kwiecień 23, 2013 przez FrozenShade (zobacz historię edycji)

[Utilaft 14]

Widzę, że robisz POST za każdym razem, gdy się postać ruszy i dopiero wtedy wyświetlasz animację - przesunięcie postaci.

 

1) Nie myślałeś o czymś "wydajniejszym" niż postowanie tego za każdym razem? Przykładowo - websockets wydaje się idealnym rozwiązaniem

 

2) Możesz również rysować animację ruchu PRZED wysłaniem posta/uzyskaniem odpowiedzi z serwera. W ten sposób: graczowi będzie się wydawało, że ruch jest płynny, a jego faktyczny ruch (ten, śledzony przez serwer i wysyłany innym graczom) będzie zależny od jego opóźnienia do serwera.

 

Większość gier multiplayer tak robi (chyba najbardziej znana, jaką mogę wymienić: world of warcraft) - co prawda, jeśli użytkownik ma problem z łączem, może sobie "chodzić" po świecie i nagle (gdy odzyska normalne połączenie) obudzić się gdzie indziej, lub nawet obudzić się z martwą postacią Możesz również synchronizować faktyczną pozycję klienta z serwerem co jakiś czas, żeby uniknąć sytuacji, w której klient wyprzedził o kilkanaście sekund serwer w ruchu. Mam nadzieję, że nic nie zamotałem

 

1. Myślałem, ale na razie pozostaje przy swojej koncepcji.

2. No fajna uwaga, przemyślę.

 

Najlepiej, w przypadku gier stosować tzw grubego klienta, czyli większość logiki trzymać po stronie aplikacji klienckiej, regularnie wysyłać dane do serwera w celu weryfikacji. Upraszczasz w tym momencie całą komunikację, gracz nie widzi, lub w większości przypadków nie jest świadomy występowania tzw. laga, przy większej ilości graczy serwer nie jest aż tak obciążony jak w przypadku innych rozwiązań.

 

Kolejna sprawa to używanie POST przy każdej akcji. Coś takiego możesz sobie robić w grze na kilka(naście) osób online. Jeśli będziesz chciał mieć większą grupę graczy to weź pod uwagę wydajność. Czym obsługujesz tego POSTa po stronie serwera? Jakiś PHP? Tego się nie robi w ten sposób, to dobre dla gierek w których nie ma dynamicznej akcji, gdzie tak naprawdę nie zależy na czasie. Samo PHP to już ogromny narzut operacji, dodatkowo debugowanie PHP to ... no właśnie, jakie debugowanie? Obsługą akcji graczy powinien zajmować się dedykowany proces po stronie serwera, najlepiej jeśli wszystko oprzesz o sockety, będziesz miał wtedy 2-kierunkową komunikację klient serwer, da Ci to np. możliwość wysyłania do gracza informacji o zdarzeniach.

 

Najlepsze imho rozwiązanie na dzien dzisiejszy to: klient jako aplikacja flash/java uruchamiana w oknie przeglądarki, serwer jako proces javy.

 

Jeśli będziesz miał jakieś pytania odnośnie samej javy lub rozwiązań które opisałem, zapraszam na PM. Sam w tym momencie tworzę grę przeglądarkową i jakiś czas temu miałem właśnie dylemat, jaką technologię wybrać.

 

 

Myślę, że jakiś dobry serwerek ze 100 osób może utrzyma, wszystko wyjdzie w praniu. Zobaczymy. Na razie "Work in progress"

[FrozenShade 18]

100 osób? Zapraszam Cię do mnie na testy, wszystko pisane w tej technologii o której mówiłem, przewidziane na tysiące osób. Testuje to teraz ok 50 osób, zużycie procka na głównym procesie to ok 15 sekund na dobę, na bazie danych niewiele więcej. Procesor 1GHz, platforma HP 5720.

 

Zanim napiszesz za dużo, to rozpatrz inne technologe.

[Utilaft 14]

Chodziło mi raczej, o 100 osób na moim skrypcie

[FrozenShade 18]

Wiem, dlatego póki nie rozpędziłeś się za bardzo ze swoim pomysłem, to chcę Ci pokazać być może lepsze rozwiązanie. Bo chyba lepiej, gdy zamiast 100 osób serwer udźwignie tysiące, lub żeby utrzymać 100 osób kupisz kilkukrotnie tańszą maszynę.

[Utilaft 14]

Ok, a mogą mi jakieś doświadczone osoby, opowiedzieć o serwerze a mianowicie..

 

Kilka/naście/dziesiąt/set ? zapytań na sekundę.

 

Update do mysql co 32px , sprawdzanie kolizji z mysql przy tym.

 

Sprawdzanie pozycji innych Graczy itp.

 

Jaki serwer by mógł to uciągnąć? Dajmy na to 100 Graczy.

 

Tzn. procesor, ram, i inne tam.

 

[FrozenShade 18]

Za mało informacji. Co to jest 'sprawdzanie kolizji z mysql' ?

Jak rozumiem, chcesz sprawdzić, czy dana postać nie zaryła w ścianę? Jak będzie wyglądało zapytanie sprawdzające kolizję? ile obiektów (ścian) przewidujesz? czy sprawdzenie kolizji będzie odpytaniem jednej tabeli? czy może będzie to jakiś widok po większej ilości tabel? jak często będą się pojawiały takie zapytania, 32 pix to nie jednostka czasu

 

Najlepszy sposób to wynająć najtańszy vps, zatrudnić 20 kolegów na wieczorne testy i kazać im klikać. Albo napisz sobie mały programik, który będzie symulował komendy wydawane przez gracza, np będzie chodził po mapie. odpal 100 instancji podłączonych do serwera, sprawdzaj obciążenie i wydajność skryptów. W miarę zwiększania się ilości obiektów w bazie (ścian do kolizji) będzie ci potrzebna coraz mocniejsza maszynka.

 

Tak na marginesie, kolizji nie liczy się zapytaniem do bazy danych, do tego powinieneś mieć dedykowany kawałek kodu. Bo jak ci dojdzie jeszcze n sprawdzań innych rzeczy co daną jednostkę czasu to zamęczysz bazę albo bardzo szybko kupisz sobie jakiegoś mocnego dedyka.

[Utilaft 14]

Każda mapa będzie miała budynki, drzewa itp. Jeden krok gracza = 32px. No i w bazie w tabeli mapy chciałbym mieć kolumne "kolizje" no i tam po przecinku np. 500 kolizji na mapie.

 

Jedno zapytanie na np. kolizje, zapisać to do jakiejś tablicy, a potem sprawdzać ifem.

Edytowano Kwiecień 25, 2013 przez Utilaft (zobacz historię edycji)

[FrozenShade 18]

Zaraz, nie rozumiem......

Pokaż jakąś przykładową tabelę z wartościami po których chcesz sprawdzać kolizje.

I jak można zapisać zapytanie do tablicy?