Sonic and Sega Retro Message Board: James K - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

Group:
Member: Members
Active Posts:
33 (0.03 per day)
Most Active In:
Fangaming Discussion (18 posts)
Joined:
16-March 11
Profile Views:
342
Last Active:
User is offline Apr 17 2013 03:21 PM
Currently:
Offline

My Information

Age:
Age Unknown
Birthday:
Birthday Unknown
Gender:
Not Telling Not Telling

Contact Information

E-mail:
Private

Previous Fields

National Flag:
br

Latest Visitors

Posts I've Made

  1. In Topic: Roadmap

    03 January 2013 - 04:24 PM

    It makes sense to keep the engine generic and as flexible as possible. I don't mean that all physics or even the default movement system should be hardcoded. I just think that whatever default movement system Mobius does use should be implemented extremely well.

    After all, the intent of Mobius is to facilitate development of high-speed 3D platformers. For a designer, why choose Mobius over already established engines like Unity or UDK unless Mobius had tools that made coding platforming-related gameplay exceptionally easy and straightforward?

    Because in UDK or Unity, it's not easy or straightforward.
    Both engines have adequate low-level mathematics abstracted through a high level scripting system. But the engines still require an in-depth understanding of programming and math "just" to make the character run on walls. Unity and UDK are so generic and abstracted it makes it difficult to code relatively simple things.

    The designer should be able to focus on high level concepts like "target this enemy", "run up this wall", etc. using functions included with Mobius. But the designer should be able to override / extend any part of Mobius's built-in functionality through using low-level code. The designer should not have to write extensive code for common platforming features(wall walk, align to plane, change gravity, 2D camera mode, etc.) like UDK and Unity require the designer to do. The designer should not have to be a programmer with high-level understanding of mathematics to use the engine effectively. The designer should also be able to tweak most of Mobius built-in functionality without requiring extensive knowledge of programming and math.
  2. In Topic: Roadmap

    24 December 2012 - 06:46 PM

    View PostAerosolSP, on 24 December 2012 - 05:30 PM, said:

    View PostJames K, on 24 December 2012 - 05:03 PM, said:

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Character movement around level, including jumping
    - Momentum and character movement physics


    THIS, this is probably the most essential part of putting Sonic gameplay into this engine.

    Since 3D physics are so crucial to a serious 3D sonic engine, maybe someone could make an outline describing how the physics in SonicGDK, BlitzSonic, or Eggengine work.

    The more detailed the better, but at least some kind of overview on how to properly align the player model on a 3D plane, how to adjust the player's velocity to a slope, how to handle the net forces acting on the player, determining the speed a player is able to run on walls, etc.

    Just a 3D sonic physics guide informative enough to get the gist of how 3D sonic physics should be implemented.

    Kind of like Sonic Retro's Sonic Physics guides http://info.sonicret...c_Physics_Guide - but for 3D


    This depends entirely on the game we make. We may not want to try to extrapolate Genesis physics into the 3rd dimension. We may want to eschew Genesis physics entirely. That'd be my preference, but the end decision is Sofox's right now.


    You mean you would prefer to have the Mobius engine(a Sonic engine) with a physics system entirely unlike Genesis physics in 3D and therefore having physics unlike Sonic GDK/EggEngine/etc?

    What is the benefit of that though?
    SonicGDK for example has Genesis-in-3D-like physics that are robust enough to replicate both
    classic Sonic gameplay https://www.youtube...h?v=KH9KSi8bFpo
    and modern Sonic gameplay https://www.youtube....h?v=QAX74ISpd4k

    And even other platform genres, like for example, a Mario-like platformer would be compatible with SonicGDK-like physics, e.g. with Mario Galaxy-like platformers, 360 player orientation support would be quite handy

    Why would it not be preferable to have a robust physics system that can emulate classic and modern Sonic platformers in addition to other platforming genres?
  3. In Topic: Roadmap

    24 December 2012 - 05:03 PM

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    To be completed for demo:
    Programming:
    - COLLADA importing
    - Load character model


    Try ASSIMP: http://assimp.sourceforge.net/ This is the best open source, general purpose 3D model loader I know of.

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Load level


    If you're going for a "Model in external program, import into game engine" then maybe assimp would be sufficient for the geometry, and you could come up with a parseable map text format that stores the positions of objects, the scripting used for that level, definition of special effects used in that level, etc.

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Character movement around level, including jumping
    - Momentum and character movement physics


    THIS, this is probably the most essential part of putting Sonic gameplay into this engine.

    Since 3D physics are so crucial to a serious 3D sonic engine, maybe someone could make an outline describing how the physics in SonicGDK, BlitzSonic, or Eggengine work.

    The more detailed the better, but at least some kind of overview on how to properly align the player model on a 3D plane, how to adjust the player's velocity to a slope, how to handle the net forces acting on the player, determining the speed a player is able to run on walls, etc.

    Just a 3D sonic physics guide informative enough to get the gist of how 3D sonic physics should be implemented.

    Kind of like Sonic Retro's Sonic Physics guides http://info.sonicret...c_Physics_Guide - but for 3D



    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Enemy movement and AI


    You probably want to use a scripting system to make enemy programming flexible

    I would recommend
    Lua
    http://www.lua.org/

    or Squirrel
    http://www.squirrel-lang.org/
    Easy C++ intergration with the squirrel scritpting language: http://scrat.sourceforge.net/


    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Lives, rings, and points managment


    This is simple, no external libraries needed

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Graphical effects including lighting and shaders


    You'll need some essential matrix math if you're going to do any fancy things with shaders

    http://www.lighthous...mple-libs/vsml/


    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    - Cross platform build system


    Or you could just maintain 3 projects Codeblocks(Windows/Linux), VStudio, Xcode(Mac)
    Automated build systems often give bloated projects with a bunch of verbose settings, but if automated build systems are the easiest to manage that's ok too.

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    Art:
    - Level design
    - Badnik design
    - Items design (springs, goal)
    - Level modelling
    - Badnik Modelling
    - Item modelling
    - Sound effects development
    - Music composing


    High quality fan-made Sonic the Hedgehog sound effects and music resources are all over the web, you can probably use some if you ask around.
    For 3D modeling, all I know is that there are a bunch of experienced Maya/Blender users on Sonic Retro

    View PostSofox, on 29 November 2012 - 01:00 PM, said:

    To be completed for final game:

    Programming:
    - Cutscene system.
    - Advanced menus
    - Special stage system (?)


    For the beginning stages, I'd recommend an in-game console over a menu, it's easier to make than a GUI, and would make development and testing easier (e.g. switching maps via in-game console, adding enemies via in-game console, etc.)


    Remember, there's a huge resource of permissively licensed open source software out there, you don't have to write all low level code yourself.
    The links I posted are ZLIB/MIT/CC0 licensed, meaning you can use the code for practically any purpose.
  4. In Topic: Low Level Engine Architecture

    01 April 2012 - 01:24 PM

    Am I the only one thinking setting up an engine is actually pretty simple?


    For the low level libraries, SDL does Input, Timing, and Video; GLM does rendering transformations for shaders and more; OpenAL does sound(or you can use SDL mixer)

    On the next level, you have:
    The shader and rendering system
    A sound system to handle and mix sound effects, music looping, and other audio effects,
    Package management - zip/folder directories/any other combination


    Higher level:
    Level format
    Game Object system
    Menu system


    It seems pretty straight forward, using C++ classes makes it easy to give each subsystem its own needed resources and such. For the most part, all you need is a basic code structure of what the main engine should look like, and people can start implementing different low level features simultaneously, then later on different higher level features.
  5. In Topic: Sonic 2 HD

    31 March 2012 - 06:15 PM

    Hypocrisy aside, why the overprotectiveness?




    At the worst, what could someone even do that would cause enough alarm to want lock down EVERYTHING on a free, hobbyist-driven game?

Friends

James K hasn't added any friends yet.