@inside: tu wkracza moje biznesowe doświadczenie. z klientami jest gorzej niż z graczami a mimo wszystko dawałem radę. Uporządkowany kod, przejrzyście napisane funkcje, elastyczne podejście do składowania danych w bazie i przede wszystkim wyobraźnia czynią cuda. Już teraz miałem kilka takich przypadków gdy trzeba było coś 'dopisać'. Przykład: zbieranie dzikich roślinek na pierwszych etapach. Nie planowałem tego, zaimplementowałem w 2 wieczory.

Nie chcę tu z siebie robić jakiegoś guru, mam soje własne podeście, uczyli mnie tego lepsi od was, lepsi ode mnie, lepsi od wielu innych, których potem, w rożnych firmach spotkałem i z którymi pracowałem. Miałem to szczęście, że gdy byłem zielony jak trawka to trafił mi się mentor, który oprogramował pół elektrowni w Kozienicach... Bezcenne doświadczenie.

no to pewnie masz rację, skoro tak to wygląda

Ja to widze tak; klient Ci mówi co chce ty to robisz i Cie wali reszta(mail jako podkładka), natomiast gracz sam nie wie czego chce, w rezultacie to ty musisz wymyśleć coś unikatowego co go zaciekawi. Nawet jak ci ktoś powie że chce zbieranie ziółek to może mu się znudzić po godzinie... więc ja nie jestem pewien czy spełnianie wymagań graczy jest łatwiejsze IMO robienie gier to raczej jest dla ludzi co nie lubią jak im się mówi co maja robić, a mają w głowie jakąś wizje jak coś zrobić lepiej

Bahamut, dokładnie tak jest. Pisząc kod komercyjny dostosowuję się do wymagań klienta i do jego 'widzi mi się'. Pisząc grę muszę brać pod uwagę opinie graczy, jednak ostateczna decyzja należy do mnie. I wszystko było by fajnie, gdyby nie mały szczegół: klienta ma czasem rację, gracz ma czasem rację. A ja muszę być na to przygotowany.

Klient chce, klient płaci, klient ma. Proste.
Gracz chce, gracz nie płaci, opinie gracza trzeba przemyśleć dla dobra innych graczy.

W obu przypadkach nie mogę występować jako osoba wszystkowiedząca, muszę być jednak przygotowanym na wszystko. A takie przygotowanie gwarantuje mi właśnie dobrze napisany kod. Przemyślany kod.
Bo program to nie tylko realizacja początkowych założeń. To również przygotowanie na totalny kataklizm i wywrócenie wszystkiego do góry nogami. A tak już nie raz bywało....

Ta na to trzeba być najbardziej przygotowanym Bo po 6 miesiącach robienia gry zmienia Ci się kompletnie ostateczny jej wygląd

No to powiedz mi gdzie masz przewagę javy nad PHP po stronie serwera
Zakładam, że wykorzystujesz JVM od oracle?
Failem jest wymaganie po stronie klienta JVM. Nie każdy chce/może zainstalować JRE jakiekolwiek. A do tego w niektórych korpo masz narzuconą czasami wersję 1.4 i zakaz instalacji nowszej. Klienci by mnie zajebali młotkiem jakbym wciskał im wersję w javie
To, że sobie kodzisz jako sztuka dla sztuki - luzik, ale Java (w wydaniu oraclowskim) nie jest ani wydajna, ani stabilna, ani akceptowalna po stronie klienta.
Serwer sobie możesz w tym napisać i potem dbać żeby nie kładł się na plecy (to jest jeden z problemow wspomnianego przez Ciebie nodeJS - kładzie się na plecy częściej niż JVM ), ale już po stronie klienta to muszą być ogólnie dostępne rozwiązania. Unity nie będzie potrzebne, bo to prosta gra przeglądarkowa, a animacje da się rozwiązać jQuery.

Wydajność, wielokrotna przewaga...
Łatwość pisania kodu, łatwość debugowania.

JVMy odpalamy czasem na długie miesiące, nie zauważyłem, żeby się wykładały.

Po stronie php oczywiście No chyba, że porównywałbyś Java+Oracle vs PHP+sqlite/MySQL. Tyle, że wtedy wąskim gardłem będzie DBE, a nie implementacja języka.
Wiesz, że php4 to już prehistoria, a obecnie mamy 5.3+ right?
Odkąd Oracle przejęło Javę, a Zend dostał zastrzyk kasy od Facebooka to szala mocno się przechyliła. To już nie jest język skryptowy, a pełnoprawny język programowania z implementacją pozwalającą na kompilację do binarek (fakt faktem, za kompilator trzeba zapłacić).
My w końcu dostaliśmy rewelacyjne connectory do baz danych, a Wam zabrano kompatybilność wsteczną.
Java za czasów Suna ewoluowała, a Oracle ją skopał po dupie - przypomnij sobie co odwalili przy update 1.7.8 czy tam 1.7.9.
I o ile przy aplikacjach desktopowych Java ma jakiś (całkiem spory) sens to przy mobilkach i webówkach została w tyle (mowa oczywiście nadal o Oracle Java - są implementacje, które działają zajebiście, ale kosztują sporo).
JSF, RichFaces, a4j to frameworki, które nie mają nawet startu do ZendFramework połączonego z jQuery. I jest to zdanie ludzi, którzy z javą mają romans od ponad 10 lat. Po prostu Oracle zostawił rozwój w tyle i zajął się wyłącznie marketingiem.
W tym czasie kwitnie konkurencja (ale bańka$ za jvm to nawet dla korpo jest sporym wydatkiem) oraz inne technologie (PHP, Ruby, Python, .NET).
Javowcy mawiają, że Oracle wykupił Suna, aby wstrzymać rozwój MySQL, a rykoszetem oberwało się javie.


Bitch, please
Widać, że o php słyszałeś tylko z opowieści. Akurat debugger w wersji przed kompilacją mówi absolutnie wszystko, a potem korzysta się już z narzędzi.


No widzisz, a w pewnej, największej polskiej korpo oracle JVMy (1.7+) przez badziewny GC padają po 2-3 dniach (po paru godzinach tracą na wydajności). W wersji php działają od pół roku nieprzerwanie (pół roku bo dopiero pół roku temu jedna z aplikacji została zportowana). To co wkurwiało korpo w javie to to, że po updacie 1.7.8 nagle dla kilku tysięcy jednostek trzeba było modyfikować instalacje oprogramowania. Oracle strzeliło sobie dezycją o olaniu kompatybilności wstecznej w kolano, ale to co odjebali przy tym updacie do był strzał w jądra.

No, ale wracając do tematu - nie osiągniesz teraz w aplikacjach webowych wydajności jaką daje konkurencja na JVM Oracle'a. Przy małych aplikacjach będzie szybko, ale przy przetwarzaniu dużych porcji danych ichniejszy GC się zesra (to co mnie boli w Javie to brak możliwości ręcznego zarządzania zasobami).

Nie można znac sie na wszystkim. Zycia by mi na te wszystkie technologie nie starczyło.

To, co mówisz ma sens, ja jednak opieram sie na moich własnych doświadczeniach. Firma w której pracuje nie romansuje z javą, bardziej nastawiamy sie na rozwiązania microsoftu, jednak cos tam w tej javie jeden z działów rzeźbi i nikt nie płacze, że boli.

Ogolnie to ta dyskusję mogli bysmy jeszcze ciągnac i ciągnąc, nie zmienia to jednak faktu, że to juz w tej javie zostało napisane i nawet gdyby Twoje argumenty mnie przekonały to i tak teraz nie robił bym rollbacka w repozytorium do pierwszych linii kodu i nie szył tego od nowa.

Naprawdę, z mojego obecnego doświadczenia nie widzę, żeby mój wybór był zły. Owszem, pisząc np w przyszłości inną grę na pewno zastanowię sie raz jeszcze nad wyborem technologii na strone klienta. Jednak po stronie serwera nadal pewnie będzie to java. No chyba, że będzie mnie stac na droższego vpsa/dedyka i serwer klepnę w C# + SQLServer.

a wogole to szukam kogoś kto by mi dał zapro na gamedevelopers.pl bo widze że jest tu pare osób co w grach robi

W sumie to też chętnie bym się tam wkręcił.

Up, aktualizuję. Od lipca wiele się zmieniło, jest nowy layout, sporo nowych grafik, poprawek i nowości.

Jak to teraz wygląda:

http://s14.postimg.org/5rirkcvup/screen1_2.png
http://s21.postimg.org/qi5yyry6v/screen2_1.png
http://s11.postimg.org/p5n9ou2o3/screen3_1.png
http://s9.postimg.org/nzp78ni7j/screen4_1.png

Aktualne informacje o postępie prac można zawsze znaleźć na naszym fanpage.

Osoby zainteresowane pomocą w testach proszone są o odpowiedź w tym temacie, prywatną wiadomość na forum lub kontakt na email: game.pgr(at)gmail.com

Pozdrawiam.