Try one: pure Python

Things have to start somewhere

The very first version started as a simple series of procedural generation scripts destined to test feasability and logic - think textual output to a console.
After those initial scripts were proven to "running well-ish status", they were quickly promoted to Django models methods and properties.
And then implemented as management commands.
And then back to properties/functions.
In a word: quite a few tries and failures.

At that time, the maximum procedural level of detail (LOD) used was cube. That is, the engine (if it could be called that way) was generating the galaxy's overall structure and very high-level characteristics - nothing more:

• Shape: spiral, elliptical, etc.
• Density: a dimensionless number, randomly calculated for a unique combination of [x, y, z] cube coordinates.

Wait… cubes?

Yes, a virtual cube used as a virtual space partitioning device. Each inherits characteristics from its parent galaxy, and has the ability to generate its children stars. This is based on the divide and conquer idea: when a problem is of galactic size, split it into many smaller problems which will: 1) be individually easier to solve 2) when looked as a group from a distance, will actually reflect/output the solution to the original galactic problem in acceptable appearance terms.

The density calculation for cube coordinates [x, y, z] was the first seeded pseudo-random calculation; when ran, it was used for a relatively small number of cubes, anything from 1 to 100.

So speed wasn't an issue.

My god, it's full of stars

Then came star generation:

• Position
• Age and lifespan
• Mass, luminosity and radius
• Temperature and color
• General physical characteristics such as surface gravity, escape velocity, etc
• Metallicity
• Surface system generation: number of and types of satellites, etc.

Now, while most of these calculations were simple "linear" computations, some of them involved seeded random calculations. For reproducibility reasons. And this is where things started to seriously slow down. I already knew the "engine" was still very shallow; but already, computing the characteristics of a few hundred cubes' stars only would take anywhere between 50 and 100 milliseconds.
Actual example:

Now a fraction of a millisecond per star doesn't sound like much at first. But the whole thing needed to be sustained and streamable for a large number of stars, and served to multiple clients at the same time, almost in real time!
Not to mention CPU usage, which was actually quite high and ran into peaks.

Even when taking into account dynamic level of detail, I knew then that trying to stream such content over websockets and displaying it to client browsers like I was envisioning would not work. It was too slow. Way too slow.

Bear in mind that, at this stage, there was practically no useful data at all!
Another proof of why Python, while great, isn't exactly known for its stellar performance.

So I had to try and to come up with alternate solutions. Have a check a my first try here.

Useful Python outcomes

This stage did yield some positive outcomes, though: some nice graphs to sanitize things such as mass distributions, mass/radius relationships amongst a star population, etc.
With a final goal: to verify that the procedural outcome felt close (**cough** enough) to the Hertzsprung–Russell diagram (at least for the main sequence) and other "real data" sources.

Maybe future posts will show such diagrams on the client, but based on actual procedural data.

Generally good outcomes

Even though the code from that version has sunk to the bottom of the repository's abyss (it's quite dark and damp down there) , many of the algorithms, values and formulae it originally implemented haven't changed a bit!

Another proof of why Python, while slow, absolutely shines for prototyping. It is fast and easy, and allows for quick tests and sanity checks.