Pages

Tuesday, August 23, 2011

Armor u strategijama i RPGovima

Nastavak na temu matematike u igrama, što mi znači +2 armora što mi daje paladinova aura?

Slično attack i defence ratingu igrice mogu imati mehanizam damagea i armora/resistencea. Tipičan primjer su strategije kao npr. Warcraft III i Starcraft. Ako se usredotočimo na strategije, dva su pristupa: oduzimanje i dijeljenje vatrene moći napada. RPGovi ili kombiniraju jedan od ova dva pristupa ili jednostavno svrstavaju armor pod defense rating.

Damage minus armor


Starcraft je primjer igre u kojoj se primjenjuje oduzimanje. Napad od 12 damagea protiv jedinice s 3 armora oduzima 12-3=9 hit pointa. Posljedice ovakvog pristupa su da ako damage i armor nisu sumjerljivi da se gubi značaj ili damagea ili armora. Ako je armor veći od damage tada meta ne bi trebala primiti nikakvu štetu. Dizajnerima Starcrafta se to nije svidjelo pa su i igru stavili pravilo da armor ne može smanjiti damage ispod 0.5. U obrnutom slučaju, kada je damage puno veći od armora, utjecaj armora postaje nezamjetan. Utjeće na račun ali čisto simbolički. Npr. ako napač vrši napad od 1100 damagea na meti s 2 armora, taj armor neće bitno utjecati na ishod, niti će nadogradnje koje povećavaju armor mete za 1 bitno joj promijeniti izglede za preživljavanje.

Damage podijeljen s armorom


Ovo izgleda malo neobično ali takvog oblika je formula za damage reduction u Warcraftu III (zapravo, količnik je 1+6*armor). Za razliku od pristupa s oduzimanjem, pristup s dijeljenjem nema problem nesrazmjera, slab armor će malo umanjivati damage, jak armor će jako umanjivati damage. Naime, štos je u tome da postotak reduciranog damage ne ovisi o iznosu damagea. To je po mom mišljenju ujedno i loša strana ovog pristupa jer na taj način armor nije ništa drugo nego +% hit pointa, odnosno isti efekt se postiže povećanjem hit pointa jedinice.

Jedan neobičan pristup


Pišući ovaj tekst, sjetih se jedne igre koja je imala zanimljiv pristup. U strateškoj igri Warlord Battlecry koristi se nešto slično geometrijskom redu. Ako je armor manji ili jednak damageu, za svaki poen armora damage se umanjuje za 0.5. Ak je veći od damaga tada se efekt dodatnog armora prepolavlja. Primjer, recimo da napadač vrši napad s 10 damagea i da meta ima 25 armora. Prvih 10 poena armora reducira damage za 5 (10*0.5), sljedećih 10 za 2.5 (10*0.25) i zadnjih 5 za 0,625 (5*0.125) i napadač vrši ukupno 10 -5 - 2.5 - 0.625 = 1.875 poena štete. Znači za svaki višekratnik armor oduzima dodatan damage ali s dvostruko manjim faktorom. To je približno jednako eksponencijalnom utjecaju, pogotovo za veće vrijednosti armora:


Usporedba


Očigledno je da sam protiv Warcraftovog damage reduction pristupa (jer utjecaj armora ne može ne ovisiti o napadaču). Pristup s oduzimanjem ima mane kada su damage i armor u nesrazmjeru. Kada je damage puno veći od armora, zapravo je i logično da bi armor trebao imati jako mal utjecaj. Činjenice da se moraju izmišljati dodatna pravila kada je armor veći od damagea i da se brojke ponašaju skokovito kad je damage jedva nešto veći od armora razlozi zašto ne odabrati takav pristup.

Pristup kojeg koristi igre Warlords Battlecry je zanimljiv i nakon malo analize, rekao bih da ispunjava očekivanja. Nedavno sam i sam smišljao formule za utjecaj armora. Formula do koje sam došao slična je onoj koja se obično koristi za vjerojatnost pogotka a izgleda ovako:


Usporedbe radi napravih sljedeća dva grafa. Prvi prikazuje funkcije za armor = 10 (pretežno slučajevi kada je damage veći od armora) a drugi za armor = 40 (slučajevi kada je armor veći od damagea).

Kao što se može iz ovog grafa vidjeti, pristup iz Warlords Battlecrya za veće vrijednosti damagea u odnosu na armor prelazi u obično oduzimanje (ali s duplo manjom vrijednosti za armor). Kontinuirana inačica WB pristupa tj. eksponencijalna funkcija se u području kada je armor veći od damagea gotovo poklapa s originalnom WB metodom. Zbog toga i zato što je ta inačica lakša za ukucavanje u Excel (lijenost FTW i zapravo sam koristio OpenOffice ekvivalent za MS Excel), na drugom grafu nije prikazana originalna WB metoda. U području gdje je armor manji od damagea, kontinuirana WB inačica konvergira u obično oduzimanje ali s neobičnom vrijednosti za armor (armor*ln(2)). No ta neobičnost ionako nije važna jer je tada damage ionako ogroman u usporedbi s armorom. Ono što je bitno je činjenica da se na početku ponaša slično kao i originalna WB metoda, da ima približno jednak utjecaj kao obično oduzimanje s armor/2. Moja funkcija također konvergira u obično oduzimanje ali za razliku od WB pristupa, konvergira u pravo oduzimanje kakvo je u Starcraftu i to relativno brzo.

Na koncu, kontinuirana inačica WB pristupa mi se čini kao najelegantniji pristup. Doslovce one liner i jasno razumljiva formula. Plus k tome, bazom potencije se može podešavati strmina funkcije.

Monday, August 1, 2011

Zvjezdojedac, planovi za verziju 0.4

Ukratko stavke za slijedeću verziju Zvijezdojeca su slijedeće:
  • Upravljanje na razini zvjezdanog sustava
  • Umjetna inteligencija za upravljanje kolonijama
  • Svemirske bitke
  • Preinaka prikaza informacija za kolonije
  • Prikaz liste kolonija
  • (Možda) Preinaka varijabli za formule da budu strong typed


Upravljanje na razini zvjezdanog sustava

Kao što sam napisao u prošlom postu, maknu bih podjelu gradnje na civilnu i vojnu i napravio bih da se brodovi grade na razini cijelog zvjezdanog sustava. Nešto slično kao u prvom Master of Orionu. Na svakoj koloniji bi se moglo odrediti koliko se sredstava odvaja za projekte na razini sustava a upravljanje redom gradnje bi se vršilo na sučelju koje je trenutno prikazuje informacije o zvijezdi i popis planeta.

Umjetna inteligencija za upravljanje kolonijama

Globalni plan za UI je da se upravljanje razlomi na razine. Prva razina bi bila glavna mapa. Algoritam bi određivao koliko je pojedini sustav u posjedu ugrožen i kolko su ostali sustavi pogodni za istraživanje i naseljavanje. Na temelju tih informacija bi se slali brodovi i određivala tendencija gradnje brodova. Druga razina bi bila pojedinačni zvjezdani sustavi. Algoritam bi za tu razinu na temelju informacija s prve razine određivao što će se graditi na razini sustava (da li ratni brodovi, da li kolonizatori ili poboljšanja za planete). Također, na toj razini bi se određivala tendencija ulaganja u zvijezdani sustav tj.  koliko će kolonije odvajati sredstva za sustav a koliko za sebe. Treća i najniža razina bi upravljala samim kolonijama. Znači, što kolonije grade i koliko u što ulažu.

Za početak napravio bih nešto jednostavno, UI koji će razvijati svaku koloniju kao da je sama svemiru. I dodato bih neki jednostavan algoritam za drugu razinu kako bi računalni protivnici gradili brodove za testiranje bitaka.

Svemirske bitke

Najsočniji dio svake igre. Trebam još definirati kako će se koji atribut ponašati. Imam neke ideje ali moram ih još uskladiti. O tome više kada ova stavka dođe na red.

Preinaka prikaza informacija za kolonije

Trenutni prikaz mi se čini kao da prikazuje previše informacija odjedanput. Htio bih napraviti sučelje na kojem se na prvi pogled može vidjeti koliko je koja kolonija razvijena i produktivna a da se do detaljnijih informacija može doći kada se miš pozicionira iznad pojedine stavke (Civilization 4) ili na klik (desni klik u Master of Orionu 2). Time bih dobio više mjesta za prikaz detaljnih informacija i izračuna kako je koja brojka dobivena i na sučelju za kratki pregled, ne bih morao prikazivat puno toga.

Prikaz liste kolonija


Nekoć davno 4X strategije sam igrao na način da bi svaki krug zavirio u svaki grad/koloniju i gledao da li mogu što poboljšati. Takvi turnovi su znali potrajati i po 10 minuta. S vremenom sam se naučio kako se većina micromanagmenta može izvesti preko popisa kolonija (Master of Orion) odnosno gradova (Civilization 3). Kod takvog pristupa, turnovi traju pola minute. Moć popisa kolonija zasniva se na prikazu bitnih informacija i načinu sortiranja stavki. Dobar popis kolonija treba biti u stanju odgovarati na upite dosta visoke razine, kao npr. "koje kolonije su dobre za izgradnju brodova?" ili "koje se kolonije još trebaju razvijati".

Za početak ću napraviti jednostavnu listu s nazivom kolonije, populacijom, procjenom razvijenosti i nazivom zgrade u gradnji i s mogućnošću sortiranja po tim svojstvima.

Preinaka varijabli za formule da budu strong typed


Ovo više finesa ispod haube. Ideja je da od <string, double> hash tablica u kojima se može nalaziti sve i svašta, napravim singleton razred u kojem će za svaku varijablu u igri postojati članska varijabla. Prednosti takvog pristupa su da ću imati jedno mjesto na kojem će varijable biti hijerarhiski poslagane, neću morati izvoditi finese s nazivima varijabli (trenutno skoro svaka varijabla ima za svoj naziv const string da ne moram rovat po kodu i prepisivati), možda će biti brže, ne ću morati instancirati toliko dictionary<string, double> objekata i biti će manje parametara u metodama za izračun vrijednosti formula.

Uglavnom, uz par velikih djelova gameplaya ova verzija će biti više fokusirana na fluidnost sučelja. Nadam se da ću je dovršiti do kraja godine a ako Bog da, u roku 2 mjeseca. I da ću po implementiranim featureima prestići FreeOrion :)