Release v0.8

Despite some recent setbacks another milestone has come to a close in exactly one year after previous one. There are slightly fewer new game features but a number of features got fully functional (instead of being stubbed) and under the hood there are lot of improvements.

Download Stareater v0.8

New game features:

• Star system policies - colonies are managed indirectly by picking a policy for whole star system.
• Galaxy scan range - other player ships are only visible within certain distance from owned colonies and starships.
• Fuel mechanic - a resource pool used by ships traveling away from owned colonies. Going further away uses up more fuel and if too much is used the economy is penalized.
• Fleet pathfinding - ships can be sent more then one starlane "hop" away and they'll automatically pick the fastest route.

 Reworked game features:

• Map generator - now actually tries to balance planet sizes and traits instead of placing them purely randomly. There is a lot more planet traits and a star type affects planets. Map preview shows star system quality.
• Colonization - generalized with interstellar migration. Both use same population transporters and automated management logic (routing, loading and unloading).
• Catalyzer (space monster) - retreats from battle after tainting a star.

Under the hood improvements:

• Nestable GUI elements - allows for more complex user interface. 
• Galaxy map GUI - mostly replaced with game engine GUI. Removed Winforms toolbar. Made graphics for new interface elements (end turn button, scan range toggle, toolbar replacement buttons, policy cycle button).
• Tooltips - hovering a mouse over certain UI elements reveals more information about it.
• Reworked text rendering - big texts are not blurry any more but small text are bit less crisp. In general characters to display graphics pipeline is more sensible now.
• Small tweaks to tech tree.
• Fixed issues running under mono on Linux.
• Fixed lockup when a player is attacked at undefended system.

Preview release v0.7.4

A long awaited tooltips are here, you can finally find out what is what and fleets can now find shortest path on their own.

Download Stareater 0.7.4

Tooltips look small on the screen and trivial to the player but that simplicity hides quite a lot of complexity under the hood. First of all positioning a tooltip is mildly complex, it is tied to both mouse position and originating GUI component placement, it must be moved horizontally in order to not be clipped by the edges of a window and moved below a cursor if it wouldn't fit above. That two dimenstions but there is a matter of depth, tooltips should be above regular UI components and not block mouse events on them. I went a step further with this one to lay the groundwork for pop-up windows so this is more complex than it need to be for now. And then there is the time dimension, a tooltip appears after a small delay but not if a mouse has moved away in the mean time. All four dimensions are simple to moderately complex on their own and look trivial to a user but they have to work in tandem without hiccup and that's where true complexity arises and where a robust GUI framework pays off.

For now tooltips can be added only to in-engine GUI elements so old WinForms that sorely need explanation can't benefit from them. But that will eventually be solved through ongoing process of conversion to new GUI framework. On top of that I'm trying to work out something better for text rendering. As you can see on the image above, it is not very sharp and there are some stray dots. I'm prototyping SDF based solution for half a year already but it still needs more time in the oven. Naive approach is not very practical and doesn't produce very good results, more advanced approach that promises awesome results takes time to implement, mainly due to how uncooperative (and archaic) font manipulation in standard .Net is. I've only recently solved the hurdle of getting a list of lines and curves out of letters so I can proceed with porting aforementioned advanced SDF method from C to C# but it has also opened a new avenue to explore. I can make a somewhat simpler method that sacrifices the quality of result for a speed of prototyping. In any case I hope to sort out text rendering before the summer vacation.

Ship pathfinding is another big feature in this version, allowing your fleets to automatically pick the quickest path over the starlane network. This greatly helps colony ships and other population transporters that are by default automated. Previously they'd just plot a direct course to a destination and in early game that could result in 200 turn journey unless a player didn't override the route. This feature doesn't necessarily limit the movement to the starlane network because starlanes add to the speed rather than multiply it, much like a conveyor belt. When you get to faster star drives pathfinding will likely give you a path that is partially or wholly off lane and there is a way (ctrl+click) to force direct flight anyway.

Here I took some time to refactor transport automation code and and some parts of fleet command code. Previously automation code was quite messy to read, figure out what is going on and where and why it's not working properly. Now it's one third shorter and ten times more readable. There are still some issue but they will be much easier to correct then with the old code.

And finally there are three more small changes made in this version: biology is merged with chemistry, fuel production is increased and ships can be sent even if you don't produce enough fuel. While testing transport automation I've found fuel mechanic to be too restrictive, it is supposed to prevent you from sending a large fleets deep into enemy territory, not to prevent you from colonizing neighboring star. So now you can freely send a fleet on the long journey if you are OK with economic penalty instead of outright being blocked from doing that. Base fuel production is increased 2.5 times and I'm inclined to increase it further so a homeworld could support at least a few colonization fleets for free but I'll will wait for now to see how that will mesh with technology balance. Speaking of which I found it hard to come up with 24 (8 tiers, up to 3 items each) biology technologies that are distinct enough and since chemistry was a bit sparse too, I've decided to merge the two. This unfortunately means removal of UKSA, an organization specialized in biology.

Preview release v0.7.3

Another Stareater release is here, bringing completed map generator and various improvements.

Download Stareater v0.7.3

Stareater map generator works in three phases: star placement, wormhole placement and filling up star system. Until now only first two phases were implemented while the final one was a stub (minimal implementation to keep systems non-empty). Implementation of the final phase brought with it more goodies in areas outside map generator. Planet and star traits are reworked, internally they are now two different things, planet traits are dead simple (a planet either has or doesn't have certain trait) while star traits have complex behaviors like temporary duration and the ability to place and remove traits from planets. There are a lot also more planet traits now: toxic (less food), radioactive, three levels of irradiated, two for atmosphere, two for magnetosphere (reduces radiation level), three for gravity, three for mineral abundance and two for temperature. All of them implemented and working. You can even get greenhouse effect if a planet has dense atmosphere and host star radiation level increases.

Map review is also updated to show the difference between map quality settings. Player can choose between various levels of early game map quality (environment selector) and various levels of late game quality (potential selector). Star system potentials are depicted with the size of darker outer circle and starting environments with brighter inner circle.

Other improvements are:

• Catalyzer space monsters are tiny bit smarter now, they fly off after tainting a star with "catalyzed" trait.
• Catalyzers now actually do attempt to taint the star. There was a bug that spawned them without necessary equipment.
• Fixed a crash when removig a ship design.
• Fixed game freeze when the player is attacked at undefended system (ie. when catalyzer shows up).
• The game is tested on Linux, made to run with mono on Linux and code is tweaked to compile in MonoDevelop. It's not tested on Mac but it should work there too.

Preview release v0.7.2

New year brings new Stareater release. There are a few but big changes this time around.

Download Stareater v0.7.2

Also I owe you progress report from the last release. I thought about writing in-depth post detailing how drawing scanner range circles works first but now I don't think I'll be done with it any time soon. New stuff in v0.7.1:

• Star system policies change how colony management is done. Filling building queue and setting investment slider on colonies is managed by setting system-wide policy. Hopefully this will reduce meaningless micromanagement and allow to see on a glance what is happening where. Policies are basically predefined building queues and investment presets which can be switched with a single cycle button. For now there are two policies: develop and exploit. "Develop" focuses on building up colonies, leaving minimal resources for ship construction while "exploit" is the opposite, giving most of resources to space projects and small amount to colony infrastructure improvement. Policies are mindful about excess resources, if you have fully developed colonies is a system with "develop" policy industry points from internal development would spill over to space projects, effectively giving the benefit of "exploit" policy. Future idea is to add "defend" policy which boosts planetary defenses but sacrifices economy.
• Interstellar scan range limits how far away you can see from your star systems. Nothing ground braking from player perspective but drawing those round edges turned out to be a major undertaking. I find it strange that solution to this problem is not well documented or easy to find on the net. The best I could find are brute force solutions that involve drawing screen sized image in memory and I don't want to assume player's GPU will have that much texture memory. In any case I've worked out much more efficient solution.
• Toggle button made in the game's GUI engine for showing and hiding scan range.

v0.7.2 highlights:

• Fuel serves a purpose of both movement range and command points in Master of Orion 2. If you played MoO 2 this may sound like a strange marriage but stick with me. Travel distance is not limited to a fixed number of light years but the limit arises from the available fuel points. Each ship size consumes a certain number of fuel points and consumption rises exponentially with the distance from friendly stars. And I really mean exponentially, it doubles for each light year of distance. The idea is to allow smaller fleets and scouts to travel deeper into hostile territory than big front line fleets. To make matters simpler there is no stock piling of fuel points, the amount you get per turn is either used or lost to the void. Think of it more like how much fuel can be produced on demand then how many canisters you produce. I may rename it to "supply capacity" or something like that to remove potential confusion. And final thing about this feature, in case your navy ends up consuming more fuel than available, economic penalty will be imposed, similar to going into negative with command points in MoO 2.
• Interstellar migration allows developed colonies to jump start new colonies and comes with unexpected baggage: transport automation. Unlike MoO 2 transport ships are not invisible abstraction but ships as real as military ones. Their movement and passengers are automated but player can override it as he sees fit. Or at least will be so, for now the player can manage movement but has to leave the passengers to the automation. Passengers will try to disembark on a planet that accepts immigrants and embark from planets that are too full.
• Reworked colonization reuses transport ships, both migration and colonization is done with the same kind of ships with the difference being that upon colonization some ships land and get converted to factories.
• Multilayer GUI, reworked mouse handling and slider element are continual effort to phase out WinForms GUI. With those additions I managed to replace star and colony management panel, it's not a looker at the moment but it will be easier to improve the old one.

Release v0.7

Another big milestone came to a close. Thanks to the effort in last milestone this one has considerably more new features and content.

Download Stareater v0.7

Major features of the milestone: 

• Torpedoes are area of effect missiles which can reach targets over long distance. They are actually combination of two features, splash damage which can hit multiple units in a tile and a missile as a board piece.
• New GUI implemented entirely in the game's graphics engine which will gradually replace WinForms and make user interface look and behave as the rest of the game.
• Victory condition is not a stub any more. Players now have to reach stareater's "brain" star and use it to eject (send to normal space) stars in order to earn victory points. Points are awarded to players owning colonies around ejected star, not necessarily to the player who performed ejection.
• Organizations now have each have affinity for a certain technology field, giving a player one tier for free.
• Early game technologies (tiers 0-3) are now researchable and do have in-game effect where implementation permits.
• Intro animation is an example of engine's animation system. Previous animations like selected ship in combat are converted to new system which automates animation handling and simplifies tying scene objects with animation effects.

Minor features of the milestone:

• Autosave that saves a game after every turn.
• Interplanetary migration and colony desirability score which makes people move from crowded to less populated colonies in the system, making smaller colonies grow quicker.
• Hostile planet maintenance will make a player choose planets to colonize more carefully since colonies on hostile planet have to be supported by the rest of the empire.
• Save game preview will let you tell at the glance which save game belongs to which game.
• Space combat camera allows you to zoom and pan combat map just like galaxy map.

Under the hood changes:

• Space combat messaging brings order to the multi-threaded world of space combat where game rules run in one thread, human facing interface in another and each AI in it's own. It also resolves some issues where AI vs AI could cause stack overflow.
• Fixed designs as opposed to predefined designs don't use highest component levels available, they have predefined levels and ignore player's technology levels so there is no more need for native organisms to have fake technologies.
• Command line arguments are primarily development convenience, allows for simplified project setup process (no need for copying or linking game data, default command line arguments already point to the folders of interest) and makes debugging release build easier.
• States without T4 is another development convenience but this one makes games more stable. It ensures that all data that should be saved in a file have saving, loading and copying logic (for read-only view while waiting turn to process or AI to finish) with minimal code overhead.

Preview release v0.6.6

Welcome migrants to more desirable world of tier 3 animations. I think I got it all in one sentence.

Download Stareater v0.6.6-alpha

In the last release animations were introduced but nothing new was done with them, only existing animations got rewritten. Now that foundation is used to create whole new intro animation when the game program is started.

Interesting thing about how it works under the hood is that specifying when and what happens with animation eerily looks like electric circuit schema. There are resistors (delays), parallel and series circuits, only batteries are missing. Here is a bit exaggerated figure (in reality parallel and series circuits are not physically connected but series "resistor" is big enough to simulate the effect):

One more feature from old CroVar version returned: interplanetary migration. Population from more populated worlds would move to less populated ones inside a star system. This is combined with planet desirability score. For now it's just a function of current and maximum population (less crowded is better) but when I implement more functions for formulas I'll add planet traits and technologies to influence it. I'm eagerly looking forward to a day when tooltips get implemented so I can show you how underlying "spreadsheet" works.

And as usual content update for release is 3rd tier of technologies. This bring along some new ship components, updated calculation formulas and brand new colony construction project: soil enrichment. Upon completion it gives a planet the "fertile" trait which is a new thing buildings can do now.

Preview release v0.6.5

New update, finally. In fact a bombastic one! One with splash damage torpedoes and navigable combat map.

Download Stareater v0.6.5-alpha

 Missiles were already present in the Stareater but they were technically limited ammunition beams. Torpedoes are true "fly over there" missiles and they have Expanse inspired look :). They also pack a splash damage which hurts multiple ships in a stack and multiple stacks in the same location. For this to happen stack health has been expanded a bit, now there are armor and shield points for a unit on top of the stack and armor and shield points for the reminder of a stack. Splash damage hits both top and reminder of a stack if the splash is big enough. Once the stack's top unit is destroyed a new top unit will not start with full shields and armor but with what was an average of the stack. Additionally splash damage treats chance to hit a bit differently then direct attacks (like beams and old missiles), torpedoes who are the sole users of splash damage (for now) have two attack kinds: direct and splash. If attacker wins chance to hit roll then top of the target stack is struck with direct attack, otherwise the top is struck with splash damage. So the top of the target stack is always hurt but the difference is by how much. If the splash is big enough (maximum number of targets a splash can affect) then the rest of the stack gets splash damage proportional to number of affected units. And if stack is smaller then splash size then other enemy stacks get splash damage too.

Splash damage is one part of torpedo implementation, the other part is, well, the projectile itself. Launching a torpedo will show a projectile on the map and over turns it will close in to the target. For now it's as simple as that, you can't target torpedo stack and attempt to destroy it before it destroys you but there is a plan to rework how combatants and projectiles are handled under the hood which will make such feature possible if it turns out to be necessary.

For now under the hood changes revolved around certain AI vs AI (or AI vs natives because natives are just different AI under the hood) behavior. Previously the communication between an AI player and the space combat controller (part that decides who is on the move and when a battle is over) was synchronous. Controller would call AI function for playing a unit, AI would then call controller function for a move it chose, controller would call again call AI to play a unit and so on. Once the battle got resolved controller's function would exit and return to AI's function which called, it would exit too and return to controller's function which called it and so on until whole call stack gets unrolled. If something goes wrong and I have to debug it, I'd see kilometer long call stack with a lot of repeating uninteresting entries and if there are too many units this synchronous communication would overflow the stack crash the game. Asynchronous communication, as anything multi-threaded, is bit more complicated but solves those issues and allows AIs to process the battle independently. Also it makes enforcing some move validity checks easier.

There is no new content in this release but I've compensated that by adding zoom and pan to combat map. Now you can zoom in and read unit numbers :). I've also improved how animations work and refactored selected unit pulsing animation to use it so for now this visually changes absolutely nothing but as previous additions in this release, allows for more goodies in the future.

Finally, sorry for delayed release, real life got really busy. The situation will remain like that for a few more months but I'll will continue to work on this game.

Preview release v0.6.4

Now that holidays are over it's time to get back to work. And what a better way to kick off a new year by doing something crazy: own GUI engine.

Download Stareater v0.6.4-alpha

Making own mouse and keyboard event handling, element positioning, drawing variable length borders, state handling, positioning text and images inside elements and many more gotchas sound like a lot of complicated work. But when you look at the project code you'd see good deal of that already implemented. Turn number on galaxy map and bombardment buttons in postcombat bombardment are the most prominent examples, galaxy map scrolling and interaction is a subtle one which also uses most of aforementioned features. So it was mostly a matter of restructuring already existing code and thinking through some details. And think it through I did, after all, I've abandoned very first Stareater incarnation due to GUI logic getting too complicated. Since then I've seen a lot of GUI code, both in use and details under the hood. I saw a lot of interesting approaches and a lot of bad realizations.

I've looked for existing solution I could use but they were either one of bad realizations or couldn't smoothly integrate with C# and OpenTK. Still, I have to give credit for an effort to Gwen.Net, a port of C++ library to C# with OpenTK. It's easy to integrate and emulates WinForms quite well. And that's the problem, I want to get rid of WinForm's look and feel. Gwen's skinning support looked very convoluted, you had to look through code to figure out which pixels on texture did what and documentation is practically nonexistent. Also I'd like to work with more modern layout mechanisms, something where it's easy to say "put this button at the bottom right corner" and have a framework calculate exact (x, y) coordinates and update them when window resizes. Something like GUI framework in Unity Engine and Android framework. WinForms is very limited in that area and from what I managed to dig out from Gwen.Net the situation is not much better there either. So I rolled my own framework and replaced old end turn button. Visually it needs more time in the oven but that's a challenge for another time and it would be an issue with any GUI framework, all of them expect you to bring your own artwork.

Core game feature in this release is colony maintenance, bad planet traits increase maintenance cost per population and it's payed up by whole nation. If maintenance cost is greater then 50% of nation's productivity then colonies in the worst shape will suffer population loss. Reason for including this mechanic is to make bad planets less desirable since they are going to put a burden on all of your colonies, to make star "catalysis"(afflicted by stareater's native organisms) bigger problem for a player and to make terraforming and building up more desirable. This also gives me an opportunity to fill some gaps in tech tree :).

Finally, another tier of technologies has been worked over and again it took more time then expected. In fact it took more time then making new GUI framework. Reason this time around is that I decided to make few changes to the tech tree: to remove limited use technologies. In Master of Orion 2 when you research new type of armor all previous types become obsolete. New ships are automatically built with the best armor and there is no trade-off between lower and higher tier armor. In Master of Orion 1 there was some nominal trade-off, lower level tech costs less and takes less space but even then I rarely went more then one tier below highest available. Something similar was in old concept of Stareater tech tree plus the fact that techs in Stareater can be upgraded with more science investment. I don't think it would play well "dead end" techs. Why would you invest a lot in an item that would go obsolete. In case of armors I've removed all techs that unlock particular armor type and replaced them with two techs: one which unlocks new types of armor material as you level it up and other which improves armor quality (level within armor type). Ditto for reactor technologies, reactor type tech and reactor level tech instead of one tech for each type. For computers, sensors and interstellar drives I'd make a mix of cumulative upgrades and special abilities. Quantum computer would increase instead of replace electronic computer bonus, lidar would add up to radar bonus and provide "telescope" ability for increased detection strength in a narrow cone, inerstellar drives would have unique movement abilities, etc. Thrusters are still one foot in old concept and one foot in new one, there will be less thruster types and upgrading them will provide some economic bonuses like lower space lift penalty due to gravity and increased migration capacity.

This left a few holes in a tech tree and by moving few items around I might go back to originally planes 7 tiers per field. Physics is still cramped full for 8 tiers while biology and sociology are very sparse, sometimes having only one item in a tier. Work on tech tree is still in progress, I hope to fill the gaps with techs for missing features (trade treaties, espionage, fuel range) and end up having 3 items in every tier in 7 tier model.

Preview release v0.6.3

In September you got two releases so October ended up without a Stareater release but don't worry, more sweet stuff got in this month! The main feature of this release is the promised one, stareater brain and ability to control it.

Download Stareater v0.6.3-alpha

Stareater brain is located in a special star system, it's loosely a homeworld of native lifeforms and the player controlling the system can use stareater itself to influence the map. For now control consists of selecting which star to remove from the map. No joke. Once a star is out, players owning colonies there receive victory points depending on the population and turn number. People on those colonies as presumed to be successful at leaving confines of the Stareater and returning to normal universe. This is the canonical way to end the game and I hope a fun one since you'll have to balance between working toward victory condition and not weakening yourself too much in the process. In this version you can just park a single scout ship at stareater's brain and eject any star but in future it won't be so easy, natives will object to your presence, you'll need adequate equipment to control the brain, you'll have to master it or take chances and risk unpleasant accidents. And I will not skip a chance to make sabotage something to fear.

Also I hope to dispel the imperative that there can be only one winner. Anyone who manages to leave from stareater has achieved something, there is second and third place. Stareater is not the game about beating others into submission through various means. No, it's a game about both good and bad human sides. While there will be incentives to go for the first place alone, forming alliances and sharing victory points will be also have it's place.

That future has to come one step at the time and and few additional steps taken this time are tier 1 technologies, a group of development projects unlockable by researching first level of a research field. That's 18 more technologies that have at ingame effect. Adding more content proved to be more tricky then I've expected, as every other programmer I've underestimated the task thinking it would be no more then one day of work. For most items it was a simple data entry update but some technologies required adding a bit more code and all of that requires testing. There is nothing more embarrassing than game crashing due to misspelled or overlooked data entry. Having more content also uncovered some GUI issues like missing scrollbar in ship designer, no "shields" category in library and wrong list item overflowing behavior, also in library (it produced additional columns instead of becoming scrollable single column list). Writing descriptions also takes non-trivial amount of time and I've not even started to replace placeholder icons. Domed apple was supposed to be icond for hydroponic farms but I just used it everywhere.

The idea for v0.7 is to have 3 tiers of technologies (including 0th) polished as much as possible. This means development costs and levels could be considered real, technologies should give intended bonuses and unlock and level up respective pieces of equipment. Those pieces of equipment also should have real cost and effects. Exceptions are technologies which require game mechanics which are not yet implemented (fuel range, espionage, ...). So far doing this really made the game shape up, removing "test drive" which made map movement trivial was huge plus, ship designs now look more legitimate, early game space travel feels more like early game and it also uncovered an issue with natives. It was a known issue which I tried to postpone because solving it was a small feature rather than bugfix. Predefined designes for players which take into account player's technology levels had to be separated from predefined designs for native lifeforms which have to have particular equipment of particular level irregardless of native's "technology".

So anyway, have fun testing this new shinny release, please report any bugs you find and know that more cool stuff is coming down the road!

Preview release v0.6.1

Features planed for 0.7 are... going to revealed later :). Actually I wanted to report on a new preview release packing new data engine and save game preview.

Download Stareater v0.6.1

Game preview is like a cherry on the top of data system rework. As the whole save format has been reworked, I've made save metadata more accessible. Previously the code had to read and parse whole save file to get save title and game turn number and when building list of saved games it had to do it for each file. Now it can read just first few lines from each file and read whole file only when actually loading a game. Preview data is also in those first few lines and it can contain whatever GUI needs to make preview image of the saved game. At the moment it contains turn number and star positions and colors but I can easily expand with occupied regions and power graphs or shrink it to just player colors for multiplayer games. That can wait because it requires more thinking what to show in preview since star dots on small map alone make too noisy image.

If you are really interested in feature list in upcoming milestone then you can take a peek at project's milestone task list. I promise to write more about it in next post :). Just one more thing about last post, I can't stress enough how important it was to change "state engine" to more native solution, I'll try a different angle at explaining it. Take a look at this image:

Previous solution contained a quite lot of "unclean" code meaning it was not fully supported by IDE (development environment) in some way or another. Engine for example was completely written in different programming language (T4) then the rest of the project (C#) and the nature of that language made it hard to write and debug. Instead of having IDE notifying me immediately when I wrote something wrong while writing the code I had to run the script in order to uncover simple type fellers and guess from cryptic error message where the problem is. Following script execution step by step was unsupported too and I had to resort to clumsy data dumping to find out where exactly the error is. At least that was the case in IDE I was using at the time, newer ones are a bit more helpful. Point of the engine was to generate C# code for data classes but it too had to happen through a bit more of T4 scripting in order to define which properties and behaviors particular class should have. Generated code should not be edited because T4 script would overwrite changes if retriggered so each kind of custom behavior has to supported by engine and used through class code generator script. In the end using all that generated code for big operations (copy, save, load) was relatively clean, there were some hoops to jump through in order to handle dependencies but nothing so dramatic.

New solution, as you can see from the picture is much much cleaner. Engine code is roughly equally in size as previous one but it's mostly nice and clean C#. There are few spots where a magic is used to generated code while application is running but it's kept to a minimum in both quantity and complexity. Even if something breaks there it's easy to debug. Data is now pure regular C#, no metaprogramming tricks. Well, class attributes have to have certain reflection attributes but let's pretend it's normal code, if nothing else it's very brief overhead. Now classes are free to have whatever constructor they need and set whatever property they want to default values and enjoy full IDE coding support in the mean time. This part was the biggest reason to change the engine and I'm happy with the result. Lastly, major operations are slightly simpler then before, there are still some hoops left but a little fewer this time. There, I'm done, hope this has convinced you :).

Release v0.6

New major project milestone is done, Stareater has officially reached version 0.6. A few new features got implemented but there was many bug and stability fixes and code quality improvements.

Download Stareater v0.6f1

Major features of the milestone: 

Diplomacy - players can now call for an audience and negotiate treaties. Although bare bones, players can switch between peace and war, combat respects those treaties (you can't attack or be attacked if you are not explicitly at war) and code is ready for more nuanced diplomacy.

Refitting - a staple of  Master of Orion 2, built ships can be retrofitted with new equipment. Player can explicitly set which design is going to be retrofitted to which design. Also when a technology improvement gets developed, refit orders will be automatically issued to applicable designs. For instance when you get laser level 2, all designs with level 1 laser will be marked for upgrade.

Semi-exclusive research - another staple of Master of Orion 2 but in a less severe form. When a player makes a breakthrough in a research field he/she will get all technologies from that breakthrough but will have to choose priorities. Technologies with higher priority will be cheaper to develop to higher levels.

Space monsters - trope from basically all space games but especially important in this game. Unlike other 4X games your main goal is not to be dominant force in the universe (though you can do it as bonus objective) but to get back to "the real" universe. Stareater is a pocket universe which keeps you trapped and it's filled with space faring creatures which help it consume stars. Those creatures don't hold any special grudge against you but they are not concerned with your welfare either, they'd gladly make a star brighter and let it irradiate all planets in the system. Unlocking their secrets will be the key for leaving Stareater.

Minor features of the milestone:

• Persistent ship damage - companion feature to refitting. Damage to ships in space combat persists after the combat and can be repaired at friendly star systems. Surplus repair points are used to retrofit ships.
• Postcombat bombardment - similar to Master of Orion 1 and 2, after a space combat is resolved, winner can bombard (and in future invade) undefended colonies by just clicking on them. Previously attacker had to remain in space combat, move ships over a target and command each ship individually.
• Weapon ammunition - some weapons like missiles and bombs now have limited ammunition in combat.
• Hot seat multiplayer - multiple human players can play the game on the same computer. Technically this was possible prior v0.6 but now it's tested and some rough edges are dealt with.
• Improved starlane generator - they now look more organic while ensuring whole map is connected and that each player has access to roughly similar part of the map.
• Active planet and star traits - companion feature to space monsters. Celestial body traits now can have more complex behaviors then just being and not being. "Catalyzed" star trait can spawn "irradiated" trait on planets in system and expire after a few turns.
• New rendering engine - not exactly a minor effort but from player's standpoint a less visible feature. Graphical objects are now handled in more organized manner, each scene simply lists where is what and underlying engine handles details like drawing order and draw state switching. Frame rate control has more options, from pushing GPU to work at max speed to battery conserving one. OpenGL version has been updated to 3.2 which allow easier use of shaders so there visual improvements too.

Under the hood changes:

• Map settings from last game are remembered
• Some of text templates are removed from code, replaced by different code structure
• More ship images
• More technologies which could end up in final game, not just for testing purpose

And more is to come. I'm tempted do to a lot more of under the hood changes, including better GUI library, restructured game data storage, add tests to prevent "f1" (hot fix 1) versions in future releases and so on. On the other hand I'd like to add more substance more quickly to finally get something really playable. I'll try my best to balance those too desires in next version.

Preview release v0.5.5

Another preview build is ready. Took some time, again, but a lot of new goodies got included.

Download Stareater v0.5.5

The biggest addition is diplomacy mechanic. It was described in greater detail in previous blog post so I won't repeat myself. That leaves us with a number of under the hood improvements and new technologies. My "tech tree" draft is shaping up and I'd say it's developed enough to start adding it to the game. So far I've added two out of eight technology tiers and I plan to add third by the end of v0.6. It amounted to whooping 46 entries which naturally exposed an UI issue in library :).

Which brings us to under the hood changes. Aside from fixing panel scrollbar to show more then one screen of technologies, I got around unifying "name" and "description" localization tags into one generic "lang code". Now items (technologies, ship equipment, ...) have only one localization entry and name, description and future library entry are automatically obtained by applying appropriate prefix. Debugging has also been improved by passing around a file name of the file being loaded which made it possible to print which file has incorrect format. It sounds a bit strange to not have that already but the thing with Stareater is that the code is split in two parts: game rules (core) and user interface (UI). Core should know as little as possible about the world outside of game rules and that includes file management. Ideally UI part should provide all data sources (which don't have to be files) to the core. Now the problem is that core knows when the data is wrong but UI doesn't know when core is analyzing data and which file is being read at the moment. So I made that along with data stream there is a little tag with "source info" which for now contains the file name.

Another quality of life improvement for development is inclusion of texture atlas generator to UI code. Atlas is collection of smaller images (planets, ships, stars, ...) into a single image and up until now it was generated with external tool which had to be run manually every time there was a new image for a game. Now the game can automatically add the image and let me know which ones were not prepackaged so I can run the tool before publishing a release.

Then there were bug fixes, a concurrency issue between turn processing and read only view (UI when next turn is being calculated but player can still look around the map from previous turn) was fixed. NVidia bug is hopefully fixed, I'd need somebody to confirm that. For the moment I'm using unofficial homemade OpenTK build while OpenTK maintainers are preparing the official one which should be published this weekend.

Preview release v0.5.4

It's been a while since the last release and a lot of new stuff was added and polished.

Download Stareater v0.5.4

As usual details are covered in previous posts and here is a brief summary:

• Refit cost from one design to another factors in component difference. More similar designs cost less to refit.
• Missiles were introduced. They are basically an instant hit weapon like laser but with limited ammunition.
• Damage on ships persists after battle and can be repaired.
• Improved graphics engine. It's a bit more powerful and a lot less prone to human error.
• Last game map settings are remembered.
• Fixed a crash on when loading invalid settings file.
• Improved starlane distribution when generating a "galaxy" map.

There are two known issues. First one is crash on startup on Nvidia GPU with recent drivers. There is no easy way to fix it so it will stay for a while. If you do observe this crash, try to run Stareater on different GPU or on no GPU at all. Second one is occasional crash on new turn. I'm still figuring out how to solve it, it a though case of concurrency issue where a piece of data is used after expiry. But don't let it ruin your fun!

Preview release v0.5.3

So what's the fuss with space monsters recently? Click link below, unpack and find out :).

Download Stareater v0.5.3

 Aside from space monsters the graphics engine has been updated to newer OpenGL version and some bugs has been fixed (stability and saving/loading).

Preview release v0.5.2

It's almost as if I have a monthly schedule, new preview release is available for download. Semi-exclusive research is a new feature and there have been a number of improvements and bug fixes.

Download Stareater v0.5.2

Semi-exclusive research had it's own post so I'd focus on under the hood improvements. I won't bore you with coding details this time, let's just say that the game is back to 1000 FPS. As usual whenever the game starts lagging it's my fault, I either forgot to remove debug info collection or performed steps in wrong order. This time it was order of the steps, text rendering was initialized during the scene rendering instead of before it, making invalid OpenGL calls. Unfortunately it didn't crash the program nor bugged out graphics (which it should), driver made an effort to control the damage so I didn't notice the issue right away. After playing a bit with GLIntercept, an OpenGL debugging tool, I've found the culprit and was relieved that the cause was my sloppiness instead of something in programming language + OpenGL + driver combination.

I've also made a bit of code clean up and some refactoring. I've decided to drop T4 text template technology because editor support is not on the level I'd like and it cumbersome to work with it. Once you make it work, it works but when you have to make a change it ends up taking whole week. So far I've reworked two "classes" of T4 dependent code but the final and the most complicated class still remains. I have a prototype of an alternative approach in making but it will take me some time to incorporate it. I'm most probably postpone it and focus on something else.

So in a mean time enjoy the preview and feel free to give feedback!

Preview release v0.5.1

A new preview release is ready! Ship upgrading and refitting is the main news but there were a number of changes and improvements under the hood.

Download Stareater v0.5.1

Refitting and upgrading ships was explained in previous post and stayed pretty much the same but the game loop was reworked again. Last implementation caused weird performance issues, whenever regular Windows GUI should pop up over OpenGL area there would be a noticeable delay before a window started appearing and it would be appearing piece by piece. The delay and the time needed for a window to get full drawn was not proportional to the complexity of OpenGL scene but oddly by the number of components (buttons, labels, check boxes, ...) on the window. It looks like as if something in Windows is synchronizing main and background thread for each window component. For that reason I've moved OpenGL logic back to the main thread and used background thread loop for sending events when to redraw the scene. So VSync, framerate limiting, power hungry and power conservative frame timing methods are still available.

There was also general graphics performance improvement for non-animated objects. Previous method worked sort of like asking OpenGL to perform A+B and new method works like asking it to perform A and then perform B separately. For some reason former method is slow and I've observed double the framerate with latter method. There is more room for improvement since drawing stars takes 30 - 40 ms (~30 FPS) but only sometimes and the scene is simple enough to be drawn close to 1000 FPS. As I was writing this post I looked again at the issues to confirm the numbers and accidentally found a few bugs including one that caused slowdown. Stuff likes happens that way, there is a problem, you try to pin it down without success, you go to explain to someone what is bothering you and in the process get both correct diagnose and solution without other person ever saying a word :). In any case fixes to those bugs will be temporary band aids until I rework graphics engine to OpenGL 3.x compatible functions.

And there has been some code maintenance changes. Data loading logic was among the first things laid down in the last rewrite and it had some presumptions about future code which are not valid any more. One such thing was progress reporting about "how many percents was loaded" but that information was not used anywhere and implementation cluttered the code needlessly. If the need arises, I'll make cleaner solution. There was also unresolved issue of loading localization data. Previously it was done when settings data was requested for the first time which is not the most reliable approach and there was no good way to add error handling to it. Now the languages and other localization stuff are loaded in controlled manner like all other game assets (technologies, ship equipment, AI modules, map generators). Whole asset loading has been improved too so GUI has more freedom for choosing when to start it and receive notification when certain parts or all assets are ready. There has been a change about how loading logic finds it's data and that is an area which can be improved more. Responsibility for managing files has been moved from core to view so on one hand it would be easier to replace WinForms view with Unity3D but on the other hand view has to know too much about internal working for the core.

There is a lot of work left to do but feel free to try latest build and leave a comment!

Release v0.5

Big rewrite has finally come to conclusion. I stared it three, almost four years ago. It was supposed to be a moderately big refactor, not outright rewrite but in the end I think it was worth it. More about it in previous post about Stareater iterations.

Download Stareater v0.5.0

Since last release Wikipedialike library has been implemented, ship construction can be managed from galaxy map and there has been a number of bug fixes and unstubs. More about it in eventual next post. Feel free to try the game and report any bug you come across!

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!

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.