Skocz do zawartości

39dll - identyfikacja i usuwanie obiektów


Jeremiah

Rekomendowane odpowiedzi

Ogarniam sobie 39dll i w ramach tego majstruję małą gierkę. Z góry schodzą przeciwnicy i rzucają piłeczkami w postacie graczy. Generalnie ruch postaci, botów i pocisków ogarnąłem. Przy graczach wysyłam co stepa info o pozycjach x i y, przy pociskach i botach informacja jest wysyłana tylko raz z serwera do klienta - z informacjami na temat początkowych pozycji x, y oraz speed i direction. Generalnie raczej działało cacy i nie było problemów.

 

Problemy mam, kiedy dochodzi do trafienia bota przez pocisk gracza. Czasem działa poprawnie, ale cóż... raz na jakiś czas zdarzy się, że klient będzie widział tylko pocisk "przyklejony" do przeciwnika i obydwa nie raczą się usunąć z mapy.

 

Dobra, a teraz jak to wygląda technicznie.

 

 

Obiekt: bot; event: kolizja z pociskiem

 

if global.host

{

with (other) instance_destroy()

clearbuffer()

writebyte(13)

writeint(id)

sendmessage(global.otherplayer)

instance_destroy()

}

 

 

Obiekt: pocisk; event: destroy

 

if global.host

{

clearbuffer()

writebyte(9)

writeint(id)

sendmessage(global.otherplayer)

}

 

 

Obiekt: gracz 2; event: step

 

case 9:

var delette;

delette=readint()

with (delette) instance_destroy()

break;

 

Co do case 13 to tak samo to wygląda. Z początku we wszystkich usuwanych obiektach wysyłało 9, ale szukając rozwiązania dodałem dodatkowe, sądząc, że być może po prostu za dużo tego wysyła czy coś.

Tak to wygląda, ma ktoś jakiś pomysł, radę? Przypomnę, że czasem pocisk i bot nie usuną się po kolizji na ekranie klienta.

Odnośnik do komentarza
Udostępnij na innych stronach

1. używaj tagu [.gml] [./gml]

2. 39dll jest przebrzydle archaiczny, a co więcej strasznie oporny, bardziej niż jest tego wart. Jak już musisz korzystać z third party spróbuj użyć faucet networking.

 

Wiem, że to nie rozwiązuje Twojego problemu, ale nie wart się męczyć dla 39dll.

 

 

A propos problemu:

id jest unikalne i to że u obu graczy równo wytworzy pocisk nie znaczy że u obu instancja będzie miała to samo id.

Stwórz sobie jakieś własne id dla obiektów, nadawaj im je i informuj gracza, że kiedy tworzy dany obiekt to ma mu nadać właśnie takie id. Kiedy usuwa obiekt niech również wysyła to id i niech na jego podstawie usuwa obiekty u klienta.

Odnośnik do komentarza
Udostępnij na innych stronach

Ogarnę kiedyś ten faucet networking, bo ten 39dlll chyba faktycznie do niczego się nie nadaje.

 

Po przypisaniu własnych id problem nie zniknął choć jest trochę rzadszy. Z jakichś powodów czasem obiekt zamiast się usunąć przyklei się do celu i tak sobie do ciężkiej cholery tkwią... mam wrażenie, że cały wysiłek na marne idzie.

 

Co może być jeszcze przyczyną? To, że w roomie jest do kilkudziesięciu obiektów naraz? Tylko pozycje x i y postaci graczy wysyłane są co step, WSZYSTKIE inne wysyłane są wyłącznie w momencie tworzenia. Mnie zaraz szlag z tym trafi.

Odnośnik do komentarza
Udostępnij na innych stronach

O ile master nadaje ID, a wysylajac informacje o zrobieniu obiektu wysyla dokladnie takie samo ID, aby klient je sobie ustawil, nie powinno byc problemu.

 

Ale jezeli oddzielnie ustawiasz ID u serwera i klienta to to sie mija z celem ustawiania tego ID.

 

Edit: Lub tracisz pakiety z jakiegos powodu ;v

Odnośnik do komentarza
Udostępnij na innych stronach

O ile master nadaje ID, a wysylajac informacje o zrobieniu obiektu wysyla dokladnie takie samo ID, aby klient je sobie ustawil, nie powinno byc problemu.

No tak mam zrobione. WSZYSTKIE obiekty tworzone są przez serwer, serwer nadaje im ID i wysyła do klienta. Podczas testów wyświetlam sobie przy obiektach ich id i jego nadawanie działa poprawnie :/

 

Nie wiem co jeszcze może być nie tak. Pewnie po prostu jak jest 10 lub więcej obiektów na ekranie to 39dll nie wyrabia. Na to gubienie pakietów można jakoś poradzić?

Odnośnik do komentarza
Udostępnij na innych stronach

Ogarnąłem tamto jakoś. Teraz problem to lagi XD

 

Co step wysyłam pozycje x i y postaci graczy. W dodatku serwer wysyła w ciągu sekundy około kilkunastu informacji z pozycjami x, y, a czasem speed i direction tworzonych w grze obiektów. Czy tak monstrualne rozmiary informacji mogą być przyczyną tego, że gra laguje?

 

Na localu działa ok. Przekierowywałem porty, wyłączałem jakieś pierdoły, hamachi i takie tam. Wątpię, by to była wina routera, jeśli z gościem, z którym gram w o wiele bardziej wymagające gry bez lagów ten dziwaczny problem występował.

Odnośnik do komentarza
Udostępnij na innych stronach

Cóż, to wiele tłumaczy. Spróbuję jeszcze jednej sztuczki, a jeśli nie pomoże to niestety, będę musiał porzucić projektu. Pozycje postaci muszą być jednak aktualizowane dość często ;/ chyba, że jest jakiś sposób, żeby zachować płynność ruchów graczy, którzy dynamicznie zmieniają swoją pozycję? I czy ten faucet networking byłby tutaj lepszy?

 

Jedno mnie tylko dziwi - dlaczego praktycznie we wszystkich tutorialach autorzy wysyłają coś co step?

 

Edit: a jak to wygląda z tymi nowymi funkcjami do tworzenia gier sieciowych, które zawarto w Studio?

Odnośnik do komentarza
Udostępnij na innych stronach

podejscie gier AAA: wysylasz tylko akcje, np. wcisniecie/puszczenie klawisza ruchu, czy wlaczenie/wylaczenie jakiegos trybu, zas co jakis czas (np. sekund kilka) wysylasz bardzo malo, ale bardzo kluczowe elementu stanu gracza, jak aktualna pozycja, kierunek, czy rozne dynamicznie zmieniajace sie statusy, aby lag, czy nie odebrany pakiet (zdarzaja sie) nie zepsul w kliencie flow gry. jeszcze lepiej, jak te rzadkie snapshoty stanu gracza beda dzielone na poszczegolne partie i wysylane w roznych odstepach czasu, miast w jednym wiekszym pakiecie.

Odnośnik do komentarza
Udostępnij na innych stronach

No właśnie przerabiam teraz kod tak, że pozycja gracza wysyłana będzie tylko po wciśnięciu klawiszy ruchu, a raz na jakiś czas (sekunda będzie ok?) wysyłać będzie dokładną pozycję x i y.

 

Tak prawdę powiedziawszy wydaje mi się to dziwną metodą na likwidację lagów. Nie siedziałem nigdy jeszcze w kodzie multi, więc może to normalne, a tylko mi wydaje się dziwne.

 

Hipotetyczna sytuacja. Czy wysyłane co step info o pozycji obiektu tak samo obciąża serw co tworzenie co step jakiegoś obiektu, na przykład pocisku?

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...