petak, 22. travnja 2016.
Download Stareater v0.4.4
Last time I tried solving DLL loading issue I went with a solution which involved applying certain application configuration. To be honest I don't really know how application configuration XML works and what it can do so the fact it didn't work might have been my incompetence. I suspect that configuration only applies to one assembly, not whole program. Since Stareater has some logic in EXE file and some in a so called "core" DLL, the configuration might not have been automatically transferred from one to another. Anyway I've found a new solution, instead of loading DLLs with LoadFrom function I could use UnsafeLoadFrom. As the name suggests and as documentation convinces me, it won't pester perform security check so I hope it won't be a case of "works on my machine but explodes on yours" any more. And I promise to take closer look at sandboxing plugins later.
About new old game features: farming and mining. Much like Master of Orion II, farming is there to keep workforce from doing useful work and make biology advances improve economy by decreasing the portion unavailable workforce. To keep mechanic relevant in middle and maybe late game I've split food production to two parts: farming and gardening (for the lack of better word). Farming produces a lot of food, especially on planets with good climate but there is limit on how many fields can be cultivated. Gardening on the other hand produces small amount of food but is unrestricted by planet's characteristics. So as technological advances enable more densely populated planets there will be an incentive to improve farming too.
It's a bit of deviation from CroVar iteration (last attempt at whole Stareater project). Back then there were only farmers but after certain point their efficiency gradually diminished according to certain nonlinear function. The problem is when calculating food production you don't really need to deal with a function of food per individual farmer but with an inverse of integral of that function. In other words, you want to calculate how many farmers do you need to produce certain amount of food. Integral will tell you how much food would certain number of farmers produce and inverse of integral will tell you how many farmers do you need to produce certain amount of food. In general integrals and inverses are more complex then original function and when you combine complexity of all three you don't get a simple formula. And that's the beauty of farmer-gardener approach, it's easy to explain, relatively easy for player to estimate the numbers, it's easy for me to fine tune and it achieves the desired effect.
Mining was and remained simple mechanic. Miners are extracting ore at certain rate and industry workers convert ore to an industry point in 1:1 fashion. In a sense it's like food production, another mechanic for wasting workforce and excuse for introducing more economy boosting technologies :). But unlike farming it rewards exploitation of minerally rich planets. In future I plan to introduce trade mechanic which will allow an empires to import minerals from rich to poor worlds, increasing the importance of rich planets to galactic level. More about it in next version.
petak, 15. travnja 2016.
Download Stareater v0.4.3
Like last time, the package is a simple zip file so to run the game extract contents and start Stareater.exe. And again the game is .Net 4.0 application so it should work as is on Windows XP SP3 and newer and should work on Linux and Mac with Mono.
utorak, 12. travnja 2016.
Shooting part of space combat is mostly done. Ships can cut each other with lasers and drop nuclear bombs on planets. Colonies can be wiped out too but I'm still testing and polishing that part. Functionally, cloaking and detection is missing and I have to decide how to make inaccurate weapons like bombs viable in ship to ship combat. The idea is to give small and maneuverable ships means of seriously hurting large ships.
Visually there is a lot of work left and I'm feeling like I am stretching Windows Forms (Windows default user interface solution) way past intended purpose. Customization options boil down to either a set of inflexible switches or overrides where I have to do whole component from scratch. There is no middle ground where I could override some parts of default look and functionality but reuse the rest. Yes, I could instead work on adding more visual feedback on hex grid like beam rays and causality numbers but GUI part is bugging me so much. I'm seriously thinking about adopting GWEN.Net (an OpenGL friendly user interface solution) and ditch WinForms as much as possible.
And I see another cloud creeping over. At some point I'll have to improve my rendering engine and basically reinvent part of Unity engine, which poses a question: should I have made the game in the Unity in the first place? I'll try to stick with no as long as I can. Rewriting would probably take way more time then it seams at first glance and I have some experience on implementing scene graphs so it might end up being faster solution. Also, doing it on my own gives me the opportunity to tailor it to my needs. There are some design decisions in Unity I don't agree with and I can work with assumptions that apply only to my project. I'm confident that my current code base is good enough to endure such changes.
It's eating me too but you'll have to suffer through ugly GUI until version 0.5 is finished. I'll put more effort in visuals in the next version.