[Azu]

I'm assuming you're making your own assets? Also, I think that you should have configurable values, with a genesis and modern default presets

This post has been edited by Azu: 24 December 2012 - 10:00 PM

[Aerosol]

James K, on 24 December 2012 - 06:46 PM, said:

AerosolSP, on 24 December 2012 - 05:30 PM, said:

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

Sofox, 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?

What I would like is have low-level mathematics like angle finding and such abstracted through a high level scripting system. If somebody wants to use Mobius later on as yet another Genesis-physics-in-3D engine, then so be it. I don't have a massive erection for Genesis-physics-in-3D, so hardcoding that into Mobius would be very disappointing to me. All I want Mobius to handle is everything required to let the designer know everything about what kind of surface the Actor is on. Let them decide how the Actor should respond to it.

This post has been edited by AerosolSP: 25 December 2012 - 04:21 AM

[James K]

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.

[Relick]

James K, on 03 January 2013 - 04:24 PM, said:

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.

The problem is, programming games does require a decent level understanding of mathematics and programming - unless you want it to be very basic and limited. I don't know if anyone here had heard of it before it went down, but there was a website called PlayCrafter which let anyone build any game they liked with a bunch of preset pieces, with the ability to change how these pieces worked if extra functionality was needed. The only problem was that even though it was really easy to use, a lot of things couldn't be done and doing simple stuff like walking on walls was impossible, unlike in Unity or UDK where it is only frustrating (but possible).

Mostly, 3D game programming comes down to understanding rigid body physics, and vectors (and rotational stuff but whether it is euler, quaternions or axis depends on the engine) - and that's about it. I made it sound like a lot but its only one step above standard level maths. While I haven't used UDK, I know that if you know how to use vectors and rigid bodies then wall walking in Unity is a piece of cake - and if you struggle with it then you need to take a step back, look at what you know, what you don't know and fill in the gaps before trying again or deciding that Unity is too hard.

None of that was directed at you specifically James, I was just explaining why Unity and UDK have done what they did.