Hit pointi i razine damagea

Jedna ideja za game mechanic koja mi se mota po glavi već duže vrijeme je podjela razine damagea na tri razine, shock, minor i major. Pod "razine damagea" u ovom slučaju mislim na hit pointe koji nedostaju unesrećenom, ne na snagu napada. Ideja je ovakva:

• Major damage: ono što je trajno uništeno, što se ne može zakrpati. Npr. kad na letjelici nedostaje cijelo krilo. Jedini način popravka ovakve štete je vraćanje u tvornicu.
• Minor damage: onaj dio štete koji unesrećeni može samostalno popraviti. Npr. ogrebotine i manje rane na čovjeku. Unesrećeni "umire" kada je zbroj minor i major damagea veći ili jednak od maksimumu hit pointa.
• Shock damage: opterećenje obrane. Nije prava šteta no utječe na sposobnost primanja štete. Kod većih razina šoka napadi imaju rade veću štetu, bilo da se napadi vode kao jednostavno jači napada ili da rade ozbiljniji oblik štete (major umjesto minor i minor umjesto shock). Šok s vremenom nestaje, hlapi.

Nešto slično sam vidio u Mortal Kombatu gdje se dio štete može regenerirati ako igrač neko vrijeme ne prima novu štetu.

Ovaj sustav bi mogao lijepo funkcionirati u akcijskim igrama. Igrač ne mora imati puno veći maksimum hit pointa od protivnika da bi preživio višestruke okršaje a s druge strane smanjuje se potreba za omraženom pasivnom regeneracijom. RPGi bi se mogli dizajnirati tako da su paketi prve pomoći koji liječe minor damage lagani za nabaviti a napitci koji liječe major damage znatno skuplji ili da za oporavak od major damagea treba otići u grad kod iscjelitelja.

Još jedan primjer u kojem bi se ovaj sustav mogao iskoristiti su situacije gdje hrpa napadača sa slabim napadom napada dobro oklopljenu metu (12 Protoss Scouta protiv Ultraliska). Obično u tim slučajevima treba cijela vječnost da se uništi oklopljena meta no s ovim sustavom meta bi s vremenom primala sve veću štetu po napadu. To bi tjeralo napadnutog igrača da se aktivno brani čak i u bunkeru.

Zvjezdijedac, progress report

Upravljanje na razini zvjezdanog sustava je bilo gotovo u srijedu ali sam još uvijek nezadovoljan prezentacijom. Mogo bih staviti download ovih dana premda kažem, ne izgleda mi kao zaokružena cjelina. Nedostatke GUIa kanim u što većoj mjeri ispraviti u zadatku #38 (Overhaul colony info window) u kojem se ne bih ograničo samo na GUI za kolonije. 

Uz to, trebao bih konačno konsolidirati procesiranje turnova. Trebao bih si staviti na papir, odnosno napravit si nekakav dijagram na kojem je opisano što se kada računa. Hmmm, možda bih čak mogao dokument s tim dijagramom staviti u repozitorij. I svakako trebam čim više smanjiti ovisnost o podacima pohranjenim u generičnim <string, double> rječnicima. To bi sve moglo povezati sa zadatakom #33 (Turn processing in background) u kojem planiram među ostalom napraviti procesiranje turnova u pozadini.


I na koncu, opet bih mijenjao utjecaj uvjeta na planeti. Imam problema s konceptom da zračenje, gravitacija i atmosfera utječu na maksimun populacije. Što bi se trebalo dogoditi kada se uvjeti pogoršaju? Da li bi populacija koja prelazi novi maksimum trebala nestati u idućem turnu? Ja bih rađe da se ti uvjeti preslikavaju na teže održavanje i manju produktivnost kolonije. Još nisam otvorio zadatak za to ali bih svakako to riješio prije zaključivanja verzije 0.4.

Zvjezdojedac, progress report

Implementacija upravljanja zvjezdanim sustavom je stvarno naporna stvar. Nakon čišćenja donjeg dijela sučelja  na redu je bilo izbacivanje vojne gradnje iz kolonije. To je prošlo manje više bezbolno. Ali dodavanje (više prenamjena stare vojne gradnje) upravljanja sustavom je potrajalo skoro cijeli tjedan. Još nije gotovo, GUI nisam skoro ni taknuo, ostalo je hrpa nekonzistentnih imena, sejvanje trenutno ne radi itd.

Nadam se da ću do srijede bit gotov s time i da će sjest download nove verzije.

Online kalkulatori

Pišući prošli post suočio sam se problemom izračuna limesa za modificiranu funkciju damage reductiona korištenu u igri Warlord Battlecry 3. Možda da nisam taj dio pisao u jedan sat u noći, možda bi sam rješio taj limes. U želji da čim prije odem spavat a da ne ostavljam dio posla nezaključen, upisah u Google "limes calculator". Naravno, Google je našao što tražim bez problema i limes je bio rješen za manje od minute.

Postoji cijelo more online kalkulatora. Prethodno spomenuti limes kalkulator samo je dio alata koje The Number Empire nudi. Ostali alati koji site nudi variraju od rješavača sustava jednadžbi i određivanja derivacije do egzotičnih alata kao što je kalkulator inverza funkcije. Još jedna od "alatki" na koju sam naletio je handymath.com sa zanimljivim alatima vezanim za geometriju, fiziku i kemiju.

Edit:

Nakon x godina života u ne znanju otkrih Wolfram Alphu. Stranica je Google za matematičke operacije. Možete upisati bilo koji pojam, jednadžbu ili tekstualno opisan problem i sustav će ga pokušati riješiti. Lijepo definirane probleme kao što je upit na slici riješava bez problema a dobro se snalazi i s puno složenijim upitima. Jako lijepa stvar kod ove usluge je temeljitost rezultata (grafički prikaz, koraci računa, svojstva dobivenog rezultata) ali još više mi se dopalo što kod složenijih upita lijepo napiše kako je input interpretiran.

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.

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 :)

Zvjezdojedac v0.3

Konačno, nakon skoro godinu dana, dovrših verziju 0.3 Zvjezdojedaca. Stvari koje su nove u toj verziji su:

• Lokalizacija
• Pomicanje brodova
• Podešavanje veličine GUIa
• "Knjižnica" (prikaz istraženih tehnologija i dostupnih komponenti za brodove)
• Migracija populacije
• Odabir početne populacije

Od navedenih, najviše sam se namučio s lokalizacijom, mislim da sam tjedana dana radio na tome. Al mislim da je to feature koji trenutno najviše doprinosi pristupačnosti igre široj publici. Naime, do sada je igra bila isključivo na hrvatskom.

Mogućnost pomicanja brodova je najznačajniji feature što se tiće igrivosti. To sam napravio praktički u 2 dana (po sat - dva svaki dan). I još sam se najviše namučio radeći na GUIu. I naravno da nisam zadovoljan sa  sučeljem.

Migracija populacije je malo manje značajan feature ali sa značajnim posljedicama. Naime, za implementaciju migracije, dodao sam efekte na razini zvjezdanog sustava (npr. ukupan broj ljudi koji se može seliti unutar sustava) što će kasnije omogućavati fensi mogućnosti kao npr. sustav za preusmjeravanje zračenja s jednog planeta na drugi kako bi se povećala temperatura na planetima koji su daleko od matične zvijezde. Općenito mislim neke stvari maknuti s planeta i staviti na razinu cijelog sustava. Jedna od većih ideja je maknuti podjelu gradnje na civilnu i vojnu i napraviti svi planeti u sustavu sudjeluju u gradnji brodova. Nešto u stilu posebnog building queuea za sustav i da se na svakoj koloniji može odrediti koliko resursa se izdvaja za taj building queue.

Odabir početne populacije je isto mali feature s velikim posljedicama. Naime, taj feature me natjerao da preinačim kalkulacije vezane za uvjete na planetu. Morat ću si jedonom sve te formule staviti na jedno mjesto i mic po mic ih podešavati. Bit će dosta posla za slijedeću verziju. Budem sutra razmišljao što ću sve raditi u verziji 0.4.