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.
Nema komentara:
Objavi komentar