Aurora C# Screenshots

[AL]

Well, we can only hope that one day something like this does get implemented. But for the time being, I'd be happy enough to see the current game state released under the C# architecture, let alone Aurora with new/improved content.

[Retropunch]

I'm mostly a lurker, but I had to come out to say how excited I am by this.  Whilst Aurora is definitely one of my favorite ways to enjoy my spare time, I'm always held back by knowing that eventually my game will experience heat death.  So this update, combined with the general/UI enhancements will make this pretty much my favorite game of all time, and I fear for my future.

All in all - great work Steve, please keep it up!!

[TMaekler]

If you would need some hexfield underground pictures for the ground combat, I have some left from an update we had planned for "Advanced Strategic Command" (updating the field size from 48x48 pixels to 96x96 pixels), which never took place due to time constrains of the programmer. So the game stayed with the smaller gfx. However they still exist and can be used somewhere else

Here is a demopicture:

[QuakeIV]

Calm down guys, he hasn't even finished the refactoring yet.

[Steve Walmsley (OP)]

Calm down guys, he hasn't even finished the refactoring yet.

Yes

It will be many months before I even get close to the VB6 version.

[eldernos]

The only new feature I REALLY want is multi-threading. 

I would never not be playing this game (even more than that is already true) if it was faster. 

[Steve Walmsley (OP)]

The only new feature I REALLY want is multi-threading. 

I would never not be playing this game (even more than that is already true) if it was faster.

It will be faster but the main reason will be minimal database access rather than multi-threading. Most of Aurora is sequential so the scope for multi-threading is limited. Detection is probably the only area where it would make a significant difference.

[Barkhorn]

Let me just say first that I'm THRILLED that Aurora's coming to the 21st century.

Now, couldn't you give each populated system it's own thread?

[Steve Walmsley (OP)]

Let me just say first that I'm THRILLED that Aurora's coming to the 21st century.

Now, couldn't you give each populated system it's own thread?

I am by no means a multi-threading expert but it seems the advantage of multi-threading is to allow the PC to perform simultaneous calculations that have no effect on each other. So multi-threading movement wouldn't work on a system level as some movement involves entering different systems and on a fleet level it wouldn't work due to the requirements of initiative etc.. There are a few things it would work for such as orbital movement, pop growth, production, etc but those are generally so fast anyway that multi-threading would make very little difference. Detection is one area that could be multi-threaded and may be improved. Perhaps another is the AI. However, I don't want to use multi-threading just for the sake of it (especially as it apparently easy to get yourself into trouble), so I'll see how the performance is once the game is mostly complete and then look at multi-threading in areas where performance is an issue,

[Shajenko]

I am by no means a multi-threading expert but it seems the advantage of multi-threading is to allow the PC to perform simultaneous calculations that have no effect on each other.  So multi-threading movement wouldn't work on a system level as some movement involves entering different systems and on a fleet level it wouldn't work due to the requirements of initiative etc. .  There are a few things it would work for such as orbital movement, pop growth, production, etc but those are generally so fast anyway that multi-threading would make very little difference.  Detection is one area that could be multi-threaded and may be improved.  Perhaps another is the AI.  However, I don't want to use multi-threading just for the sake of it (especially as it apparently easy to get yourself into trouble), so I'll see how the performance is once the game is mostly complete and then look at multi-threading in areas where performance is an issue,

Multithreading on a system level would only work if you could figure out which systems (or system groups) are "separate", or that will have no ships going between them during a given time pulse.   Early on that would make every system its own thread, but later on there would have to be "clusters" of systems that have to belong to the same thread, and if things get interconnected enough then you wouldn't be able to do it at all.   Since the later game is the part that is the problem performance-wise, it doesn't seem like this strategy would help very much.   

Multithreading sensor detection would probably help quite a lot though, as I understand that it is very calculation intensive, and I don't see how resolving different signature detections would interfere with each other.   I could be wrong though.

[Barkhorn]

Well as long as the thread creation overhead isn't too bad, it still seems like it might be useful.  Surely not every system would be in the same cluster every time interval.  Ships don't jump THAT often.

[83athom]

Surely not every system would be in the same cluster every time interval.  Ships don't jump THAT often.

Imagine a game where there are 5 different empires at war with each other with each having several war fleets. During wartime, any given fleet would take 5 days between system transits (give or take). With these fleets, they have support fleets behind them a jump waiting for the war fleets to need them, with empty support ships going back for reload while fresh ones come up. Now lets add civilians who automatically trade between your own systems (between colonies) that can number in the hundreds at times, and your other ships such as scouts/survey ships going around doing deep recon to find new paths, finding new empires that will on their own will now build and explore.
Granted outside of wartime, there would be a lot less jumps, but there would still be a lot.

[bean]

Well as long as the thread creation overhead isn't too bad, it still seems like it might be useful.  Surely not every system would be in the same cluster every time interval.  Ships don't jump THAT often.

The problem is that working out which systems fit in which cluster is not trivial for several reasons.  First, it's possible that a ship could cross multiple systems in a single full step, so you'd have to recompute for every substep.  Second, what happens when clusters collide?  You initially have one empty system between two clusters.  During the turn, ships jump into it from both clusters.  Thus, to a first approximation you'd need two unoccupied systems between each cluster.  Early game, when that might happen, performance is good enough as-is.  Later on, it won't.

[Steve Walmsley (OP)]

I've not posted any screenshots in a while as I have been working on loading and calculating all the data for the economics window (plus I have been back at work after some time off). When this is done it will lay a lot of foundation for the 5-day intervals.

One interesting item has popped up. Due to the new Low Gravity Infrastructure (now LG Infrastructure, not AG - thanks for the suggestion), comets can be colonised. However, their colony cost will change over time depending on their distance from the sun, which may lead to some interesting situations. If this works out OK in practice, it would open up the possibility to use elliptical planetary orbits and have changing colony cost over time for planets/moons and asteroids.

[QuakeIV]

Huh, that could be interesting.  I would guess that colony management would need some adjustments to get that to work.  Some way to either cap population, or automatically terraform to maintain a certain temperature.  Maybe swap between nitrogen and greenhouse gas and back?  It would make fixed terraforming installations a lot more popular in some cases.