Výber zaujímavostí no. 7

20.01.2016

Posledné mesiace sa v mojom živote niesli prevažne v znamení prác na Feudariu. Konečne som si však našiel čas aj na to, aby som dal dokopy zopár poznámok z článkov prečítaných za posledné obdobie a tak vám prinášam sumár toho, čo ma zaujalo a čo sa dialo.

Feudarium#

Začnem Feudariom, predsa len je to môj srdcový projekt. Začiatkom novembra som do sveta vypustil verejnú alfa verziu a oznámil to niekoľkým kamarátom a kolegom. Týmto môj niekolkoročný projekt vstúpil do nového štádia a ja sa teším, kam to všetko povedie. Veľmi príjemne ma prekvapilo, že niektorí hráči to začali hrať celkom intenzívne a dokonca ich to baví. Obával som sa toho, že ľudia to začnú hrať, len preto, aby sa na to pozreli a dali mi nejaký feedback a potom to nechajú tak. Našlo sa však niekoľko hráčov, ktorých to celkom pohltilo.

Som vďačný každému, kto sa zaregistroval a o to viac každému, kto sa aj chvíľu hral a prípadne dal nejaký feedback. Pomáha mi to pretriediť množstvo plánov a vytvorených issues a sústrediť sa na to, čo je hráčmi považované za potrebné.

Aktuálne v hre beží odpočet konca sveta, o pár dní budú vyhlásení víťazi a potom môžem spustiť druhý testovací svet s novými vlastnosťami. Už teraz sa teším.

Game Design#

S Feudariom trochu súvisí aj nasledovný článok z Gamasutry o balansovaní multiplayerových hier. Je to ukážka, aký jednoduchý prístup používajú v Relic Entertainment k balansovaniu hier, konkrétne výkonu a cien jednotiek. Vysvetlené na príklad Company of Heroes 2 a je to pomerne jednoduché. Z rôznych vlastností najskôr vytvoria niečo, čomu vravia Raw Unit Value. Použijú pritom jednoduchú matematiku, napríklad sqrt(útok * obrana). Na základe tejto Raw Unit Value potom vedia robiť porovnania jednotiek medzi sebou. Následne ešte vytvoria základné jednotky pre každý typ (jednu pre pechotu, jednu pre tanky a pod.) a týmto dajú nejaké základné hodnoty ich vlastností. Ďalšie jednotky v rámci jednotlivých typov potom porovnávajú relatívne k týmto základným jednotkám. Nasledovným krokom je určenie ceny jednotky. Prvotne sa cena nastaví iba podľa pomeru Raw Unit Value a následne sa testuje, ako sa hra správa a či to takto dáva zmysel. Keď z testu vyjde, že niektorá jednotka nemá výkon odpovedajúci cene, tak sa cena upraví.

Autor napísal aj pokračovanie článku, kde hovorí o tom, že cieľom dobrého vybalansovania hry je to, aby hráča hra bavila. A baví ho vtedy, pokiaľ v nej má výzvy a jednou z možností, ako mu ponúknuť výzvu, je dostať ho do pozície, kde musí zvažovať následky svojich akcií a vyberať optimálnu možnosť. Autor ďaľej rozoberá tri koncepty potrebné pri balansovaní hier: Opportunity Cost, Power Concentration a Relative Balance.

Opportunity Cost je cena každého hráčovho rozhodnutia. Môže byť vo veľa formách, ako napríklad času, výhody, strategickej pozície alebo ich kombinácie.

O Power Concentration a Relative Balance je dobré uvažovať zároveň, pretože sa silno ovplyvňujú.

Power Concentration je charakteristika nejakého herného objektu/jednotky, ktorá typicky exponenciálne rastie, keď objektu pridávame viacej sily.

Relative Balance zase zvažuje interakcie jednotky proti každej inej, kde cieľom je nájsť také modifikácie charakteristík jednotky, ktoré budú viesť k lepšiemu výsledku.

V článku sú uvedené aj niektoré príklady používajúce Raw Unit Value a autor ukazuje, že táto hodnota nemusí nič hovoriť o výkonnosti danej jednotky. Pre mňa to bol rozhodne u6itočný článok, ktorý mi trochu doplnil vedomosti o balansovaní hier a ukázal, ako to robia inde.

Symfony#

Symfonisti vo Fínsku si povedali, že skúsia porovnať reverznú proxy v Symfony (napísanú v PHP) s Varnishom. Ako testovaciu aplikáciu si zvolili demo inštaláciu eZ Platform. Podľa výsledkov varnish neprekvapivo vyhral a to s veľkým náskokom. Zaujímavé však bolo, že nie je veľký rozdiel medzi výkonom varnishu na jednom, dvoch a štyroch procesoroch. Pri ôsmich CPU však už počet obslúžených requestov opäť značne porastie. Symfony gateway cache zase skracovalo náskok varnishu s každým pridaným procesorom.

Composer#

Lorna Mitchell píše o tom, prečo nie je dobré mať v composeri závislosť na dev-master verzii balíčkov. V základe je problém v tom, že takto je projekt závislý vždy na tom, čo je práve na vrchu master vetvy balíčku. A tam môže byť úplne hocičo a veľmi pravdepodobne tam skôr, či neskôr budú zmeny, ktoré sú nejakým spôsobom spätne nekompatibilné a rozbijú váš kód. Preto je lepšie vo svojom composer.json uvádzať závislosť iba na konkrétnych verziách a iba v určitých špecifických prípadoch mať dev-master. Tieto špecifické prípady podľa Lorny sú:

  • je to interný kód organizácie zdieľaný vo viacerých projektoch, ktorý však nie je dostupný externe
  • je to závislosť na vlastnom forku nejakého balíčku (ale aj v takom prípade je lepšie uviesť iný branch, než master)
  • iný špeciálny prípad, kedy chceme mať updaty k dispozícii tak často, ako je to možné (napr. z bezpečnostnýčh dôvodov)

Organizácia času#

Ian Feather sa zamýšľa nad tým, prečo nemá problém dosahovať ciele, ktoré zdieľa s niekým iným (či už formou spoločného snaženia, alebo kontroly), ale je pre neho problém dosiahnuť ciele, ktoré si vytýčil a kontroluje on sám. Tento problém má veľa ľudí a v komentároch mu jeden čitaťeľ odporúča si prečítať niečo o koncepte "Mastermind Group". Mastermind Group je v skratke malá skupina ľudí, ktorú si vytvoríte, ktorá sa pravidelne stretáva a kde každý človek má nejaký svoj cieľ a na stretnutí rozpráva o tom, čo sa mu podarilo alebo nepodarilo a čo chce dosiahnuť do najbližšieho stretnutia. Ostatní sa ho na jeho pokroky a plány pýtajú a tak dostáva každý člen pocit, že vo svojom snažení nie je sám a zároveň, že existuje niekto, kto jeho napredovanie sleduje, kontroluje a očakáva.

Usability#

Ešte minulý rok vyšiel na SitePointe článok o 15 krokoch, ktoré zlepšia použiteľnosť vašej webovej aplikácie. Síce sú to všetko pomerne jasné a známe princípy, ale nezaškodí si ich pripomínať.


  Testovanie Game Design Symfony Php Composer Time Management Usability Feudarium Scrapbook

Diskusia