don't click here

Technical Discussion

Discussion in 'Mobius Engine Project' started by Sofox, Nov 28, 2012.

  1. Sofox

    Sofox

    Member
    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.org/Sofox/mobius-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.
     
  2. Relick

    Relick

    Member
    197
    0
    16
    England
    C++/DX10 Engine (not sonic related)
    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).
    (c) 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.
     
  3. winterhell

    winterhell

    Member
    1,165
    7
    18
    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.
     
  4. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    There's no need to reinvent the wheel when it comes to physics engines. I also throw in my vote for Bullet3D.

    Also:

    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.
     
  5. Relick

    Relick

    Member
    197
    0
    16
    England
    C++/DX10 Engine (not sonic related)
    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.
     
  6. winterhell

    winterhell

    Member
    1,165
    7
    18
    I agree about the images and audio being better archived.
     
  7. Sofox

    Sofox

    Member
    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.
     
  8. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    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?
     
  9. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
    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.
     
  10. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    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.
     
  11. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
    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.
     
  12. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    Dang nabbit, I knew I forgot something. Hold on a second.

    BAZAM.