(Ugh, forum lost my post, I think).

1) Horizontal layered architecture, with a more service-oriented approach

2) Vertical delivery of function, so that "something" is delivered early

However, I think it's too early to be guessing what tool(s) will be needed or whether SimPE should be extended.  (There are arguments that the existing tool could be split into more specific components with a shared core library.)

I probably would have contributed a plugin for SimPE, rather than seperate plugins for MilkShape, had it not been for the .NET based C# interface. I know Quaxi has talked of using C++ before, and if we are able to and keep the present shell, maybe we could implement at least a straight secondary external editor plugin interface, a modal interface similar in concept to the external tool interface, so that a block of data (or a file handle) is passed to an editor, with a pointer to a series of function calls or methods that return or set some of the package level data items. When done the editor would pass back a return code that would either cause the file to be inserted back in the package (with any user changes) or if -1 then SimPE would delete the file, discarding changes. SImple and effective.

In concept this DLL would get registered for specific sub-packages at startup by calling the DLL itself. SimPE would maintain control of the overall package integrity, but various file converters, exporters and editors like Echo's neat little footprint editor could be added or updated without compromising the integrity of the main program.

So, it is too early to know what we will be faced with, but I am planning on contributing in some way, even if it is just researching game formats.

<* Wes *>

I agree. Please do so.

I am not opposed to GCC for the core at all. If we do the spec right, you should be able to link almost any language to the core, written in GCC or Visual Studio (C++ or VB) or what have you.

<* Wes *>

I use Eclipse for all my C/C++ work.  In fact, I use Eclipse as my CVS and SVN client for all my C# work, too.  And I've even tried writing ANT build scripts to build SimPE using MONO under Eclipse (that was fun).

What Eclipse doesn't have is a nice free Windows C/C++ GUI editor, AFAIK.  (I imagine there are commercial GUI designer plugins for it.)  If the GUI was completely separate from the core code, then those classes could be maintained in VS but the project build could be run under Eclipse (either using make, or the C/C++ Eclipse build tool, or ANT).

I don't know HOW (I've never used C or C++ myself, willing to learn though), but I know that you can build DLLs in C/C++ and then use them with Visual Studio. So at least with that it'd be easy enough for the team to make the code for the libraries cross platform.

From there, each developer or other outside developers could then write small, efficient tools with whatever language they want and whatever platform they want to handle certain tasks, depending on what EA gives us of course. I'd imagine we'd have to make an object editing tool for sure, but at the same time I'd love to see a tool specifically for hacking be made seperately.

I dunno, just some of my thoughts anyhow. I've been liking Java lately since the classes I'm in all use it, but I'm not sure I'd want to ever use it for a project like this. I think something cross platform for the libraries is the best move though, at any rate, and from there, who knows...