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