CYBERWOLF: To mi neprijde. Ted mam hrdinu na 8 levelu a cas vystavby uz vylezl na hodinu a pul, questy obvykle behem pul hodiny a vic. Takze pri praci naprosto v pohode. A to nemluvim ani o pomalem tempu jakym pribyvaji suroviny, zvlaste pote co vyprsel ten zrychlovaci bonus do zacatku. Tohle mi tam pripada jako dost divny usek. Veskere upgrady jsou drahe jak svina a oni jeste seberou bonusy, ktere to cekani prodlouzi.

CYBERWOLF:
strasne jednoduse ale ucine je tento princip pouzit na hre sfgame.cz

Co se tyka tech vydelku, asi nejefektivnejsi se zatim projevil prodej virtualniho zbozi (viz. Zynga). K tomu je samozrejme vhodna nejaka virualni mena (diamanty, houbicky, reward pointy). Nejaky primereny obnos teto meny od zacatku je nutnost - aby hraci vedeli, co si za to mohou poridit a jak je to fajn, stejne jako je dobre je odmenovat touto menou za herni akce. Samozrejme - chce to oboji v rozumne mire a soucasne mit spoustu super veci, co se za to da koupit.

Nemusi se jednat o veci, ktere cloveku daji kdovi jakou vyhodu, ale jsou proste fajn a jsou "vzacne" a tak si je lide koupi proste proto, ze se jim libi. Famville a ostatni ville v podstate nestoji na nicem jinem.

Celkem dobre take funguje utraceni za "odpustky", kdy mam moznost splnit nejaky herni ukol, nebo zaplatit bodiky. Skvele to funguje v kombinaci s omezenym casem a serii ukolu. Kdyz vam dochazi cas a uz jste se tolik snazili, budete docela nakloneni utratit par bodiku pro ziskani te pochybne odmeny a dost mozna si je budete chtit i na rychlo koupit.

Jeste mi prijde zajimava forma ziskavani bonusovych statusu (donator, gold, vip...), ktere v sobe skryvaji nejaky balik drobnych vyhod, vsichni vidi, ze TOHLE je platici hrac a soucasne ma platici hrac pocit, ze podporuje svoji oblibenou hru a stava se tak jeji soucasti.

Na druhou stranu, prodej permanentnich drobnych vyhod a usnadneni se zda byt neprilis lukrativni - i kdyz si je hrac koupi vsechny, je tu strop kolik muze utrait, usnadneni vlastne nic neprinese, kdyz uz je clovek zvykly na to hrat bez nej atd.

AREX: me prave to jejich casovani prislo celkem nestastne, protoze na intenzivni hrani jsou intervaly dlouhe a na hrani pri praci zas dost kratke. Mozna se to na vyssich levelech zlepsi, ale tak dlouho jsem to nehral :)

Jinak hra samozrejme hratelna je a podle ohlasu si hraci docela pochvaluji vtipne dialogy (ktere se me nechtelo cist), akorat mi neprijde nicim zvlast zajimava. Vsechno uz tu bylo a rekl bych, ze i hodnekrat.

TRANCEWARP: Jako nesmi to byt prilis vtirave a do oci bijici - kdyz nezaplatite, budete hrozny luzri a nikdo se nevyrovnate tem ostatnim. Niborea to ma celkem sikovne resene. Daji ze zacatku pomerne dost diamantu a jeste v prubehu dalsi pribyvaji. Nevim jestli to casem polevi, ale tipuju ze ano a v te dobe uz je hrac navykly vyuzivat bonusu, ktere diamanty poskytuji a zacne premyslet o zaplaceni.

Nevim jestli pro webovky lze vymyslet nejaky lepsi model zisku. V nejake forme je to asi potreba vzdycky vyjadrit kolik si toho dotycny vlastne koupil.

AREX: napada te lepsi zpusob vydelavani? ;)

my se snazime jit podobnou cestou, tzn. iterni mena a za ni nakup vychytavek... ale vychytavky jsou taky dost funkcionalniho charakteru, tzn. lepsi klient co toho umi vic

CYBERWOLF: Tak zkousit tu Niboreu. Nevim v jakem stavu to bylo v dobe kdyz jsi to testoval ty. Kazdopadne ted mi to prijde docela hratelne. Grafika by mohla trochu polepsit, hlavne uhladit ty ovladaci prvky a trochu je zatraktivnit javascriptem. Kazdopadne prijde mi to jako idealni hra, kterou lze hrat pri zamestnani. Clovek tam naklikne quest, ktery se sam splni treba za pul hodky a pak se tomu nemusi venovat. Podobne funguje Shakes & Fidget a me zatim neomrzel. Pro vikendove hrani to vsak neni zadny odvaz.

Zpusob vydelavani pres nakup "diamantu" je celkem otrepany, podobne jako ve zminemem SF, kde se zase kupuji houbicky. Kazdopadne tady zatim moc nevidim k cemu ty diamanty vlastne jsou krome najimani nejakych poradcu, ktery davaj ruzny bonusy.

CYBERWOLF: budem musiet urobit nejaky test ako dlho sa bude generovat obrazok, potom uvidim.

chapes spravne

TOMAS3333: jasne, ale jde o to, ze s vygenerovanim bludiste muzes vygenerovat obrazek a ten si ulozit a tomuhle uzivateli ho servirovat pokazde, dokud bludiste neprojde. Zkratka ze si bludiste jednou vyrenderujes, pak nad tim jen ukazujes pozici (a dotazujes se jestli muze z aktualni pozice tam a tam).

Mimochodem, chapu to spravne, ze mas jednotliva policka a u nich urcene, z kterych stran maji steny?

TOMAS3333: jestli v tom bludisti nechces vyhledavat (v ramci SQL dotazu), tak bych to bludiste ulozil v ramci jedny textovy/binarni bunky.

CYBERWOLF: tie bludiska si bude moct vygenerovat uzivatel ked pride na web, pricom kazde vygenerovane sa ulozi do db. s tym suvisi ako to do db ukladat, je to dvojrozmerne pole ktore obsahuje info o tom kde je stena a kde nie pre kazdu bunku

CZUPA: toto vyzer dost dobre, dik

TOMAS3333: offtopic to rozhodne neni.

Netusim, jak dlouho trva vygenerovat obrazek bludiste, ale pokud se vygeneruje jednou, pak by nemuselo vadit, ze to chvili tva. Zobrazovani pozice v bludisti bych resil tak, ze obrazek bludiste bych si dal na pozadi prislusne velkeho divu, ve kterem bych absolutne pozicoval ukazatel aktualni pozice.

CZUPA: to 3D bludiste je vyborny!

TOMAS3333: http://raphaeljs.com/

trochu offtopic ale je to hra a je to online, tak...
je nejaky vhodny sposob ako zobrazit bludisko vygenerovane v php? divy s floatom su nepouzitelne pre nizsie rozlisenia alebo vacsie, bludiska, lebo sa to rozpadne, tabulky zasa maju tendenciu sa zuzovat aby sa zmestili na stranku. generovat obrazok asi bude dost casovo narocne a riesit potom pohyb po bludisku by bol zrejme problem... http://tomas01.herniweb.cz/maze/class.generate.php

Sice mi to prijde jako pitomost, ale zajimave to rozhodne je :)
Gamasutra: Robert Boyd's Blog - Monetizing Griefing - the Next Stage in Social Gaming
http://www.gamasutra.com/blogs/RobertBoyd/20110415/7439/Monetizing_Griefing__the_Next_Stage_in_Social_Gaming.php

Jeden se prihlasil, ale pak se uz neozval, takze se zda, ze ne. Abych to nekomu nutil, na to znam moc dobre, jak to dopada ;)

AVATAR: Tak co, nasel se nejaky pomocnik?

TENCOKACISTROMY: no tak mu holt nesmis dat tu uplne nejvyssi prioritu :)

TENCOKACISTROMY: Ano. A pokud to na sobe zavisi, tak to centralni logikou proste nepridelim. Mam nastaveny collision bit pro situace, kdy to muze nastat. Takovy ukol pak pocka az mu bude dovoleno se zpracovat.

Vzhledem k tomu, ze to jsou ukoly jako "kup si neco k jidlu", "najez se", "utrat nejake penize", "trenuj" atd. tak to neni moc rizikove. Navic vetsinu veci insertuju (napr. mnozstvi, statistiky atd), takze soubeh taky moc nehrozi.
Kdyz to neuhlidam, vetsinou se mi neco zdvoji a na to rychle prijdu.

WEWERKA: A ty 4 childy pocitaj neco, co na sobe navzajem nezavisi, rozumim tomu spravne?

TENCOKACISTROMY: Ne, bezi mi najednou 4 childy a jeden master (ten bezi nonstop) + sem tam nejaky zombie :) Vic jak 4 nemaji smysl kvuli vykonu (4 cpu)

WEWERKA: Aha, takze to forkujes ale nakonec ti to stejne bezi seriove?

TENCOKACISTROMY: Oni se diky centralni logice vzajemne mezi sebou synchronizovat nemusi. Proste mam v php cyklus, ktery si na zacatku nacte ukoly, pak jednotlive ukoly forkne, potvrdi zpracovani a uz neceka na dokonceni. V dalsim cyklu uz mi centrala neprideli ukol, dokud nedostane potvrzeni od dokonceneho childu, ze predchozi ukol byl splnen. Zaroven centrala hlida vsechny (doufam) moznosti soubehu, priorit atd.

WEWERKA: Jak teda resis synchronizaci tech forknutejch procesu?
CYBERWOLF: To zalezi na priorite procesu. Kdyz mu das uplne tu nejvyssi a strcis tam "while(true){}", tak to je dost znat.

AVATAR: stavet na pesimistickem predpokladu je urcite dobre, ale 50k mi proste prijde jako hrozne male cislo. Otazkou samozrejme je, co vsechno se s tim dela nebo nedela a tezko k tomu takhle od stolu neco rict.

Jake zkusenosti mas na mysli? :)

YAWGMOTH: Pokud jde o vyhodnocovani "tahu", tak tam bych rekl se muzeme pohybovat i ve vyssich cifrach nez desitkach MB. Samozrejme to zalezi pripad od pripadu.

Kdyz o tom tak ale premyslim, ma cenu tam cpat sleep? Jeden proces si preci nevezme tolik prostredku, aby ohrozil plynuly chod serveru.

YAWGMOTH: Premyslela jsem taky o semaforech, ale nakonec rozhodlo centralni zpracovani v db. Php pouzivam jen na "vypis", veskerou herni logiku mam v db.

WEWERKA: notifikace by v php mohla jít udělat pomocí unixových pipe ... otevřeš "soubor" vytvořený přes mkfifo a čteš, proces spí dokud do fronty něco nepřijde :)

HAKUBJOZAK: ja mel podobnou myslenku, jen teda bych tam spis strcil nejakou frontu (treba rabbitmq apod.)...clovek by do ni cpal vsechno ke zpracovani, pak by clovek pustil bokem workery, ktere by si brali zpravy, zpracovali je, potvrdili jejich vyrizeni apod...

velkej respekt ke vsi ty magii s PIDama, procesama, forkama a dalsim harampadim ale tak me napada, jestli neobjevujete kolo a nebo neignorujete "use the right tool for the right job" ... co treba http://rubyeventmachine.com/ (nevim jestli je neco podobnyho pro PHP)

pripada mi, ze http://en.wikipedia.org/wiki/Not_Invented_Here

ale treba sem uplne mimo a fakt to musite delat hardcorove a na kolene - dopodrobna samozrejme nevim co potrebujete

CYBERWOLF: ano, normálně si uložím pid, v cronu se to pouští pořád znovu, pokud zámek existuje tak se zkontroluje jestli běží proces s daným pidem, jinak se zámek uvolní. Udělat to tímhle způsobem (přes filesystem) dobře neni úplně triviální, souhlasim.

ale co se týče paměti, to mi nepřijde úplně dobrej argument proti. Jestli se skript stejně pouští 1x za minutu tak ta by ta paměť stejně volná být měla, jinak budeš akorát pořád swapovat :). Žere to nějaké prostředky, ale konstantní a ne nárazové. Naopak ušetříš overhead za ty opakované inicializace. Jakejkoliv rozumnej skript se vejde do několika (nízkých) desítek mega a to dneska neni až takovej problém na to vyhradit.

Nemuselo to tak uplne vyplynout, ale vsechny procesy se v php forkuji.

Jinak nevyhoda - spatne se mi debuguji problemy.

Po nejake dobe testovani jsem prisla na nejlepsi variantu zpracovani. Treba bude nekoho zajimat jake problemy ho muzou potkat.

Pracuju s postgresem a php. Diky php nemuzu pouzivat listen/notify, takze se porad musim dotazovat do db. Php sice ma fci na notify, ale ta se stejne porad dokola pta. Dalo by se vyresit dotazovanim z C, tam notify funguje bez problemu.
To je slabina c.1.

Dalsi vec je pamet viz CYBERWOLF. Pouzivam na to knihovny, ktere si pri kazdem volani par bajtu seberou.
Kvuli viceprocesorovemu zpracovani musim volat jednotliva db volani samostatne (connect, query, close). Protoze close potomka by mi zavrel persistentni spojeni i pro hlavni pripojeni. Proste pamet se pri takovem volani zabira pomerne rychle.
Slabinu c.2 - pamet, jsem vyresila automatickym ukoncenim skriptu pri dosazeni urcite obsazene pameti. Skript se navic ukonci 10 sec pred kontrolou na nove spusteni (spousteni z cronu kazdou minutu), tim padem nemuze dojit k vypadku zpracovani (minuta uz je hodne).

Je to na freebsd a nemuzu uplne vyuzit signaly, protoze se tam zpracova vic signalu najednou a to pro moje ucely neni idealni. Na linuxu bych signaly nejspis vyuzila a mozna bych neresila centralni zpracovani pres db.


Takze si eviduju ukoly v db. Ukladam si pidy childu, ktere prijmou job a eviduji stavy, tak abych mohla zajistit vetsinou failover stavu. To vsechno pro napr. 4 procesy najednou (nastavitelne za "behu").

Navic skript si kontroluje, zda vsechny joby opravdu bezi. Kazdy job ma predpokladany cas, takze kontrola nastava az po danem case. Krom toho je u jobu nastavene jak moc kriticky je, zda stopnout cele zpracovani nebo to jen oznamit, ci proste ignorovat a jit dal. Nekriticky job se teoreticky muze pri prelomu proste smazat a udelat se jindy.

Pokud dojde k padu, jsem schopna opetovnym pustenim nedodelane ukoly znovu pustit a dozpracovat. Tady byla potreba kontrola na dvoji zpracovani (job se dela, nastava pad, job se v db dozpracoval a nedal vedet ridicimu zpracovani, opetovne pusteni, dozpracovani spadleho jobu, priznak ze job je jiz zpracovan, pad childu resp. rollback)

Na vsechno existuje planovac. Paradoxne existuje job na vytvoreni planu, ktery tvori ukoly :) Joby vytvari tak, aby se zpracovavaly pokud mozno rovnomerne a logicky s ohledem na logiku hry.
Joby maji v nastaveni priznak, ze muzou ci nemuzou byt soucasne pustene - nemuzou tak vzniknout situace jako "kdyz tam nic neni, vloz tam 1000 zaznamu" a ve vysledku se vytvorilo 2000 zaznamu, protoze se to najednou zpracovalo ve 2 procesech.

Vysledkem je histogram jobu. V budoucnu se pouzije statistika pro dalsi upravy za behu napr. prumerna delka pusteni bude upravovat limit pro kontroly bezicich jobu.

Timhle zpusobem zpracovani veci, ktere trvalo 20 minut se na 4 jadrech (atom, 2 cpu, 2 HT) dela presne 5 minut.