Turn reports

Oh boy a year passed already! I'm  alive, the project is alive and real life is real. There has been steady inflow of features in the Stareater despite steady inflow of real life distractions. Turn reports were first thing implemented after game loading. Oh boy, that was almost a year ago! Please feel free to contact me, comment below or in any other way ping me when I go silent for so long.

Anyway, I have finally found a proper solution for the under the hood details for report handling. Problem in the previous iteration of the Stareater was all kinds of reports (discovered technologies, buildings built, built ships) where contained in a single container and logic that handled openning a particular message had to perform, a not exactly object oriented, type checking. Technology related messages should open either research or development GUI, building completion message should open colony screen of the colony where the building has been built and so on. Back then I've included type information to the base class (those not versed in object oriented programming, base class is sort of common data and functionality for different data types that build upon particular base class) and "open message" logic simply asked a message are you type A, are you type B, ..., are you type Z. Action taken depended on which question was answered with yes. This was simple enough but there were few issues with that approach:

1. Each data type already contains type information (programming language feature)
2. Message "consumer" has to keep in mind which message types there are
3. When new message type is added each message consumer has to be manually located and inspected for an update

Technically I could have used built in type information but back then I was quite stubborn with not using the black magic of code reflection and in the end it would not make much of a difference. True solution to the problem was so called double dispatch and the "visitor pattern". Double dispatch means action taken (function/method called) is deduced from two parameters, in the case of turn reports those would be message type and consumer type. Since C# doesn't have ready syntax for double dispatch, visitor patter is one way to emulate it. It's a design pattern which I've encountered while looking for parser generator for something in modding logic and at the time I didn't understand it because it requires a shift of perspective. Imagine a situation where Alice boards a train, normal sentence would be "Alice boarded a train" but in visitor pattern a sentence has to be paraphrased as "A train was boarded by Alice". Once I understood it, the pattern was perfect match for the problem. There was no need for explicit type checking and the pattern has nice feature of ensuring all consumer types know about and can process all message types. When adding a new message type, a single update to the base message class would cascade the update to all consumers.

All that said, user interface could use some more work and message filtering is not implemented. I'll make filtering later when I add more features and see what needs filtering. Polishing interface will also have to wait, I'm looking for alternative to Windows forms, preferably something with OpenGL rendering, so I can have more control over the look and feel but not to go all the way back to reinventing the wheel. GWEN.Net is in the consideration but I have to test it more and the whole thing is low priority for now.

Stay tuned for info about other features completed over the year!