My questions may not be relevant this early in development (however with my engine we did this straight away) but:

1) Physics Engine - Will we use a pre-built one or make our own. I'm leaning towards the former and using the Bullet3D engine (as I've only had good experiences with it) however the latter would give us a lot more control and rid us of a lot of unnecessary overhead.

2) File Storage - When we deal with the user created content (levels, scripting etc.) we need to know which way we will store it. I see three options for this:

a) Completely unencoded and left in neat folders for easy access
b) Encode* each file that is used and keep them in the folders
c) Zip (or some other method to compress all the files together) them up (and possibly encode* that too).

* When I say encode, I mean any method that will knock some bytes off of the files (such as Huffman encoding). It doesn't have to be encryption and since this is open source it would be pretty pointless to bother encrypting the stuff anyway.

You should know that binary uncompressed models load faster than either compressed or uncompressed text models, be it COLLADA, obj. Especially the XML formats. Most of the times the uncompressed binary would take less space than the rest of the options.

I'm not a programmer, so what I'm about to say is based off my own research and may or may not be accurate. But it seems like GLFW is far less heavy handed than SDL is. If all we need is a window manager and an input manager, I'd rather use the more lightweight approach.

You should know that binary uncompressed models load faster than either compressed or uncompressed text models, be it COLLADA, obj. Especially the XML formats. Most of the times the uncompressed binary would take less space than the rest of the options.

But when it comes to loading textures, scripts, sound etc. it all builds up which is why I suggested the compression in the first place. I don't know - I'm only going off of what I have done in the past. If there are better alternatives out there I'd gladly hear them.

1) Physics Engine
I'm leaning towards Bullet3D also, but I'm not naive. It can be tricky making it work seamlessly with the rest of the game. We'll focus on the engine for now, and consider integrating Bullet3D when we've got a bit more firm footing.

2) File Storage
a) Completely unencoded and left in neat folders for easy access
This is the approach we'll use in early stages of the project, no doubt. For simplicity, debug and testing, and source control, it's just easiest to have the files stand on their own in a simple directory project. At later stages of the project, I think this would be good to have as an option, both for development and modding.

b) Encode* each file that is used and keep them in the folders
I'm not sold on this approach. It seems to make things more complex and I'm not sure how much of a benefit it would be compared to...

c) Zip (or some other method to compress all the files together) them up (and possibly encode* that too).
This is the method a lot of professional games use. We've got compression, and we've got ease of managing files.

There's obviously more I've got to learn in this area, but my feelings is that a) for now and with the option of c) when we get to the stage where the assets get big.

winterhell: We will have to consider the speed of loading COLLADA models, but for now they're an open format that should make getting assets into the game easy so that's my concern for now. If you know of a format you think is better suited I'd appreciate it if you could propose it.

Aeresol: I created this thread after I saw your comment so don't worry.
In any event, I see where you're coming from. I'll consider changing to GLFW, but not right now as there are other things that I'm concerned about. Frameworks are things you can get easily hung up about (we could spend ages debating whether to choose SDL, SFML or GLFW; each have their advantages), and right now I'm more focused on making the game then getting too caught up in the debate.
Don't worry though, any good engine will make it as easy as possible to swap one framework out for another, and as the game project continues, we'll have a better idea on what we're looking for.

I created this thread after I saw your comment so don't worry.
In any event, I see where you're coming from. I'll consider changing to GLFW, but not right now as there are other things that I'm concerned about. Frameworks are things you can get easily hung up about (we could spend ages debating whether to choose SDL, SFML or GLFW; each have their advantages), and right now I'm more focused on making the game then getting too caught up in the debate.
Don't worry though, any good engine will make it as easy as possible to swap one framework out for another, and as the game project continues, we'll have a better idea on what we're looking for.

Absolutely. I don't want to get hung up on small details either.

By the by, don't mean to sound pushy, but are we going to get a roadmap going? Cross off that one entry on the todo list?

I also agree that Bullet3D is the best choice as far as physics engines go.

I'm surprised by the progress this project has been getting ever since Sofox has revived it. I do think we need a proper roadmap, as AerosolSP said, though. Since it seems the next two tasks are movement physics and COLLADA support, there should probably be a roadmap thread for suggesting features and when to implement them.

I also suggest that there should be someone overseeing the 'content' side of things, since we're gonna be making content to demonstrate the engine's capabilities.

A content overseer might be a good idea in the long run. I'm not sure about right now, though. Anyone can throw together a countryside scene, really. I'm doing one right now, but there's nothing stopping someone else from doing it before me (or better than me). Maybe when the scope of content that needs to be created broadens up we'll need one.