[Codr]

History of the Project:
Hey guys, this is my latest project, I haven't named it yet but I've been working on this engine for the past year on and off. The engine runs on Unreal Engine 4 and uses only blueprints, I have not written any C++ code. It all started when I downloaded Unreal Engine 4 and saw the potential the engine had. I started researching on how to implement 360 degree movement using blueprints, however everywhere I looked everyone said that such a mode of movement would be impossible to implement with blueprints only. Long story short I needed to know C++ to make a Sonic Engine in UE4. I chose to peruse this topic further and built a prototype that featured no 360 degree movement (so loops couldn't be used) but had gimmicks such as springs, dash panels, and boosting. Eventually I hit a dead end with the blueprint scripting and decided to scrap the engine around 2 months in due to complications with the movement.

Around September, I decided to revisit this idea, now having much more knowledge on how to use Unreal Engine 4, here is how the engine looks now.

Engine Features

• Boost Gameplay Style
• 360 Degree Movement
• Common Sonic Game Gimmicks (Springs, Dash Panels, Dash Rings, etc.)
• 2.5D and 3D Gameplay

Confirmed Levels

• Green Hill Zone Act 1 & 2 (Generations)
• Windmill Isle Act 1 (Unleashed)
• Hydrocity Zone (Remake)
• Terminal Altitude (Original Level)
• Rooftop Run (Undecided)

*(Original Level) - This tag means that the level will not be ported from any other Sonic game and will be an original level.
*(Remake) - This tag means that the level will include remastered elements (like higher poly models or even a complete level remake from 2D to 3D).

Major Things Left To Do

• Fix control rotation so it works like in Unleashed
• Add QTE
• Implement grinding (Code is there just needs to be implemented)
• Better 2D path following
• Animations
• Smooth rotation when in air

The engine is still in a very early stage so I won't be releasing any game play builds in the meantime (maybe in the summer). However I look forward in hearing your thoughts and opinions about the engine //forums.sonicretro.org/public/style_emoticons/default/smile.png/>/>/>/> . Any recommendations? Clearly there are things I don't know how to do however I am trying my best to learn.

[Engine updates are uploaded more on my Youtube channel.]

Features:

• Smooth Air Rotation
• Fixed Boost
• Homing Attack
• Animations :D
• Bug Fixes
• Grinding

Version 0.15:
https://www.youtube....h?v=6Xm4m28RN0k
https://www.youtube....h?v=q9OSydRlMUA

Old Versions:

Version 0.1:
https://youtu.be/3Wc8Mt9Jwls

Version 0.04:
https://www.youtube....h?v=brQY79IJrxk

All feedback is greatly appreciated! //forums.sonicretro.org/public/style_emoticons/default/smile.png/>/>/>/>

This post has been edited by Codr: 17 February 2017 - 11:54 AM

[Codr]

Quick Update: I have decided to migrate the project to CryEngine V, this is due to the fact that it has Global Illumination, this will make the project look way better. Also if that fails and it proves too hard then I guess I will be continuing the Unreal Engine 4 version. CryEngine 5.4 release date will be the time I begin development.

[Andrew75]

How far did you get in Unreal 4 ?

Edit:
Unreal 4 has an alternative like LPV but its got some issues, This thread goes into comparing the Voxel and LPV lightly.

https://forums.unrea...ll=1#post508682

This post has been edited by Andrew75: 16 July 2017 - 08:10 AM

[Amnimator]

UE4 has GI, granted it's prebaked. There is a method to do it real time but I hear it's not optimal, ^

Unity has prebaked global illumination, but it also has a prebaked - realtime hybrid kind of thing. Might want to look into that. If you want people to make content for it, know CryEngine is the least popular of the big 3 (Unity, UE, CE), you'll have an even harder time than UE in terms of user generated content.
I'd recommend either sticking with UE4 or maybe going with Unity. UE also has native modding support, which is a huge plus for what you're trying to do. As opposed to Unity where you have to do a build of a game for every modification unless you want to implement modding support yourself (which with Unity gets hairy quick). With CryEngine; I doubt implementing mod support is as problematic as Unity, but I also doubt it's as clean and simple for the developers as well as the players. I mean, this is a bit of a tangent, but that's a big deal if you're focusing on letting players distribute their content in an efficient way. See Blitz Sonic vs Sonic GDK in terms of how easy it is to share content you made.

This post has been edited by Amnimator: 18 July 2017 - 04:41 PM

[winterhell]

If it was me I'd focus on the gameplay first. You can make hyper realistic graphics on both UE4 and CryEngine

[Amnimator]

^ Yeah, you can do hyper realistic graphics on pretty much any modern engine available. Heck, you could achieve some really good looking graphics in UDK if you really wanted to. I'm guessing he wants a bit more incentive to do a rewrite and at the same time learn something new. I argue the relevancy of CryEngine, but he's free to do as he pleases. But it's not like CryEngine will suddenly make the game look better, or UE is inhibiting him any. I assume he just wants realtime GI, for the sake of rapid prototyping and making things easier on the content creators.

This post has been edited by Amnimator: 20 July 2017 - 04:49 AM

[Codr]

Hey guys! There are plenty of reasons I chose to switch over to CryEngine, first and most major is that with the use of blueprints in Unreal Engine 4, the blueprint for Sonic has gotten so huge and inter dependent on itself that it was difficult maintaining it while adding features (when BPs get big they are a pain to work on), adding one thing could easily break the other. At the state the project is in currently converting it to a modular design would be a complete remake of the whole project. You could say it's my fault for not making the project modular and it is. So I decided to modularize the project, since if it was modular I could activate and deactivate aspects of the player's behavior accordingly, so I began, but gave up midway through because I thought that starting the project from scratch with my previously gained experience would be faster, better, and cleaner. So then I was faced with another dilemma: Go with blueprints again and suffer when they get huge and complex, or use a programming language. The only programming language I know well enough is C#, so I looked for good C# plugins for UE4 and the ones I found weren't that good and seemed like support for them could be dropped any second.


So I decided to look for other engines that have C# support: Unity and CryEngine. So I have decided to try my hands on CryEngine 5. Please note that CryEngine 5 is completely different from 3, they have a new editor, C# support and an Entity-Component system like UE4 and Unity. Also I always wanted to see how coding a Sonic Game in C# goes so here is my chance. Also note that if I have any difficulties that cannot be surpassed, or if the engine is too difficult after all the updates and simplifications, then I can just continue the UE4 version... I'm not deleting it //forums.sonicretro.org/public/style_emoticons/default/smile.png.

Anyway here is how some assets I imported into the engine look (the fan, rings and 1-up are C# entities):

http://imgur.com/rKUQ8Zb

So 4 more days since CryEngine goes full Unity with it's Entity-Component system (joking), pretty excited to see how this goes.

I'll start posting updates on Twitter, and also start uploading updates onto Youtube again so everyone can see how it goes.

[Lobotomy]

Wait, are you saying that you got loop handling to sort of work in UE4 blueprints without succumbing to gimbal lock?


Fucking how??

[Codr]

Lobotomy, on 21 July 2017 - 04:32 AM, said:

Wait, are you saying that you got loop handling to sort of work in UE4 blueprints without succumbing to gimbal lock?


Fucking how??

Yes I did, the loops fully worked, the reason that they appeared buggy was because I changed some code in the way Sonic handles slopes (in order to be like the genesis games where he would accelerate down a hill alone and stuff), I think by the method I used to handle 360 movement. It's been a while since I looked at that part of the blueprint so I may not be correct (don't have access to my computer right now to check, sorry) but I think that I recalculate the rotation each frame instead of using the previous rotational values, I think this is what allows the gimbal lock to be surpassed, as using previous rotational values would mean that at some point, the gimbal lock would occur.

I plan on using quaternions for the CryEngine version as the 360 movement issue is very simple with those.

This post has been edited by Codr: 21 July 2017 - 05:13 AM

[Amnimator]

Typically, you'd stop gimbal lock by going with Quaternions. Gimbal lock is an inherent part of how Euler angles work. I mean, as long as it works, it works; but I wouldn't stick with Euler angles at all for this kind of slope detection. Rotate in more than 1 axis, and gimbal lock is almost ensured. Kind of weird how UE4 requires you to use Quaternions in C++ only, but they have their reasons. I can see why you'd want to use Cry Engine or Unity if you want to work with C#.
Anyway, wish you luck on the project.

This post has been edited by Amnimator: 21 July 2017 - 05:26 AM

[GalaxySoftware]

Hi !

I think it's a good idea to port it to CryEngine 5 for some reason
And this will be the first sonic fangame powered by cryengine
And if you want too you can check the hedgephysics engine who is coded in C# to help you to recode the sonic physics etc..

I wish you the best for this project and I hope we will be able to see your new content on your new channel

Good Luck

[Codr]

Amnimator, on 21 July 2017 - 05:16 AM, said:

Typically, you'd stop gimbal lock by going with Quaternions. Gimbal lock is an inherent part of how Euler angles work. I mean, as long as it works, it works; but I wouldn't stick with Euler angles at all for this kind of slope detection. Rotate in more than 1 axis, and gimbal lock is almost ensured. Kind of weird how UE4 requires you to use Quaternions in C++ only, but they have their reasons. I can see why you'd want to use Cry Engine or Unity if you want to work with C#.
Anyway, wish you luck on the project.

Thanks everyone!

Just found out that UE4's BP system only uses euler angles when the user directly edits them, when performing certain operations, such as 'combine rotator', the engine automatically converts the euler angle over to a quaternion, behind the scenes, performs the operation and then converts it back to euler angles. Still not as good as allowing direct access to quaternions but still something to take note of.

//forums.sonicretro.org/public/style_emoticons/default/smile.png

Also gimbal lock also occurs only when you increment the rotation, in my project, I never used incremental rotation for slopes, I always recalculated the rotation so this avoided the gimbal lock problem.

Andrew75, on 16 July 2017 - 07:34 AM, said:

How far did you get in Unreal 4 ?

Edit:
Unreal 4 has an alternative like LPV but its got some issues, This thread goes into comparing the Voxel and LPV lightly.

https://forums.unrea...ll=1#post508682

I got pretty far. Also UE4's GI is nothing compared to CryEngine's. Somehow Crytek managed to make the GI in their engine real time, no baking, which amazes me because most if not all engines use pre baked.

This post has been edited by Codr: 21 July 2017 - 08:24 AM

[Amnimator]

^Ah, I see. I'm still apprehensive about using Euler angles for this kind of thing, but that's actually a clever workaround. As you said, not quite as good as using Quaternion functions, but functional. I can see there being issues if you start to add more rotations to the player under different scenarios.
Also, tip: Unless you want a really bad headache, Quaternions should very rarely be manipulated directly. Instead you should use Quaternion functions like FromTo, or something of the like. Almost certainly UE4 and CryEngine has an equivalent.