[Sofox]

This is for general discussion of various technical issues. If a given technical issue gains a lot of discussion, we'll branch it off into it's own topic.

To round up the basics: The source Code Repository is at: https://bitbucket.or...ius-game-engine and uses Git. (Discussion here);

The license is likely to be MIT as discussed here.

Currently, the engine is programmed using C++, OpenGL, and using SDL for Input and Windows Management.

The architecture is still being developed, and likely to be revised, but at the moment is largely functional with a strong emphasis on keeping the engine in neat segments.

If anyone has any issue or something else they want to raise, feel free to respond.

This post has been edited by Sofox: 28 November 2012 - 10:02 AM

[Relick]

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.

Anyway, each option has pros and cons. (a) I don't think will be a good option, because the total size will be huge and therefore load times will be too - however it does have the ease of use of simply copy paste for anyone who is making/modding a game.
(b) I think is the best option as it keeps the loading times and file sizes down however it won't be as easily accessible as unencoded (as mentioned above).
© would have the lowest file size, however high loading times (because it has to access every file at the initial load as opposed to as it needs it).

I personally would go with (b) with a toggle option to switch to (a) for whatever reason they wish.

[winterhell]

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.

[Aerosol]

There's no need to reinvent the wheel when it comes to physics engines. I also throw in my vote for Bullet3D.

Also:

Sofox, on 28 November 2012 - 10:16 AM, said:

Aerosol: I have no objection to using GLFW instead of SDL, but I'd appreciate it if you could post your reasons for wanting the switch in this thread I just created for technical discussion.

You're right, my bad!

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.

This post has been edited by AerosolSP: 28 November 2012 - 02:43 PM

[Relick]

winterhell, on 28 November 2012 - 01:45 PM, said:

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.

[winterhell]

I agree about the images and audio being better archived.

[Sofox]

Relick:

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.

[Aerosol]

Sofox, on 28 November 2012 - 06:29 PM, said:

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?

[Candescence]

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.

[Aerosol]

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.

[Candescence]

Probably a good idea as well, I've been having similar considerations.

Also, Aerosol, how far along with the countryside in question are you? I'd like to be able to see something big in scale, shouldn't be that hard with a terrain generator/editor.

This post has been edited by Candescence: 01 December 2012 - 09:12 AM

[Aerosol]

Dang nabbit, I knew I forgot something. Hold on a second.

BAZAM.

This post has been edited by AerosolSP: 01 December 2012 - 09:32 AM