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

Member: Members
Active Posts:
37 (0.02 per day)
Most Active In:
Fangaming Discussion (19 posts)
16-March 11
Profile Views:
Last Active:
User is offline May 27 2017 07:16 PM

My Information

Age Unknown
Birthday Unknown
Not Telling Not Telling

Contact Information


Previous Fields

National Flag:

Latest Visitors

Posts I've Made

  1. In Topic: Question: Best way to open-source an engine to the community

    26 May 2017 - 09:11 PM

    View Postcmakeshift, on 23 May 2017 - 08:00 PM, said:

    My problem is, while I'd love to develop this as much as possible before release, I simply do not have the time.
    I thought it would be a nice thing to do to just give it to the community right now, and see what can be done with it. Maybe bring on more people and then work on a fangame? Who knows.

    Is anyone really, truly interested in this? Would it be a problem to just put this up on GitHub, with the Sonic assets and all? Opinions, ideas, and angry mobs are all welcome.

    Please reconsider using MIT, BSD, or Apache 2.0;

    GPL will discourage people from using your code with existing MIT/BSD/Apache code.


    cmakeshift said:

    Thanks guys, I have settled on GPL v2.

    Please reconsider not using GPL.

    GPL will add extra restrictions that will limit the amount of people that can use your code.

    GPL is a viral license
    This means, anything you combine with GPL, must also be under GPL.
    This is bad, because relicensing existing work to GPL is not always practical.

    First of all, most new open source software is MIT licensed(at least on Github's ten million+ repositories
    Posted Image

    GPL is incompatible with MIT, BSD, Apache, and most other licenses
    This is bad because it means people can't easily use their own MIT code with your engine to add new features.

    What if someone has made a good graphics engine in MIT license,
    and then they want to combine MIT code with your GPL code for the 2D physics so they can make this?:

    If you use GPL, they can't do that, they have to relicense all of their code just to use a part of your engine,
    and most people won't relicense, they just wouldn't bother because your GPL code is incompatible with their license.

    If you use MIT, BSD, or Apache 2.0; your code can be used in many more projects; and more people can build on top of your code.

    More and projects have switched from GPL to MIT/BSD/Apache recently; because MIT/BSD/Apache is compatible with more existing code bases, AND you still receive credit and the possibility of others contributing back code. And for many many MIT licensed projects, people DO contribute back code and have dozens of contributors.

    People won't be contributing back any code at all if your GPL license means they can't use your code in the first place
  2. In Topic: Sonic Social Media Shenanigans (This totally just happened...)

    20 April 2017 - 11:37 AM

    View PostBlivsey, on 19 April 2017 - 12:07 PM, said:

    The Japanese text under nearly all the buttons is nonsensical, but the Japanese part under "Action" says:

    Which means, "More clues/secrets"

  3. In Topic: Sonic Mania (Switch, PS4, Xbox One, PC)

    19 April 2017 - 12:35 AM

    View PostOcelotBot, on 14 April 2017 - 03:57 AM, said:

    Mania's Jp site has been updated.

    *translates Mania Jp site*

    "Mirage Saloon

    This is the first stage appearing in this work.

    View PostApocalypticSalad, on 14 April 2017 - 10:05 AM, said:

    It doesn't make sense that Mirage Saloon is the first zone of the game, it has to be some kind of mistranslation or misunderstanding.

    To clear up confusion, Japanese <-> English machine translations are often very wrong even for simple cases.

    The website doesn't say what order Mirage Saloon appears in Sonic Mania; It actually just says that in Sonic Mania, Mirage Saloon makes its debut(first appearance).

    The original Japanese text:



    Grammar is the hardest to explain(Japanese grammar is nearly reverse compared to English), but from word choice alone it's still clear that the website just means 'this is a new stage appearing for the first time'
    本作 で In this work,
    初 登場 の first appearance of
    新規 (the) new
    ステージ stage

    So the website says: In this title (Sonic Mania), the new stage(Mirage Saloon) makes its first appearance.

    (We could really use some more bilingual Japanese + English speakers on these forums to help out with translations like this :P )
  4. 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.
  5. 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
    and modern Sonic gameplay

    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?


James K hasn't added any friends yet.