ponedjeljak, 17. rujna 2012.


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.