Autor Wątek: Gra sieciowa  (Przeczytany 1465 razy)

Offline .Dexter.

  • Użytkownik

# Październik 10, 2011, 22:23:23
Piszę sobie gierkę (dots&boxes) i pomyślałem, że fajnie byłoby dodać możliwość gry przez sieć. Nie bardzo jestem w temacie jeśli chodzi o praktykę programowania sieciowego, dlatego chciałem spytać o kilka rzeczy. Mianowicie jak to tak ogólnie rozwiązać? Myślałem nad tym, żeby nie pisać oddzielnej aplikacji serwera, tylko przy uruchamianiu wybrać czy chce się być klientem czy serwerem. Chciałbym zrobić to na gniazdku TCP, żeby uniknąć samodzielnego sprawdzania poprawności pakietów. Nie jestem pewny gdzie umieścić właściwe tworzenie socketów i łączenie klienta z serwerem, chyba przed pętlą główną gry, nie? W pętli tylko przesyłać pakiety po wciśnięciu guzika np. i odbierać co każdy obieg (?).
Nie jestem pewny jak ten kod zorganizować, dlatego jakby ktoś mógł podrzucić proste pomysły, byłbym wdzięczny. Jeśli ma to znaczenie to używam SFML to wyświetlania grafiki i do sieci też jak na razie.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline mwojt

  • Użytkownik

# Październik 11, 2011, 00:19:14
Wydaje mi się, że UDP pakiety docierają poprawne tylko jak wysyłasz ich więcej to mogą docierać w innej kolejności niż były wysłane lub mogą nie dotrzeć. Jak to gra na dwie osoby to każdy może być klientem i serwerem jednocześnie. Łączenie to raczej w pętli głównej, coś w rodzaju if (połączono) gra(); else próbuj_połączyć();

Offline bomkallo

  • Użytkownik

# Grudzień 28, 2011, 18:00:35
UDP jak dotrze to zawsze poprawne i w calosci. Gorzej, ze sie potrafi duplikowac, gubic, kolejnosc etc. Wiec dobry pomysl z tcp, bo bys musial zrobic praktycznie to samo od nowa.
A schemat...
1. Wpierw gra identyfikuje sie, czy hostuje czy sie laczy.
2. Jak hostuje - tworzymy baze pod nasluch na porcie, jednoczesnie flagujac cala gre, zeby dzialala jako server. Dodatkowo trzeba miec na uwadze, ze obslugujemy sami siebie, dlatego ja lubie server jako osobna machine.
3. Klient - musi wiedziec gdzie sie podlaczyc i co wstepnie wyslac, zeby nawiazac jakas ustalona forme komunikacji/autoryzacji.
4. Tcp, poczytaj o enkapsulacji i innych metodach przesylu informacji, chyba ze wystarczy ci czysty tekst.
Odbierajac informacje w formie jakichs 'sygnalow', musisz miec na uwadze, ze nie wszystko uda ci sie od razu odebrac i w tym miejscu musisz to obslugiwac. Przykladem moze byc fragment wiadomosci od klienta, ktory nijak nie bedzie mogl byc obsluzony do momentu pelnego otrzymania.
5. Nie mozesz blokowac petli, wiec select z socketow albo watki. Beej's networking programming ladnie  opisuje istote sieci.
6. Petla gry, gdzie wszystko sie dzieje powinna zawierac odbiornik pakietow i jakas metode ich interpretacji.
Anyway, chcialem to prosto opisac, ale jak widac co chwila mozna dodac cos nowego:P
W kazdym razie powodzenia.

PS: gre trzeba pisac z nastawieniem na siec, bo potem moze byc ciezko ja dostosowac.



# Grudzień 28, 2011, 18:20:05
Najlepiej zdobyć konto na uczelnianym serwerze i tam uruchomić aplikację. Oni raczej powinni mieć globalne IP, niezagospodarowaną moc, i dobrą przepustowość. Sam testowałem i nie było źle.

Dlatego serwer najlepiej pisać z myślą o Unix,ale nie ignorować Windowsa.
Z tym że chyba w funkcja "Select()" Działa na Unixie nieco inaczej niż na Win - chodzi o czas oczekiwania

No i najlepiej projektować od razu kod nieliniowy z myślą o wielowątkowości, chyba że OpenCL,OpenMP.