Gra via www a aplikacja mobilna

Cześć,

Jestem totalnym laikiem w kwestii programowania a pojawiam się tutaj ponieważ chciałbym to zmienić.

Mam swój pomysł na grę przez przeglądarkę i chciałbym do tej gry stworzyć również apkę mobilną. Pojawia się jednak dość istotne pytanie w jakich językach powinienem to zrobić?

Gry via www z tego co wiem pisane są w PHP/MySql ale czy może istnieje jakiś "lepszy" język do wykorzystania w tym celu? Czy później mając taka grę via www da się do niej napisać apke na androida i w jakim języku najlepiej to robić?

Prosiłbym Was o pomoc w dobraniu optymalnych narzędzi. Udzielając swoich odpowiedzi proszę napiszcie dlaczego akurat ten język i jeżeli macie jakieś kursy online do polecenia to tez chętnie przyjmę linki do nich (najfajniej byłoby gdyby były za free).

Z góry dziękuje za pomoc.

PS. Gdyby ktoś chciał pomoc w samym tworzeniu silnika to tez byłoby super.

PS2. W załącznikach dodałem zrzuty z gry podobnej do tej o której myślę.

Php to mozesz sillnik gry napisac ale potrzebujesz jeszcze klienta najlepiej w javascript/ajax/jquery/json

Biały Szczur napisał(a):

Php to mozesz sillnik gry napisac ale potrzebujesz jeszcze klienta najlepiej w javascript/ajax/jquery/json

Jeżeli chodzi o klienta to napisz coś więcej. Bo z tego co widzę w innych grach via www to nie mają klienta.

WAŻNE. Nie dodałem tego w pierwszym poście. Gra z założenia jest bez grafiki 2D/3D. To będzie gra fabularna tekstowa.

W PHP wystarczy, że napiszesz backend gry. Front najlepiej zrób w Unity. Potem sobie zbudujesz grę pod WebGL i pod Androida, czy iOS'a.

Spine napisał(a):

W PHP wystarczy, że napiszesz backend gry. Front najlepiej zrób w Unity. Potem sobie zbudujesz grę pod WebGL i pod Androida, czy iOS'a.

Czy potrzebne jest Unity skoro nie zakładam żadnej grafiki 2D/3D?

Update.
Popatrzyłem trochę na wygląd Uplink'a i mimo ze to w ogóle inna gra niż miałabyć moja fakt ładnego wyglądu jest sporym argumentem. Ale czy w takim razie da się to jakoś sensownie połączyć: gra via www + apka mobilna + taki właśnie wygląd?

Łukasz Walesiuk napisał(a):

Spine napisał(a):

W PHP wystarczy, że napiszesz backend gry. Front najlepiej zrób w Unity. Potem sobie zbudujesz grę pod WebGL i pod Androida, czy iOS'a.

Czy potrzebne jest Unity skoro nie zakładam żadnej grafiki 2D/3D?

Na pewno jest wygodne i przenośne między platformami. Chcesz mieć apkę mobilną i grę działającą na stronie. Dzięki Unity nie będziesz musiał rozwijać frontendu aplikacji webowej oraz aplikacji mobilnej. Wystarczy, że zrobisz build na odpowiednią platformę z Twojego projektu Unity.

Spine napisał(a):

Na pewno jest wygodne i przenośne między platformami. Chcesz mieć apkę mobilną i grę działającą na stronie. Dzięki Unity nie będziesz musiał rozwijać frontendu aplikacji webowej oraz aplikacji mobilnej. Wystarczy, że zrobisz build na odpowiednią platformę z Twojego projektu Unity.

Wiec do samego frontendu bez problemu mogę wykorzystać Unity. Silnik gry jest do napisania w PHP/MySql (czy polecacie jakieś free kursy?). No i apka mobilna w Javie, tak? (Znów prośba o polecenie kursów i narzędzi to tego)

To trochę nie tak... Apkę mobilną zbudujesz w Unity. Ale oprócz tego możesz w Unity zrobić builda WebGL (czyli gra osadzona w stronie internetowej, jak np. http://www.kongregate.com/games/JasonSpine/the-immortal-life-of-the-son-of-jay )

Możesz też napisać wszystko w C#. Serwer w ASP, a klienta na komórkę z użyciem Xamarin. Dzięki temu masz jeden język.

Juhas napisał(a):

Możesz też napisać wszystko w C#. Serwer w ASP, a klienta na komórkę z użyciem Xamarin. Dzięki temu masz jeden język.

Używając tego języka będę mógł osiągnąć takie same funkcjonalności jak w PHP?

Czy mając wykupiony serwer muszę "pisać" serwer?

Spine napisał(a):

To trochę nie tak... Apkę mobilną zbudujesz w Unity. Ale oprócz tego możesz w Unity zrobić builda WebGL (czyli gra osadzona w stronie internetowej, jak np. http://www.kongregate.com/games/JasonSpine/the-immortal-life-of-the-son-of-jay )

Które z tych rozwiązań będzie łatwiejsze? Szybsze?

Możesz też napisać front w js i wtedy appkę mobilną z tego samego kodu phonegapem.

Używając tego języka będę mógł osiągnąć takie same funkcjonalności jak w PHP?

W każdym języku programowania da się napisać wszystkie funkcje: https://pl.wikipedia.org/wiki/Kompletno%C5%9B%C4%87_Turinga

aurel napisał(a):

Możesz też napisać front w js i wtedy appkę mobilną z tego samego kodu phonegapem.

Używając tego języka będę mógł osiągnąć takie same funkcjonalności jak w PHP?

W każdym języku programowania da się napisać wszystkie funkcje: https://pl.wikipedia.org/wiki/Kompletno%C5%9B%C4%87_Turinga

Jeżeli front-end zrobię w JS to w jakim języku najlepiej pisać silnik (back-end?) tak żeby to wszystko się ładnie komunikowało?
I czy posiadając wykupiony hosting mogę to postawić na tym hostingu? Bo nie rozumiem co oznacza "napisać serwer" :(

Jeżeli front-end zrobię w JS to w jakim języku najlepiej pisać silnik (back-end?) tak żeby to wszystko się ładnie komunikowało?

Obojętne. Klient frontend komunikuje się z backendem po HTTP.

I czy posiadając wykupiony hosting mogę to postawić na tym hostingu? Bo nie rozumiem co oznacza "napisać serwer" :(

A rozumiesz, co to jest serwer? https://pl.wikipedia.org/wiki/Klient-serwer
W tym przykładzie: backend to serwer, frontend to klient.
Problem w tym, że twój backend to nie jedyny serwer w tej historii. Twój backend odbiera wiadomości twojego frontendu, ale musi je odebrać przez HTTP. A do tego musi stać na serwerze HTTP, który te zapytania przekaże do backendu. Tak samo frontend musi stać na serwerze HTTP, żeby wiadomości wysyłać. A ten serwer HTTP też stoi na serwerze, tzn. na fizycznej maszynie, której zasoby są ci udostępnianie (i tą usługę udostępniania ci zasobów nazywamy hostingiem).

Na większości hostingów masz już od razu zainstalowany serwer HTTP i możesz mieć ograniczone możliwości konfiguracji tego serwera. Są też hostingi, które po prostu dają ci dostęp do maszyny i róbta co chceta.
Na tanich, popularnych hostingach serwerem HTTP jest zazwyczaj Apache, co ogranicza twój wybór backendu do PHP. Jeśli już masz hosting, to na 99% masz tam Apache'a.
Ale są też dostępne serwery pod wszystkie inne technologie.

Ale tak generalnie, to w slangu raczej mówi się, że masz napisać backend, a nie serwer, właśnie dlatego, że serwer to bardzo ogólne pojęcie.

edit:
Trochę OT, ale przy tych dywagacjach o serwerach tu i tam, przypomniał mi się kultowy cytat, który warto sobie wbić w głowę dokładną analizą i zrozumieniem zagadnienia:

Warstwy! Cebula ma warstwy! Ogry mają warstwy! Cebula ma warstwy, dociera? – ogry mają warstwy… I SIECI TEŻ MAJĄ WARSTWY

aurel napisał(a):

Jeżeli front-end zrobię w JS to w jakim języku najlepiej pisać silnik (back-end?) tak żeby to wszystko się ładnie komunikowało?

Obojętne. Klient frontend komunikuje się z backendem po HTTP.

I czy posiadając wykupiony hosting mogę to postawić na tym hostingu? Bo nie rozumiem co oznacza "napisać serwer" :(

A rozumiesz, co to jest serwer? https://pl.wikipedia.org/wiki/Klient-serwer
W tym przykładzie: backend to serwer, frontend to klient.
Problem w tym, że twój backend to nie jedyny serwer w tej historii. Twój backend odbiera wiadomości twojego frontendu, ale musi je odebrać przez HTTP. A do tego musi stać na serwerze HTTP, który te zapytania przekaże do backendu. Tak samo frontend musi stać na serwerze HTTP, żeby wiadomości wysyłać. A ten serwer HTTP też stoi na serwerze, tzn. na fizycznej maszynie, której zasoby są ci udostępnianie (i tą usługę udostępniania ci zasobów nazywamy hostingiem).

Na większości hostingów masz już od razu zainstalowany serwer HTTP i możesz mieć ograniczone możliwości konfiguracji tego serwera. Są też hostingi, które po prostu dają ci dostęp do maszyny i róbta co chceta.
Na tanich, popularnych hostingach serwerem HTTP jest zazwyczaj Apache, co ogranicza twój wybór backendu do PHP. Jeśli już masz hosting, to na 99% masz tam Apache'a.
Ale są też dostępne serwery pod wszystkie inne technologie.

Ale tak generalnie, to w slangu raczej mówi się, że masz napisać backend, a nie serwer, właśnie dlatego, że serwer to bardzo ogólne pojęcie.

edit:
Trochę OT, ale przy tych dywagacjach o serwerach tu i tam, przypomniał mi się kultowy cytat, który warto sobie wbić w głowę dokładną analizą i zrozumieniem zagadnienia:

Warstwy! Cebula ma warstwy! Ogry mają warstwy! Cebula ma warstwy, dociera? – ogry mają warstwy… I SIECI TEŻ MAJĄ WARSTWY

No i miło ze mi tak tłumaczysz jak totalnemu tłumokowi :) zaczynam rozumieć coraz więcej :)

Z tego wszystkie o co się już naczytałem wybór padnie na C# jako back-end a do front-endu użyje Unity. Czy waszym zdaniem takie rozwiązanie jest słuszne?

I z tego co widzę zaraz będę produkował kolejny temat dotyczący projektowania własnej gry od podstaw :)

Masz zamiar to sam pisać? Masz jakieś doświadczenie? Bo ja troszkę bałbym się tak przeskakiwać na C# (robię w phpie)
[edit] - doczytałem że jesteś laikiem, hmmm no cóż - będzie trudno :)

axelbest napisał(a):

Masz zamiar to sam pisać? Masz jakieś doświadczenie? Bo ja troszkę bałbym się tak przeskakiwać na C# (robię w phpie)
[edit] - doczytałem że jesteś laikiem, hmmm no cóż - będzie trudno :)

Może i będzie trudno ale skoro warunkiem jest możliwość połączenia www z mobi właśnie dzięki c# to wole to tak zrobic. A co do samej nauki to czy będę się uczył php czy C# to w sumie i tak trzeba się uczyć.

Połączenie mobilnego urządzenia z www nie wymaga pisania w C#.
Ja mam receptę na to - z wykorzystaniem API

1. Piszesz w dowolnym języku backend - logika działań, zapis stanu gry, wszelkie operacje bazodanowe itp itd (może stać na czymkolwiek php/c#/java/python.... )
2. Wszelkie akcje które użytkownik może wyklikać udostępniasz w API (to też po stronie backendu)
3. Piszesz frontend w htmlu + js (angular/react/jquery/ vanilla js/ cokolwiek) - za pomocą JS'a korzystasz z backendowego API
4. Piszesz appkę na mobilne (głównie frontend + odwołania do backendowego API). Urządzenie na jakie piszesz i język także nie ma znaczenia (ios/windows/android)
5. Jeśli potrzebujesz wypasionej grafy - korzystasz z Unity

Z czym możesz mieć problem?

1. Prędkość - jeśli użytkowników będzie dużo i np udostępnisz np jakiś czat - to polecam to zrobić na socketach
2. Autoryzacja - będziesz musiał co nieco pokombinować z tokenami do uwierzytelniania

Jak coś mi przyjdzie jeszcze do głowy to dopiszę :)

A wyjaśnisz o co dokładnie chodzi z API? Takie API tworzy się samemu? Jeżeli samemu to jak/czym?