Vylihl se mi v hlave takovy napad...

Zavzpominal jsem si na stare casy a hry jako Stiny nad Rivou, Brany Skeldalu a jim podobne (tj. kecaci RPG kde hrac ovlada skupinu nekolika postav). Napadlo me, ze tenhle typ her by se dal docela jednoduse prevest na web, zejmena pro jejich z velke casti textovou podstatu. Kdyby si navic mohl clovek do party pridavat svoje kamarady, mohlo by se to hezky zaintegrovat do socialnich siti a urcite by se dalo najit i par dalsich zpusobu interakce mezi hraci.

Dalo by se namitnout, ze z toho spis bude takovy multi-singleplayer, ale to je vetsina veleuspesnych her korporaci jako Zynga, Bigpoint nebo Redmoon studios vlastne take.

Co si o tom myslite?

Nahodou neznate nejaky pekny portal o webovych hrach, idealne s hodnocenim jednotlivych her?

CYBERWOLF:
nekdy je levnejsi koupit HW nez platit programatorsky cas... jinak jako u vseho je treba najit rovnovahu mezi dostatecnym HW a zaplatitelnou optimalizaci SW

Co jsem koukala, tak bezne naprogramovane veci a lehce zoptimalizovane udelaji i treba 300% narust vykonu. Kdyz vidim co za monstra treba delame v praci, kde se na optimalizaci mirne kasle a jen jednou za cas se sef zdesi, kdyz vidi tu spoustu sekvencnich scanu :D

Mimochodem, Zynga pustila do sveta novou hru - FrontierVille. Je to jenom muj pocit, nebo je to dalsi zoufala zdimacka sita horkou jehlou a naroubovana do noveho prostredi?

Pochopitelne od urciteho objemu muzeme optimalizovat jak chceme, ale bez dostatecneho HW to proste bude naprd. Na druhou stranu, spatne optimalizovany SW je ten samy pripad a proto rikam, ze je dobre zacinat od SW a HW resit pak, stejne jako pri nedostatku mista doma nejdriv zkusim vyhazet co nepotrebuju, nez zacnu shanet nove skrine, nebo vetsi byt :)

CYBERWOLF: ono hlavně sw optimalizací nahnat rozdíl mezi datama na disku a v paměti, v případě, že ty data potřebuješ skutečně +- všechny, to může být docela problém, pokud to bylo napsané rozumě :)

samozřejmě zvětšovat paměť neni řešení na všechny problémy, ale rozhodně tohle nevidim jako "buď hw nebo sw optimalizace", musíš řešit oboje :-)

CYBERWOLF: Jenze to je v pripade, kdy predpokladas neustaly narust. Coz je jen hypoteticky pripad. Predpokladam, ze se tu nebavime o googlu apod. :).

CYBERWOLF: To sice ano, ale v radu tak velkyho casu, ze do ty doby ziskas alternativu za mensi penize a zasahne te to bez ohledu na zpusob reseni.

Pomer mezi cenou HW a optimalizaci SW je proste takovej, ze v mnoha pripadech se ti to vyplati. Kdyby ne, porad bychom jeli na "starejch" strojich a vicejadrovy procesory na vysokejch kmitoctech bychom nepotrebovali. Mimoto, muzes taky v nekterejch pripadech kus SW nahradit primo HW prvkem, kterej "sam od sebe" bude mit mnohem vyssi vykon nez vypocet na CPU. Ale to uz jsou krajni meze, a hlavne se dostavame OT.

...a dalsi vec je HW ma omezenou zivotnost :)

TENCOKACISTROMY: Pokud mas prilis zravy SW, tak i kdyz pridas vykon HW, tak kazde zvyseni navstevnosti ti z toho zvyseneho vykonu ubere vic, nez kdyby slo o SW optimalizovany. Treba vrazis tech 20k do RAM a disku, takze problem nyni vyresis i s rezervou, ale za rok bude zpatky, protoze tam leze vic lidi a budes muset znovu volit mezi 20k za HW nebo 50k za optimalizaci. A za rok zas.

Takze v dlouhodobem horizontu (kdyz budeme pocitat se slusnym rustem) se vyplati spis ta optimalizace (samozrejme zalezi pripad od pripadu, tezko se to da brat obecne)

CYBERWOLF: Co cini hw zdroje docasnymi oproti sw optimalizaci?

Ja bych radsi investoval do optimalizace, protoze hardwarove zdroje jsou docasnym resenim.

Na druhou stranu je potreba rict, ze optimalizovat se taky neda do nekonecna, ale tak zkusit by se to melo.

CYBERWOLF: Nekdy to tak ale skutecne je lepsi (zduraznuju to "nekdy"). Ja jsem na obou stranach barikady - jak vyvojar, kterej chce ten system vymazlit, tak clovek, kterej to plati. A kdyz vim, ze to je reseni pro XY a zatez budy YZ, tak proste kalkuluju s tim, jestli mam dat 50k vyvojarum za optimalizaci nebo 20k za vetsi RAMku nebo dalsi disk.

TENCOKACISTROMY: veci jako ze je lepsi koupit vykonejsi hardware nez vyladit vykon program (query/cehokoliv) prede mnou vubec nerikej ;)

Pro zajimavost, databaze, ve ktere se zrovna hrabu by se z daneho vyctu vesla tak akorat do tech 64GB (no, vesla by se do 32, ale uz prakticky nic vic) a uprime receno ta databaze jeste neni az tak velka...

Jojo, do hry je potreba investovat. Kuprikladu ja ze sveho stareho testovaciho atoma udelala dual atom na otestovani vice threadu.
Dokonce pamet se zvysila o 1gb :DDD Velka investice, snad se mi to za 10 let az do doprogramuji i vrati :DDD

CYBERWOLF: Tak ona ta RAMka neni zas tak draha (oproti cene vyvojare/db specialisty) a v dnesni dobe 64bitovejch serveru s tou velikou pameti neni zadnej zasadni problem. Mit 16/32/64 GB RAM sice neni uplne bezny, ale na druhou stranu to taky neni zadny zavratny mnozstvi.

Tak nejak jsem na to natahovani do pameti vzpomel, kdyz jsem se ted hrabal v databazich a kdyz vidim celkovou velikost databazi v radech GB, tak mi to prijde jako celkem nerealne, aby se skutecne drzelo v pameti vsechno (ve vetsine pripadu aplikace skutecne pracuje s drtivou vetsinou databaze). Mohlo by to fungovat s DB co ma par stovek mega, ale u velkych DB si to nedokazu predstavit.

TENCOKACISTROMY: Hmm :) tak tohle asi pgsql nema :) Teda aspon myslim..

CYBERWOLF: Natahovani tabulek do pameti by mel umet ten DB stroj sam od sebe. Mel by splnovat ACID, a pak se o vubec nemusis starat o to co se ti kam zapsalo ci nezapsalo, protoze vis ze to mas na disku i v pameti.

WEWERKA: U tech tabulek je zajimava moznost to rozdelit jak vertikalne (jednotlive sloupce jsou na ruznych discich), tak horizontalne (na zaklade nejakeho indexu jsou radky na ruznych discich). Doufam, ze jsem to vertikalne/horizontalne neprehodil, neustale si to pletu :)

No koukam, ze je tu diskuze asi hlavne o mssql. V pgsql jsou shared buffers, ktere pri spravne velikosti pomahaji vykonu a to tak ze dost. Ale pri vetsi velikosti skodi.
Dalsi vec je rozdeleni dat do tablespace. Takovych X (x > 10) SAS disku taky udela svoje.
Pak treba misto beznych disku muzete pouzit SSD.