Yet Another Update news

Intro
Much of the work I've been doing is behind the scenes coding that can't really be shown off, or even bragged about. But I think you deserve to know some of what I've been working on these past few weeks.

Skyboxes
Pretty nebula textures are an essential part of any game set in space. There are currently 11, and here are the 3 newest additions to the family (click for a full size version).

Not too shabby for a game sitting in pre-alpha. I'm going for a healthy mix of plain and "interesting" skyboxes.

Music
Work has commenced on a musical score for AS. The first WIP track is a passive track that should play when there is no danger and you're near a planet.

Track 1: Glass - Mod DB

As you can tell, this is a work in progress. I am trying to emulate the musical style found in X3, which is best described as a mix of techno and alternative.

If you want to contribute tracks or compositional ability, I am willing to accept.

Multithreading
From the start, I designed Astral Clause to take advantage of multicore processors. Seriously, everyone has one now. Instead of the single threaded or render thread-logic thread approach, I have divided the logic thread into a few smaller threads. This results in a noticeable performance (as in more fluid game play and stable frame rates) on multicore CPU-based systems.

Here are the highlights.

1. Only ships in the same solar system as the player are updated in the same logic thread as the player. This means that I can have hundreds or even thousands of NPCs all around the universe doing their own thing without hurting the player's experience. Only objects in the same system as the player are updated in the central logic thread, everyone else is updated on a separate thread. If this thread gets laggy, the player probably won't notice. This helps avoid the issue of slowdown as you explore the universe and add more sectors to the map.
2. The orbits of planets and other objects are always calculated in a dedicated thread. Once again preventing your gameplay from being affected by the linear growth of the universe. By keeping orbital mechanics out of the main logic thread, we get a substantial performance benefit.
3. The multithreaded approach is seamless. If you switch systems, there isn't an issue changing what thread is responsible for updating an object. Each updater class holds pointers to the ArrayLists for the relevant objects, and uses some simple if-then logic to determine who it's responsible for. Since nothing is moved, there are no weirdnesses that pop up.

Stations
I am currently working on the in-station market and other features that you can only use while docked, but it isn't presentable yet. As a side effect of this work, I've also had to work on cargo bays and commodities to have something to buy and sell, and somewhere to move it.

Let's be clear. I am opting for a true dynamic market based economy. I've played enough Freelancer to know that trading commodities that are in infinite supply and statically priced is lame. Also, factories will produce goods at a predictable rate, as long as they have the needed resources. And eventually, borrowed from X3's "GoD", a watcher will determine when a station is bankrupt and remove it from the game, spawning a replacement station somewhere else.

Comments
Questions? Comments? Email me at masternerdguy@yahoo.com or feel free to talk to me here! All feedback is valuable. This is a very young project open to influence.