Just like rocketchat/confluence! Thank you much.
The density issue occurred to me too after I fired up the game again, but your suggestion about using pixel information is fascinating and not something I’d have even considered. I might have approached it in the opposite direction and described nebulae as grid units of fixed density (within the grid unit) bounded by lines and then algorithmically generated the imagery from them. I guess being a C programmer makes one think in structs… I’d be curious to discover how they actually do it. The notion of using pixels reminds me a bit of the Cyan guys extruding heightmaps from greyscale images back in the day.
Regarding the density calculation; in either case I don’t think it’s too hard. Once one determines the segments of the LoS intersecting the nebula, merely take a regular sample of the density along it, average their sum, and apply that as a second coefficient.
I concur. This game makes my creativity itch. So many things I can think of to add…
As for making an API; I believe they’re using the .NET framework, so Objects is probably written in C++ or C#. Maybe some of those .NET script macros thrown in too.
Unless they wanted to open source their code (hint: they don’t) having an closed source application written in a compiled language makes for some hard times. Making an API available in a different language that doesn’t need compilation, thus insulating the core of their application from exposure, would still be non-trivial.
I guess they could make a tiny SDK with which one could write DLL’s and load those at runtime, but this approach would limit their audience fairly substantially. It also seems like most commercial games that can be modified are either based on something like Java (compiled to bytecode not native, decompileable, etc) make use of an existing scripting language, or have their own.
This all being said, making an API would hinge most of all on how well the application is organized for it. Usually one needs to plan ahead for this sort of thing.