[nchavez]

Alright guys, I've been scouring the internet for this information, and I have had no luck finding it -- (I even tried using Bing and Yahoo..) so I decided I would come to the source:

Does anyone know the general, and I'm talking about the high-level mathematical and algorithmal design, construction of a classic 2D Sonic Engine? I've scoured the forums, and I've peeked at some engines (E02's looks great) but I don't want to read anyone's source code because I'm not extending something. I just want solid general advice on how to implement levels (like tiles/collisions/slopes) and loops and other dynamic objects like floating tiles and things like that. I'm very good with Java, C and C# so don't hold back on the programming angle of this guys. And yes, I've read the Sonic Physics Guide, but it's only on Sonic's motion and not the architectural aspects of how the game is put together.

Specifically, I'm working on an engine and I'm concerned about the maps/tiles. Should each tile have a slope and y-intercept based on a unit square system? Should the game be defined by a connection of linear equations/graphs? Should each tile be off/on or true/false and just have a high resolution of these tiles? I have no idea where to start and these are a couple of ideas I have. I'll be sure to ask more!

Thanks a lot guys!

Also, first post whhhhhhhhhhhheeeeeeeeeeeeeeeee!

[Relick]

Depends whether you want an 'authentic' sonic 1/2/3 experience or you want 360 degree movement.

I had a similar problem before and I now have a good idea of what to do for both but obviously depending on what you want to do.

[nchavez]

I guess Sonic2 is a pretty good standard physics-wise, but I mean would you be using a simple height map (I.e. an array of Booleans in code) and if so how would you determine angle at any given point and how would you handle loops?? Also what about different map "layers"? ASDFGHJKL my brain is exploding....

Also, what do you mean 360 degree movement? Like 3D? I'm thinking 2D here...

This post has been edited by nchavez: 25 November 2012 - 08:14 PM

[Relick]

No, I mean like you know how in sonic 1, 2 and 3 when you go round a loop sonic just jumps to the next rotation rather than rotating smoothly? Well it is very similar to that (however that was just sprite limitations, not physics). Now if it DID rotate smoothly round that loop then that is an example of 360 degree movement.

The first uses collision masks in specified tiles - you get the position of sonic's feet and then you know exactly what tile he is in, so you get the correct collision mask and work out a position/rotation from there.

As for the second, basically you'd have to implement a pixel collision detection (which I recommend tiles for too for optimization purposes) and then get the rotation by taking the point of impact and going out to a circle. You can then extend this into a capsule to make it more like sonic than just a moving ball. This one is arguably harder, but has a (IMO) better result.

[winterhell]

nchavez in Sonic 2,3&K you have 2 collision layers, and the art in general is in 3 layers - Sonic, Behind Sonic and In front of Sonic. Every 128x128 tile has 2 parts, one that is background, one that is foreground. Now, many tiles have one part completely blank. You draw the back part first, then Sonic & Friends, then the front part and thats it.
As for the physics part of the story, each 128x128 piece is made up out of 16x16 collision masks, each having only 1 angle(yes, at first glance thats strange but it actually works fine). So each tile has 64 collision masks per layer. You switch between layers with Collision Plane Switchers. Depending on which way you cross it, it gets you to one plane or another. Different CPS behave differently.
Also each mask has a flag that tells if its completely solid, or if it is letting you pass in a certain direction, like bottom->top, left<-> right.
Relick mentioned 360 because Sonic does move at all 360 angles. In the classics the problem is divided into 90 degree segments. You make the character behave on "flat" ground -45 to +45 degrees, then make it work for the other 3 quadrants by flipping the values, and figuring out how to make the transitions between quadrants. Now, you may want to make the physics one whole continuous 360 thing, like the original team *might* have done if the hardware was right at the time, but you won't achieve an "authentic" Sonic engine.
For the tiles themselves you might want to make first a simple viewer or even editor before getting in the deep with the physics.
Other than how the file formats are in the original games, basically everything you need to know is in the Physics Guide. Trust me, I've been down this road (with C#)

[BlazeHedgehog]

http://info.sonicret...c_Physics_Guide

This might be what you're looking for, or at least part of it. It offers no programming advice, but explains some of the nuts and bolts of how a lot of the Genesis games work.

[nchavez]

Guys, thanks a lot, winterhell especially, so yeah I was thinking that each collision mask was like a curve, but I can see them being all linear, that makes a lot more sense.
The layers, graphically and physically also make sense, you would want to collide with the first part of the loop only when you're on that layer then switch at the top or something and only collide with the second part, and then for visual complexity you absolutely need the visual layers.
Ok makes sense do far...
And I need to specify the "directional flags" -- would it just be easier if instead of a mask/map for each 16x16 block I just specified an angle or slope and a y-intercept? Or would that be more memory-consuming/less efficient?
Also, yeah an editor would definitely be in order.
One last thing -- like you said, in the Genesis games Sonic and Pals have the "flat" or 0 degree running and walking animations and then the "diagonal" or 45 degree animations and then they simply flip those animation to cover all the other angles; did the original artists simply pre render a rotation in 45 degrees? Or do you think they made it from scratch? Or does it really matter....?

Thanks a lot guys! I appreciate it.

Also, this video is helpful in that you can see that all the terrain is linear really,

Some Video I Found but I cant remember where I Found it

and then just as a proof of concept, I made this a while ago with the same idea -- curves made of lines:

Proof

Its in Java, so you'll need that but other than that the controls are intuitive (hopefully!)

Can't say it 'nuff but thanks guys!

This post has been edited by nchavez: 26 November 2012 - 10:30 AM

[winterhell]

The collision masks don't have to be linear, some of them are curved, its just that all of the 16 heights of the mask share the same angle and the physics are processed at it. This is similar to how the art rarely follows the collision layers to the pixel. Even the collision angles do not match the visual ones. If you take a screenshot and measure 27 degrees slope, it'll be actually 22.5 the way the game handles it.
Yes the artists prerendered the walking and running animations for several degrees: 0,45,90 and 135. In a modern engine you can just rotate the sprite however you want in real time.

[Mercury]

Also, in the original games, each collision mask is actually a set of two - a series of 16 heights, and a series of 16 widths - so Sonic can treat them as either floors/ceilings or walls depending on his angle.

nchavez, on 26 November 2012 - 10:26 AM, said:

Some Video I Found but I cant remember where I Found it

That's my video, of a really old build of my upcoming AeStHete engine. I was still using Game Maker's precise collision checking and pushing the player out of the ground with a while statement at the time.

Linear collision masks work okay (they're what I used for Sonic Fan Remix) but they can only get you so far. Height maps (collision masks, whatever you want to call them) are preferable, especially if you want to emulate classic zones' terrain accurately.

[nchavez]

Got it -- I'll probably stick with the linearization because I'm on a schedule, but Mercury, how did you implement the moving platforms and the breakable tiles and the wooden bridge? Are they objects scripted into the game or are they "tiles"? It would be hard to make them tiles because they're pretty dynamic but...

[Relick]

nchavez, on 26 November 2012 - 12:33 PM, said:

Got it -- I'll probably stick with the linearization because I'm on a schedule, but Mercury, how did you implement the moving platforms and the breakable tiles and the wooden bridge? Are they objects scripted into the game or are they "tiles"? It would be hard to make them tiles because they're pretty dynamic but...

Anything that moves in the originals is handled separately from the terrain simply because it is easier and more optimized to do so. They're called objects, and so every frame Sonic checks if he is touching the terrain; if so do this etc; then straight after it checks all the objects whether he has collided with them. These aren't nearly as complicated at implementing as the terrain - it's as simple as checking distances between the two centers of the objects and seeing if the hit box has been crossed; if so destroy the badnik or hurt sonic or whatever. Since they only use hitboxes (height and width from center) rather than full collision masks it saves a lot of computational power, so on the (comparatively) weak genesis it meant more objects could be in the level at once. Obviously not such a problem nowadays, but it is useful to know in order to make sure your engine is optimized.

Unless I'm completely wrong, in which case please correct me :S

[nchavez]

I figured as much -- guys thanks a lot!!!!! In case you guys are interested, I'm writing this in C++/DirectX as a Windows8 App.

[Relick]

nchavez, on 26 November 2012 - 01:17 PM, said:

I figured as much -- guys thanks a lot!!!!! In case you guys are interested, I'm writing this in C++/DirectX as a Windows8 App.

Sounds good, would be great to see the first engine for the new platform.

However, if you are going to go through the trouble of making it for Windows 8 you may as well just use C# or VisualBasic because it is 100 times easier than managed C++ and I believe it can export straight into Windows RT as well as 8.

[nchavez]

Trust me, I love C#, it's too easy (psst... It's just a Java clone..) but apparently using C#/XAML for the app is pretty slow and not geared toward heavy graphics manipulation as much as it is for like a calculator app or something. DirectX, by no surprise is pretty efficient, but its soooo low-level and geared toward hardware I almost got scared off. Worse, it is not managed C++, like with .NET, it's just straight up C++.

Good idea though, that should be a project -- making a solid Sonic engine in cross-platform, solid popular languages like C++, HTML5/JS, Python, Java, etc.

Also: MonoGame is an open source implementation of XNA/C# which I believe runs on Mac and Linux... I liked XNA but they killed it for Windows 8 although MonoGame might be able to convert it...

[Relick]

nchavez, on 26 November 2012 - 01:46 PM, said:

Worse, it is not managed C++, like with .NET, it's just straight up C++.

It might just be me but using managed c++ was so hard after using unmanaged because unmanaged is so simple and makes sense whereas managed does crazy things that don't make sense, and since its so high up in the code hierarchy it's nearly impossible to revert it back to before. With unmanaged, once you get around the fact that there are a lot of extra things you need to remember to do (such as deleting objects) it feels much more powerful than C# or VisualBasic and combined with the power of DirectX you can just about do anything you like (without having to delve into the depths of assembly lol).

Quote

C#/XAML for the app is pretty slow and not geared toward heavy graphics manipulation

Coming from a fairly uninformed standpoint I'd say that anything on Windows 8 will not be geared towards heavy graphics manipulation. Obviously you don't get the power of DirectX (but remember DirectX works with C# too!) with XAML but when taking on a huge project such as creating a Sonic engine you might want to experiment with its capabilities anyway - you never know what you'll find and it could be useful for future projects. Just my .02 pennys.

This post has been edited by Relick: 26 November 2012 - 02:27 PM