New code organization

Terrain for a new version is being prepared. Currently I'm working on how should the source code be organized. As stated (hinted that is) in previous post there will be separate projects for the "game core", GUI, map generators and AI, see the big picture below. Game core would consist of game mechanics (MVC model), MVC controller and interfaces for map generators and AI.

Second thing I'm working on is documentation for the code organization. There will be a document that lists and describes responsibilities for each component. It will answer questions such as what data should be in "Game" class, what data should be in "Player" class, what namespace is responsible for what and stuff like that.

Third thing is external dependencies. There should be well define formats for data files and localization files. I was looking for third party solution but wasn't really happy with any. XML is not exactly "human readable" and more importantly, not human editable. Only environment where XML is OK is when developing Android applications in Eclips IDE. Eclipse with Android Development Tool make a very powerful and easy to use environment but in the case of Stareater there is not going to be such advanced support just for editing XML. JSON and YAML were also considered. There is a quite good .Net library for JSON, Json.NET and a solid library for YAML, YamlSerializer but I wasn't fond of using either markup. Maybe it's just me being picky... Anyway, I've created yet another "my own format" that meets my needs.

That's just about how to read and write data files but there is more to be defined on how to format the data. In previous versions, there were two complex data formats, functions and text builders. Functions were used to represent values such as how food production changes with technologies and how damage increases with weapon tech level. Problem with functions was that their textual representation were either prefix  or postfix (also know as Polish and reverse Polish notations) to simplify parser. Prefix and postfix are notations where operator is before (prefix) or after (postfix) operands while notation where operator is between operands is called infix notation. Simple a + b translates to + a b in prefix notation. Prefix and postfix notations are easier to implement, operator precedence is not an issue and there is no ambiguities such as 2/3/4=?. Those notations are too much machine/algorithm oriented, expressions with more than one operator may look cryptic to the eyes used to infix notation. In v0.5 I'm going to make parser for infix expressions. ANTLR looks like a good tool for making parser in .Net though they have silly homepage :).

Text builders are used for localization. Initial idea was to make a simple key-value mapping where a key is a kind of the text identifier and a value is localized text. Than I've spotted situations like "Remaining: 5 turns" would require two key-value pairs to localize because it brakes down to the following sequence of textual units: transalation for "Remaining", semicolon, number of turns, translation for "turns". Another thing to notice is that last word should not always be in plural. To cope with that, localization data format had three ways of expressing localized text. One was simple single line of text, another was sequence of primitives (literate texts, conditions, functions) and last one was multiline block of text with substitution parameters. It was not hard to implement that and it was indeed powerful enough to put words in the proper form even in Croatian but readability was not the strongest point. Hopefully in v0.5 it will  improved.

Uf, that's a lot of work and I haven't even started with GUI. Good design documents are the key and I'll spend some time writing them before I star coding.

Stareater 0.4

Five days ago version 0.4 finally got packed up and ready for download. Big changes happened between 0.3 and 0.4, space combat is implemented, ship design interface is changed to reflect redefined space combat, star system management is introduced, part of colony management is moved to star system and basic AI is implemented.

Plans for version 0.5 are not yet defined but this is a list that is currently on my mind:

• Define exactly how planets and colonies work
• Refactor whole code base
• Redo GUI
• Victory conditions

Only last item adds something tangible to the game but other items where piling up for a long time. It's time to do those things right. Every now and then something about colonies would go off. Since all game mechanics are based on non-integral arithmetic final numbers can get too low or too high than intended if parameters are  not constrained. Math behind colonies has such problems and I'd like to take some time to think about how exactly colonies should behave. There are other part that I'll address in a similar manner such as map generation.

Refactoring is also something that should be done before adding more features. I'd like to strip user interface code from all non-interface related code. That means game logic, data preparation and data conversion should be outside the GUI source code (classes). I'm aiming for model-view-controller design pattern where game logic is model, GUI is view and controller mediator between them. Also I'd split source code to two projects, one with model and controller and other with GUI. While refactoring, I'd like to redo whole GUI. There has been a number of conceptual changes that are not properly propagated to the user interface and some thing simple has to be done differently. Galaxy map is such thing. I'd like to scrap "big picture box in scrollable pane" implementation and try my luck with OpenGL.

That's enough to keep me busy until the end of the year.

The blog

Finally decided to open a dedicated blog for Stareater and to write it in English. I was delaying that until project had more to show but I've decided to stop spamming my main blog with Stareater this, Stareater that kind of posts and Blogger service likes like it more aligned to multiple blogs with few topics then a few blogs with various topics. This is first official post on this blog and posts before this one are imported from my main blog. That's why those posts are in Croatian.

Stareater galaxy map and colony view

So, what is Stareater? It's a strategy game, 4X TBS, Master of Orion wannabe. Early development was simply to implement a prototype with game mechanics with minimal user interface, to test out the idea but now I see I'll have to devote a lot more energy to GUI. After all, I don't want to make another Master of Orion III, a game that bombards with numbers but doesn't tell what they do. Stareater will be the game where player rules from high above, mostly doing macro-management decisions and moving star ships. There will be an option to do micromanagement decisions but that won't be mandatory.

More information about the project is on Google project hosting site:
http://code.google.com/p/zvjezdojedac/

Don't be alarmed by word "zvjezdojedac", it's just stareater in Croatian. Initial development was completely in Croatian, from code to user interface. Since I'm going to increase awareness about this project, I slowly adopting a "common trade language" to it.

Zvjezdojedac 0.3.3

http://code.google.com/p/zvjezdojedac/downloads/list

Prošli tjedan stavih novu verziju Zvjezdojeca na download. Kao što sam pisao u prošlim postovima, u novoj verziji je implementiran space combat. Uz sam space combat dodah još malo contenta, warp pogon i čestični štit. Doduše te komponente su dodane čisto zbog testa space combata.

Space combat commitan

Whoohoo! Nakon pet mjeseci source code je konačno stabilan. Doduše ima jedno mjesto gdje se krši, u starom sučelju za dizajniranje brodova. Sredim to, istestiram još malo bitke, malo zglancam sučelje za bitke i ide novi build u download sekciju.

Space comat radi

Space combat u Zvjezdojecu je implementiran. Još ga nisam do kraja testirao ali chance to hit, damage reduction, i uništavanje brodova funkcionira. Čim stavim da se bitke mogu razriješiti, uploadam u repozitorij. Trenutno se combat turnovi odbrojavaju ali se ništa ne dogodi kad se prođe "zadnji" i potpuno uništenje protivničke strane isto trenutno ne dovodi do razrješenja bitke.

Našao sam zašto se događao bug kod učitavanja igre, zbog kojeg si igrači odjednom dobe par tisuća brodova. Stari problem s decimalnom točkom. Količina ostatka gradnje je bila pohranjena s decimalnim zarezom (regionalne postavke na Windowsima) a kod učitavanja se tražila točka (eksplicitno specificiran format). MICROSOFTE, ZAŠTO MJEŠAŠ STROJNI I KULTURNO OVISAN PRIKAZ BROJEVA? Naime, C#-u double tip podatka služi za pohranu realnih brojeva (uz kolku tolku preciznost), na svakoj varijabli i konstanti tipa double se može pozvat metoda za pretvorbu u tekst (tako reći). Moj problem nastaje u tome što se broj pretvara u tekst poštujući regionalne postavke operativnog sustava. Osobno smatram da se to ne bi trebalo tako raditi je vrijednost tipa double sama po sebi ne pripada ni jednoj državi ili kulturi. Kada se double vrijednost pita za tekstualni zapis, trebao bi se koristiti neki univerzalni format. Univerzalan u smislu da ne ovisi o ničem osim o samoj brojčanoj vrijednosti. Turčin, Arap, Kanađanin i Francuz bi za istu double vrijednost trebali dobiti isti tekstualni zapis. Za prikaz broja u kulturno ovisnom zapisu bi se trebala koristiti metoda kojoj se eksplicitno definira način pretvorbe broja u tekst.

Nazad na temu. Zadnjih par dana sam se uhvatio u koštac s balansiranjem igre. Htio sam se koncentrirati na testiranje i dovršavanje space combata ali brojke koje sam još davno postavio za snagu napada i obrane su takve da bitka traje u nedogled. Kako sam bio prije testirao tehnologije i mehanizme automatske nadogradnje tako je ispalo da igrači odmah u startu imaju do kraja nadograđen tier 3 oklop i da obični kolonizator ima 12k hit pointa dok je napadač s kojim sam testirao imao 8 strojnica koje su na taj oklop radile oko 9 damagea. S takvim brojkama bitka je trajala 170 krugova a ciljam na to da je ograničenje broja krugova za bitku negdje oko 20. Problem kod kolonizatora je što moraju s jedne strane biti ogromni a s druge ranjivi. Već prije sam razmišljao o tom da dodam specijalnu opremu za proširenje teretnog prostora i mislim da ću to napraviti u ovoj verziji. Nešto u stilu battle podsa iz Master of Oriona 2 ali da se uz povećanje nosivost se smanje hit pointi. To ja lagan dio posla, ono što je crna rupa koja upija sate mog rada je izbor brojki za damage oružja. Recimo za sam što na empirijski što na egzaktan način došao do načela po kojem određujem brojke za nosivost i izdržljivost vrsta trupova i sve komponente koje utjeću na vjerojatnost pogotka. Ali brojke za damage mi nikako ne idu. Načela kojih bih se držati su da brodovi iste veličine i tehnologije se međusobno unište unutar 5 krugova i da manje više svaki vojni brod može u dogledno vrijeme uništiti kolonizatora.

No već ću nešto smislit, dovršiti testiranje i uploadati u repozitorij. Nakon toga malo dotjerati GUI, spakirati u release i staviti na download.

Zvjezdojedac, zastavice

Zar je već prošlo mjesec dana od zadnjeg posta? Hmm, dobar ovaj posao koji radim kad mi ne primijetim da vrijeme proletjelo.

GUI za space combat napreduje polako ali sigurno. Konačno sam napravio prikaz pozicija brodova (ona 4 crna kvadratića iznad popisa brodova). Prikazuju se trokutići koji govore na kojoj poziciji ima brodova i kamo se kreću, prikazuju se zastavice za prisutne igrače na pojedinoj poziciji i klik na kvadratić šalje GUI event s potrebnim podacima. Obrada tog događaja baš ne funkcionira najbolje ali to je slijedeće na dnevnom redu. Još mi od vidljivog dijela GUIa nedostaju kontrole za upravljanje brodovima i za upravljanje bitkom (end turn i auto combat gumbi) no to već imam spremno u obliku skice.

Htio sam biti nadobudan prošlu nedjelju i napraviti kompletni space combat u jednom danu. Kako je taj dan bio prvi april, dobro sam se našalio. Dan je završio tako da sam u SPAZu došao s levela 25 na level 48. Realno, mislim da za dovršiti space combat treba više od 12 h. Jučer sam radio na pretvaranju "taktike" i "poželjne pozicije" i potrošio sam oko sat i pol. Po starom modelu brodova za dizajn se trebala definirati taktika, da li će brod funkcionirati kao presretač, da li će se držati po starni ili će biti na nekoj srednjoj udaljenosti. Po novom modelu brodovi se mogu kretati po pravcu i taktike su se pretvorile u pozicije. Najbitnija razlika je da je za svaku taktiku bilo posebno definirano kakvi su joj efekti a za pozicije jedan set formule koje vrijede za sve pozicije. Efekti pozicije računaju se tako da se u formule se uvrsti udaljenost između brodova. Ne izgleda kao velik posao ali eto, ode sat vremena samo tako jer promjene nisu samo u jezgri igre već i na GUIu i u data fajlama (karakteristike, nazivi i prijevodi) i još k tome dosta sam se vrtio koji razred instancira kojeg.

Jedno dana kada ću imati vremena, prerovati ću source code vezan za dizajn brodova. Trenutno za svaki tip komponente broda postoje dva razreda, jedan koji općenito opisuje komponente (tzv. info) i jedan koji opisuje konkretnu instancu. Ono što mi se ne sviđa je da su info razredi ugnježdeni pripadnim razredima za konkretne. Razlog tome je bio funkcionalnost da samo info razredi mogu napraviti instancu konkretne komponente. Ta funkcionalnost je ostvarana tako da razred za komponente imaju privatni konstruktor a info razredi pošto su ugnježdeni jedini imaju pristup tom konstruktoru. Imam ideju kako to smisleno izvesti bez ugnježđivanja razreda ali o tom potom, to je low priority.

Vidjeh da ima već 3 mjeseca od zadnjeg commita koda u repozitorij. U međuvremenu se zbilo dosta promjena ali stvar još uvijek nije stabilna a ne volim objavljivat kod koji ne radi. Trenutno kada se inicira space combat, GUI za bitku se ne da ugasiti i igrač ne može dalje igrati. Naime, kada se ugasi prozor za bitku, program zatraži igru slijedeći nerazriješeni konflikt a pošto se trenutno konflikti ne mogu razriješiti, igra mu vrati isti i tako u beskonačnost. Kad napravim space combat, tako će sjesti jedan fini debeli commit, uff.