Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[c++] System Rozproszony, Gra sieciowa

Templarious 04 Lis 2013 15:57 2079 17
  • #1 04 Lis 2013 15:57
    Templarious
    Poziom 22  

    Witam Serdecznie,

    Tematem mojej projektu jest:

    Zrealizować rozproszoną grę sieciową o następującej funkcjonalności. Dany jest świat w postaci czterech tablic NxN zawierających mapę danej części, połączonych szeregowo i zapętlonych. Na mapie mogą wystąpić dwa rodzaje terenu: wolna przestrzeń i zabudowa. Z każdej części świata pochodzi jedna istota, która może się poruszać we wszystkich jego częściach startując w części macierzystej. Napisać 4 programy implementujące poszczególne części świata i sterujące poszczególnymi istotami przy następujących założeniach:
     Ruch możliwy jest wyłącznie w wolnej przestrzeni.
     Przejścia między częściami świata są możliwe o ile przystają do siebie wolnymi przestrzeniami.
     W jednym z pól jednego świata ukryty jest skarb. Wygrywa ten kto go znajdzie.
     Każda istota ma kompas pokazujący kierunek do skarbu.
     Część wolnych pól jest losowo zaminowana
     Wejście na minę eliminuje gracza.
     Użytkownik programu sterującego daną częścią świata widzi:
     Stan poszczególnych części (w tym pozycje istot innych graczy) ale ograniczony jedynie do obszarów odwiedzonych przez jego istotę. Pozostałe obszary są niewidoczne. Za część odwiedzoną należy przyjąć pole, na którym znalazła się istota oraz jej najbliższe sąsiedztwo.
     W odwiedzonym wolnym polu widoczna jest liczba min otaczających to pole (jak w grze Saper)

    Projekt przeznaczony jest dla 4 podzespołów 1-osobowych. Każdy podzespół implementuje środowisko w innym języku programowana/środowisku:
     C++ platformie Windows ---> ja na tym robie
     Java
     C#
     C++ na platformie Unix lub Python
    Mechanizm komunikacji sieciowej: dowolny

    Jestem osobą która zna dosyć dobrze język c++, umiem sobie radzić z różnymi zagadnieniami, ale nigdy nie używałem komunikacji TCP/IP w c++.
    Nie wiem w sumie jak się nawet za coś takiego zabrać. Każda podpowiedź będzie dla mnie ważnym elementem, który pozwoli mi wykonać takową grę.

    Pozdrawiam

    0 17
  • #2 05 Lis 2013 03:59
    McMonster
    Poziom 32  

    Templarious napisał:
    Jestem osobą która zna dosyć dobrze język c++, umiem sobie radzić z różnymi zagadnieniami, ale nigdy nie używałem komunikacji TCP/IP w c++.
    Nie wiem w sumie jak się nawet za coś takiego zabrać. Każda podpowiedź będzie dla mnie ważnym elementem, który pozwoli mi wykonać takową grę.


    TCP/IP to sprawa prosta jak budowa cepa, gdzie tu problem? Chyba, że nie ustaliliście między sobą protokołu i algorytmów, wtedy nigdy tego nie uruchomicie i tak.

    0
  • #3 05 Lis 2013 09:38
    Templarious
    Poziom 22  

    Jeszcze nic nie ustaliliśmy. Mamy czas do lutego.
    Chciałbym zabrać się za to już teraz, napisać grę, a TCP/IP zostawić na koniec.

    Chciałbym jakieś wskazówki, które faktycznie naprowadzą mnie na właściwy tor myślenia. JAk np. obsłuzyć klawisze ? A może zrobić gre turową ?

    0
  • #4 05 Lis 2013 10:19
    mi14chal
    Poziom 27  

    Żeby obsługiwać klawisze najpierw pasuje żebyś wybrał odpowiednią bibliotekę w której chcesz korzystać przy pisaniu gry np.: http://www.sfml-dev.org/ i masz od razu obsługę grafiki i sieci, wszystko w jednym miejscu.

    0
  • #5 05 Lis 2013 12:51
    Szymon Tarnowski
    Poziom 27  

    Skoro to praca zespołowa to czemu jeden zespół nie podejmie się zadania napisania biblioteki którą wykorzystają pozostałe? Wydaje mi się że najwiekszym problemem w tej grze będzie właśnie wymiana danych i komunikatów, wszystko pozostałe to kilka tablicy wypełnionych wartościami.

    0
  • #6 05 Lis 2013 16:25
    Templarious
    Poziom 22  

    Dziękuję za zainteresowanie tematem.

    Tylko jak napisać własną bibliotekę skoro... każdy prawie ma inny język programowania ?

    Myslałem szczerze, aby napisać własnie z uzyciem jakiejś gotowej biblioteki, a przy wymianie danych np. ustalić, że zmienna taka i taka odpowiada za to i za to.

    A obsługa klawiszy?

    0
  • #7 05 Lis 2013 16:27
    mi14chal
    Poziom 27  

    Templarious napisał:
    A obsługa klawiszy?


    SFML nie odpowiada? To może WinAPI?

    0
  • #8 05 Lis 2013 16:38
    Templarious
    Poziom 22  

    mi14chal napisał:
    Templarious napisał:
    A obsługa klawiszy?


    SFML nie odpowiada? To może WinAPI?


    Nie sądziłem, że sfml ma to wszystko. Ok, wybieram jego. Widze też, że ma obsługe tcp itd, grafika, wszystko fajnie. Na co powinienem zwrócic sczególną uwagę pisząc taką gre ?

    0
  • #9 05 Lis 2013 16:59
    mi14chal
    Poziom 27  

    Na to żeby pisać kod bez błędów, ciężko powiedzieć na co, wszystko jest równie ważne jak każdy inny element w grze.

    0
  • #10 05 Lis 2013 19:02
    McMonster
    Poziom 32  

    Templarious napisał:
    Jeszcze nic nie ustaliliśmy. Mamy czas do lutego.

    No to czas najwyższy zacząć coś ustalać. Jak zaczniecie najpierw pisać, a pod koniec to sklejać, to skończycie w ciemnej... Byłem, widziałem. ;-] Szczególnie, jeśli koledzy nie mają pojęcia o pracy zespołowej. Musicie na starcie ustalić szczegółowo logikę całego systemu i protokół komunikacji, a potem każdy wg tych ustaleń ma to sam implementować. Jeśli zrobicie na odwrót, to daję wam gwarancję, że któryś z was będzie "wiedział lepiej", zrobi po swojemu i reszta będzie zmuszona na gwałt się dostosować.

    Sama obsługa TCP jest prosta jak but. Na najniższym poziomie warto ją wyrzucić do osobnego wątku z dwoma kolejkami do odbioru i wysyłania danych, koniecznie w implementacji bezpiecznej dla wielowątkowości. Główny wątek aplikacji będzie implementował logikę systemu w oparciu o komunikację.

    0
  • #13 23 Lis 2013 00:11
    Szymon Tarnowski
    Poziom 27  

    Przejrzałem specyfikację i jedyne co mam zastrzeżenie to ten kompas. W przypadku zapętlonych przestrzeni nie da się określić jednego właściwego kierunku "do skarbu", bo jest nieskończenie wiele prawidłowych kierunków prowadzących do skarbu. Wydaje mi się że nawet może dojść do sytuacji kiedy więcej niż jeden kierunek posiada minimalną odległość.

    Można by się też pokusić o użycie multicastu do komunikacji, albo chociaż multicastu do "dowiedzenia" się o adresach IP klientów i wtedy nawiązać połączenia unicastowe.

    0
  • #14 23 Lis 2013 13:54
    McMonster
    Poziom 32  

    Kilka uwag:

    * Do lutego jest mało czasu, poganianie miałoby efekt tylko negatywny, ale musicie sobie zdawać z tego sprawę.
    * Zbadaliście praktyczne użycie CORBA, czy tylko wybraliście, bo definicja brzmi nieźle?
    * Konstrukcja świata gry to wasz pomysł, czy odgórne założenie? Składając mapę z czterech ćwiartek prostokątnego obszaru potencjalnie może uprościć system. Zastanowiliście się nad wizualizacją tego?
    * Brak zdefiniowanego zachowania przy przejściu między światami.
    * Mieszacie pojęcie gracza i świata macierzystego, możecie mieć problem z rozumieniem siebie nawzajem.
    * Warunek istnienia drogi do skarbu może być trudny do zaimplementowania, szczególnie w rozproszonym systemie przy zapętlonych mapach zignorowałbym to.
    * Brak zdefiniowanych informacji o wyglądzie świata, które pola są widoczne na starcie i jak powiadamiane są systemy poszczególnych graczy o jego szczegółach.

    Jak mi coś więcej przyjdzie do głowy, to napiszę.

    0
  • #15 24 Lis 2013 00:25
    Templarious
    Poziom 22  

    Nie wiem jak CORBA.. nie znam tego w ogole.
    Jeżeli chodzi o to czy się wyrobimy, wątpie. Osoby z mojej grupy wzięły się za pisanie tego koło 23.. także nie wróże dobrej pracy.

    Sam nie mam pojęcia jak się do tego zabrać, ale jezeli chodzi o wizualizację tego - dowolna jest.
    Pola widoczne są zrealizowane na zasadzie pomieszania gry Saper oraz Diablo... czyli odkrywamy mapę i pokazane są otaczające na odlegołosci od miny.
    Przejscie pomiędzy światami: system sprawdza czy można przejsć czy też nie. (zajęte pole w macierzy bądź nie).

    To jest jeden z 7 projektów na politechnice, po prostu nie wiem jak ja mam dać rade :/. Mam tez napisac adaptacyjny koder/dekoder Huffmana, inteligentny program do rozmowy na wybrany temat i wiele wiele innych. -- Chyba coś nie tak jest ? za duże to obciążenie.

    0
  • #16 24 Lis 2013 00:44
    McMonster
    Poziom 32  

    Templarious napisał:
    Nie wiem jak CORBA.. nie znam tego w ogole.
    Jeżeli chodzi o to czy się wyrobimy, wątpie. Osoby z mojej grupy wzięły się za pisanie tego koło 23.. także nie wróże dobrej pracy.

    Sam nie mam pojęcia jak się do tego zabrać, ale jezeli chodzi o wizualizację tego - dowolna jest.
    Pola widoczne są zrealizowane na zasadzie pomieszania gry Saper oraz Diablo... czyli odkrywamy mapę i pokazane są otaczające na odlegołosci od miny.
    Przejscie pomiędzy światami: system sprawdza czy można przejsć czy też nie. (zajęte pole w macierzy bądź nie).

    To jest jeden z 7 projektów na politechnice, po prostu nie wiem jak ja mam dać rade :/. Mam tez napisac adaptacyjny koder/dekoder Huffmana, inteligentny program do rozmowy na wybrany temat i wiele wiele innych. -- Chyba coś nie tak jest ? za duże to obciążenie.

    Jak studenci sobie pościelili, tak teraz nie śpią, bo gonią projekty. Powszechna przypadłość uczelni wyższych, szczególnie "prestiżowych". Na moim wydziale pewien zakład pewnego semestru się zdziwił, bo nikt nie wybrał ich prestiżowej specjalności inżynierii oprogramowania. Bo zawalili tak studentów pracą, że ci się zdenerwowali i odpowiednio zareklamowali specjalność.

    Co oznacza "system sprawdza"? Który świat sprawdza, który informuje inne? Takie rzeczy trzeba szczegółowo ustalać przed implementacją, bo potem się okaże, że np. sklonuje się gracz, albo zniknie. A wizualizacja innych światów jak przebiega? Wymiana danych plansz z góry, czy po polu w miarę odkrywania?

    To CORBA niech ktoś z was zbada, tj. spróbuje użyć w praktyce i upewnić się, że we wszystkich czterech przypadkach się da na jakichś prostych programikach testowych. Albo darujcie sobie modne technologie i napiszcie własny i prosty protokół oparty o sockety i binarne wiadomości. Zacznijcie od rozrysowania sobie schematów komunikacji, jakie zachodzą, np. w formie diagramu stanów i na tej podstawie łatwo będzie określić jakie komunikaty i jakie dane do nich są rozsyłane. Ustalcie prosty schemat kodowania tego i dopiero implementujcie.

    Ten projekt by był znośny, gdyby cztery osoby pracowały nad jedną aplikacją rozproszoną i wspólną bazą kodu, pod warunkiem odpowiedniego podziału ról.

    0
  • #17 25 Lis 2013 10:40
    kradam
    Poziom 14  

    To dość złożone zadanie, mają pracować ze sobą cztery różne aplikacje, cztery różne osoby. Wynika z tego, ze trzeba to zrobić zgodnie ze sztuką inżynierii oprogramowania. Po to ją właśnie wymyślona, próba zrobienia tego po partyzancku skończy się kłótnią i zawaleniem projektu. Na 99%.
    Konkretnie najpierw należy spisać precyzyjnie wymagania, czyli jak ta gra ma działać ale bez wchodzenia w szczegóły technicznej implementacji. Sam zobacz ile uwag do niejasnych wymagań zgłoszono poniżej. Dopiero jak to zamkniecie można przejść dalej, do projektu. Tu pierwsza rzecz jaka mi się nasuwa, to decyzja odnośnie architektury. Z lektury wnioskuję, że ma to być czyste peer to peer. Z reguły prościej tego rzeczy robi się w konwencji master - slaves. Przy p2p będziesz miał 4*(4-1) kanałów komunikacji, przy m/s tylko 4. Ja bym negocjował z prowadzącym przedmiot możliwość, aby jedna z osób napisała mastera a reszta slave'y. Jak już to ustalicie to pora zabrać się za protokół komunikacji (patrz McMonster), choć wcale bym się nie upierał przy binarce, czemu nie tekst? Debug będzie łatwiejszy no i nie będzie problemu z byte order. Jak już go opiszecie precyzyjnie, to można brać się za development. NIE WCZEŚNIEJ, powtarzając znów za McMonsterem.
    I tak będzie mnóstwo zgryzów, zastanówcie się jak będziecie integrować ze sobą aplikacje. Razem u kogoś, czy też przez net? Sporo czasu będzie potrzeba.

    Zostawcie pierdoły typu grafika, czy tez ten kompas. To bez większego znaczenia dla projektu, w razie konieczności negocjujcie z prowadzącym uproszczenie tego typu wymagań .Podejrzewam że nie po to dał wam ten projekt, aby uczyć was algorytmów trasowania geograficznego w przestrzeniach zapętlonych

    0