Stareater iterations

Before I move to the next topic I'd like to make a little intermission. Stareater is long running project, it's about 7 years old and yeah, still not done. I admit I have taken on very ambitious goal back then but instead of giving up when things got over my head I have started over. If you have been following this blog you'd noticed just that, the current programming effort is a rewrite of the previous iteration. What might have been lost to time is the fact that there has been one before that. Below is a short description of each iteration and names I made up just now so I can refer to them in future posts: 

• DIY or "do it yourself" was the very first incarnation of the Stareater where I have literately went by coding everything myself in C++. Only "others" work I took was OpenGL for graphics and GLUT for "windowing" (how application window is started and managed) and mouse and keyboard input. Unfortunately such ambition had to hit a brick wall somewhere and it was in GUI department. Making GUI engine from scratch is science for itself and I've spent more time on it then making an actual game. Since I didn't take robust enough approach it got really tiresome. DIY iteration ended with pretty beautiful galaxy map (stars only, no planets), map navigation and minimal GUI for starting the game.
• CroVar or "Croatian variables" began as GUI mockup project for DIY iteration. It was C# Windows Forms project and at some point I realized I'd be happier to spend more time on game logic and keep GUI effort to a minimum. So I filled in mockups with a actual game logic from DIY and somewhere along the line I've decided to use Croatian words for class and variable names. That's why I'd call this version CroVar. This iteration got pretty far, stars, planets and colonies were fully functional, planets could be colonized, ships could be designed, built and moved, foundation for AI was laid down and even space battles worked!
• WhyNot is the current iteration of the Stareater. At some point CroVar code got big enough mess to consider refactoring it. At first wanted only to make better separation of GUI logic and game logic but I figured I could fix many other wrong decisions made in CroVar. And it resulted in a total rewrite with good amount of why not this too additions? In all seriousness "why not" approach saved me a lot more trouble than it has brought me and it improved the quality of the code and final product. Mod files got more intuitive format, OpenGL graphics are back, it got easier to code new features and simplified changing and maintaining old features.

Fleet movement

Next feature on the completed list was fleet movement. Well sort of completed because it was refactored while doing colonization (more about it next time) and there is an open question of how to propagate information about multiple missions to GUI.

Let me start from the beginning, in the last iteration of the project I made two collections for fleets, one for stationary and the other for moving fleets. Reasons were difference in data structure, moving ones have current, start and destination positions while stationary only have current position; in visualization, stationary fleet marker should appear next to the star instead in the center of it; and in some internal logic. In the current iteration I wanted to unify those two collections for easier handling and I did it by introducing the concept of fleet missions. I started by giving stationary fleets a "stationary" mission and moving fleets a "move" missions and while most parts got simpler, some were not in the best shape. With only two things fleet could do there was no need for spending more time on the topic.

That changed when implementation of colonization started. At first I started by making separate collection for colony ships but then I've realized it won't make stuff simpler. It worked well for colonizing within a star system but when it came to moving ships to remote stars I had to either duplicate the code of normal fleet movement or unify colonizers with regular fleets. Guess which path did I choose, more complicated one with better scalability. And on top of that I've pulled out visitor pattern. It was like climbing uphill a bit be rewarded with relaxing bike ride downhill. I've changed fleet data from having a single mission to having a list of missions which combined with visitor pattern led to simpler code, believe it or not. Missions themselves were changed, descriptor for "stationary" mission was removed, now fleets with empty mission list are considered stationary, "move" missions have reference to star lane they are using instead of starting star (which was used to deduce whether star lane was in use or not), "move" missions also have reference to only one destination instead of all waypoints (not yet implemented on GUI but planned for future) and "colonize" and "skip turn" missions were introduced. "Colonize" missions does what you'd expect, marks ships ready for landing and establishing a colony. "Skip turn" also does what the name says but the reason for introducing it was to prevent colony ships from having unfair advantage over normal ships by taking action on the same turn when they are built.

In the Stareater I aim for having strict rules about what happens when. Construction is an action that takes a whole turn so when a ship is built it should act as if it (or should I say "she", I find it weird to refer to ship as she, partly because it's inanimate genderless object and partly because in my first language and in German the ship is "he") has spent it's turn. Since colonies and stellarises (made up word for star system wide government) are processed before fleets and colony ships are built with non-empty list of missions, colony ship could colonize a planet within a system or move toward destination on the same turn it was built. Explicit "skip turn" mission was a way to prevent that.

Finishing fleet movement allowed for tackling more features. As you might have figured out colonization was next but it's worthy to mention that also brought me one step closer to implementing space combat. And I've decided to make it more interesting then it was in last iteration.

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!

Loading game

Sometimes when I promise I'll do something soon I really do deliver in timely manner :). Game loading works, it's tested and code generation saga is over. There are few cosmetic stuff missing such as map preview next to saved game name. I don't think I'll do it in version 0.5 in fact I think I'll have to dedicate whole next version on such features.

What to do next? There is a lot of stuff to think through before implementing ship related stuff (movement, colonization and combat) so I'll make turn reports in the mean time.

Saving game

Another long pause on the blog but don't think it was equally long pause on the project! I've been working on save and load features and let's say I took longer road. Last time I was coding it, it was done in less then a week but it was boring copy-paste labor. For each chunk of data there was almost identical peace of code. It was OK once written but future edits got more prone to errors, adding new property (a piece of data) meant also ensuring that the property is saved and loaded properly and there was no mechanism that ensured that. This time I've made such mechanism and I must complain it was neither easy nor smooth.

Programmer rant:

I've made it with T4 which is kind of metawriting tool for writing code that generates text or in my case code. I've made text template with helper stuff for describing properties and classes and used it on each state data class. Each state data class is described by two or three files: text template filled with information about the class (which properties are there, how do they behave, does class need something extra, ...), C# code generated from template and optionally C# code with extra functionality that is either to hard to describe with template or doesn't belong there.

 

It all sounds great in theory but in practice it back to the stone age. Both Visual Studio (2010 at least) and SharpDevelop don't offer any content assistance, maintaining consistency over multiple files requires checking each file separately and there is no debugging support. If text generator throws exception, exception message and stack trace is all information you'll going to have. After a couple of rewrites I got system with satisfactory structure but I still feel the urge to complain. On the other hand I understand them, Microsoft took already existing ASP.Net renderer and reworked a little to generate any kind of text file and sold it.


Programmer rant over.

Anyway saving game works, file management and GUI needs some work. Loading should be up and running soon.

Ship designs

As promised I've started to work on ship design feature. First thing on "to do" list for the feature is a list of ship designs. Figure above is a mockup and figure below is how it looks now.

The list works and "info panel" (details about selected design ) will have to wait. Currently ship design data has very few attributes: name, size (hull type) and image. Once I implement the rest (weapons, mission equipment, special equipment, shields type, armor, reactor, engines, sensors and maybe something else that I can't remember right now), I'll implement info panel. As you can see there is a lot of different component types, it might take a while. On the other hand I have a template that I can reuse, hull type data so it might as well take 2-4 days. What really slows me down is designing GUI for making ship designs.

This is what I have for now. It's missing few stuff (interstellar drive on/off, short info about armor, mobility, sensors and cloaking) but that's no-brainer to add. What I can't decide is how to present equipment (both weapons/mission and special) selection. Previous version had a slider for dividing space between primary and secondary weapon/mission and I wanted to get rid of it this time. It didn't reflect the decision making process very well (player would think in equipment quantity rather in percent space occupied) and made certain complications for design update logic. So I was thinking about predefined ratio (let's say 2:1) or limiting ratio selection to only few options (let's say 2:1, 3:1, 4:1 and 5:1). I had more radical ideas such as allowing more than two types of weapons/missions with predefined ratio (let's say 1:2:4: ... : 2^n or simply 1:2:3: ... : n). I'm still not satisfied with any of it. Maybe in the end I'll do it MoO way, by letting player to enter desired quantity.

Edit:
Since it took me some time to write this post, mockup has been changed.

Now all elements are there and I think weapon/equipment list looks OK. Quantity manipulation controls are still work in progress but the basics are there. MoO 1 & 2 had simple +1 and -1 buttons which were not so elegant for adding dozens or hundreds pieces. I came up with few idea, one is to add or remove multiple pieces by "shift" clicking a button and the other is to allow player to type the number directly. On the mockup the "up" arrow button is supposed to open such window but now that I think of it I could as well place a text box beside "+" and "-" buttons. Another thing I'm not happy with is info at the top right. It's crammed and I've just noticed it doesn't show combat speed (mobility is currently evasion score).

Anyway I'll work on it some more and in parallel implement parts that are good (image and hull selection). And one more thing, predefined designs are essentially implemented. See the "Interceptor" on the second image? It's predefined design. Those designs are automatically added to design list as player acquires necessary technologies or at the beginning of the game it they have no requirements. I say essentially implemented because designs themselves are missing 80% components but as new components are added, predefined designs will get updated.

Buildings

Along with implementing colony and star system details I have implemented buildings logic. First I'd like to make a difference between construction project and building. Industry points are invested to construction project which upon completion either produce a building or some other non-building effect (such as removing planets negative trait). This distinction simplifies ship construction that was hackish in previous version and allows cleaner implementation of terraforming.

Currently implemented construction projects are:

• Colonization - increases planet's population for a turn and produces no actual building (like housing and trade goods in Master of Orion II)
• Industrialization - produces workplaces for population, an actual buildings

Buildings such as workplaces will be destructible during bombardment (and perhaps sabotage) once it gets implemented. I also thought about indestructible "buildings" that would represent certain knowledge about the planet such as geological data that increases miner efficiency. I'll return to this idea in the future.

Next on the menu is ship design. Yay, finally!