don't click here

Mobius Engine Project General Discussion

Discussion in 'Mobius Engine Project' started by Gen, Feb 16, 2012.

  1. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
  2. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    We need to do two things right now for this project, before continuing much further.

    First off, we need to discuss a general scope for something like a pre-alpha. I think there's an idea of what a final version should be, but there's still many, many steps between here and there. So lets start with a pre-alpha. Where should this project be for a pre-alpha version of the engine? Keep in mind that pre-alpha doesn't have to be perfect, it doesn't even have to really run very well. After work is underway for the pre-alpha, and we've gotten a general idea of how things will evolve for the Alpha, we should begin focusing on ideas for an Alpha to build upon what has been and will be accomplished with the pre-alpha. We can iterate through the process as needed for future milestones as well, refining it as need be along the way.

    Next, we need to discuss licensing. Should we use LGPL? How about GPL? Maybe a more permissive license such as MIT, BSD, or ZLIB? What if we used GPL + Exceptions, or even licensing the core engine under one license, and a smaller module SDK of sorts under another? Maybe a custom license? This is a topic that should be discussed at length, as it will effect what people can and can't do with the engine's code, and will likely effect the general direction of development. Some licenses have more benefits than others, and some are more restrictive than others.
     
  3. StreakThunderstorm

    StreakThunderstorm

    Member
    216
    0
    0
    Mecha Madness
    Well first things first. For the alpha, there must be some sort of asset importing. Will the engine have its own IDE for asset editing, maintenance, etc? Will there be some sort of material editor as well? I was pretty impressed with UDK's material editor and how it was compiling down to HLSL. Unity has something similar created by someone else that compiles down unity shaders based on the editor. Its not very optimized though. Something like that could be great for beginners for the simple fact that its actually compiling down a shader. They could compare the connections they made to the code that was compiled and learn from that. Obviously we'd need a basic render engine. Something to see everything with. I don't think the alpha should have anything like HUDS or any extraneous things. Maybe just a simple movement to show that the engine works. Basic camera functions. Lights. There have to be scene lights. What kind of lighting methods would you be looking to incorporate into the engine? What kind of shadowing methods do you wish to incorporate with that? As far as performance goes, it would be nice if characters would be GPU skinned. It'll take the load off of the CPU.

    As far as licensing goes, I'm not too knowledgeable on the subject. I can't really contribute much. I know for a fact that if this is going to be based off of a Sonic engine, we obviously cannot sell the games we're going to make. To me, thats fine because it would provide a great foundation for people to get into real programming so that when they're done making Sonic fangames, they'll have enough knowledge to branch out and maybe even make their own engine. Thats probably expecting too much but it would be nice.

    It would be nice to have things implemented further down the line like global illumination, SSAO or even SSDO. A global illumination method would be nice because it wont require multiple lightmaps to be loaded to the GPU. I don't know where those would come into play but there's plenty of examples of how to implement them. SMAA would be nice too since its a really cheap and smart method of AA.
    http://kayru.org/articles/dssdo/
    http://www.ogre3d.org/forums/viewtopic.php?f=11&t=46794&sid=ab01b6329a160a1941e059b2eef4e0ce
    http://www.iryoku.com/smaa/
     
  4. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    Let's not get so much into the alpha, and lets focus moreso on the pre-alpha.

    For the pre-alpha, I'm thinking there should be more discussion about the lower-level functionality of the engine, than tangible features. We need to determine what libraries will be useful to development, how some libraries would be better than others, what we need to do to establish the basis of different systems in the engine, and other shit that no one will probably want to touch again later on in development.
     
  5. StreakThunderstorm

    StreakThunderstorm

    Member
    216
    0
    0
    Mecha Madness
    Well basically, how will the engine be programmed? What language(s) will be supported? Define that and move forward. As far as pre-alpha features... Basic input response. Press something, something happens on the screen. Maybe something basic like directional movement based on arrows. As basic renderer that will just show something on screen.
     
  6. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
    Well, I think we've established that we'll be using C++ and OpenGL. We should allow this engine to run on more than just Windows, and last I checked, OpenGL was just as good as DirectX.
     
  7. Knucklesdood

    Knucklesdood

    Member
    9
    0
    0
    Redmond, WA
    Solipsys Redux
    I have a number of additional questions about the underlying engine:

    • What kind of build system will be used? Will there be some sort of premake solution that can generate different kinds of projects for different platforms, or will there be separately maintained projects?
    • Will the STL be used? Boost? Many games avoid the STL or Boost because more highly optimized and use-specific code can be custom-written for the game engine.
    • Will a math library be brought in or custom-made? (GLM was brought up earlier)
    • Will a custom memory manager be needed?
    • Is OpenGL the graphics library of choice? How about GUI APIs? APIs for editors and tools perhaps.
    • How will fonts work?
    • Which model/animation formats will be supported?
    • How will input be handled? Which library or libraries will be needed to handle all forms of input?
    • Debugging tools? AntTweakBar is useful.
    • How are resources loaded in and handled by the engine? How does some high-level code (such as script or GUI interface) load in a renderable mesh?
    • Will strings be allowed or forbidden in the engine? GUIDs?
    • How are objects serialized? Binary serialization? XML? JSON?
    • What form of script binding will the engine use? Lua, javascript, etc.
    • How do systems operate and interact? Message-driven and/or event-driven?
    • What is a game object? Is it a bunch of components? What are the core components that need to be implemented for pre-alpha?
    • Where is the game loop? What does it do?
    • Will any systems need to be multithreaded? (common candidates are resource loading or rendering; threads where "jobs" can be queued and worked on)
    • Overall, what does the engine architecture look like? Is it layered? Is it based on a series of managers (for graphics, sound, etc.)? Does everything talk through a core? Or do systems communicate with messages?

    Note that what also needs special consideration when choosing low-level APIs is that it's a goal of this project to be multi-platform, so the platform layer of the engine has to be able to run on all supported platforms using all of the listed APIs.
     
  8. Elratauru

    Elratauru

    Little Shiny Emurralds Member
    I'd gladly like to postulate to help after the groundwork of the engine has started with basic 2D stuff, I'm a professional web developer and graphic designer and while my programming knowleadge is limited to web-stuff (PHP, AS3, and CSS shit) I'm pretty good at 2D textures, from HUD's to menus and similar stuff. Also I'm interested in the fonts question that Knucklesdood asked.

    I know that first comes a lot of stuff, but I'm following this throughly and well I must admit I like the whole concept/idea of having an engine made by the community for the community.
     
  9. Falk

    Falk

    Member
    1,570
    15
    18
    If it helps any for the prototyping stage, I can actually throw together packages for both fmod and Wwise for comparison's sake. They essentially both spit out dlls and .h includes that you plug in and call.

    p.s. Wwise still handles music a bajillion times better than fmod lalalala closing my ears and I can't hear your argument.
     
  10. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    I'd opt for cmake here. Trying to maintain separate build files for each platform would be a pain in the ass.
    This is one of those things that deserves a bit of discussion on its own. STL's iterators and vectors (which really, are just dynamic arrays at the end of the day) can be nifty, but may be worth implementing as a separate light weight array class that provides the same functionality. Boost is within the realm of stable now days, and may be worth looking into to assist with threading at the very least (as well as possibly JSON or XML parsing).
    I don't see any need to write a custom math library when something like GLM already exists, and will generally fulfill most if not all vector math needs (and can be extended for cases where it doesn't).
    Would be nice I think. In the long run, if we want scalability, we'll be needing a memory manager that can handle allocating and deallocating resources in a fairly efficient way for the purposes of streaming content much later on down the road, to allow for larger levels.
    OpenGL will be the graphics library of choice. GUI, editor, and tool APIs are things that need to be discussed.
    These are all things that need to be discussed still. At least some ideas should be thrown out there for consideration.

    Personally, I'm a fan of having a series of managers. But ultimately, the biggest factor that'll influence the engine architecture will be what threading approach we take. On that note, it'd be pretty awesome if we could handle issuing calls to OpenGL on a separate thread (which is more or less what constitutes a "multithreaded renderer").
    Agreed.

    EDIT: One thing I've been looking at, are different GUI frameworks that could make it easier to develop GUIs for the engine. One that comes to mind is Awesomium, which allows for GUIs to basically be written with a combination of HTML and javascript, and even allows for browsers to be embedded within a game. They offer a non-commercial license. Something similar to Scaleform would be kinda cool too, since it'd basically allow people to create UIs in flash, and directly export a SWF to the engine for inclusion with a game. Any Open Source alternatives that can provide similar functionality would be pretty awesome.
     
  11. Elratauru

    Elratauru

    Little Shiny Emurralds Member
    Well, Awesomium like you said, is free for non-commercial stuff and for cheap indie companies and I think that its capabilities are just perfect. HTML5, JS, CSS and AS3 is just the perfect combo for creating UI's to a web developer, and not just that... It actually renders stuff using WebKit and that makes it even better along with its multicore-capability if needed. I'd vote for it, unless there is any other open source alternative with the same features.
     
  12. StreakThunderstorm

    StreakThunderstorm

    Member
    216
    0
    0
    Mecha Madness
    Would be nice to have a GUI editor. I just hope the whole engine doesn't become entirely web based. Try not to do what construct 2 did.
     
  13. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    Fuck WebGL.
     
  14. StreakThunderstorm

    StreakThunderstorm

    Member
    216
    0
    0
    Mecha Madness
    Thank you. Lol.
     
  15. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
    Hardly a fair comparison, two entirely different projects with entirely different goals in mind. :p
     
  16. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    I took a cursory glance towards the LGPL and GPL licenses, and I'm leaning towards LGPL right now. I'll give them a more thorough read when I'm not dog-shit tired. Maybe that should be the next poll, since we're not using my awesome non-suggestion for the project name? :colbert:

    + - I'm kidding  
     
  17. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    As far as the buildsystem goes, I'd be willing to pitch in and help maintain CMake scripts. I'm pretty good at it, and my work can be seen in the open source Lugaru and ProSonic projects on Google Code. It's flexible and lets you generate project files for various IDEs and makefiles for Linux, Mac OS X, and Windows.

    I'd recommend trying to use standardized libraries because we can take advantage of well-tested code that we know works. Being able to maximize code reuse through the STL and the Boost library kits is probably a good idea. It also opens us to using C++11 features that may be helpful in developing the engine. Finally, using these libraries mean that static and dynamic analysis through clang, valgrind, and gdb will be extremely useful for debugging purposes because if issues crop up from usage of those, we can catch and fix them quickly.
     
  18. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    Maybe we should have a recruitment thread somewhere.

    Also, that would be very awesome.
     
  19. Sofox

    Sofox

    Member
    In terms of pre-alpha, here are my thoughts.

    A character (doesn't need to be animated), in a 3d location (maybe NOT Green Hill? Just suggesting...). You can move the character and jump. If you jump over some ridges you can reach a goal and get a "Act Completed" sign. The program then reformats the users computer

    There, we keep it simple and we focus on the aspect that we're making something for games. Just implement what's needed for the above, and then plan out each new release with a demo that has something new for the engine to support.
     
  20. Rolken

    Rolken

    Tech Member
    There's something to be said for shipping, but it's also true that planning out separation of responsibilities (in code) and architecting things properly from the outset can save you a lot of trouble later. Where to split the difference there largely depends on how much experience and knowledge you have.