[Thaeris]

While the internal forums start to come to life in this board, the outside observers and those directly interested in the project might be wondering what direction needs to be taken so that Starshatter can further evolve and mature in the years to come. The internal board may also be wondering about this as well...

...So, an open discussion is in order. That said, let's begin..

First, Starshatter is a pretty stable, good game just as it is. Vanilla FreeSpace was like that, too. Heck, I can even play FS1 and FS2 just as they are (or were) from my GOG download. But, those, just like Starshatter, were not without their problems and limitations. The current build of Starshatter, as we are distributing (correct me if mistaken), is 5.0.5. This build was released by the game's author and tweaked/re-compiled by The_E, and omits the need for a serial key to run. Unfortunately, it also breaks multiplayer. That said, this is probably the first pertinent task at hand for Starshatter Open.

After fixing the articles which are directly and obviously broken... things become grey. Starshatter uses DirectX 9. I think most of this board is in favor of OpenGL, as it is far more flexible with multiple platforms, and seems to be the graphics format that most coders are comfortable with around here. Moving to OpenGL will certainly expand the user base of Starshatter, and I'd like to think that anything with DX9 you could do then or now, you could do even better with OpenGL.

And then there are tools and documentation...

And then there are matters of game physics and AI - what do we do here? Making a fork in the code base is probably not a bad option, because the old, retail game may not cooperate well with actual Newtonian physics, or an improved AI or campaign system. Starshatter has a lot of potential...

...But it's probably best to start slow, and fix the broad issues first.

[Polpolion]

I'm in the process of learning OpenGL, and I plan on taking a look at that in the code at some point in time. That said, I work full time, I know zero Direct3D and I literally got my superbible last Tuesday, so that'll probably let you know what to expect from me. Also, what else (other than 3D) does Starshatter rely on DirectX for?

[MatthTheGeek]

And then there are matters of game physics and AI - what do we do here? Making a fork in the code base is probably not a bad option, because the old, retail game may not cooperate well with actual Newtonian physics, or an improved AI or campaign system. Starshatter has a lot of potential...

Ideally, any Starshatter Source Code Project should follow a similar "Thou Shall Not Break Retail" philosophy as FSSCP. There are many ways to implement new features without breaking retail and without needing a fork in the code base. Tables, command line flags...

[The E]

We have an internal board? Why do I not know about it?

[Dragon]

There's a small thing I noticed, that could use a fix. When playing with my 5.1 headphones, the interface sounds are played only in the left speaker, which is very irritating. I've seen this happen in a lot of older games (like Red Faction), and the only way to fix it is to tell the computer to emulate a standard headphone configuration (disabling all the neat features my headphones have in process). The problem most likely also appears on 5.1 speaker systems. Anyway, a fix for that would be appreciated.

In other news, I'm slowly getting started with the game. It's absolutely amazing, and I'll most likely get into modding it (once I get done with most of my FS stuff and RL gets off my back, that is). Good luck with the SSCP. 

[The E]

My personal Roadmap (excluding the necessary bugfixes) consists of getting an OpenGL renderer to work. I just do not have the time to really learn how to DirectX in depth.

There are also bits and pieces in the code where wheels were reinvented that I think can be better served by reimplementation using STL code. This of course involves C++0x features, which involves figuring out which parts of C++0x are supported by Visual Studio 2010, or looking into making Starshatter cross-platform (so that we can have a build path that involves gcc).

[Thaeris]

And then there are matters of game physics and AI - what do we do here? Making a fork in the code base is probably not a bad option, because the old, retail game may not cooperate well with actual Newtonian physics, or an improved AI or campaign system. Starshatter has a lot of potential...

Ideally, any Starshatter Source Code Project should follow a similar "Thou Shall Not Break Retail" philosophy as FSSCP. There are many ways to implement new features without breaking retail and without needing a fork in the code base. Tables, command line flags...

There are again, quite a few options up for grabs. But, I think I indicated clearly enough that blantantly breaking retail was not one of them. One can fix the game or enhance it without changing it entirely. That was in fact the bulk of the first post. The potential fork was noted... you might want to start playing the sim before that matter is discussed further.

As far as the assumption that there was an internal board - I suppose I assumed too much.

[The E]

Once there is an actual team working on the Starshatter source, I may request the addition of an internal board. As it is just me at the moment, I don't see the need for it.

[braddw25]

What is an internal board anyway?

[Scotty]

It's a sub-forum that's hidden from the general public and accessible by the actual team members to discuss things that the general public has no business mucking around with, and is just generally less cluttered and more organized if you have mods that know what they're doing at all.