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.

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.

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!

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.

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.

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.

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