Achievementi

Nekoć davno su igre imale isključivo bodove kao mjerilo igračeve vještine. Danas su to mjerilo postali achievementi. Ako se igra distribuira preko Steama, jednostavno mora imati achievemente. Zanimljivo je promatrati kakve sve ideje ljudi imaju za achievemente, bedževe i ostale unlockable stvari. Ali ima par stvari koje mi se ne sviđaju i na koje bih se osvrnuo.
 
Achievementi za puku činjenicu da igrač igra igru. To su achievementi tipa "završi igru", "skupi x toga i toga", "uništi y neprijatelja". Te stvari uopće nisu dostignuća, ne odražavaju igračev trud (s time da ponavljanje jednostavnih radnji milijun puta ne smatram trudom). Ipak govorimo o igrama a ne o poslovima u stvarnom životu. Isto tako ne prihvaćam achievemente tipa "pokupi rijetki random drop" kao dostignuća jer je riječ o šansi koja nema veze s igračevom vještinom.

Po mom mišljenu achievementi bi se trebali otključavati na akcije koje ne spadaju pod regularno igranje igre i iziskuju dodatan trud od igrača. Npr. završavanje neke misije bez primanja štete ili prelazak nekog dijela nivoa na teži način i sl.

Zvjezdojedac, space combat

Izgleda da će implementacija space  combata ići puno sporije nego što sam mislio. Prvo zato što izrada dokumentcije traje, drugo, mislim napraviti promjene na GUIu za dizajniranje brodova i treće zato što je real life posao uvatio maha.

Dokumentacije sam se uhvatio zato što  na mali milijun mjesta imam napisane ideje za space combat koje nisu 100% konzistantne i potpune. Za sada imam 4 strane i materijala za još dvije. Ne zvuči puno ali za svaki odlomak sam morao pet puta razmisliti da li dobro opisuje ono što želim, kako se to slaže s ostalim idejama i da li bi taj odlomak trebalo premjestiti na neko drugo mjesto u dokumentu. Dokumentaciju bih trebao dovršiti ovaj tjedan.

GUI za dizajniranje brodova trebam kompletno pretumbat. Možda čak napraviti ispočetka. Pod broj jedan zato što se bussines logika promjenila. Pod broj dva i tri zato što bih napravio kao odvojen prozor, ne kao tab i zato što promjenio izgled same forme.

Neću ni procjenjivat kad će space combat bit gotov. Bio bi sretan da ove godine :). S druge strane, kad imam viška vremena a nisam pri kompu, pišem si ideje za tehnologije. Za sada imam 30-ak tehnologija i inspiracije za još upola tolko. Poućen iskustvom s Char lovca i Zlih poligona, smišljanje sadržaja igre ne treba čekati kraj programerskog posla jer se jednostavno izgubi zanos. Isto tako, treba razmišljati o brojkama u smislu ako je na početku izdržljivost oklopa x, pred kraj normalne partije na srednje velikoj mapi bi trebala biti 5x. A sad nazad na dokumentaciju...

Passwordi

Nedavno sam guglajuči jedan pojam, naletio na drugi koji mi je odvukao pažnju, znate kako to biva. U jednom trenutku sam naletio na članak na Coding Horroru u kojem autor tvrdi da je sigurnost u internetu jako slaba tj. da passwordi koje većina ljudi ima su "preslabi".

Ono što mnogi članci koji se bave tom temom iznose (i s čime i ja slažem) je činjenica da su korisnici web usluga tako reći trenirani da smišljaju komplicirane šifre (kombinacija brojeva, velikih i malih slova i specijalnih znakova). Zbog naglaska na složenost, kako bi ih lakše pamtili, ljudi obično smišljaju kratke passworde. Tipa 6 do 8 znakova. Na siteu InfoWorld.com sam čitao članak u kojem čovjek koji se navodno bavi probijanjem passworda (u svrhu ispitivanja sigurnosti, ne zato da krade podatke) tvrdi da se šifre kraće od 10 znakova probijaju bez problema. E sad, da li to znači da ih se probije u roku deset sekundi ili u roku sat vremena, ne znam al sam uvjeren da je u pitanju manje od 24 sata.

Nazad na problem. Postoji problem s "algoritmom" po kojem obični smrtnici smišljaju šifre. Kuharica ide ovako:
1. uzmi nasumičnu riječ, npr. klokan
2. zamjeni slova s brojkama (klokan -> k10k4n)
3. pretvori nekoliko malih slova u velika (k10k4n -> k10K4n)
4. ako šifra nije dovoljno dugačka, dodaj nešto jednostavno na kraj (k10K4n -> k10K4n5)

Problem je u tome što je recept dobro poznat. Svako ko na ovaj način smišlja šifre misli da je pametan i da mu je šifra neprobojna dok napadači s druge strane znaju da puno ljudi ima upravo takav tok misli. Mane kod smišljanja kompleksnih šifri postaju izraženije kada isti korisnik mora pamtiti više takvih šifri. Čovjek prirodno želi sebi olakšati posao a to znači pamtiti čim manje kompliciranih stvari. S toga ljudi ili smišljaju više lako pamtljivih šifri ili manji broj (obično jedan) master passworda.

OK, ljudi smo, imamo ograničeno pamćenje i strpljenje no kako da si pomognemo? Moderne tehnologije zaštite podataka se nažalost temelje passwordima. Koliko je "jaka" šifra, toliko su dobro zaštićeni podaci. Možemo si pomoći na dva načina, korištenjem tzv. passphrasea i zapisivanjem šifri koje ne možemo zapamtiti.

Passphrasei su zapravo šifre sastavljene od više nasumičnih riječi. Na primjer "AutoBakaCiklaDvoranaEtanol". Fora kod passphrasea je da su dugački kada se raspišu a lagani su za zapamtiti. No koliko je siguran ovakav pristup? Gore sam spomenuo navod iz članka koji tvrdi da password mora imat barem 10 znakova da bi se mogao smatrati sigurnim no brojanje slova u passphraseu ne daje pravu mjeru sigurnosti. Daleko od toga. Ako napadač pretpostavi da žrtva koristi passphrasse onda se može ograničiti na određen skup riječi a ne pogađat nasumce sve znakove.

Uzmimo s jedne strane passworde koji se sastoje isključivo od engleskih slova i brojki (ukupno 62 različita znaka) i s druge strane passphrasove načinjenih od nasumično odabranih riječi iz rječnika s 5000 riječi (vidi linkani člank s Coding Horrora). Ne toliko kompliciranom matematikom (log 5000 / log 62 = 2.0637) dobivamo da svaka riječ passphrasea vrijedi oko dva znaka passworda. Znači da bi postigli sigurnost passworda duljine 10 znakova, passphrase treba bit načinjen od 5 riječi. Ne zvuči baš puno bolji omjer sigurnosti i praktičnosti od klasičnih šifri. Ubacivanje nasumičnog znaka na nasumično mjesto može malo poboljšati sigurnost passphrase. Za passphrase AutoBakaCiklaDvoranaEtanol svako dodavanje nasumičnog znaka (slovo engleske abecede ili broj) podiže sigurnost za 1.78 znaka prethodno opisanog oblika passworda. No ako se u passphrase ubaci puno takvih znakova, izgubi poanta passphrasea. Passphrase zapravo postane dugački password sa svim manama passworda.

Druga metoda je korisnik za sve ima drugačiji i siguran password (dovoljno dugačak i nasumičan) i da ih sve ima zapisane na jednom mjestu. Znači, da korisnik ne pamti sve šifre nego da ih drži na sigurnom mjestu i kopira od tamo kada mu koja zatreba. Mane ovakvog pristupa su sigurnost i pristupačnost repozitorija šifri. Ako napadač probije zaštitu repozitorija, dobiva na raspolaganje sve šifre koje su pohranjene u njemu. Ako korisnik izgubi repozitorij (npr. krepa disk), gubi pristup šiframa i svime što te šifre otključavaju. E sad, ako je netko optimističan i misli da neće pobrati keyloggera ili neki sličan spyware, može probati Keepass 2 u kombinaciji s DropBoxom.

U svakom slučaju, za stvari koje su vam bitne imajte šifru duljine barem 10 znakova.

Zvjezdojedac, progress report

Napravih računalnog igrača koji nasumično gradi brodove i pripremih teren za pravi UI (umjetnu inteligenciju) koju će igra kasnije imati. Uz to dio te podloge bi se mogao iskoristiti i za multiplayer, za remote igrače.

Prošli feature na kraju nisam zapakirao i stavio na download jer nije bilo skoro ništa vidljivih promjena. Uvođenje jednostavne UI isto nije neki vidljivi napredak ali količna popravljenih stvari bi opravdala podizanje verzije za 0.0.1. Tako da ću ovih dana staviti za download novu verziju.

Edit:
Prema indikatoru na Google Codu, projekt je nazad na "high activity". Jupi!

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.

Attack rating II

Ovaj post se nastavlja na prethodni.

Razmatranje nelinearnih modela htjeli ili ne, zahtjeva malo višu matematiku. Pokušati ću ne komplicirati.

Ima jedna igra u kojoj sam vidio na djelu ne linearnu inačicu modela temeljenog na razlici attacka i defensa. Master of Orion II. Inače, obožavam tu igru no neću koristiti ovu priliku da ju hvalisam. Master of Orion II: battle at Antares koristi tzv. logističku sigmoidalnu funkciju [1] za pretvaranje razlike attacka i defensa u vjerojatnost pogotka. Logistička sigmioda ima mnogo lijepih svojstava [2], linearna je oko nule, derivabilna je, ima lijepi integral itd. U Master of Orionu II dobro funkcionira dok je razlika između attacka i defensa manja od 100 no izvan intervala [-100, 100] praktički se događa imunost na kocku. Mislim, u svakom modelu  će se uz dovoljno veliku razliku u attacka i defensa pojaviti imunost na kocku. Ili tako da kocka uopće ne utječe na ishod ili tako da je vjerojatnost jednog ishoda 99.9999% a drugog 0.0001% (tzv. zasićenje). Naime, to je ok kada je razlika attacka i defensa, u kontekstu igre, ogromna. Npr. kada običan miš pokušava ozlijediti ninđu.

Da bi nastavili analizirati nelinearne modele, moramo prvo definirati relevantna svojstva. Naš idealan model trebao bi zadovoljavati slijedeće:

• Linearnost oko nule. Ako su attack i defense jednaki, vjerojatnost pogotka je 50%. Manja odstupanja od jednakosti linearno povećavaju ili smanjuju vjerojatnost. Npr. 1 poen attacka ili defensa povećava ili smanjuje vjerojatnost za 1%.
• Asimptote na 0% i 100%. Za veće razlike u korist attack ratinga, vjerojatnost se približava vrijedosti od 100% ali ju nikad ne sustiže (niti ne prelazi). I obratno, za velik defense u odnosu na attack vjerojtanost teži u 0%. Ovo svojstvo povlači zahtjev da nelinearna funkcija mora imati vrijednosti u intervalu [0, 1] (1 = 100%).
• Opadajuća granična korisnost. Kod većih razlika attacka i defensa, 1 poen gore-dolje manje utječe na vjerojatnost pogotka nego kod manjih razlika.
• Simetrija s obzorom na (0, 0.5). Drugim riječima ako je attack rating x poena veći od defense ratinga, da je vjerojatnost pogotka jednaka vjerojatnosti promašaja kada bi attack rating bio istih x poena manji od defense ratinga.

Ponašanje granične korisnosti je svojstvo po kojem se dobri modeli razlikuju od loših. Npr. u linearnom modelu događa se da kod malih vjerojatnosti pogotka svaki poen puno znači, recimo da svaki poen mjenja vjerojatnost za 5%. +5% na 5% znači duplo veća vjerojatnost dok +5% na 90% ne čini tako drastičnu razliku. I to smatram lošim. Dobar model bi trebao biti taka da svaki poen ima otprilike jednak utjecaj na vjerojatnost pogotka.

Eksponencijalna funkcija

Ako želimo da svaki poen razlike jednako utječe na vjerojtanost tako da svaki poen razlike povećava ili smanjuje očekivan broj pogodaka  za 1% (npr. ako je vjerojatnost pogotka 30% i napadač si poveća attack rating za 10 poena, da se vjerojatnost pogotka poveća na 33%), tada je traženi model u obliku eksponencijalne funkcije. Osobi pokušaj konstrukcije takve funkcije doveli su me do formule slijedeće formule:

Gdje je baza potencije (parametar a) utječe na strminu funkcije, odnosno na to koliko svaki poen utječe na vjerojatnost. Ako želimo da bude točno 1 poen -> 1% tada baza treba biti . Ako je nekome to preekzotičan broj, može slobodno uzeti a = 0.98 što je otprilike tu negdje. Funkcija je podijeljena na dva segmenta kako bi se postigla simetričnost.

Na slijedećoj slici prikazane su logistička sigmoidalna funkcija (zlatna linija), prilagođena eksponencijalna funkcija (plava linija), linearna funkcija (crvena) i još jedna sigmiodalna funkcija (ljubičasta linija). Funkcije su podešene tako da nagib u nuli iznosi 0.01 (za pomak na x osi za jednu jedinicu, funkcija raste ili pada za 0.01 jedinicu na y osi).

Iz grafa se može vidjeti kako linearna finkcija izvan intervala [-50, 50] više ne može poslužiti kao funkcija vjerojatnosti (jer joj vrijednost izlazi iz intervala [0, 1]). Logistička sigmoida nema takvo ograničenje ali njena praktična primjena prestaje izvan intervala [-100, 100]. Modificirana eksponencijala ni se nekako čini najbolji izbor, interval na kojem je primjenjiva je otprilike [-150, 150], možda čak i na [-200, 200] i trend promjene je upravo takav da svaki poen ima svoj značaj. No da li bi to bio dobar izbor, jednostavno treba isprobati.

Attack rating

Mnoge igre, posebice RPG-ovi uključuju "bacenje kocke" u procesima odlučivanja. I većina igara radi to ofrlje, izabirući jednostavan model. Na primjer, u Diablu 2 vjerojatnost zadavanja štete računa se po formuli ovoj formuli:

gdje je a "attack rating" napadaća i d "defense rating" mete. To je zapravo jednostavan omjer, napadač ima a naprama d šansi za pogodak. Taj pristup smatram lošim jer dovodi do toga da kako igrač napreduje, attack i defense rating moraju rasti eksponencijalno. Recimo da na početku igrač ima attack rating 10 i da neprijatelji imaju defense rating isto 10. To daje vjerojatnost pogotka od 50%. Da bi igrač podigao vjerojatnost pogotka n 75%, mora si utrostručiti attack rating (znači na 30). Da bi neprijatelji bili izazov, moraju do neke mjere pratiti igračev razvoj tako da će se u jednom trenutku dogoditi da igrač ima attack rating 30 i neprijatelji defense rating 30. I opet igrač mora utrostručiti svoje brojeve da bi dobio prednost i tako u nedogled. Brojevi počnu divljati, sustav postane noćna mora za balansiranje i u najgorem slučaju dio igre ovisan o tom modelu odlučivanja kockom prestane funkcionirati. Osobno tu pojavu nazivam "eksponencijalnom zamkom".

Primjer drugi, D&D. U D&D-u (mislim da od 2nd editiona na dalje) odlučivanje o pogotku se vrši tako da se na napadačev attack rating doda iznos s kocke i ta suma usporedi s defense ratingom mete. Ako je defense rating manji od te sume, napadač je pogodio. Ovakav pristup nema problema s eksponencijalnim rastom brojeva i čini mi se dosta lakši za balansiranje. No pati od problema kojeg osobno nazivam "imunost na kocku". Ako je napadačev attack rating bez kocke veći od metinog defense ratinga, napadač će uvjek pogoditi. S druge strane, ako meta ima veći defense rating od sume napadačeva attack ratinga i maksimalnog iznosa kocke, tada napadać neće nikad pogoditi. Taj se problem može izbjeći pravilima da napadać ima barem x% šansi da pogodi (npr. ako dobije 20 na d20 "kocki") i barem y% šansi da promaši (ako dobije 1 na d20). No osobno, kada bi radio RPG pokušavao bi izbjeći takvim iznimkama.

Varijacija na temu je model koji se koristi u iPhone igri Uniwar [1]. Ako napadač ima attack rating jednak defense ratingu mete, šanse za pogodak su mu 50%, za svaki poen razlike, šansa se povećava ili smanjuje za 5%. Praktički isto kao i u D&D-u samo je uklonjena potreba da defense rating u startu bude 10. I u Uniwaru to savršeno funkcionira iz prostog razloga što je igra strategija a ne RPG. Attack i defense rating jedinica se ne mjenja u tolikoj mjeri kao u RPG-ovima i balansom je postigunto da ne dolazi do problema imunosti na kocku.

Dosta sam si razmišljao kakav model odabrati u igrama koje trenutno postoje samo u mojoj glavi. Trenutno mi se model temeljen na razlici, kao u D&D-u i Uniwaru, čini kao way to go. No ono što mi se ne sviđa je spomenuti problem imunosti na kocku. Ako se malo bolje pogleda, taj problem prizlazi iz toga što se vjerojatnost linearno mjenja s razlikom attacka i defensa, bez obzira da li je ta razlika 0, 10, 100 ili - 500. Znači, u model treba dodati nelinearnost. Malo sam se igrao s brojkam i formulama, no rezultate ću iznijeti u sljedećem postu.

Otvorih blog

Odlučih nakon skoro godinu dana da ipak nastavim s pisanjem blogova. Pa odlučih to raditi na "google compatible" blog sajtu. Stari blog sam vodio na http://pljs.blog.hr/ ako koga slučajno bude zanimalo.

Kad ulovim vremena, pisati ću o svojim projektima i o ponekim idejama iz sfere programiranja i stuff like that.