Autor Wątek: PHP/*ServerPages vs C++/C#/Java  (Przeczytany 29827 razy)

Offline mINA87

  • Użytkownik

# Kwiecień 30, 2007, 18:40:12
peter: Tak to dla mnie oczywista sprawa, ale sam takiego czegoś raczej nie będziesz implementował we własnym zakresie - rozumiesz?
A z wykorzystaniem takiego środowiska może być dużo problemów, bo bardzo ważną cechą aplikacji webowych jest łatwość ich deploy'ingu, a takie customy to powoli wkraczają w sferę corporate. Właśnie dlatego nie stosuje się aż tak szeroko baz obiektowych.
Po prostu chodzi mi o klasyczne aplikacje webowe, tam świetnie sprawuje sie zwykła relacyjna baza danych i odchodzenie od nich na rzecz innych mechanizmów powoduje tworzenie właśnie małych, customowych baz danych, czyli powoduje replikowanie funkcjonalności.

Goliatus: sam świetnie skwitowałeś jak to wygląda. Poza tym ja ciągle myślę o aplikacjach webowych w sposób strukturalny podobny do tego z PHP, ASP, klasycznego CGI, czy najbardziej lamowatego JSP(a to jest właśnie rynek i podwórko aplikacji webowych) - tam obiektowe bazy danych fajnie to mogą conajwyżej wyglądać, albo być wykorzystywane w jakichś hackach do interpreterów.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Kwiecień 30, 2007, 18:51:52
mINA87: Wrzucasz gry i np. sklepy internetowe, robienie dla siebie i bycie na etacie do jednego wora i to jest przyczyną konfuzji, która pojawiła się w tym wątku.

Spróbuj poczynić wstępne założenie:
- robisz coś dla siebie wg własnego pomysłu
- będziesz to coś pieścił przez najbliższe 5 lat

Takie są właśnie gry internetowe. Gra nie jest jak sklep, nie możesz jej zaprojektować raz a dobrze. W trakcie rozgrywki wychodzą nie tylko zwykłe bugi ale również poważniejsze błędy projektowe, które wymuszają gruntowe zmiany w kodzie.
Gry się robi po to, aby zadowalać graczy. Jeśli większość graczy Ci powie, że coś w Twojej gierce jest fundamentalnie spartolone to musisz to przerobić, bo stracisz tych graczy, a jeśli założymy dodatkowo, że oni płacą za możliwość grania to stracisz również ich pieniądze. Nie wiesz jak dużo będziesz musiał przerobić i jak głębokie zmiany w kodzie to wymusi, nie możesz tego przewidzieć.

Właśnie dlatego potrzebny jest dobry nie pisany strukturalnie na pałę kod, do którego możesz wrócić po 2 miesiącach albo po 2 latach i który będzie zrozumiały dla innych programistów(optymistycznie załóżmy, że się projekt rozrośnie :)). Komponenty, warstwy, obiektowość - to wszystko ułatwia rozumienie i modyfikację kodu.
« Ostatnia zmiana: Kwiecień 30, 2007, 18:54:31 wysłana przez Goliatus »

Offline mINA87

  • Użytkownik

# Kwiecień 30, 2007, 19:07:49
Jeśli rozmawiamy o FPS/cRPG/RTS to się zgodzę - wrzucanie tego do jednego worka ze sklepami internetoymi jest błędem, dlatego, że raczej się nie zrealizuje takich aplikajci na zasadzie aplikacji webowych. A jeśli developujemy aplikacje webowe to narzuca to pewne podejścia samo przez sie - powtarzam się :]

Odnośnie refaktoringu to ja praktykuje właśnie ostatnio cały czas rapid development dużego portalu, gdzie przerabiam, dorabiam i dopracowuje funkcjonalność dosłownie w locie, pracuje na kodzie swoim i nie swoim, na kodzie który rozumiem ale też na takim którego wolę nie tykać bo nie opłaca się go ani analizować ani przepisywać - tak to wygląda. Nie chcesz wiedzieć jak projektowałem system blogowy, ile razy na życzenie zmieniałem funkcjonalność starając się nie naruszyć projektu, jak najmniej refaktorować i wpasować się w istniejący model z całą nową funkcjonalnością. Dokładnie znam to co mówisz o tej zmianie bo coś się komuś nie podoba itp i wiem co to znaczy pisać kod w taki sposób żeby można było do niego wrócić za jakiś czas, bo robię to na okrągło.
I właśnie m.in. o takich rzeczach mówię, a nie tylko o jakichś sklepikach na papierze, gdzie deisgn powstaje najpierw ładnie na kartce a nie on-the-fly, gdzie kodzik jest pisany na spokojnie w oderwaniu od środowiska klienta, na koniec ładnie sprawdzony i dopiero oddany.

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Kwiecień 30, 2007, 19:12:13
Rozmawiamy o grach przez przeglądarkę. Gra przez przeglądarke nie musi być tekstowa.

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Kwiecień 30, 2007, 19:13:39
Jeśli rozmawiamy o FPS/cRPG/RTS to się zgodzę - wrzucanie tego do jednego worka ze sklepami internetoymi jest błędem, dlatego, że raczej się nie zrealizuje takich aplikajci na zasadzie aplikacji webowych. A jeśli developujemy aplikacje webowe to narzuca to pewne podejścia samo przez sie - powtarzam się :]
a strategie (szczegolnie te czasu rzeczywistego) przez przegladarke to juz nie?
osobiscie podpisuje sie z pod tym co napisal Goliatus - gre inaczej sie robi niz sklep internetowy.
od siebie dodam jeszcze jedna roznice - sklep ma okreslona funkcjonalnosc i na niej sie poprzestaje, w grach (szczegolnie typu MMO) caly czas jest jeszcze cos do dopisania - gracze zawsze, ale to zawsze chca wiecej i nie sposob do konca zaprojektowac takiej gry przed jej napisaniem

Offline mINA87

  • Użytkownik

# Kwiecień 30, 2007, 19:23:08
Goliatus: Ciągle się nie rozumiemy :]
Jeśli piszesz grę opartą o przeglądarkę, a do tego typu gier zaliczam wszelkie OGame'y, Travariany, Crimsy i inne takie, bo to są typowe gry przez przeglądarkę to gra taka dużo się nie różni od sklepu internetowego :]
Inna sprawa to gry real-time, ale o te ciężko ciągle przez przeglądarki, bo dla mnie gra przez przeglądarkę == coś opartego o protokół HTTP. To są po prostu pewne ograniczenia, pewne przyzwyczajenia użytkowników, środowisko pracy, które narzucają pewne podejścia i koniec.

peter: napisałem RTS :] Pokaż mi strategię czasu rzeczywistego przez przeglądarkę.
A ja się podpisuję pod tym co napisałem wyżej - dla mnie to sklep internetowy i tyle :]
Hehe z takim podejściem to możesz wystawić sklep na allegro za 100zł od sztuki. Spójrz na mój post wyżej i przeczytaj co napisałem o swojej pracy.
I wracając właśnie do tego systemu blogów - myślisz że wiedząc jak płynne będzie projekt zdecydowałem bym się na C++? To by mi wcale nie ułatwiło roboty tylko wręcz ją utrudniło, bo właśnie takie języki skryptowe są bardzo podatne na refaktoring i takie żonglowanie kodem. Poza tym wiele spraw można ciekawie załatwiać. Kod C++ jest bardziej sterylny, zamknięty przez co często nie nadaje się do takich zastosowań. To jest moja opinia i będę przy tym obstawał. Gdyby wszytsko było takie piękne to CGI by kwitło, gierki online klasyczne i kasyna internetowe powstawałyby w oparciu właśnie o te technologie a jak widać tak nie jest.

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Kwiecień 30, 2007, 19:31:39
mINA87: Jeśli nie potrafisz zrobić gierki real-time przez przeglądarkę to powiedz, a nie kategorycznie stwierdzaj, że jest to niemożliwe. Świat gierek przez przeglądarkę i możliwości samych przeglądarek na Crimsach, Travianach i Ogameach się nie kończy.

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Kwiecień 30, 2007, 19:34:01
Goliatus: Ciągle się nie rozumiemy :]
Jeśli piszesz grę opartą o przeglądarkę, a do tego typu gier zaliczam wszelkie OGame'y, Travariany, Crimsy i inne takie, bo to są typowe gry przez przeglądarkę to gra taka dużo się nie różni od sklepu internetowego :]
Inna sprawa to gry real-time, ale o te ciężko ciągle przez przeglądarki, bo dla mnie gra przez przeglądarkę == coś opartego o protokół HTTP. To są po prostu pewne ograniczenia, pewne przyzwyczajenia użytkowników, środowisko pracy, które narzucają pewne podejścia i koniec.

peter: napisałem RTS :] Pokaż mi strategię czasu rzeczywistego przez przeglądarkę.
A ja się podpisuję pod tym co napisałem wyżej - dla mnie to sklep internetowy i tyle :]
Hehe z takim podejściem to możesz wystawić sklep na allegro za 100zł od sztuki. Spójrz na mój post wyżej i przeczytaj co napisałem o swojej pracy.
I wracając właśnie do tego systemu blogów - myślisz że wiedząc jak płynne będzie projekt zdecydowałem bym się na C++? To by mi wcale nie ułatwiło roboty tylko wręcz ją utrudniło, bo właśnie takie języki skryptowe są bardzo podatne na refaktoring i takie żonglowanie kodem. Poza tym wiele spraw można ciekawie załatwiać. Kod C++ jest bardziej sterylny, zamknięty przez co często nie nadaje się do takich zastosowań. To jest moja opinia i będę przy tym obstawał. Gdyby wszytsko było takie piękne to CGI by kwitło, gierki online klasyczne i kasyna internetowe powstawałyby w oparciu właśnie o te technologie a jak widać tak nie jest.
ostatni agument jest nietrafiony - po naszych ulicach jezdzi wiecej seicento niz wszystkich modeli lexusa razem wzietych - i raczej nie oznacza to, ze japonczycy zrobili gorzej swoje auta niz wlosi ;)

kolejna rzecz - nie porownoj prosze systemu blogow do gry online.

wpomniane przez Ciebie travian, ogame, czy the crims sa w pewnym sensie strategiami czasu rzeczywistego, moze niezbyt rozbudowane, ale jednak - przy czym kazdy zabierajac sie za taka produkcje w domowym zaciszu ma nadzieje, ze uda mu sie zrobic Prawdziwie Rozbudowana GreTM , ktora bedzie nieporownywalna do konkurencji... bo czy jest sens inaczej zaczynac wlasny projekt? ;) (pomyjajac oczywiscie czysto edukacyjne kolka i krzyrzyki, czy inne tetrisy)

update:

mINA87: Jeśli nie potrafisz zrobić gierki real-time przez przeglądarkę to powiedz, a nie kategorycznie stwierdzaj, że jest to niemożliwe. Świat gierek przez przeglądarkę i możliwości samych przeglądarek na Crimsach, Travianach i Ogameach się nie kończy.
mozesz rozwinac ostatnie zdanie? jest jakis projekt o jakim nie wiem, jakas gra, w ktora jeszcze nie gralem? :)

Offline nameczanin

  • Użytkownik
    • devlog

# Kwiecień 30, 2007, 19:35:14
a FPS w JavaScript? :) Juz nie pomne linku w tym momencie. Jednak niemalze grywalne. RTS-a tez daloby sie zrobic, a nie robi, bo jest z zalozenia chore [mm, i like it].

EDIT do mINY ponizej:
Popieram zdanie, ze rozni sie gra dostosowana pod przegladarke, a pod jakas tam glupia kontrolke ActiveX/Java itp. Mowisz "zastanowcie sie", wiec odpowiadam Ci - HTML+JavaScript+PHP to moj wybor.
EDIT2:
quasi - napisany w C++, ale to tylko serwer - baza danych, trzymanie tych wszystkich informacji i update. A ja mowie raczej o pisaniu W PRZEGLADARKE - na klienta! mINA ma racje, ze quasi, to tez ten jego sklep.
EDIT3:
peter zaznaczyl to samo, wspominajac o modelu.
« Ostatnia zmiana: Maj 01, 2007, 00:39:34 wysłana przez nameczanin »

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Kwiecień 30, 2007, 19:41:41
A czym się będzie różnił RTS od Google Maps? Z resztą zawsze można zrobić w applecie i komunikację z serwerem przez HTTP lub przez własny protokół na socketach. Tylko teraz ciekawe co jest lepsze, ActionScript(tm) czy Java? :)

Offline mINA87

  • Użytkownik

# Kwiecień 30, 2007, 19:49:41
Goliatus: Potrafię :], ale jak jesteś taki cwany to bez Javy, Flashy i innych takich napisz gierkę real-time z prawdziwego zdarzenia, przypominającą funkcjonalnością Fallout'a, C&C: Red Alert, czy NFS: Unerground. Ja sądzę że się nie da. Gra przez przeglądarkę to dla mnie z definicji coś prostego co odpali każdy na IE, Operze, FireFoxie, nie ściągając żadnych pluginów czy kontrolek ActiveX, bo co innego gra przez przeglądarkę a co innego gra wykorzystująca przeglądarkę gdzieś tam do czegoś niejako przy okazji.

peter: czy ja wiem czy nie trafiony? Nawet te auta oddają jakoś sytuację :] Chodzi o cenę, popularnosc i inne kwestie. Poza tym tu rozmawiamy o technologii a nie o marce.
Będę porównywał, bo żonglujecie argumentami o refaktoringu i elastyczności kodu natywnego vs skryptowalnego, więc odbijam to w ten sposób. W tym wypadku czy to blog czy "gra" nie ma znaczenia.
A w pewnym sensie są grami turowymi, zobacz na Crimsy i ich rozbudowę - jak ta gra przyrastała. Gry może faktycznie nie są strasznie rozbudowane, ale to są właśnie gry przez przeglądarkę - odzwierciedlają trend aplikacji request->response, umożliwiają jednoczesną grę nieograniczonej niemal liczbie użytkowników a przy tym game play jest tak wyważony żeby dało się w to w ogóle grać przez tą przeglądarkę (uwzględniając to że nie jest to typowy realtime, że nie jesteśmy sami, że możemy wrócić do gry za 5 minut, jutro albo za tydzień itp) i dlatego to są dla mnie właśnie typowe gry przez przeglądarkę. Teraz przyjrzyjcie się im, troszkę bawiać się w social i reverse engeenering, trochę zgadując jak to tam wygląda i zróbcie to samo ze sklepem internetowym. Imho wrażenia będą podobne.

A jeśli np. Crimsy to nie jest dla was gra przez przeglądarkę to nie wiem - opiszcie co chcecie zrobić, czego oczekujecie, jak chcecie to wpasować żeby było to grywalne i wpasowało się ładnie w protokół HTTP i przeglądarki i nie pozostaje mi nic innego jak życzyć powodzenia w pisaniu WoWa pod przeglądarki Wapowe.

//edit:
No właśnie Panowie - zastanówcie się w końcu - piszecie gierkę pod JVM / FlashPlayer czy pod przeglądarkę, bo to jest cholernie duża różnica.
//edit2:
I czy piszecie po stronie serwera aplikację webową czy usługę czasu rzeczywistego, bo coś mi się wydaje że chcecie postawić klienta i serwer do WoWa i wcisnąć mi że to jest gra przez przeglądarkę - aplikacja webowa.
//edit3:
Czy to http://quasigame.pl jest przykładem tego jak fajnie można użyć C++ pod kątem gier przez przeglądarkę? :> Bo sry, ale dla mnie to sklep internetowy :P
« Ostatnia zmiana: Kwiecień 30, 2007, 19:58:01 wysłana przez mINA87 »

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Kwiecień 30, 2007, 20:15:54
Oczywiście, że można dużo uczynić poprzez sam JavaScript(czego wynalazki inżynierów Google są najlepszym przykładem), ale applet przyspieszający komunikację z serwerem, zapobiegający wyciekom pamięci FireFoxa to jest coś co każdy gracz ścierpi. Trzeba stosować różne techniki wg potrzeb, ale jedno jest ważne, aby one były technologicznie spójne. Tzn. jak dla mnie to użycie appleta na stronie wymusza użycie javy po stronie serwera.

Offline mINA87

  • Użytkownik

# Kwiecień 30, 2007, 20:23:46
Z JavaScriptem jest ten problem że jest jak d... - każdy ma swoją :P Znaczy każda przeglądarka interpretuje go inaczej trochę. Dlatego tej technologii staram się wystrzegać.
Dobra może tak - rozmawiamy ciągle o dwóch różnych rzeczach :) Ja ciągle mówię o klasycznych technologiach webowych jak JS+XHTML+CSS+Server Side(PHP/ASP/CGI/JSP) co umożliwia zrealizowanie niedorobionej Tibii w najlepszym przypadku, a wy mówicie o klasycznych grach multiplayer które jakoś tam wykorzystają przeglądarkę do komunikacji, ale mogłyby się obejsć bez niej - dla mnie są to już aplikacje stacjonarne i tutaj faktycznie podejście jest trochę inne, jednak myślę Goliatus że ta druga idea jest bliższa Tobie, bo wydaje mi się, że peter stara się uzyskać coś pokroju pierwszego rodzaju tylko że na szerszą skalę - mocno rozbudowane.

//edit:
Ale ogólnie bardzo się ciekawie dyskutuje/dyskutowało i coraz bardziej się przekonuje do platformy ASP .NET, teraz za przyczyną tego hibernate'a. Ehh tyle ciekawych technologii a tak mało wolnego czasu :/
« Ostatnia zmiana: Kwiecień 30, 2007, 20:37:33 wysłana przez mINA87 »

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Kwiecień 30, 2007, 21:33:18
caly czas staram sie trzymac pierwotnego tematu - gry przez www, a nie RTS, FPP, etc i osobiscie proponowalbym przy nim pozostac u bo wszyscy wiemy, ze da sie napisac FPP we flashu czy JS, ale przecierz nie o to chodzi :)

@mINA87:
co do gier podobnych to the crims czy ogame - zajmowalem sie kiedys zmianami w reddragonie i do dzis mam jego kod na dysku (gra podobna w zalozeniach do ogame, choc zdaje sie byc troche ambitniejsza), i IMO model request-respone narzucal tam momentami duze ograniczenia, ktore trzeba bylo sztucznie obchodzidz - watpie zeby w pozostalych grach bylo inaczej - taki model kompletnie nie pasuje mi do gry - piszac gre chce myslec o pojedynczych obiektach i ich wzajemnych odzialywaniach, a nie o pobraniu danych, przerobieniu, wyswietleniu i zapisaniu do bazy - nawet jesli bedzie to ladnie rozwartwione to i tak sam model sie nie zmienia i kompletnie nie pasuje do podejscia jakie stosuje sie w innych grach

Czy to http://quasigame.pl jest przykładem tego jak fajnie można użyć C++ pod kątem gier przez przeglądarkę? :> Bo sry, ale dla mnie to sklep internetowy :P
no teraz troche juz przesadziles... wiekszosc sklepow jest znacznie bardziej rozbudowana, niz moja gra na obecnym otapie ;)
ale to dlatego, ze od sierpnia do lutego bawilem sie w projektowanie automatycznej serializacji i innych pierdol ktore w PHP zajelyby mi pewnie kilka dni, ale dzieki temu teraz pisze sobie user->village->nextTurn() nie zastanawiajac sie czy ktorykolwiek z tych obiektow jest w pamieci czy nie - jesli go nie ma to sam sie zaladuje, jesli pamiec bedzie sie konczyc to nieuzywane obiekty same poleca do bazy danych, zeby zrobic miejsce dla nowych.
owszem w PHP tez da sie pisac obiektowo, ale nie az tak ;)
aha i jeszcze jedno - jesli nie doszedles do grodu, to nie masz prawa glosu :P

BTW uzywajac googlewebtoolkita nie pisze sie w JS tylko w Javie
« Ostatnia zmiana: Kwiecień 30, 2007, 21:46:46 wysłana przez peter »

Offline mINA87

  • Użytkownik

# Kwiecień 30, 2007, 22:00:05
peter: widzę że powoli zaczynamy się rozumieć - przyznaj że taki model request->response przypomina właśnie sklep czyli klasyczną aplikację webową, a gra przez przeglądarkę chcieć nie chcieć w pewien sposób musi się w ten model wepchać. Hacki są wszędzie, też sporo tego widziałem, ale one wynikają z innych rzeczy - złe podejście projektowe. Gdyby się to inaczej zaimplementowało to 90% sytuacji o których mówisz można wyeliminować.
W PHP nie da się aż tak pisać obiektowo? Co masz na myśli? :> Jedyne co według mnie staje na przeszkodzie sensowności (nie mówię o możliwości tylko sensowności zauważ)  zastosowania mechanizmu obiektowego w PHPie to właśnie krótki life-cycle obiektów wynikający z modelu request->response, ale user->village->nextTurn() też można zrealizować bez problemu w PHP'ie w oparciu o automatyczną serializację - ja tam problemu nie widzę.
Odnośnie Twojej gry to muszę przyznać że nie grałem w nią, tylko się zarejstrowałem, w wolnej chwili może się pobawię, ale uwierz że pomijając wygląd, wnioskuję po tym co piszesz i w jaki sposób piszesz, że Twoja aplikacja jest 20x lepiej napisana i rozbudowana niż 3/4 sklepów internetowych :]
Dla mnie wyznacznikiem sposobu pisania i wyboru języka jest tutaj sposób interackji z użytkownikiem - aplikacje webowe z założenia nie są dla mnie real-time tylko request->response i stąd moje poglądy, opinie i podejście do tematyki :)