[The Taxman]

Gen, on 20 February 2012 - 01:53 AM, said:

Ross-Irving, on 20 February 2012 - 12:33 AM, said:

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

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.

Retro-Engine is already the name of my proprietary tech so no

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.

[Aerosol]

The Taxman, on 20 February 2012 - 04:00 AM, said:

Retro-Engine is already the name of my proprietary tech so no

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.

I love you dude but I just said all that :P

The Taxman, on 20 February 2012 - 04:00 AM, said:

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.

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.

[Gen]

The Taxman, on 20 February 2012 - 04:00 AM, said:

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.

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).

[StreakThunderstorm]

I don't think it should be named retro if its going to incorporate modern sonic gameplay.

[Gen]

StreakThunderstorm, on 20 February 2012 - 11:54 AM, said:

I don't think it should be named retro if its going to incorporate modern sonic gameplay.

Well Mach 5 Engine isn't a bad one, but it'd be nice to see more suggestions.

[Azu]

Is this going be a Sonic engine, or a an actual engine?

[Lambda]

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

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.

[Azu]

The"You've GOT this Sonic" Engine?

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

This post has been edited by Azu: 20 February 2012 - 07:28 PM

[Shade Vortex]

What about the Blast Processing Engine? :V *Shot*

[Morph]

Shade Vortex, on 21 February 2012 - 12:11 AM, said:

Blast Processing Engine?

... 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.

[Candescence]

Morph, on 21 February 2012 - 06:20 AM, said:

Shade Vortex, on 21 February 2012 - 12:11 AM, said:

Blast Processing Engine?

... 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.

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?

[Azu]

Quote

Due to the Genesis' head start, much larger library of games, and lower price point,[54] it was able to secure an estimated 60% of the American 16-bit console market by June 1992.[55] Sega's advertising continued to position the Genesis as the "cooler" console,[54] and at one point in its campaign, it used the term "Blast Processing" (the origin of which is an obscure programming trick on the console's graphics hardware[56]) to suggest that the processing capabilities of the Genesis were far greater than those of the SNES

http://en.wikipedia....ki/Sega_Genesis

4th paragraph under "Console Wars".

[Candescence]

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.

[James K]

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

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!

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

[Gen]

James K, on 21 February 2012 - 08:03 PM, said:

...

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.