don't click here

Mobius Engine Project General Discussion

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

  1. Azu

    Azu

    I must be stupid. Member
    UDK takes time to get use to, but it's much easier to import your assets. Although, I've never used anything else besides CryEngine3 SDK. I could figure out heads or tails on how to import things in there.
     
  2. Shade Vortex

    Shade Vortex

    The Black Vortex Member
    567
    40
    28
    USA, WA.
    Twitch Streams
    All I can do is offer my support to this project. I personally think it's a great idea, but I can definitely see this project being a big hurdle that will take lots of time, maybe lots of people, and a bunch of other complications within its existence. Since fangames barely get finished, making an entire game engine from scratch may be even more of a problem.

    Thing is, not only do you need a team of hard-working people who know what they're doing and can get the job well in a reasonable amount of time, they need to be dedicated and have free time to spend on the project, and it must be understood that this work would be done for free, as a hobby, with almost no gain aside something else to put on a resume and helping out fans to make their own fangames with better/more convenient tools. And for those who already have jobs in the fields they specialize in, they won't have time, nor probably interest to join into the project.

    To sum my thoughts up, I hope this project succeeds if it does start, and hopefully it won't take 5-10 years to complete. It's a lot of work, that's for sure!
     
  3. Ross-Irving

    Ross-Irving

    Member
    1,087
    0
    0
    Gen, it's been a while. I read most of what's been said, save for the talk of libraries and what not as that's not my forte, but I've gotten the gravity of the proposal. I know that nothing is set in stone yet, and I certainly don't want to start pushing anything on anyone, but I'm curious about the possibility of 2.5D. Sort of like what the hedgehog engine does with those transitions. You said that it was an extension of a 3D engine, so I'm assuming that would mean a lot of work in coding the camera to work correctly. Good luck, man, if saying that means anything.

    Oh, one more thing. Since the engine has a focus on Sonic games, and the fact that you're trying to be economic in the features implemented and in the coding, I have a possible name for the engine. Mach 5
     
  4. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    Not unless someone can come up with a good idea for a streamlined editing environment to handle different camera transitions, the best I can think of is a decent camera scripting API with a few included script examples to get people started with their own camera control systems.

    Granted, doing a system that can account for both 3D and 2.5D areas at the same time may be doable from a technical perspective, but we'd still need a way to setup cameras that isn't a massive pain in the ass in-editor.

    I suppose it would be a good time to start tossing ideas out there for a name. Though it may not be retro necessarily, given that the discussion and probably the development of the project is on Sonic Retro, maybe call it the Retro Engine? I'll add an additional poll for the projects name after there's some more name ideas out there.
     
  5. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    That's what Taxman's engine was called. Retro3D, RetroSpace, or something else involving the word "retro" would be better, so as to distinguish it. I really don't think names should be tossed out at all until the project is actually started. Right now we're just talking about it...it doesn't really need a name yet. It's not even a thing yet, after all.

    Now, when it comes to 2.5d, there's really only two things to consider, as far as I can tell. The first is obvious. Hint: it has something to do with camera scripting! The other involves trying to figure out how to handle movement when it starts going on the Z axis, as opposed to just the y and x axis. I'm talking about things like loops, corkscrews, jump-under platforms; basically anything that would be solved in a purely 2D engine with layer switching. I know there's two or three people around here that have their own solutions to that problem, and it's something that we'd have to discuss at length before we settled on one way to do it. There's no point in having two or three ways of doing something.
     
  6. The Taxman

    The Taxman

    Tech Member
    673
    7
    0
    Retro Engine & Related Projects
    Retro-Engine is already the name of my proprietary tech so no :ssh:

    Regarding a basic 3D/2.5D camera, the extra work isn't really with the camera but the player itself. 2.5D imposes restrictions on the player's path of movement (e.g. using collision 'rails' or spline curves) and the camera still follows relative to the player.

    The key to having a flexible camera system is a camera object that can have itself (or the target it's pointing at) bound to other objects or systems. For example, for general gameplay the camera's target would be bound to the player and the camera itself would be bound to some other object/script that controls the camera's orbit. For cutscenes, it would be a matter of binding it to some sort of animation setup (think key-frames) so the camera's parameters can be controlled in the same way as one would animate in something like 3DSMax or Maya.
     
  7. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    I love you dude but I just said all that :P

    But this has definitely given me something to think about. I'm gonna agree with this until I can think of a reason not to. Unlikely, though.
     
  8. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    You'll still need to lock the camera's rotation on an axis however, and in the event of rotating the camera such as in Generations version of Sky Santuary, know when to rotate it around a point. Another problem with 3D space in the context of 2.5D gameplay, is what happens when the player moves across the camera's local z axis. The best way to handle it is to simply restrict movement to the camera's local x and y axis, and ignore the players z movement (local to the camera of course). Tick boxes can be provided to define how the camera moves with respect to the player's movement, and some sort of event system could be devised to control camera properties, such as how the camera should rotate when the player runs up a cylindrical structure. Could maybe do it by detecting when the camera moves into a special volume placed within the editor, and applying attributes accordingly.

    I suppose a system like that would have plenty of general applications as well outside of 2.5D gameplay. Worst part about putting it together will be making it easy to use in the editor.

    Cutscenes I'm partially of the opinion should be handled externally in a program like 3ds or Maya. The reason being is to reduce editor complexity. But maybe someone can think of an easy method to facilitate cutscene creation in the editor without any external tools later on (if cutscene support is even in the cards at that point).
     
  9. StreakThunderstorm

    StreakThunderstorm

    Member
    216
    0
    0
    Mecha Madness
    I don't think it should be named retro if its going to incorporate modern sonic gameplay.
     
  10. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    Well Mach 5 Engine isn't a bad one, but it'd be nice to see more suggestions.
     
  11. Azu

    Azu

    I must be stupid. Member
    Is this going be a Sonic engine, or a an actual engine?
     
  12. Lambda

    Lambda

    Member
    Sonic NEXUS, because it's a connection between Sonic fans! :v:

    Now, for real. I like the sound of "Mach 5", it sounds kinda like the name of a secret prototype or something. Though, you could just take the simple route, and call it "The Sonic Engine"...

    Or, if we wanted to do something more creative, we could name it the word for "Engine" in some other language where it sounds cool. :)
     
  13. Azu

    Azu

    I must be stupid. Member
    The"You've GOT this Sonic" Engine? :v:

    Seriously, I like the Mach 5, or simply the Mach Engine. Or maybe the Mobius Engine
     
  14. Shade Vortex

    Shade Vortex

    The Black Vortex Member
    567
    40
    28
    USA, WA.
    Twitch Streams
    What about the Blast Processing Engine? :V *Shot*
     
  15. SF94

    SF94

    Tech Member
    ... To be honest, I kinda like the sound of that. Doesn't roll off the tongue very well, but I imagine that could be fixed. :eng101:
     
  16. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
    Well, changing it to "Blast Pro Engine" certainly makes it roll off the tongue better, and is actually a neat name by itself.

    Speaking of which, was Blast Processing ever an actual feature, or was it just a marketing buzzword?
     
  17. Azu

    Azu

    I must be stupid. Member
    http://en.wikipedia.org/wiki/Sega_Genesis

    4th paragraph under "Console Wars".
     
  18. Candescence

    Candescence

    Member
    2,023
    21
    18
    Sydney, Australia
    3D Indie Stuff
    Huh, so it WAS a real thing, but at the same time, it wasn't nearly as interesting as marketing made it out to be. Well, that answers that.
     
  19. James K

    James K

    Member
    39
    0
    0
    I'm not a formally trained expert in game engine design, I'm just a hobbyist for now, but I sure as anything have more than just a little experience with source code, compilers, libraries, and graphics, and programming C++.

    I can help with the planning.

    Level Geometry
    To me, the most complicated thing, yet also the most important thing to take on is the geometry, collision, and basic rendering first.
    By basic rendering I mean being able to render polygons with correct normals, and being able to render UV mapped stuff, the 3D format could be anything I guess, .dae, .3ds, .obj :v:

    And then collision, to the point where the player can at least walk across any polygon surface normal in any orientation, then the real Sonic momentum physics can come! And I'd say the 3D Sonic physics is the absolute most critical thing about making a 3D Sonic engine; I really want to see a fully working Sonic physics system with rolling and running on walls and everything implemented in C++.

    Basically, once we take care of that, we've gotten the majority of the complex math out of the way and it's easy Object Orient programming to add in the actual game elements, no?

    -------

    Editor Integration

    I assume the engine does not intend to be a complete content creation solution and level geometry and characters are handled with external editors.

    Personally, I always thought a fully built-in editor for things like the actual level would be the easiest thing for the level designer(but the most involved thing for the coder).

    Hear me out, if we use our own custom map format, then things like the camera, cutscene scripting, water, object placement and other things that are naturally in a level don't have to be disruptively separate from the main editor. Streamlining this stuff would ease the workflow for the level designer(s). Organizing file directories for a level would be almost completely handled for you and possibly packed in a neat little zip file.

    Why such integration would be useful is because: say you could just draw a 3D area right in the editor, and in that drawn area whenever the player touches it, it executes a script. And that script could be edited right there in the built in menu and saved with the level itself. And then you can instantly test your level without having to wait or rebuild or anything.

    Imagine that you can play a cutscene you made in game, and you see that one of the camera angles is a little bit off, you press the edit button in the engine, tweak that camera right there, switch back to game mode, then be right on your merry way without having to go re-edit some script in another editor and relaunch the game.


    Content Organization
    The actual level format could be as simple as a zip file with sub folders for the geometry format(.obj? .3ds? .dae?), the textures for the level(and/or references to a main set of textures that comes on a default install), the script files including things like the level title, map author, camera sequences etc. and the extra volumes data such as water, bottomless pit areas, etc. stored in .txt or in binary format.

    Have the engine automatically arrange these things for you when you save a level.

    Some people may prefer editing and handling every script file and .objectposition.txt file themselves, but doing this seems rather fragmented and not as efficient, but that's just my opinion. Still, using a zip based format would let people who DO like to edit everything themselves have that kind of workflow, and for faster dev times, make the engine also support loading content directly from uncompressed folders too! :specialed:

    This opinion comes from the way I see people have been editing with UDK(SonicGDK), or even while hacking Sonic Generations, I know working with Sonic Generations is far more difficult than having an actual IDE, but than again, it's not THAT different from the way modern game engine development works. So many different editors and systems and scripts, with both UDK and Sonic Generations you have to work separately on the actual level geometry file and the collision file for the level!


    I'm not saying make a completely do-everything editor, but I mean at-least make the collision data and geometry somewhat unified if possible! (Automatically generated collision organized into Octrees? And then that collision data can be saved into the neat .zip file for the level?)


    But the packaging is really step 3.

    Step 1. Is to be able to load and render some kind of standard, flexible geometry format (pretty simple, no?)
    Step 2. Be able to get good 3D SONIC PHYSICS with it (Using original math definitions for vector/matrix math, let's not use boost or Bullet or something for the core vector physics/math please!!! No engine bloat!)
    3D Sonic physics in plain C/C++, that's one thing I've ALWAYS DREAMED OF, someone make it happen, I shall try to make it happen but my math skills are no where near as good as many of the members here! Once Sonic physics has any form of decent start to it (I.e. walk along any normal with any orientation, some basic gravity), then the rest is of creating the engine should be rather easy in comparison.

    Step 3. Decide on a good packaging system for content.
    Step 4. Graphics: Gen, I really like graphics, the technical side too, exactly how much GLSL goodness could you deliver? Deferred rendering? Realtime Shadows? Depth of Field? Global Illumination?!*dreams*
    Step 5. Add the Sonic stuff like rings title cards, level transitions, the easy stuff
     
  20. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    Interesting ideas.

    I'm thinking of having an internal binary model format, to decrease the runtime cost of loading up text based formats (whether it be obj or an XML format like COLLADA). COLLADA and similar would be more of an intermediary format for import purposes.

    Regarding rendering. Deferred and real time shadows are within the realm of trivial now days. Handling transparency effects and so on would be a bit tricky in that pipeline however. Real time gloal illumination is one of those ideas where if there was a truly practical, general purpose, and most importantly, high performance solution, we would have seen it by now. That is, don't hold your breath having real time GI implemented. :p

    I can guarantee that the hardest part will be creating fallbacks for older hardware, as the pipeline evolves.