četvrtak, 8. studenoga 2012.

New game screen


So, GUI time. To be honest, I didn't do much coding. I've spent some time writing about technologies in design document. For now research and development are covered by the document but those topics also opened some new questions and made me aware of one more topic related to technologies. The new topic is  point spending focus. So far I thought about it as a little detail but it turned out it's bigger than that, big enough to have a chapter for it self. The questions I mentioned are should research scale with the number of players and should researched theories be easy share (traded during diplomatic agreement or stolen through espionage). Problem of scaling is that if theories are easy to share, having an ally could drastically speed up the research. I'm not talking about 10%-20%, I'm talking about 100%-200%. By writing this, I recalled a certain feature of Civilization EVO game. Trading technologies there didn't simply counted as acquiring fully researched tech, instead cost of researching traded tech was halved. I like that approach and maybe I'll do something along that line.

Oh, that picture on the top? It's a concept for a "new game" screen/window/form/dialog. It's much like old one except "Map" and "Starting population" drop down menus are replaced with buttons that will open respective dialogs. Reason for those changes are support for multiple map generation methods and more options for starting population. The concept is by no means final and there are some stuff I'd like to change. For instance, there is no way to select player's color and I'd like to add some way for choosing "faction" and color for the opponents.


Also I'd like to mention that I was a little distracted by making tools for creating graphical content. One such tool is for toying with procedurally generated images (picture above). Old images for stars on the galaxy map were in GIF format and don't contain information about transparency in the so called alpha channel and this tool is designed to produce such images. Also the tool is a framework for implementing different image generators.


Other tool is for making "vector graphics", images defined by shapes rather than by limited number of pixels. As you can guess from the picture, the tool will be used for drawing ships for the Stareater. The thing with this tool is that shapes' vertices are always on the grid. Somehow I find it that my drawing skill work best with that restriction.

And last but not least distraction is the IKON library. I was writing unit test for IKSTON to do the "test app" right, to test the nifty TDD features of Visaul Studio and to easily check whole library when I change something. I'll continue with these distractions, I have to write some more unit test for IKSTON and there is still a lot to do on the Grid Canvas (that air plane on the image above). I hope I'll soon find enough motivation to finish the new game screen for the Stareater and to finally start with the interesting stuff.

nedjelja, 7. listopada 2012.

Localization

I was going write about localization as I was implementing it but the lack of a free time prevented me form finishing the post before the implementation was completed. Now that it's finished and it's weekend with holiday on Monday, I finally have the time to write a few words about it.

I did some polishing on the IKON library, my pet project, to streamline the data loading logic in the Stareater. As I said in the previous post, application settings (language choice, GUI size, game settings) use IKSTON variant of IKON and language files use a custom variant.This is how a simple language file looks like:

:FormMainMenu
FormTitle = Main menu
Title = Stareater
NewGame = New game
Settings = Settings
Save = Save
Load = Load game
Quit = Quit
-
Except the first and the last line, entries are key-value pairs. This is the simplest format that is and will be supported. It's easy to read and easy to edit. At least I thinks so, complaint in the comments if you don't think so :). I'm planning to add support form more complex formats along the way.

If you remember from the previous post, each IKON value starts with a "sign", a character that defines it's format. First sign in the example is ":", a colon. That sign defines what I call a context, a named set of key-value entries, much like IKSTON compound value. Terminating character for contexts is "-", a minus. Context in the example is named FormMainMenu and contains entries for the game's main menu. Sign for other values in the example is "=" and represents the beginning of a single line text value. Text in those values  is interpreted as a literal text with stripped leading and trailing white spaces. Other formats I'm planning to implement are for supporting multiline and variable texts. Both formats will be introduced after (re)implementing technologies and expression in data files.

There is one more thing to say about localization support, folder structure. All language data are stored in {Stareater}/language/ folder (where {Stareateris thefolder where the Stareater is installed). Subfolders of that folder are named after the language code, so US English texts are located in {Stareater}/language/en-us/ and Croatian in {Stareater}/language/hr/.  Also if the language is intended to be used as "default", suffix(default) is added to it's folder name. Default language is the language that is set initially and used as a fallback. If a certain translation is not found in the language selected by user, text from the default language will be used.

Now that first few bricks are laid, it's time for more game related work: "new game" screen, map generators and organizations. I finally decided what should be organizations used for (except cosmetics), they would provide bonus level for technologies. Bonus levels would affect benefits from that technology but would not increase research cost and requirements for upgrading technology effectively reducing the cost of developing that tech. Sound simple but don't expect it to be done by the end of a month :).

ponedjeljak, 17. rujna 2012.

IKON and IKSTON

As mentioned before, I've designed my own data format for the Stareater data. The language has an abstract foundation and concrete version. Abstract part is called IKON (Ivan Kravarščan's object notation) and on it's own doesn't define any data format and cannot be used as such. What it does define is:
  • Identifier format (sequence of a-z, A-Z, 0-9 and _ characters).
  • Value syntax:  sign data [@ identifier]*
    • The sign is a character associated with the parser for that kind of value. 
    • Identifers after "@" are reference name, "*" means zero or more.
  • Each value should  have a type.
  • Abstract classes, interfaces and helper classes for quick development of concrete data formats.

IKSTON (Ivan Kravarščan's object notation) is concrete IKON. It resembles to JSON without double quotes in keys in key-value pairs. It has five types of values, number, text, array, compound, referenced values. Text is perhaps the simplest. Sign for text is ", the double quote. Text ends with the second double quote that is not escaped. Escape codes are:

Escape sequence Translates to
\\ \ (backslash)
\" " (double quote)
\n new line character
\r "carriage return" character
\t tab character
Standard stuff, escaping escape character, escaping "end of data" character and a few convenience options.

Numbers are slightly more complex, sign is =, equals character and number parser reads (after skipping whitespaces after sign) the input until it finds a character that not either from 0-9, a-z, A-Z or period or minus. Reason for accepting letters is that scientific notation (such as 1.5e3 instead of 1500) and special numbers such as Infinity, -Infinity and NaN should be accepted. Scientific notation is useful especially since a lot of cost values in Stareater tend to be 9 digit values and infinity "symbol" is good to have around. Also it's good to point out that a number is ambiguous terms when it comes to programming. Numeric IKSTON values do not automatically convert textual representation to numeric representation (integer, decimal, floating point) but they offer methods for getting a value as specific numeric representation.

After explaining text and number values, arrays sound are simple, sign is [, left square bracket, data are whatever IKON data there is and closing character is ], right square bracket. For example:

[ "text1" "text2" =1 =2 "text3" =1e6 ] @testData

Now you see the deal with sign characters. In many other data formats numbers are just numbers but in IKSTON numbers require equality sign. It may seen unnatural but the up side for that is there are no type guessing. Text may not accidentally end up being number. Example also shows how references are declared. Before explaining compound type, example first:

{ star
   size = 12
    x = 9
    y = 4
    name "Alpha Centaury"
    planets [
        { Planet size = 100 }
        { Planet size = 120 }
        { Planet size = 10 }
    ]
}

As you can see, the sign in {, left curly bracket. First thing in the compound value is the identifier with the name of the "class". As stated before each value has a type. Numbers, texts and array have the constant type names (IKSTON.Numeric, IKSTON.Text, IKSTON.Array respectively) while compound values have whatever that first identifier is as a type name. After type name, compound value can have key-value pairs (identifier and IKON value) before being closed with }, a right curly bracket.

Shish, that's a lot of explaining for a something that will not be used "as is" in the project. IKSTON will be used for application settings but localization and game data will use different implementations of IKON. Come to think of it, save game format might be the pure IKSTON. I've already started with localization implementation but more about that in the next post.





nedjelja, 9. rujna 2012.

Creating code projects (lazy loading)

Don't get the wrong idea, lazy loading is not a bad thing, it's even the formal software design pattern. Lazy loading is the tactic of delaying the creation of an object, or some other expensive process until the first time it is needed. Although it's intended to use during software run time, I'll also use it during documentation and design time. I've started to write the design document but it felt so dry. That's why I'll do a little coding right a way, write documentation about topics that are hot at the moment and consolidate and expend from time to time.

So, what's hot now? In short, localization and application settings. Long story, I've started from the top, with the first thing that should happen when the application starts, the main screen. To fully realize a main menu I need the UI concept, localization and application settings (for interface size feature). I find old main menu good enough to be reused as is in v0.5 so I won't need new UI concept. Localization as mentioned in the last post is not so trivial and I should well define that feature. Application settings may not look as a big deal but they too have to be carefully defined. Idea is to support various UI implementations (one friend is/was willing to do in GTK) so app setting should support variable amount of UI settings.

I'll write in the next post how will localization and application setting work .

četvrtak, 6. rujna 2012.

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.




četvrtak, 16. kolovoza 2012.

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.

utorak, 14. kolovoza 2012.

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.

ponedjeljak, 4. lipnja 2012.

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.

četvrtak, 24. svibnja 2012.

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.

ponedjeljak, 21. svibnja 2012.

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.

srijeda, 4. travnja 2012.

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.

petak, 9. ožujka 2012.

Zvjezdojedac, space combat GUI

Polako ali ide. Svako tolko naletim na nešto na grafičkom sučelju što nemrem riješiti s nečim gotovim već moram potrošiti cijelu noć. Source code ću uploadati u repozitorij tek kada bude stabilan a to će biti tek kada će bitke funkcionirati. Naime, trenutno se ne može započeti novi krug ako se se ne razriješe sve bitke a bez funkcionalnog space combata to se ne može. Napravio sam tako sustav kako bi kasnije lakše odvojio "dužnosti" jezgre igre i grafičkog sučelja. No, da ne bi sve ostalo na obećanjima i frazama tipa "radim, radim" i "bit će, bit će", prilažem screenshoot trenutnog stanja sučelja za svemirske bitke:


Crni kvadrati s crvenim linijama su polja s pozicijama boraca. U kvadratima će se nalaziti oznake tipa da li igrač ima brodove na toj poziciji i da li mu dio brodova odlazi ili dolazi na tu poziciju. Klikom na kvadratić će se prikazati koji su sve brodovi na toj poziciji. Za prikaz liste brodova predviđen je prostor ispod. Na screenshootu je prikazana situacija kada svaka strana ima jedan tip brodova pa se ne vidi sva funkcionalnost liste. I da, iz nekog čudnog razloga bot je uspio u jednom krugu napraviti 97 tisuća colony shipova :). Blah, mislim da je bug u pamćenju ostatka gradnje. Uglavnom, ideja je da svaka stavka u listi skup brodova s istim dizajnom i da su prikazani prosječna izdržljivost štitova i oklopa za takve grupe.

Now back to work.