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!

Colony details mockup

With construction logic working for both colonies and star systems it's a time to do GUI for colony and star system details. Figure above is mockup of colony details GUI. It's considerably smaller compared to previous version (before rewrite). Spending control is moved star system view,calculation details will be presented in tooltips and there are no tabs, all is on a single screen. 

Environment information is also redesigned, instead of five numbers (gravity, temperature, irradiation, atmosphere quality and density) there is one and a list of icons (in place of 8 sun icons). This also reflect the change under the hood. By default planets don't have any gravity and climate statistic but they can have traits (wrote about it in "Orbital habitation" post) and those traits can influence general environment statistic. Old environment model is basically repacked as planet traits. Good thing with new model is ease of adding more than n hardcoded environmental traits and possibility of combining one trait with another. For instance "high winds" trait my be stronger in presence of "dense atmosphere".

All of it holds true for star system details GUI.

Instead of explicit radiation stat there will be "low/medium/high radiation" traits. Compared to colony GUI it may not seam odd, but notice star system building list. Prerewrite version didn't have that.

And now, to finish the topic I'm going to plug in the real data to GUI.

Stareater v0.4.1 downloadable

Current state of the project is available for download at

http://code.google.com/p/zvjezdojedac/downloads/detail?name=Stareater%20v0.4.1.zip

Compared to the last downloadable version there are no new features (in fact stuff are missing) but the game looks completely differently. Changes are not just cosmetic, under the hood stuff are radically different too and despite of loosing a year of progress project might be over sooner. Code maintainability is greatly improved and it's much easier to develop. To make it up I promise to make better space combat, a proper 2D mini game.

Future builds will be uploaded at some other service because Google is going to kill downloads section on their project hosting service. Allegedly the download section was abused for spreading malware. I disagree with their reasoning but I have no power to change their mind. It's not their only BS move, they killed "updates" section which showed recent changes on the project and they broke user experience on GMail web interface. Something wrong is happening with Google.

Silent fail and rage

I raged last Friday over a stupid designed choice Microsoft made for .Net framework. It all started with benign change, I changed folder where game settings were stored. When I tried to test the change the main window refused to close. I stabbed red "close window" button a couple more times but to no avail. It seamed as absurd as not being able to start a car because a house few street away has new door. So I paused the program through debugger and it turned out that "close window" event was being aborted for some reason. For those unfamiliar with MS Windows Forms, program can subscribe to "somebody requested to close the window" event. On such event the program is notified and can act upon it and even prevent closing. Stareater GUI code is subscribed to such event and naturally I checked it out:

A single line that saves settings. There is no code that cancels closing. With debugger tools I followed internals of SettingsWinforms.Get.Save() and it's execution wasn't as I expected. It was cut in a middle of execution. I spent some time trying why and it turned out there was an exception being thrown (sort of runtime error) inside Save. When a program doesn't handle an exception it usually crushes but proper programming tool catches it and presents plenty of information that helps programmer to fix it. Take a look at Visual Studio 2010:

It clearly says where the code broke and why. Other C# IDEs (programs for programming) also offer such good debugging tools so it's kind of expected that every exception will show on programmers radar. But no, Microsoft decided that in certain conditions window must not crush. If exception occurs in such situations, framework will catch it and "handle" it by not doing anything. That's called silent failure. This is how it looks like when it happens within "window is about to close" event:

Do you see it? I made similar divide by zero error like on previous image. Take some time. It's hidden in the last line in the "Output" window at the bottom. On top of that full message doesn't fit the window. Now I hope You can understand, dear reader, why I was furious.

Reasoning behind silent failure is usually that end user is see less crushes. In my opinion it's just giving the sense of false security for end user and as demonstrated makes job unnecessarily more difficult for programmer. There is absolutely no benefit from it in "debug mode".

And in the end, how did saving settings prevented window from closing? Destination folder didn't exist. Normally when non-existent file is open for writing it is automatically created. Apparently creating missing folders is completely different beast but it's OK as long as I get informed when my presumption turns to be wrong.