gre w C++ udostępnić via internet

0

Cześć. Chciałem się zapytać o taką rzecz. Załóżmy, że ktoś stworzył grę w C++ - prosta gierka ale fajna. Teraz chciałby, żeby można było ją jakoś udostępnić, bez możliwości pobrania jej - najlepiej poprzez wrzucenie na serwer i umożliwienie grę przez internet. Czy to jest możliwe bez ingerencji w kod? Czy gry napisane w C++ w ogóle można jakoś napisać, by działały z serwera?
Jeśli grę trzeba zmodyfikować to jak to najlepiej zrobić?

1

Czyli ktoś napisał grę, ale nie chce nawet dać pliku *.exe?
imho, jeżeli już ma być hostowana, to lepiej byłoby od początku napisać ją w np.PHP i JavaScripcie, aczkolwiek Twój problem nie jest nierozwiązywalny.
Należałoby "po prostu" uruchomić ten plik *.exe na serwerze (do tego nie wystarczy bynajmniej zwykły hosting, tylko potrzeba dodatkowy serwer, na którym te aplikacje będą uruchamiane) oraz przekierowywać input/output do danego klienta poprzez np.JavaScript i PHP.
Ciężko powiedzieć coś dokładniej, ponieważ nie wiemy nawet w jaki sposób działa ta aplikacja (czy wymaga np.interakcji myszki, czy działa wyłącznie w konsoli itd.).

0

jeśli gra działa w konsoli i nie używa biblioteki curses, to względnie łatwo można by bez ingerencji w kodzie to zrobić. jeżeli używasz jakiejś biblioteki graficznej (napisz jakiej) to może być bardzo duży problem...

0

No właśnie problem jest taki, że gra polega głównie na operowaniu myszką :/
Biblioteka to SFML
a pliku exe nie chcę udostępniać z nadzieją, że grę można byłoby w przyszłości sprzedawać za drobniaki :D

0

Rozumiem, że brak odzewu oznacza, że będzie ciężko? ^^

0

bez ingerencji w kodzie (albo z niewielką) to można by napisać w js na socketach napisać klienta serwera X. no i oczywiście bez serwera dedykowanego się nie obejdzie. to gra nie warta świeczki... przynajmniej dla takiej prostej gry.

0

Nie łatwiej będzie później trochę powycinać i zrobić z tego demo ?

0
Inquis1t0r napisał(a):

Nie łatwiej będzie później trochę powycinać i zrobić z tego demo ?

No właśnie ta upubliczniona wersja ma być okrojona :). A jak się komuś by spodobało to mógłby wykupić dostęp do pełnej wersji - bardziej zaawansowanej :)

A tak swoją drogą, rozważając możliwość większych zmian w kodzie to jakbyście do tego podeszli?
Nie chce mi się tego wszystkiego przerzucać do PHP/JS :(

0

w ogóle byśmy to tego nie podeszli bo to z założenia głupi pomysł.
po prostu zrób demo i udostępnij binarkę tego dema, tak jak wszyscy producenci gier to robią. w ostateczności niech gra wymaga połączenia z internetem i łączy się z twoim serwerem skąd pobiera jakieś niezbędne dane. wyłączysz serwer - wyłączysz dostęp do gry. oczywiście nie jest to rozwiązanie w 100% odporne na crackerów, ale jest względnie dobrym kompromisem między wydajnością działania gry, zabezpieczeniami i wygodą użytkowania.

0
dawidgarus napisał(a):

w ogóle byśmy to tego nie podeszli bo to z założenia głupi pomysł.
po prostu zrób demo i udostępnij binarkę tego dema, tak jak wszyscy producenci gier to robią. w ostateczności niech gra wymaga połączenia z internetem i łączy się z twoim serwerem skąd pobiera jakieś niezbędne dane. wyłączysz serwer - wyłączysz dostęp do gry. oczywiście nie jest to rozwiązanie w 100% odporne na crackerów, ale jest względnie dobrym kompromisem między wydajnością działania gry, zabezpieczeniami i wygodą użytkowania.

No właśnie podobną opcję z połączeniem on-line również rozważałem i działałoby to na takiej zasadzie (jak możecie to oceńcie):

  1. Użytkownik ściągałby całą wersję programu, ale do dyspozycji miałby tylko wersję demo - pozostałe opcje byłyby zablokowane/nieaktywne.
  2. Gra na demo nie wymagałaby połączenia z internetem - byłaby ogólnie dostępna.
  3. Na serwerze zrobiłbym sobie bazę danych w której zapisywałbym różne informacje o użytkownika o czym szerzej za chwilę.
  4. W przypadku wykupienia gry użytkownik pobierałby "kod aktywacyjny", który musiałby wpisać w pewnym, przeznaczonym do tego, miejscu w grze, który by zapisał go gdzieś na później.
    4a. Zamiast powyższej opcji jeszcze coś chodzi mi po głowie ale nie mogę do tego dojść :/
  5. Gdy klucz/kod zostałby wprowadzony program by go zapisał w swojej pamięci i odblokowałby pozostałe opcje gry.
  6. W przypadku wciśnięcia "play" program wysyłałby na serwer podstawowe informacje o użytkowniku, szczególnie numer IP, czas kiedy gra jest włączana etc. w celu zbadania czy gra/kod aktywacyjny nie została bezprawnie udostępniona innej osobie - co byłoby zabronione a konsekwencją byłby ban ("licencja" byłaby udostępniana tylko jednej osobie - bez możliwości przekazywania kodu innym użytkownikom). Gdyby gra działałaby w tym samym czasie na dwóch różnych adresach IP to oznaczałoby, że klucz został przekazany dalej a użytkownik złamał warunki umowy co skutkuje zablokowaniem klucza.
    Przy wciśnięciu start program sprawdzałby również również czy wprowadzony kod nie został zablokowany (ta informacja byłaby zapisana na serwerze) - jeśli tak dodatkowe opcje byłyby ponownie blokowane.

Co o tym myślicie?
Jak to ewentualnie można rozszerzyć?
pozdrawiam

0

Zabezpieczenia niczym w Diablo 3, a czy twoja gra jest warta tej świeczki?

0
stalk3r napisał(a):

Zabezpieczenia niczym w Diablo 3, a czy twoja gra jest warta tej świeczki?

Jakie zabezpieczenia? Od kiedy model SaaS sam w sobie jest zabezpieczeniem? Po prostu gra działa jako aplikacja cloudowa, ale to duża inwestycja.

0

Naprawdę myślicie, że to dużo roboty? Nigdy czegoś takiego nie robiłem więc musiałbym to jeszcze technicznie przemyśleć, ale wydawało mi się, że nie jest to takie znowu trudne.
Poza tym to chyba lepsze niż przepisywać całą grę na inny język :/
Pominę już fakt, że PHP nie trawię a JS nie umiem praktycznie wcale.

0

Nie wiem, jak jest w tym przypadku, ale moim zdaniem w prawidłowo napisanej aplikacji są osobne klasy odpowiedzialne za główny program, czyli przebieg gry, punkty, zdarzenia itd. i osobne klasy implementujące interfejs i obsługę interfejsu.

Najlepiej utworzyć nowy projekt C++ i do niego od początku napisać komunikację przez sockety, klasy odpowiedzialne za grę po prostu przekopiować. Możliwe, że będą konieczne drobne modyfikacje kodu jądra gry w zakresie komunikacji i interakcji z interfejsem. Serwer gry powinien przewidywać kilka niezależnych sesji gry w osobnych wątkach, czyli np. uruchamianie osobnego jądra przy każdym nowym połączeniu.

Potem są dwa sposoby, jeśli chodzi o udostępnienie gry.

Sposób pierwszy:
Aplikacja internetowa uruchomiona na serwerze, łączy się z programem w C++ i generuje stronę na podstawie przebiegu gry.

Sposób drugi:
Na stronie internetowej byłaby aplikacja uruchamiana po stronie klienta (aplet javy, flash, silverlight itp.), która łączyłaby się z serwerem gry i potem przyjmowałaby czynności od użytkownika oraz wyświetlałaby interfejs gry.

Sposób trzeci:
Niech Twoja aplikacja zachowuje się jak serwer HTTP (przyjmuje i generuje komunikaty HTTP i dokumenty HTML), sposób nie jest pewny co do stabilności, bo wymaga przewidzenia wszystkich sytuacji (różne przeglądarki, duża ilość połączeń, poprawność generowania i interpretowania komunikatów).

We wszystkich przypadkach, gry nie będące czasu rzeczywistego (np. szachy, bilard, reversi) będą działać. Natomiast z grami czasu rzeczywistego (np. platformówki, bijatyki, wyścigi) może być problem ze względu na opóźnienia na łączach.

1 użytkowników online, w tym zalogowanych: 0, gości: 1