petak, 24. studenoga 2017.

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!

utorak, 24. listopada 2017.

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 :).

ponedjeljak, 9. listopada 2017.

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 :).

nedjelja, 24. rujna 2017.

Plan for 0.7 features

As promised, the feature list planned for next milestone, after two features are already done :). This milestone will more deliberately follow a way of working which emerged in the previous one: one under the hood change, one feature implementation and then preview release. On top of that I'll try to add more meat to the game and work toward establishing similar rhythm of implementing systems and adding game content.

Features planned for 0.7:
  • Save game preview, a small thumbnail image of a game state in a save game list. This one is already implemented and you can see it in action in previous release.
  • Organization traits. Previously a player could pick an organization he is going play as but it was not reflected in gameplay, every organization was virtually the same. With this feature each organization will have a preferred research field and it will advance faster within that field. It's not as groundbreaking as MoO II racial traits but I hope to design research in a such a way that each field would promote different play style. Also already implemented but will be included in next release.
  • Stareater brain is going to be a special star system, kind of like Orion system in MoO series but with more prominent importance. Controlling this system will grant owner an ability to control whole stareater and work toward victory condition: leaving stareater's pocket space.
  • Colony maintenance is a comeback for a feature before last rewrite but with more time in the oven. Each hostile planet trait will incure certain maintenance fee per population which is going to be payed by whole nation, not just that particular colony. It's similar how Sword of the Stars handled hostile planets and discouraged too fast expansion. Additionally global maintenance system is a groundwork for future mechanics (like espionage).
  • Population migration is another feature comeback but this one is as simple as it sounds. As colony gets more crowded people will try to migrate to more roomy places. I may complicate it with planet habitability being a factor in migration desirability but for now I'll limit migration range to planets in a star system. In some future version I might add interstellar migration.
  • Area of effect weapons are going to be weapons which damage all units in a tile. Top unit of a target stack will receive full damage while other units in the area are will get reduced "splash" damage. Another feature I'll try to push with this feature are torpedoes, missiles which travel on the map like ships do in order to reach target and can be shoot down.
Since I've already finished two the listed six features I may add more along the way but on the other hand there is plenty of non-feature improvements waiting to be done too. I seriously need to change GUI engine and that's a huge work. Fortunately it can be broken down to small manageable pieces but I still have to be careful with architecture. Then there are graphics. I'm working on procedural planet generator for minting high resolution cartoony planet images and it's progress is so-so. I have decent asteroid algorithm and rudimentary rock planet recipe which should work for Earth-like, Mars-like and Mercury-like planets. I'm still looking for good random stripe generator for gas giants and Venus-like could covered planets. For starships I've finally developed a tool which suites my style of drawing so there is an opportunity for updating existing ship graphics and include source code of images in version control instead of binary data. That's plenty of work to do, will see how much time and energy I'll have, my real life situation is about to get permanently changed.

subota, 16. rujna 2017.

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 :).

utorak, 22. kolovoza 2017.

New state engine progress

Last major release went well, all in all. The game attracted a few curious persons and one was very generous with feedback. Some of the easier suggestions (turn count in the corner, special equipment limit in ship designer) are already implemented and other are added on to do list.

What is going to be done for next major release? This will be reviled in next post, I'm still working on the feature list and I've already started working on something. I'm weighing how much refactoring should I do because I really want to clean up some things but the downside of refactoring is that features doesn't get made during that time. So I've started new milestone to by refactoring the biggest thorn in the side. Now is the best time while there is no psychological pressure to work on polish, feels like I have all the time in the world and it's better to do breaking changes early with plenty of time to test them thoroughly. In last version I've been working on removing text template code generators but I had to keep state handling ones due to complexity and their time has come to an end.

In Stareater code game data is split in following categories:
  • States - facts of the game world such as star positions, which planets are colonized and by whom, which technologies players have researched and so on.
  • Orders - how players want to change the state. This includes building queues, technology development order, audience request and so on.
  • Derivates - implications of states and orders. Population growth for example is calculated from colony's current population, population limit and "housing" building which converts industrial production to population.
  • Statics - assortment of stuff in the game. Which technologies there are, kinds of ship equipment, kinds of buildings and so on.
When it comes to juggling data statics are simple, they are loaded once and that's it, derivates are recalculated when needed so they don't require much management either but states and orders have to be copied, saved to a file and loaded back. Ordinary mortal programmer would simply write functions for each operation in each data type. Maybe I would too if it's was a smaller project but in this one there are currently 20 state and order data types with total of 82 attributes (members/properties/fields). That's a lot of stuff keep in mind and remember to update when adding new features. So like every engineer I've decided to let computer do the bookkeeping for me and that's where T4 text template came to play. I'd simply list which attributes a type has and for each attribute it would generate logic for initialization, copying, saving and loading. It sound awesome in theory but T4 is hard to debug (at least was at the time) and there were always some edge cases which were hard to solve with general approach.

Developing and updating T4 based solution took me at least two months, in total making it almost 10% of effort since v0.5 rewrite. New system already took a month to develop but I'm confident it won't take much time to maintain. Firstly, it already works, secondly it's easier to work with since it's pure C# code. I also simplified data a bit in order to make it work, some relations were really complicated and required a certain unintuitive order of operations to get stuff done.

How does this new "state engine" works and why didn't I implement it first time around? In C# there is something called reflection and I tend to call it "dark magic". It allows you to get information about data types while the program is running, information such as which attributes a type has, how they are called in source code, which types does the type inherit, reading and writing values where you normally can't and many more. All of this comes at the price of quite slow performance. Also there is another form of "magic", so called expressions trees which basically let's you  create more program logic while the program is running. At first I was concerned whether it's a good idea (how fast is compilation, would antivirus freak out) but I've found out that Microsoft's own database access functions use so it's not something foreign to the world. The price is only a slowdown on first use (compilation actually), further uses work almost as fast as native code. New state engine uses both schools of magic, reflection for gathering data and build up engine and compiled expression trees to do the actual operations but I tried to keep them to a minimum since they don't make very readable code. It's much more readable then T4 templates, true, but still not self-explanatory on a first glance as normal C# code.

This engine didn't come out of a blue either, I've been experimenting with technology a year ago and developed a small prototype project to test out those "magics". Now that a new engine is made, there is some minor code cleanup is left to do, full removal of remaining T4 templates and verification if all state and order data types save and load properly. God, I need to automate this somehow but only thing that comes to mind is to make a test suite which would take another month of making features. Back to compiling feature list for the milestone, one thing is certain, organizations are going to have a tangible effect.

utorak, 11. srpnja 2017.

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.

subota, 24. lipnja 2017.

Bombardment Mk II

Real life got me busy again, it has been a while since last update but the last feature for v0.6 is done. Bombardment can be performed after victorious space battle.

New bombardment kicks in when attacker is at undefended colonies. Be it after defeating defender's fleet in space battle or by simply there being no space defenses at all. Rules for in battle and out of battle bombardment are virtually the same: damage calculation, ammunition limits and turn limit are the same. This also means that ammunition and turns spent in space combat are not available in bombardment phase. In essence bombardment acts like simplified space combat without unit movement, any colony can be bombarded instantly with all ordinance without spending turns on travel.

On top of this feature I've improved starlane generator so the map looks more organic and less like a crystal lattice. It was in rather a simple change, I've increased minimum angle between incident (coming out of a same star) lanes and decreased the number of extra lanes beyond the minimum required to connect all stars. It turned out that those extra lanes were major contributor for turning organic look to crystalline. Now, if 0% means minimum number of lanes to connect all stars and 100% means maximum lanes possible then new starlane density settings are as follows:

  • Few - 20% (was 33%)
  • Decent - 33% (was 50%)
  • Many - 65% (was 100%)
  • Maximal - 100%
Why stop on simple things when I can do complicated stuff too? Occasionally in maximum lanes setting there would be a few extra long lanes at the edge of the map, practically running along the whole edge. I've made an algorithm to remove them. It's something along the lines if a long lane was not there, find out if previously connected stars can still be reached via other lanes which are individually shorter and form a path which is not much longer then removed lane. Sounds simple but is a bit of a calculation intensive.

And now the plan is to fix a major bugs, polish a few things and finally release v0.6.

srijeda, 10. svibnja 2017.

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.

utorak, 18. travnja 2017.

Peace by deafult

Peace is now a default state, meaning diplomacy has been implemented. In other games in the genre, even if it is called peace, by default you are neither at peace nor at war with your neighbors. In Master of Orion for instance parties have to form a non-aggression pact in order to stop each other from engaging in combat. Without it you are free too attack each other and still enjoy trade treaties if neither side explicitly declares a war. Sure, an AI will automatically declare war every single time you attack it's ships (even if you let them retreat without casualties) but when AI attacks you it's "only" a friendly rub and you end up being rude for feeling offended.

Peace in the Stareater on the other hand assumes non-aggression pact. Picking on targets of opportunity (weak fleets, unprotected colonies) is strictly forbidden before formally declaring a war. Natives on the other hand don't respect human customs so they are always treated as enemies.

What is implemented at the moment is public relations screen where you can see your contacts with other players and see which treaties you have with them. From there you can call for an audience which will be held after hitting next turn. During the audience you can declare war or offer peace. For now this is it and AI will go along with whatever you ask of it. It will take some fleshing out but the idea for the future is to have "public opinion" feature where each civilization population holds an opinion about other civilizations. If opinion is too low then war can be declared and trade treaties will be harder to form. If opinion is very high then cease fire must be declared and war between those civilizations can't be declared again.

It was a bit boring to implement this feature, mostly due to sizable amount of GUI involved. It doesn't look much but there is quite a number of things inside the things. At the end it became interesting and I even did an extra mile to finish an old task of including undefended colonies to space combat check. There are not many tasks left in the backlog for v0.6, this milestone is going to conclude faster then I've anticipated.

četvrtak, 16. ožujka 2017.

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!

subota, 11. ožujka 2017.

Map generator 2/3: starlanes

It's been cooking for some time and it's finally out, starlane distribution algorithm in map generator has got some actual implementation instead of stub. The algorithm could use some tweaking but it already produces good results.

The algorithm has three subalgorithms: maximum connectivity graph, minimum connectivity graph and interpolation between minimum and maximum. Don't get discouraged by the word graph, I won't dive too deep in graph theory mathematics, I'll just as a convenient word for "a way how points are connected with lines".

The general idea is to start with maximum connectivity and remove connections until desired starlane density is reached. Maximum connectivity algorithm has been the hardest part to nail down. I've tried and scrapped about a dozen methods. First couple of ideas looked promising until I've run into edge cases which were impossible to handle without introducing some undesired properties like bias toward topmost or leftmost star positions. Then I've tried to get so called Delunay triangulation working. Failing to find easy to copy-paste code and after contemplating whether it's worthy or not to spend time integrating nontrivial code I have found, a simple solution dawned on my mind. I figured my ideal solution would always contain shortest possible connection and from there I assumed the ideal would favor short connections over long ones. I expanded it to an algorithm which checks potential connections one by one, from shortest to longest, and adds a connection to a solution if it doesn't cross over previously added connections. Prototype was promising, there was only an issue where some points had a lot of lines coming out in a narrow cone. After adding a condition where a connections has to have certain minimal angle between them I solved that issue and got satisfactory results.

Minimum connectivity algorithm starts from maximum connectivity solution and finds the smallest set of connections necessary to connect all points. First it picks a point closest to the center and adds connections which form a shortest path from player homeworlds to that point. That central point is momentary substitution for what will later be a stareater's "brain" system so this steps ensure that players will have access to it and to eachother (and shortest path ensures there will be no cycles meaning no superfluous connections). Then the rest of points unconnected by those paths are added to solution by taking the shortest connection which would connect a new point with the set.

Finally, depending on chosen starlane desnity some extra connections are added to minimal graph. Again, the shortest candidate connections are added but this time the ones linking points with least connection endpoints have a priority.

All this was accompanied with some general map generator code refactoring. Parameters (map size, position randomness, starlane density) are handled in a much nicer way and last map settings are finally getting remembered. Now that I think about it last number of players is still not remembered, oh well. Anyway, the map still has to be filled with stars and planets in some meaningful way, I have some ideas and I'm look forward for a day when third piece of the puzzle will fall in place.

ponedjeljak, 6. ožujka 2017.

Warning: Graphic content

Few post ago I've thought about making planet orbits and combat grid textured, consider it done now. I've repurposed the shader to apply texture instead of flat color and instead of regular rectangular texturing it bends rectangular image to fit on curved surface. So orbits in system view are no more jagged and combat grid looks a bit nicer too.

Which drove me insane at one point. Adding texture to old polygons produced black spots around line intersections because they were overlapping and had same depth level, making depth test sometimes passed through a darker color. On top of that each hexagon produced all of it's boarder lines so lines between two hexagons were drawn twice. At first I've tried utilizing that by making each hexagon draw only it's half (half width, from border middle to line edge closest to the center of a hexagon). It worked well for all but for outermost lines which ended missing outer half. I've tried hundred ideas to get them finished properly but there was always some edge case which required twice as much code to handle as regular case. In the end I flipped the table, stopped thinking in hexagons, started thinking in lines and devised a two phase process. First phase was repurposed old code for processing grid per hexagon basis but this time it only made a list of where each border line starts and ends. Second phase inspects each line from the list, checks with which lines it is connected and generates draw polygons in a way that each line covers it's part of intersection. If you know me then it wouldn't surprise you that first phase is quadtree territory (for removing duplicate lines and points, plus cardinal sin of using non-integer numbers as a table key) and second phase is linear algebra town. Now I won't make any promises but I was pondering different shape for combat grid, something that still plays like current hex grid but looks more spacey :).

Shaders are not the limit of my limited artistic prowess. Oh, no I can make distinct low resolution images too. I've reworked two more smallest ship images and made up four new images for second ship size. Some long time ago I've came up with five distinct spacecraft shapes, some inspired by SF shows, some by permutating underlying shape. For instance, one of the inspirations is "fighter1" which resembles colonal Viper from Battlestar Galactica and it's rough shape it upside down kite. Simple way to get another shape of a spacecraft would be upside up kite. Make a broad part broader and thin part thinner and you get "T" shaped "fighter2".

Make rough outline with darker color, fill it with brighter and move pixels around until it looks right. That is how I arrived at images of the smallest spacecrafts. Larger ones I've made by inflating small ones, following the initial shape but adding a little twist here and there and adding a bit of detail.

I also thought more about hull size assortment and decided for fewer sizes then in CroVar iteration. Instead of having 10 or so sizes which grow by factor of 2.5 I decided to have 5 sizes which grow by factor of 5. I think having fewer but better defined sizes would suite the game better then having a lot of small increments and it gave me easier time coming up their names. I don't want to default to usual military frigate-destroyer-cruiser route if I have other options. One reason is that in real world navy these words describe ship role, not necesserly it's size class and second reason is that I don't want to depict spacecrafts as exclusively military vessels. For instance it would be awkward to describe a colony ship as a battleship class. I also don't want to use vague size gradations like small-medium-large because what is large for early game is medium or small in the late game and I want names to have some absolute meaning like X is this big. For now names are meteor, shuttle, cruiser, liner and asteroid but they are not set in stone and I'm open to suggestions.

utorak, 14. veljače 2017.

Refit discount

Time to address some leftovers. Proper refit cost calculation got implemented and scene building code got simplified.

Previously, refit cost was equal to full construction cost. On one hand it was not a big issue since refit and construction points are generated in parallel so there was never a situation where rebuilding ships was more profitable then refitting. But the idea behind whole feature was to have small refit changes result in lower refit cost while major role changes require more investment. In order to achieve that ship designs are now decomposed and compared component by component with following rules in order that would minimize cost:
  • Refitting to same equipment type and level is free.
  • Refitting to same equipment type but higher level has discount on full new item cost. Discount is 80% for 1 level difference and falls exponentially.
  • Refitting to 5 levels higher item of same type or to entirely different type receives no discount.
Items which don't have explicit cost (armor, sensors, reactor and thrusters) are priced at certain portion of hull cost. Unless hull is being upgraded too, then they are free. I may change that in the future with something like if hull receives 80% discount then armor and other items would have 20% discount. Reasoning behind that would be that upgrading hull partially includes retrofitting those parts too.

Scene building improvement is one of the under the hood changes which aren't visible in the game but very visible in project development. With previous approach I had to specify and manage almost every of drawable objects in the scene code. Term "scene" here means major game "screens", ugh, defining one word with another ambiguous one. Galaxy map is one "scene", zoomed in star system is another scene, space combat is third scene and so on. With new approach scenes only have to define what is there to display and let the engine sort out "how" and "when". Yes, they still have to cope with raw numbers like transformation matrices and vertex data values but they don't have to manage them all the time. The underlying engine tracks when low level buffers should be updated and in which order they should be drawn. It also tracks "physical" data for detecting which objects' region has been clicked/tapped by the user, greatly simplifies bookkeeping in galaxy scene. There I previously had a mess of multiple parallel lists (quad trees) for keeping track of fleet visual positions vs their real positions.

And lastly, a friend tested a game and ran into an issue. The issue appears with recent NVidia drivers and is a manifestation of an old OpenTK bug. The bug is fixed in new version but at the moment I can't use it because Stareater works with other component which depends on old OpenTK version. One option is to pray and wait for maintainers to update the component, which given their track record is not going to be soon. After some discussion with OpenTK maintainers I learned that I can make OpenGL in Stareater work without that extra component on top of OpenTK. To achieve that I'd have restructure user interface code but at the moment I'm not keen on large refactoring endeavors. If the component gets updated any time soon that would be great in short term solution. In the long term I will make GUI less and less dependent on it and ultimately get rid of it.

ponedjeljak, 16. siječnja 2017.

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).

srijeda, 4. siječnja 2017.

Space butterfly

Stareater's native life forms are coming to ruin you day. Or whole year if turns represent years. Lovecraftian space butterfly may look harmless at first, it will ignore your glowing cities and curious star ships, it will go straight for the star in a middle of a system and put a curse on it. It will turn temperate solar weather into living hell with extreme radiation and flaming tongues of solar flares.

Catalyzers (those space butterflies described above) are very old life forms, dating lineage back to the first generations of stars. They were born on rogue planet, a gas giant without a star to orbit about. There the life evolved around utilizing liquid helium and planet's powerful magnetic field. Extremely low temperatures made one peculiar evolutionary advance possible, the fusion catalysis. A life form utilizing it would inhale hydrogen, preform cold fusion and have access to nearly inexhaustible source of energy. At least from human perspective that is. After millions of years, gigantic gas dwellers have had exhausted their hydrogen supplies. Because of it some resorted to preying on others and some to far more radical measures: interstellar travel. Another strange ability of liquid helium's superconductivity is twisting the space itself, allowing life forms to slingshot themselves toward new sources of hydrogen, the stars of their galaxy. Like moths flying into flame, many have died but some were lucky enough to stumble upon other gas giants and eventually evolve the ability to exploit stars. They would devour the galaxy if there wasn't another fantastic leap of evolution, moving through multiverse. Instead of traveling through normal space to another star they could reach much closer (in time, not necessarily distance or effort) another version of their main star, effectively exploiting it over and over. This eventually led to birth of a stareater, a seemingly single star swallowing entity which in fact is a byproduct of much smaller beings.

For now catalyzers are only native life form implemented but more are to come. As it was the case with previous features, my main goal was to work out the foundation and have at least one example of the feature in action. In this sense catalyzers are one example of special participants in the game who partly play as regular player and partly have special privileges. They can make order their fleet on galaxy map and in combat but can live without colonies, can see whole map and spawn "ships" out of thin air/vacuum. It was fair challenge but I now have a system which supports "fake" players without reinvention of the wheel. Theoretically I can add another fake player for parasitic life forms who pray on stareater's organism and have them fight each other. A theory which I intend to put in practice one day :).

Another big deal introduced with this feature is an ability to put persisting traits on stars during combat and they can have active component now. So far traits were passive, a celestial body would either have it turn 1 or not have it ever. Now for example stars with "catalized" trait can actively inflict increased radiation to orbiting planets and ceasing to do so after a few turns.

There are few bug left to iron out, mostly when saving and loading. When I fix them I'll make a new build available for download.