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!

1000 code commits

The project hits another milestone, this time one of existential kind. Code repository now counts 1000 commits!

For those who don't know, in software for tracking file versions (VCS - version control system), a commit is a single version increment. VCS when hosted on the internet or corporate network allows collaboration among multiple individuals who work simultaneously on potentially same files. Even for one man teams it offers a benefit of jumping to older versions and recovering files when an unfortunate disaster destroys a computer or when something gets deleted accidentally. In case of Stareater VCS mostly tracks changes in code files but sometimes it has to deal with binary files like images.

Long development not only brought multiple rewrites of the game but also saw multiple versioning systems. Hopefully whole history from the first system was retained in the current one. First iteration (WhyNot) was not tracked by any VCS but the second iteration was tracked with SVN on Google Project Hosting (GPH) about half way through. SVN was first VCS I learned to work with and it was a bit clunky. It worked well when there were ordinary file creations, deletions and updates. File renaming would pose it a problem and folder renaming would freak it out and require delicate order of operations to get it through. The project was only 53 commits in when a friend told me about Mercurial (or Hg as it was frequently referred) and that GPH can seamlessly convert SVN repository to Hg. This VCS was easier to work with, renaming was not a headache anymore which was proven 77 commits later when the time came for the second rewrite where, among other things, whole file structure got reworked.

It served me well for 283 more commits when Google announced they'll retire their Project Hosting. They were slowly killing the service by first removing very useful "Updates" page (code changes and issue reports overview) and later on preventing upload of new releases in "Downloads" page until in 2015 they informed their user to find an alternative. That's when GitHub got plenty of new users and I with Stareater was one of them. It's very similar to Hg in how it works conceptually but in practice I had to go outside my comfort zone: I had to learn command line.

With all shortcomings SVN had a good GUI client and Windows Explorer integration. GUI for Hg was on similar level too but Git client despite looking similar didn't click with me. One provided by GitHub was and still is, to put it mildly, a garbage. It has custom non-WinForms interface, uses unreasonable amount of resources (probably just to run fancy interface) and one "Sync" button mentality which only works in trivial cases. Fortunately in the mean time I learned to use Git from command line on the job (the real one) and I started to use "Open in Git shell" button as often as "Sync". And that's where the project is now, 582 commits on GitHub and 1000 commits in total. I hope to see version 1.0 in less then 2000 commits :).

Preview release v0.6.2

You got a real treat, two releases in a month! In this one organizations finally have a purpose (they give you boost in a research field) and starting technologies have a description and an in-game effect.

Download Stareater v0.6.2-alpha

In Stareater story there are multiple alternate universes and in some of them humanity tries to send manned mission to Mars on spacecraft propelled by nuclear engine (think of project Orion). For certain reason the Stareater pulls them in his pocket universe and those lucky enough to end up near habitable planet form a colony. Some of those colonists were pulled from universe where NASA launched the ship and others were from other universes where some other organization was leading the space race for Mars.

When starting a game player picks which organization has sent the people he is going to lead. Each organization brings technologies from the first level of one of the research fields which means that player will not have to pay prototyping cost for those technologies and will advance faster through that field (research cost decreases with level). For now there are 7 organizations to pick from:

• NASA - North American Space Agency. Specializes in sociology which will allow them to grow their colonies faster and get more out of them.
• ESA - European Space Agency. Specializes in physics which translates to more advanced weapons and impact blocking shields.
• JAXA - Japan Aerospace Exploration Agency. Masters of mechanics, have higher industry output and more special equipment for starships.
• CNSA - China National Space Administration. Specializes in chemistry, meaning better mining efficiency, more advanced armor types and longer ship range.
• SSSR - Soviet space program. Specializes in energetics which brings more advanced reactor types and impact absorbing shields.
• ISRO - Indian Space Research Organisation. Masters of mathematics who sport more advanced interstellar drives and stealth technologies.
• UKSA - UK Space Agency. Masters of biology who can get more out of their planets and improve their habitability faster.

It's still work in progress, mind you but that's how I hope the game will play out. I could write in similar length about starting technologies but I'll save that material for later. Writing blog posts ends up taking up a lot of time. On this one I've been working for almost full week and the topic is an event from two weeks ago. And the project is about to hit a pretty talk-worthy milestone, a 1000th code commit so yeah I better start in advance :).