Still Unnamed 3D Sonic Engine

Hello! Some of you might remember me as one of the creators of the BlitzSonic Engine. (Along with Damizean: He did like, 90% of it after the rewrite, so kudos for him :-) I've been really busy for the last 2 years or so with IRL stuff, mostly college and work, so I almost completely disappeared from the Interwebs. That is, until now.

ALERT: Giant wall of text ahead. If you're not much of a reading person, you can skip directly to the video at the bottom.

Partially motivated by my wish to put in practice what I've learned about linear algebra, computer graphics and game development in college, aswell by the recent Sonic 4 controversy and by a lot of personal reflection about what made the classic Sonic games so good (and why they're so different from what we have today) I decided to get back to fangaming.

What I'm going to show here is what I've been able to put together on my free time during the last 1 month or so. I was planning for a bigger, more 'surprise'-y release on a later date, but I decided that early feedback from the community was necessary to keep the project right on track. Besides that, I suck at keeping secrets :-).

I'm working on a "fully 3D" Sonic engine. That is, it's not an on-rails engine that tries to replicate the classics with 3D graphics, but an engine with completely 3d environments for you to explore and interact.

As I didn't want to stand on completely new grounds when it comes to the controls and physics, I decided to generalize the genesis physics for the 3D case. I've successfully implemented a pretty complete and consistent mathematical generalization of the physics described by Mercury on the physics guide (Thanks, man!). My goal is to have the game to handle exactly like Sonic 3 & Knuckles, considering you only touch the "left", "right", "crouch" and "jump" buttons, yet still allow for full blown 3D controls without switching control modes or whatnot. I'm already quite close to that, save for some minor floating point quirks with the air drag (which I'm not going to fix), and for the fact that collisions are checked using ray-triangle intersections, not height maps. (Also not going to fix.) You would be surprised on how well the physics of the original games stand on the third dimension.

Once the player code is ready, I'm going to release it for peer review, for whoever might be interested. If something's not like the classics (and it's not because of an explicit engineering decision) it's a bug that needs to be fixed.

Besides getting the game to handle properly, I'm using what I've learned from working on BlitzSonic to address the other important/unresolved issues with 3D Sonic games: Camera and Level Design.

For the level design, I'm keeping it faithful to the classics by using tile-based maps. The world is made of 3D, 128x128x128 tiles (each tile is a mesh). All objects are carefully constructed so they're exactly on the same scale as their Mega Drive-era counterparts, and the size of the player model in relation to the view size is also calibrated by adjusting the camera's field of view, to give the exact same feeling of speed as the Mega Drive games.

It might seem strange to use tiles for a 3D game, but they allow for great flexibility and consistency, and they're are going to make the creation of a level editor much easier.

For the camera, I'm addressing the problem by not addressing it at all: If you think about the cameras on the 3D Sonic games, you'll realize they were usually bad because they had to keep constantly changing their direction and position relative to the player. This is Ok on a slow-paced game, but not so Ok on a game like Sonic. The reason they had to do that, however, is because full blown 3D scenery usually occludes the player eventually (where 2D scenery usually doesn't.) If you address the occlusion problem, you don't need to address the camera problem anymore, and a static camera with some manual controls does the job quite well. This is what I'm doing; It is a similar approach to the one Team Ninja has taken on Metroid: Other-M, Thought their camera is certainly much more complex than that. (I haven't played it yet.)

Anyway, back to the engine, unlike most other 3D fan game projects, which are using either Blitz3D, Unity, Unreal or Build as a starting point, I'm working on a 100% custom 3D engine. I might get criticized for that, since it's an awful lot of work (it really is!) and software development these days is all about code reuse, but I decided to take the hard route for a variety of reasons:

1. I'm doing it for fun and learning, and I wanted to learn more about all the math and infrastuctural code that goes behind a full-fledged, modern 3D engine.

2. I did not want it to be based on proprietary technology, and I didn't quite like any of the free/open-source game engines out there. When you rely on proprietary technology, you're bound to be caught on technological roadblocks. Take Blitz3D, for example. The guys from BlitzResearch pretty much abandoned it. The result is that what once was a state-of-the-art 3d engine is now a piece of legacy code forever tied to DirectX 7.0 (which was released on 1999 and has no shader support) That means all the power of current GPUs can't be tapped, and that all the fancy effects can't be achieved (at least not easily/efficiently). All of the engine is based on open industry standards, which won't go away on a near future.

3. A Sonic the Hedgehog game is much more complicated than say, a first person shooter, (at least a simple one) and requires a lot of very specific architectural decisions. (take the collisions, for example) A pre-built solution wouldn't be able to provide that, or would require workarounds. "Generic"/All Purpose 3D engines usually try to be jack-of-all-trades, but end up being aces of none.

4. I'm a Mac user, and I am usually saddened by the lack of Mac support when it comes to (fan) games and game engines. I think the Linux folks should also agree with me. With a completely custom engine, I can address this, by making it cross platform.

5. With a custom 3D engine, I am only limited by what I can code on my free time. I don't have to pay for some extra component or wait until something is implemented for me. I can go and implement it myself, as I need it.

6. There's also another reason for me to code it from the ground up, which I'm going to reveal later. (It's worth the wait.)

Here's the engine's current feature set:

- Cross-platform, OpenGL based. Runs on Mac OS X, Linux and Windows out-of-the-box. Getting it to run on something else shouldn't be hard, provided the right libraries are available. A Direct3D backend for the ~60% or so of Windows users who don't have OpenGL drivers isn't entirely unlikely in the near future;
- Fully programmable, hardware accelerated scene rendering: Uses the full potential of GLSL Vertex and Fragment Shaders; (The FFP is bypassed entirely)
- Tile-Based 3D Environments;
- Objects;
- Spatial indexing using a dynamic, sparse grid structure implemented through hash tables (which have O(1) == constant access time) for super fast scene rendering and animation. Preeliminary tests have been done with 100,000+ objects randomly distributed along the scene space, without any performance hit;
- Asynchronous resource loading;
- Super fast ray-triangle intersections for collisions;
- Multiple render targets;
- Per-pixel (phong) lighting;
- Static (whole stage) and dynamic (local) shadow mapping;
- Automatic generation of static shadow maps during scene load; (Fast!)
- Post processing (glow effect, not enabled on the video)
- Adaptative framerate with support for "non-rendered substeps"; (To ensure playability even on computers with slow/low-end GPUs)
- 3D Sonic physics generalized from the Sega Genesis;
- "Ghost Mapping" to solve the occlusion problem;
- Ringloss;
- A 100% custom Sonic Model, made by taking the original game sprites as reference. Same proportions, same animations; (Not quite an engine feature)
- Blast Processing;
- Zero `Constant Execrations from Gimmicks like Booster`.

Besides that, the engine's code has been carefully profiled and optimized. All care has been taken to ensure great performance. (e.g. the engine tries to keep the same textures on the same GPU texture units whenever possible, to reduce the number of unnecessary flushes on the rendering pipeline).

Sorry for not providing anything playable at this time, but I only want to have public or even private beta tests for the engine when it's more complete. (And when some technical problems are solved)

The video below has a choppy framerate because my MacBook's low-end Intel GMA is struggling to deal with the game and the video capture program at the same time. Sorry about that too. Performance should be much better on good graphics hardware.

Enjoy!



@the admins: Thanks for such a speedy validation.

 

Hey guys! Thanks for all the feedback on this! =)

Hmm. Right now, everything is hard-coded into it, but adding some form of scripting support is not entirely impossible.

Yeah, that's true. I haven't implemented that yet because I wanted first to have as many animations working as possible, so the game felt more "real". (Sonic was a blue placeholder ball mesh before that.) I'm going to figure out the tweening, but it shouldn't be that hard. Just linearly interpolating the positions and normals.

Right now, I'm only supporting 8-directional controls. The camera angle actually snaps to increments of 45º, so getting Sonic to walk straight along a wall is easy. Adding analog controls might break that, so I'm kinda concerned, but if a lot of people request them, I might try to figure out how to mix them with the classic physics.

That's a good question. I'm not quite sure on how I'm dealing with this issue. The same problem arises with the end-level signs. Maybe we can work out something on this. I'm open for suggestions.

You mean, the level or some other aspect?

I'll say that, yes, the white outline is a little hard to get used, but once you get used to it you won't mind it that much. At least, that was what happened with me. I wanted to get a more subtle effect going, but I didn't want to step on hard-to-fix alpha-sorting issues.

Taxman pointed out the same thing. I'm going to add tweening so the animations are smoother.

Oh. They're the Hidden Palace tiles, redrawn in high-res. :-)

 

You mean, something like the Sonic Heroes checkpoint, but bigger, with a starpost on top?

 

Yeah, I think I'm going to release the source eventually. If I decide to make a full fledged game out of it, I'll release the source after the game is released. If it ends up being only an engine, or the game gets canned, I'll release the source for the Engine so people can use it. Regardless of that, I'm going to release the Player source code once it's complete (or at least partially complete) for a physics audit of sorts, if someone is interested in that.

 

Oh, no offense taken. :-) The level is completely busy right now, because whenever I needed to test how the engine responded to something (the stairs, for example) I added a new tile and instantiated it somewhere. It's pretty much a sandbox right now. Also, since I don't have a level editor yet, I made the level by changing numbers on a text file, hence, it looks like crap.

I might add a shadow like the one from Super Mario Galaxy, if the "ghost maps" on the walls really end up being disorienting on an actual level. I'm not completely sure on how to do it, though. Maybe I can get something working using the stencil buffer and depth testing. You think enemies, rings and other objects should also have "shadows" through the walls?

About the editor, yeah, I'm planning on adding one. About not requiring tiles? I suppose you could make the entire level out of solid/platform objects (these are not implemented yet, though) but performance might suffer for a lot of objects (since the 3D tile grid makes it faster to rule out which meshes need to be tested for collisions.)

 

Hmm.. I might eventually add some sort of automatic adjustment of the camera's Y angle around the player, but I do not want to move the camera to different views as much as the 3D games usually do. IMO, it's kind of disorienting, and breaks your ability to control the player. To fix that, they had to make it that, for instance, during a loop, or during the whale sequence on Sonic Adventure, whatever direction you hold the analog stick makes you go on the correct direction. I don't like that, and I think you should be on full control of the player all the time.