Preview release v0.4.5

Now that the biggest features for version v0.5 are implemented it's time to apply much needed polish. A lot of incomplete stuff is finished and stubbed stuff unstubbed, see below for more info. There is one new feature: game over screen.

Download Stareater v0.4.5

So far the game had no ending condition, one could destroy all colonies of other players and game would happily go on. Now at least there is a game over screen. Currently there is only one victory condition but I plan to add more down the road as well as some sort of game retrospective and more compelling victory screen.

As I mentioned in the last post there is new star image. Graphical work was and still is a low priority but this one was in the work for a long time and even low priority tasks get done eventually. I also changed starlane visual a tiny bit and plan on adding back old planet images. They are not meant for large surfaces but still better then current placeholder.

More colony related mechanics got implemented. Space construction penalty is back, it reduces industry points for ship construction and other objects outside of the planet. It incentivizes space projects on low gravity colonies and asteroids and allows improving space industry with space lifting technologies without penalizing colony development. Planet traits are implemented. Instead of having fixed set of attributes like atmosphere density rating and mineral abundance rating in previous version planets now have list of traits which detonate high or low rating of certain attribute or presence of special resource. For now there is only one test trait which increases farming efficiency but other traits can be easily modded in without touching the code.

Construction logic has been revisited and stockpile mechanic has been redone. Now construction projects have stockpile groups instead of each one having their own. When building an item which takes multiple turns to complete industry points are accumulating on the stockpile until there is enough to cover the item cost instead of being immediately spent. If you switch to another project within the same stockpile group then accumulated points would count toward that project and be spent when that project is completed. There is no penalty for switching projects and unused stockpile stays there forever.

While working on stockpiles I've fixed construction time estimation. It's was a bit messy and stockpile data sometimes made faulty situations like second queued item taking stockpile points accumulated from the first one. Colonization logic is also fixed and finished, colonization projects go away when colony is established. Colony ship arrival is handled a bit differently, instead of gradually landing on a planet as they come now they hang around the star system until there is enough of them to establish the colony and land together. Reason for it was to remove hidden ship pile and help with colony ships without colonization mission in the future. Theoretically I can now make idle colony ships count towards new colonization project if their star system is selected as colonization source.

Ship designer got revisited too. I finally ironed out how ship variables are organized and how resulting numbers are plugged in to both attribute used in combat and values displayed in ship designer. Now all numbers affected by special equipment are visible on GUI. Equipment amount input is fixed, both slider and textual input field work for normal and special equipment. Design list now shows design info when moused over. Unfortunately other design list features like number of built ships and deleting design are still stub.

Finally applied first aid for an issue when multiple fleets occupy same or almost the same location on the map. Instead of being able to select only"topmost" fleet player can now choose which fleet to inspect before getting the list of ships in a fleet. This works even for opponent fleets. Better solution where multiple fleet marks don't occupy the same position is postponed for next version where I plan to reorganize how visible objects are tracked and displayed, something like scene graph from popular game engines.

Stealth and detection in combat got implemented. It took me some good thinking for how to calculate distances on hexagonal grid but this awesome post helped me about it. There is a simple nice trick to convert square grid coordinates to hexagonal, visually simply shift every other column (can work for rows too just switch roles) by half tile size and under the hood treat each row as having two neighboring tiles on each side. The problem with that trick is having to constantly check and adjusting if tile is in even or odd column when calculating neighboring tiles and checking parity of both tiles when calculating distance. Before I only had a function which tested if a tile is inside a "circular" hex grid of certain radius and used it for simple distance checks like testing if target is in weapon range. It turned out it didn't work correctly if "center" tile was in odd row and converting it to distance calculation turned out to be way more complicated then a method proposed in aforementioned post. I was reluctant to use that method because it required representing positions with three coordinates, one along normal up-down axis, and others along left-right tilted up and left-right tilted down axes. It turned out it's easy to calculate those coordinates from usual horizontal and vertical coordinates and final solution ended up being fairly brief and clear. I wholeheartedly recommend reading the article for everyone working with hexagonal grids.

And finally, I've improved error reporting GUI. It should now catch more (if not all) unhandled exceptions and display them in copy friendly manner. Happy testing and feel free to comment the game!

New star

It's a funny story how drawing a star has bothered me from the very start of Stareater project to the recent days. I'm not good at drawing stuff by hand so did next best thing, I made program do the drawing for me.

First one was simple, it generated a texture (image) with each pixel painted according to a certain formula and displayed it. Any change in star shape or color required changing the code and rerunning the program. Actually using the resulting image in game was a bit complicated. Back in a day I didn't know about PNG so I did screenshots of each star color variant, pasted it in MS Paint, saved as BMP, loaded in GIF editing program (which name escapes me and) and marked black as transparent. This is how it ended up looking:

Bottom row is how it looks in the game, mostly OK but could be better. Edge between star color and darkness of space is too prominent especially in the case of red.White center is invisible in yellow star and too prominent in blue. Top row demonstrates functional problem with the whole thing, since GIF has so called key based transparency (all pixels with "key" color are treated as transparent) there was no way to make some pixels semitransparent and if the star was on top of something then the fake space darkness would become visible.

At the time it served the purpose and after a while I decided to fix those shortcomings. I've made a more complex program which could save usable PNGs and could change parameters on the fly. It had a little framework for making procedural images generators and star image was just one implementation of the framework. Each image generator had it's own logic and set of parameters on GUI and the best thing was that one of the supported parameter types was symbolic function. You could type "4*x+0.5*y" if x and y were applicable variables and it would work.

Above are examples of some image generators and as I said, star image was just one of them. I also used the program for experimenting and fine tuning Stareater algorithms like starlane generator (middle image) and star positioning (right image). It was great tool for making quickly visualization.

On the other end I was exploring vector graphics for drawing starships. Inkscape was the best and de facto the only good tool for the job but it didn't click with me. It's great for hand drawing, so to speak, but lacking for technical drawing which happens to be my way of thinking when it comes to drawing something bigger then 20x20 pixel art. So I started making my own program for vector graphics, it was no good so I made another with different approach, it was better but not up to a task and repeated the process a few more times. The thing evolved from clicking points on canvas to typing them in table to writing a sort of programming language. Seriously:

On the right side is code, a sequence of points and shapes made with those points and on the left side is resulting image. It was not the most polished tool but it had potential. Unfortunately it took a lot of effort to keep improving it and code editor was devoid of usual IDE (code editor) luxuries like autocompletion and syntax highlighting. As I was developing programs in SharpDevelop, an opensource IDE, I was pondering an idea of using their code editor for my vector graphics language. And then I took the idea even further, to use C# itself for drawing. On the one end I'd to develop image generator as DLL (much like other Stareater plugins for AI and map shapes) and on the other end was program which continually monitored if DLL has changed, loaded new version of image generator and displayed a resulting image.

It's kind of return to the first program I had back in 2008 but with much faster code to image loop and so far it's serving me well. There is a bit of initial setup overhead for establishing OpenGL logic (making texture, setting perspective, setting rendering flags and drawing textured rectangles) but once set up it really easy to adjust and experiment about. Especially when secondary monitor is available, put C# editor on main screen, image preview on the other and watch the image change as you type.

And there is one more important bit of the story. While I was making all those programs I was collecting images of real stars in order to figure out what to actually draw with my programs. The challenge was to find an image were star was not a simple globe of light and not overly distorted by atmospheric noise and lens. When I finally made a satisfactory program and picked a good looking star the real fun has began, analyzing how colors change from black to blue to white and how to make similar looking stars of different colors. That part might be too geeky so I'll just leave a picture without too much explanation:

Preview release v0.4.4

This is getting embarrassing, last release had same issue as the one before it. Despite me having checked 10 times if the game works on other computers, applying a solution a solution that should have worked there was still an unaccounted catch. This time it has to work. Period. Good news: farming and mining are implemented and included in the release!

Download Stareater v0.4.4

Last time I tried solving DLL loading issue I went with a solution which involved applying certain application configuration. To be honest I don't really know how application configuration XML works and what it can do so the fact it didn't work might have been my incompetence. I suspect that configuration only applies to one assembly, not whole program. Since Stareater has some logic in EXE file and some in a so called "core" DLL, the configuration might not have been automatically transferred from one to another. Anyway I've found a new solution, instead of loading DLLs with LoadFrom function I could use UnsafeLoadFrom. As the name suggests and as documentation convinces me, it won't pester perform security check so I hope it won't be a case of "works on my machine but explodes on yours" any more. And I promise to take closer look at sandboxing plugins later.

About new old game features: farming and mining. Much like Master of Orion II, farming is there to keep workforce from doing useful work and make biology advances improve economy by decreasing the portion unavailable workforce. To keep mechanic relevant in middle and maybe late game I've split food production to two parts: farming and gardening (for the lack of better word). Farming produces a lot of food, especially on planets with good climate but there is limit on how many fields can be cultivated. Gardening on the other hand produces small amount of food but is unrestricted by planet's characteristics. So as technological advances enable more densely populated planets there will be an incentive to improve farming too.

It's a bit of deviation from CroVar iteration (last attempt at whole Stareater project). Back then there were only farmers but after certain point their efficiency gradually diminished according to certain nonlinear function. The problem is when calculating food production you don't really need to deal with a function of food per individual farmer but with an inverse of integral of that function. In other words, you want to calculate how many farmers do you need to produce certain amount of food. Integral will tell you how much food would certain number of farmers produce and inverse of integral will tell you how many farmers do you need to produce certain amount of food. In general integrals and inverses are more complex then original function and when you combine complexity of all three you don't get a simple formula. And that's the beauty of farmer-gardener approach, it's easy to explain, relatively easy for player to estimate the numbers, it's easy for me to fine tune and it achieves the desired effect.

Mining was and remained simple mechanic. Miners are extracting ore at certain rate and industry workers convert ore to an industry point in 1:1 fashion. In a sense it's like food production, another mechanic for wasting workforce and excuse for introducing more economy boosting technologies :). But unlike farming it rewards exploitation of minerally rich planets. In future I plan to introduce trade mechanic which will allow an empires to import minerals from rich to poor worlds, increasing the importance of rich planets to galactic level. More about it in next version.

Preview release v0.4.3

New release is ready! Space combat is the biggest new thing since the last release and of course there is a number of bug fixes, code cleanups and streamlining .

Download Stareater v0.4.3

Like last time, the package is a simple zip file so to run the game extract contents and start Stareater.exe. And again the game is .Net 4.0 application so it should work as is on Windows XP SP3 and newer and should work on Linux and Mac with Mono.

Nukes and lasers

Shooting part of space combat is mostly done. Ships can cut each other with lasers and drop nuclear bombs on planets. Colonies can be wiped out too but I'm still testing and polishing that part. Functionally, cloaking and detection is missing and I have to decide how to make inaccurate weapons like bombs viable in ship to ship combat. The idea is to give small and maneuverable ships means of seriously hurting large ships.

Visually there is a lot of work left and I'm feeling like I am stretching Windows Forms (Windows default user interface solution) way past intended purpose. Customization options boil down to either a set of inflexible switches or overrides where I have to do whole component from scratch. There is no middle ground where I could override some parts of default look and functionality but reuse the rest. Yes, I could instead work on adding more visual feedback on hex grid like beam rays and causality numbers but GUI part is bugging me so much. I'm seriously thinking about adopting GWEN.Net (an OpenGL friendly user interface solution) and ditch WinForms as much as possible.

And I see another cloud creeping over. At some point I'll have to improve my rendering engine and basically reinvent part of Unity engine, which poses a question: should I have made the game in the Unity in the first place? I'll try to stick with no as long as I can. Rewriting would probably take way more time then it seams at first glance and I have some experience on implementing scene graphs so it might end up being faster solution. Also, doing it on my own gives me the opportunity to tailor it to my needs. There are some design decisions in Unity I don't agree with and I can work with assumptions that apply only to my project. I'm confident that my current code base is good enough to endure such changes.

It's eating me too but you'll have to suffer through ugly GUI until version 0.5 is finished. I'll put more effort in visuals in the next version.

Hex grid

At last something visible in space combat! Well, by the time I finish this post it might be complete :). Boring stuff first, some more ground work had to be done in order to trigger space battle for right player at the right time. The way how battle events are pushed to GUI had to be more strictly defined and there were some changes in AI handling. Then there was also a question of how to organize ongoing battle data. I started with what there was in CroVar version and after some experimentation I ended up with game within the game structure. Space combat is going to have similar model-view-controller pattern as the main "galaxy" game and will not be entirely stuck inside the main game. It would pop in to existence, run as separate entity and feed the results to the main game.

Now fun stuff, image above is how game looked on paper a year ago. I've been thinking about space combat for a long time, I've decided to abandon one dimensional simplification from CroVar and do proper 2D tactical TBS. And while I'm at it I could do it on hexagons. Math is slightly more complex then it is for square grid but only slightly and there are few tricks for representing hex grid in memory in a same way as square grid. Image below is how it looks like at the moment, a grid, a star, a defender near the star and an attacker's fleet on the edge (exact location deduced from the direction it came from).

More coming soon!

Preparing space combat

On a way to implement space combat I have implemented conflict detection logic and unstubbed some parts of the game. Conflict detection is a mechanism for finding where and when space battle happens. Under the hood a fleet can have multiple waypoints and with advanced enough interstellar drive it can pass through multiple star systems in a same turn. If one of them happens to have an enemy presence, space battle happens and the fleet ends it's turn there. When the conflict begins is also important, it influences a turn limitation. If at the end of player's turn a fleet was 1 light year away from destination, traveled at the speed of 2 ly/turn and battle happened there then it would have 50% of maximum combat turns to resolve the fight. In case the battle doesn't end by then I plan to make persistent battles which can span multiple galaxy turns. I also thought about making a mechanism where a quick enough fleet can fight in multiple systems. For instance if a fleet finishes one battle quickly and is fast enough to travel to next star system it would be able to fight a few more turns there too. The problem is int that case conflicts wouldn't be isolated and players wouldn't be able to play each conflict to the end before moving on to the next one. It might work by making players play all space battles simultaneously, one turn at the time but that doesn't sound like fun. So I'll go with one battle per fleet per turn limitation and keep the idea in the drawer :). There is also a question of what to do with colony ships that retreated from the battle, do they try to reach a marked planet or do they go home and do what exactly? I'll cross that bridge when I come to it.

Next step toward space battles was making AI build ships so a player can have somebody to attack. In order to implement that I had to change how the game rotates players during the turn. So far I had a "current player" number and only one player could interact with a "game core" at the time. On the other hand AI was supposed to do it's work in the background. Since both AI and human player used the same means of communicating with the game core AI could only manipulate the empire of current human player so for a brief moment there was an AI which filled my building queues with random stuff :). To make AI independent I tossed the concept of the current player out of the core so from the it's perspective everybody is playing simultaneously and it is up to a user interface to worry about who has the turn. Interesting consequence of it is that Stareater is now very close to having hot-seat multiplayer.