[gra via WWW] Programista PHP


#1

Witam,
poszukuję osoby, która byłaby zainteresowana dokończeniem projektu gry tekstowej. Dotychczasowy kod został wykonany w czystym PHP.

Do realizacji:

  • stworzenie systemu premium wraz z implementacją płatności SMS,
  • wykonanie systemu ataków pomiędzy graczami,
  • wykonanie klanów (wraz z prostym czatem i forum) oraz system wojen klanów.

#2

Elo Guger, za bardzo nie pomogę bo sam jestem scenarzystą, ale miałem przyjemność robić grę tekstową, a raczej gierkę via WWW, która aktualnie jest przepisywana z php na node.js.

Moja rada: Znajdź kogoś, kto to przepisze w node.js, dlatego, że php jest o wiele mniej wydajne i zwyczajnie, skoro macie zamiar mieć system premium z implementacją płatności SMS (Swoją drogą polecam dotpaya, ale nie polecam bawienia się w sms’y bo operatorzy zabierają wam od sms’a 50% a z przelewu tracicie 1.2% chyba, jak nie mniej).

Tak czy inaczej, skoro robicie w PHP, najpewniej robicie coś typu vallheru i podobnych jak battleknight? Polecam bardziej wykorzystać co macie jako prototyp, przepisać na node.js. Oferuje on więcej dynamiki, gry takie jak forge of empires są na na nim. Cechują się generalnie większą dynamiką a w tych czasach gracze o wiele bardziej sobie to cenią, przynajmniej w komercyjnych produktach…

PS: Myślcie od razu o wersji mobilnej. My mieliśmy z miejsca pytanie o apkę, jako pierwsza rzecz jaką ludzie chcieli xD


#3

Nie ma to jak ktoś porównuje wydajność PHP nie wspominając którą wersję porównuje.
To tak jak porównywanie maksymalnej prędkości tego samego modelu samochodu bez podawania ich mocy silnika. Co z tego, że jeden ma 100KM drugi 200 KM.


#4

Faktycznie nie napisałem xD Musiałem z rozpędu pominąć, tak czy inaczej już daje sprostowanie, że korzystaliśmy z PHP 7 :slight_smile:


#5

W porządku. Wybaczone. :slight_smile: A tak na serio. Nie bez powodu na to zwróciłem uwagę, bo miedzy wersją 5.* a 7.* jest gigantyczna różnica wydajności.
Nie będę oceniał noda bo raz go użyłem.


#6

Ano właśnie jest spora, a co do noda, prościej potem jeżeli o apkę chodzi, zwłaszcza do gry via WWW, łatwiej to dostosować bo to jednak js jest, a żyjemy jednak w czasach kiedy ludzie nie na kompie a na komie lub tablecie grają :slight_smile:


#7

Tak tylko wtrącę, bo widzę już któryś raz twój post na temat programowania, w którym piszesz kompletne bzdury.

Odnosząc się do tego i poprzedniego postu:

dlatego, że php jest o wiele mniej wydajne

PHP (także 7) sam z siebie jest wolniejszy od node. Jednak w grach tego typu zapewne większy narzut czasowy spowoduje “rozmowa” z bazą danych, lub samo wysyłanie/odbieranie requesta od usera.

i zwyczajnie, skoro macie zamiar mieć system premium z implementacją płatności SMS

Zwyczajnie co? Nie dokończyłeś swojej wypowiedzi

Tak czy inaczej, skoro robicie w PHP, najpewniej robicie coś typu vallheru i podobnych jak battleknight? Polecam bardziej wykorzystać co macie jako prototyp, przepisać na node.js. Oferuje on więcej dynamiki, gry takie jak forge of empires są na na nim.

Nie mam pojęcia co ma do tego jaką grę robią język który wykorzystują. O ile są języki stricte desktopowe/webowe, o tyle to czy wykorzystują PHP, Node.Js czy Ruby nie ma żadnego wpływu na sam wygląd gry.

prościej potem jeżeli o apkę chodzi, zwłaszcza do gry via WWW, łatwiej to dostosować bo to jednak js jest

Znowu argument bez sensu. To jest javascript, co nie zmienia że jest to SERWEROWY javascript, co sprawia że nie ma on absolutnie żadnego wpływu na frontend aplikacji (nie ma więc znaczenia czy jest to strona www, czy aplikacja smartfonowa) i przy dobrze napisanym kodzie niezależenie czy korzystasz z PHP czy Node api serwera konsumowane będzie tak samo.
Ba, powiem więcej, możesz nawet napisać dwa serwery, jeden w php i jeden w nodzie i mając taką samą stronę www i aplikację korzystać z nich wymiennie (bez żadnych zmian w kodzie frontendowym, poza adresem serwera oczywiście).

Ostatecznie, nie bierz tego do siebie (nie jest to hejt na ciebie, tylko na to co prawisz). Lubię nowe technologie, tak samo jak lubię je promować, wiem jednak że łatwo porwać się “z motyką na księżyc”. W przypadku nie dużych projektów, ta różnica wydajności na serwerze autorowi nie zrobi różnicy (ciężko mi wyobrazić sobie to że ktoś zauważy różnicę pomiędzy np. 0.4 a 0.7 sek), a w przypadku dużych projektów znacznie ważniejsze od wydajności jest obycie z danym językiem i znanie jego “min” (których akurat w javascripcie jest od cholery).


#8

Widzę rozpętała się dyskusja :wink:

Z pewnością w przyszłości przymierzę się do takowego rozwiązania. Na obecnym etapie, gdzie to jest projekt pół-amatorski (a większość tutaj jest w zasadzie silnie sprofesjonalizowanych) chcę po prostu zbadać delikatnie rynek bez dużych nakładów finansowych. Chcę wykorzystywać swoją umiejętność promowania projektu sprawdzonymi sposobami. Bardziej traktuję to jako pasję niż projekt stricte biznesowy.

Temat jest mi znany, przyjrzałem się temu bliżej. Aby móc wykorzystywać płatność przelewami konieczna jest działalność gospodarcza, zaś jeśli chodzi o SMS to możliwe jest rozliczanie umową o dzieło. Rozwiązaniem jest w przyszłości ewentualna próba podjęcia wprowadzenia innych rodzajów płatności, podpinając się pod Inkubator Przedsiębiorczości.


#9

@Takechi Nie traktuje tego jako hejt, bo w bardzo konstruktywny sposób wypowiedziałeś się odnośnie moich poglądów powyżej, a to doceniam :slight_smile: Po prawdzie, bardzo możliwe, że napisałem wiele głupot (całą masę), gdyż programowaniem dopiero od niedawna zajmuję się amatorsko bo moim zajęciem jest głównie marketing, copywriting i bycie scenarzystą, jednak przydaje się to by dogadać się z programistami, którzy myślą mniej humanistycznie a bardziej umysłem ścisłym :wink:

Generalnie co do Noda, proponowałem tylko to rozwiązanie, bazując na własnym doświadczeniu z grą WWW. Problemy dotyczyły głównie dynamiki, ponieważ w php 7 kiedy gra była w nim napisana, zrobienie najzwyklejszych puzli było wręcz koszmarem wydajnościowym, natomiast Node.js nie odstawiał takich cyrków w przypadku mini-gierek i animacji. Może da się wydajnie wykorzystać PHP7 aby to grało, aczkolwiek nie miałem przyjemności się z tym spotkać ^^

Co do wyglądu masz rację w zupełności, że sam język nie ma na to wpływu, to jest bardziej mechanika, aczkolwiek systemy drag’n’drop były trudniejsze do zrobienia w php7, ale być może to zależy od umiejętności. Na pewno warto przyjrzeć się rynkowi gier via WWW, zobaczyć co jest popularne i w jakim silniku pisane, przynajmniej tak uważam, że lepiej uczyć się od najlepszych,

@Guger

Tego z tym przepisywaniem nie traktuj serio, Takechi skorygował w dużej mierze moje błedne myślenie. Zgadzam się, że warto najpierw zbadać rynek pod tym względem, aczkolwiek jeżeli zamierzasz to w taki sposób zrobić, zaznacz, że jest to beta. Kiedy my wydawaliśmy naszą pierwszą grę, wiele systemów o których mieliśmy przekonanie, że są super, okazały się irytujące dla graczy i była masa przepisywania.

Przykład: Daliśmy możliwość wydobywania surowców do crafting, 1/1h. Można było sobie nastawić ich max 4 i odliczał się licznik potem, czyli jak ktoś nie miał czasu na grę, to mógł sobie wejść okazyjnie i też grać :slight_smile: Brzmi to fajnie na pierwszy rzut oka, ale doprowadziło do tego że:
A) Gracze grali 5 minut na 4 godziny
B) Multikonta się namnożyły
C) Liczniki blokują inne aktywności często

Z naszych doświadczeń wyszło, że gracze w czasach obecnych preferują raczej dynamizm w grach, czyli wszelkie liczniki okazały się totalną klapą produktu. Są gry które mają pulę energii np. masz 100 punktów, jakaś akcja kosztuje 5. A 5 punktów odnawiasz co godzinę. Takie systemy kiedyś były ale to też zachęcanie graczy by: Weszli, wyklikali energię, wyszli z gry i poszli grać w miejsce, gdzie tego typu limitów nie mają.

Z tymi SMS’ami masz rację, jest możliwe rozliczanie się umową o dzieło. Sporo się traci na tym, ale jeżeli nie robisz projektu stricte biznesowego i nastawionego na sprzedaż to masz racje, że to może być dobra metoda akurat dla Ciebie na ten moment :slight_smile: na zakończenie od siebie dodam jedną rzecz, bo wiele osób pomija ten temat w grach przeglądarkowych, a nie wiem jak to z tą Twoją wygląda. Generalnie chodzi o dane osobowe, czyli rejestracja tego w GOIDO. Najpewniej nie przechowujesz danych osobowych użytkowników, jeżeli masz tylko nicki i e-mail, tylko z e-mailem jest nieco kwas bo on może a nie musi być danymi osobowymi. Jak ktoś będzie miał jan.kowalski@gmail.com to są już dane osobowe i musisz rejestrować tą ochronę danych. Jest na to kruczek, jeżeli w regulaminie gry zaznaczysz zakaz rejestrowania konta takimi mailami, wtedy użytkownicy robią to na swoją własną odpowiedzialność :wink:


#10

Dodam tylko że znowu trochę gubisz pojęcia:

to jest bardziej mechanika, aczkolwiek systemy drag’n’drop były trudniejsze do zrobienia w php7,

Drag’n’drop realizowany jest przez frontendowy javascript, co oznacza mniej więcej tyle że znowu, serwer możesz podpiąć jakikolwiek i nie będzie to miało wiekszego znaczenia. :slight_smile:
Wydaje mi się poprostu że porównujesz “stare” metody budowania stron, gdzie wymieszany jest front i back, wtedy ciężko jest uzyskać wiele rzeczy, a nowe metody, gdzie serwer udostępnia jedynie api z danymi, a to klient (przeglądarka) odpowiedzialna jest za odczytywanie tych danych. :wink:
Przykładem mógłby być chociażby Angular.JS lub React, w których dragdropy robi się prościutko :wink: a serwer nie ma tu żadnego znaczenia, gdyż otrzymuje on jedynie requesty na zasadzie “użytkownik przeciągnął element XYZ do okna YXZ, zapisz to do bazy”


#11

Najpewniej masz rację ponownie ale to Ty jesteś programistą i specjalistą, a nie ja :wink: Na pewno w starym projekcie korzystaliśmy z angular.js przy dragowaniu mapy świata, ale jak pisałem wyżej, proste puzzle tak lagowały że to była kaszanka programistyczna. Obrazek był bodajże 400x400px, dzielił się na równe kwadraty i mieszał. Gra polegała na tym, by zaznaczyć jeden element i zamieniać go miejscem z innym i ogólnie to był totalny koszmar jeżeli chodzi o funkcjonowanie, lagi i ilość zapytań do bazy. Ogółem początki naszej gry via WWW były dość koszmarne :wink:


#12

Jeszcze w temacie:
Największą różnicę w porównaniu PHP/Node odczuje się w przypadku gier realtime opartych o sockety. :wink:
Głównie dlatego, że obsługa socketów w PHP jest dosyć toporna (z założenia skrypty php powinny wykonywać się przez określony czas a potem zakończyć, za to sockety wymagają ciągłego działania serwera ;)) i sam za nią nie przepadam. :slight_smile:
Jednakowoż jeżeli mówimy o właśnie hobbistycznej grze tekstowej, php powinno w pełni wystarczyć.

A co do projektu, proponuję wrzucić gdzieś jakąś próbkę kodu. Osobiście gdy słyszę “został wykonany w czystym PHP” to już czuję armagedon :slight_smile:
Lubię czyste php, jednak frameworki mają tą zaletę, że wymuszają podążanie za wzorcami, narzuconymi przez twórców, dzięki czemu jeżeli dwie osoby znają ten sam framework to powinny być w stanie mniej-więcej rozumieć swój kod bez większego zagłębiania się.


#13

To ja tak podrzucę w sumie swoją grę, która aktualnie jest przepisywana na node.js, bo być może Cię zainteresuje, skoro lubisz wypociny programistów xD

http://sixthworld.pl/Game

Ogólnie jeśli chodzi o użyte technologie przy projekcie to gra jest napisana na autorskim frameworku w php 7. Po stronie klienta oczywiście angularjs :slight_smile:

Do projektu od początku użyty był orm o nazwie redbean, niestety na tak zaawansowany projekt redbean to nie było dobre wyjście i około miesiąc szybko było to trzeba zmienić póki nie byo za późno i obecnie ma to autorski orm w którym w odróżnieniu od redbeana definiuje się własności modeli, ma wsparcie dla typu enum i object oraz wiele innych rzeczy, których redbean nie robił xD Patrz i przeraź się xD

Ogólnie dobrze co prawda funkcjonuje to jako prototyp ale inaczej to jest tragedia :slight_smile: A dla @Guger polecam pooglądaj sobie nasze changelogi na forum, być może zobaczysz co zmienialiśmy i jakoś natchnie Cię to do własnego projektu :wink:


#14

Zerknąłem, zastanawia mnie czemu przy każdym wywołaniu, nawet przy pobraniu czatu, zwracacie wszystkie dane użytkownika? Jeżeli synchronizujecie je z bazą za każdym razem to już macie masakryczne zbędne zużycie :slight_smile:
(Czat chyba raczej nie zmienia stanu użytkownika? ^^


#15

Ten czat to jest w ogóle nieporozumienie jakieś XD Laguje jak nie wiem co xD W ogóle sama strona się źle skaluje do tego i jest masa innych błędów i głupich rozwiązań :stuck_out_tongue: Muzyka i klimacik fajny, nawet szata graficzna stylizuje na takie: Stare-dobre-rpg ale właśnie po stronie kodu to nie jest zbyt kolorowo. Powodem jest najpenwiej to, że zamiast zrobić prototyp i go przepisać, zrobione było wszystko na spontana xD


#16

No i masz odpowiedź dlaczego tak opornie to wszystko chodziło :wink:
Generalnie jak kod nie będzie przemyślany to nie ważne jaki to będzie język i tak będzie chodził topornie. :slight_smile:

Grafikę robił ktoś z forum? Wygląda bardzo ładnie :wink: a od dłuższego czasu nosze się z zamiarem zrobienia przeglądarkowej strategii (Clash of clans, chociaż bardziej z mechanikami a’la settlers) :wink:


#17

Mamy w teamie graficzke, bardzo zdolna, styl malarski ale nie z forum gamedevu :slight_smile: Ogólnie teraz przepisujemy cały projekt właśnie na node.js, zarzucę i screeny co mi tam szkodzi. Już alfę mamy na serwie :slight_smile: Btw. screeny są z prototypu jeszcze :wink:



Poszliśmy krok dalej w modernizację projektu :slight_smile:


#18

W sumie Takechi wszystko rozsądnie powiedział (widać że programista z doświadczeniem) , wiec nie mam za bardzo co dodać.

  1. Prawda jest taka, że wydajność, języka jest mniej ważna od samego projektu i kodu, bo z najwydajniejszego kodu można zrobić wolny bubel i odwrotnie.

  2. Wręcz wasz błagam, żeby ci którzy nie mają doświadczenia w programowaniu z danym językiem, nie pisali własnych frameworków do dzieł użytku publicznego, tylko używali sprawdzonych. Framework napisany przez niedoświadczonego programistę jest bardzo dużym zagrożeniem, a pamiętaj, że n.p jeśli w swojej grze zbierasz dane osobowe i one wyciekną, będziesz miał spore problemy.

  3. Czytałem tematy gdzie się wypowiadałeś i na początku tak pewnie siebie spierałeś się o wadach i zaletach danego języka programowania jakby doświadczony programista ( przy czym doświadczony programista tak się nie zachowuje, bo wie że każdy język ma swoje przeznaczenie, zalety i wady ) i nagle piszesz, że dopiero zaczynasz. Nie obrażając, ale odebrałem wrażenie, że woda sodowa uderzyła ci w głowę, po kilku skryptach. Pod sumując wszystkie lata praktyki będę miał ok 6 lat komercyjnie w różnej postaci. Ale nie odważył bym się powiedzieć, że jestem świetnym programistą, który wie wszystko najlepiej. Jestem dobry i to tylko w swojej dziedzinie, może to się zmienić jeśli przestanę ciągle się dokształcać bo wszystko się zmienia.

Przy czym znajomość składni języka i napisanie jakiś programów /skryptów nie czyni jeszcze z człowieka programistę a tylko klepacza kodu. Żeby być dobrym programistą, potrzebne jest przede wszystkim doświadczenie zwłaszcza doświadczenie z błędami. Po za tym wiedza na temat projektowania aplikacji w tym wykonywania testów , dobrych zasad projektowania, wzorców rozwiązujących najbardziej popularne problemy i umiejętność ich rozsądnego wykorzystania lub nie (nie na silę) i wiele innych zagadneń. To odróżnia zwykłego klepacz kodu od programistę, a przede wszystkim myślenie.

A z tego co pamiętam, pisałeś wcześniej gdzieś, ze swój projekt pisałeś spontanicznie z palca, bez przemyślenia, podejrzewam że spaghetti code.

Ale jedno muszę przyznać, że grafika gry jest świetna.
Tak czy siak, Życzę powodzenia w rozwoju gry. Mam nadzieje, że nikogo nie obraziłem.


#19

Nie przesadzał bym z moim doświadczeniem, bo też 20 lat w branży nie mam ;), ale zgadzam się z lukasssz’em :slight_smile:
Dodam tylko, że różnica między przeciętnym a dobrym programistą nie leży tylko w lepszej znajomości składni danego języka, ale w umiejętności przekładania funkcjonalności serwisu na algorytmy i późniejszej optymalizacji tych algorytmów. (ciekawostka - np. w google, podstawą przy rekrutacji na programistę jest właśnie algorytmika i optymalizacja :slight_smile: )
Można to bardzo łatwo uargumentować - co z tego że programista pisałby w asemblerze, jeżeli jego algorytmy i tak wykonywały by się 3 razy wolniej niż algorytmy robiące to samo napisane w c++ :wink:
Jeżeli chodzi o sam język programowania, najważniejsze jest znanie jego “niuansów” (znowu odniosę się do javascript, gdzie przykładowo takie działanie " [] + [] " zwróci nam nie pustą tablicę, a pustego string’a ;)), reszta to w większości zdolność czytania dokumentacji, tudzież od czasu do czasu zerknięcia na wydajność różnych operatorów, które “powinny” robić to samo :wink:


#20

Nie obraziłeś, a ja doceniam to, że zostałem zdisowany bo faktycznie głupoty popisałem, nie mając doświadczenia i wiedzy jakie mają osoby zajmujące się stricte programowaniem. Mimo to, wyszło na dobre, bo przynajmniej dowiedziałem się wielu ciekawych i nowych rzeczy :slight_smile: Sam programuje amatorsko w c# i faktycznie to nie czyni ze mnie programisty, daleko mi do tego bo zajmuje się tym tylko od pół roku :wink: Sprostuje tylko jedną rzecz, że to nie ja z palca kodowałem pierwszą wersję Sixthworld, opisuję tylko jak była ona robiona przez pierwszego programistę, ale ja osobiście ręki do pierwotnej wersji jeżeli o kod chodzi, nie przykładałem, tylko scenariusz i koncept. Generalnie, kiedy powstawała, to jeszcze osobiście nie miałem pojęcia w ogóle zielonego o czymkolwiek poza pisaniem scenariusza ^^