Construct 2 Sonic Engine?

(reposting this from SFGHQ)

Sonic Construct Worlds was a good effort by Candescence, but it's not nearly adequate enough to make a Sonic game with. A Construct 2 Sonic engine is looking to be too difficult to accomplish because Construct 2 lacks pixel based collision detection and its only alternative are customizable six point polygon shapes, which is not a viable method. Construct Classic on the other hand does have pixel based collision detection.

StreakThunderstorm created an incomplete Sonic engine for Construct Classic. It only features core physics, basic moves, sprite animations, sounds, and springs. So, while it is adequate to work from, it's quite raw and you'd have to create everything else yourself. If you'd like to try, here's the last version: https://www.dropbox.com/s/pt51atpbhn545uw/SonicConstruct%20v10.rar?dl=0

Construct's built in movement behaviors do not have anything close to Sonic physics out of the box. You'd have to work it all out on your own. If you want to try that, I'd start here: http://info.sonicretro.org/Sonic_Physics_Guide

You may want to wait, however. There may just be a Construct Sonic engine in the works...

 

You should be able to get Sonic Construct Worlds (for Construct 2) here.

The problem is that a six point polygon shape cannot account for the complex terrain shapes that are involved in a Sonic game. A quarter pipe for example, three points are needed just for the corners, and then you only have three more points to define the curve, which would make for a very coarse curve. Any shapes more complex than that, such as an S shaped ramp, is just not possible. You could break down the terrain into many small pieces, but this only stretches out the problem and would require ridiculously greater amounts of time when setting up terrain and creating levels. No matter how you slice it, it's just a really bad method and will be problematic.

I don't understand your last question.

 

Oh, they increased the polygon point amount? That's news to me. Unless it's like 32 points per sprite, it's still not enough. (Edit: Just tested... it's now seven points... why did they even bother)

Not sure where to get it then. Maybe Candescence will see this thread and help. You could always send him a PM here or on SFGHQ.

I'd say the best Sonic engine for Game Maker is the recently released MAX engine, which you can find on SFGHQ.

 

There isn't a strict polygon limit, Construct 2 will warn you if you create more points beyond 7 that you might face performance problems, but that's about it, really. As for assembling terrain, that's really not so much of a problem when tilemaps are thing. With tilemaps, you only need to set up tile collisions once for each tile, and for smaller tiles being part of a larger tile, you can also easily select an entire group in one go and place them anywhere on the tilemap, even flip and mirror it. It's really a lot more convenient, since there's a dedicated tilemap bar to easily and quickly grab what you need, rather than having to go into the object folders or the part outside the stage where you store the various tiles and copy-paste them. The actual curves aren't gonna be as smooth as you'd find with pixel-based collision, but I don't find it to be that huge a deal, and it could be worse, Stencyl and Unity are guilty of having problems with having 'hollow' collision polygons, that's not an issue for Construct 2.

My actual problems with trying to implement a Sonic engine in C2 stem mainly from optimization and some bizarre physics quirks, despite replicating Streak's code pretty much exactly. The engine used to run like shit, and that's just in a bare-bones level, but newer C2 optimizations with collisions have helped somewhat. I'll probably look over my latest capx with the latest beta and see how it holds up, and see if I can figure out where the bottlenecks are, but I think it's either collisions or the way the functions are implemented.

Edit: yeah, while the engine runs fine on my machine (though it is an Inside Core i7), it probably needs some serious optimization, especially if anyone even thinks about implementing multiplayer. That being said, it's worst problems are some oddities with the physics in specific circumstances.

 

Oh, right, I knew I forgot something. Go nuts with it. The actual thing is pretty old, hence why it's not using newer features like tilemaps, but still. I'm not sure if its compatible with collision cells, really, it's difficult to tell, but the movement routines are CPU hogs, and the number of collision checks per tick doesn't exactly give me confidence. I honestly think the code needs a do-over, it's apparently not very efficient.

 

I've managed to get a decent stable Sonic engine going on in Construct 2 (unfinished but playable), although it's not a port of Sonic Worlds or anything, I've made it completely fresh by myself. I feel pretty confident with Construct 2 and I'm happy to try and help explain what I would do in a situation. Some things are harder to explain though, like for example the polygon-based collision stuff. It's limiting for sure, and you probably won't be having true pixel-perfect accuracy as far as I can see, but it's not a deal-breaker by any means. I was pretty miffed when I went from MMF2 to CC then C2 to have to deal with polygon hell, but it's honestly not that bad if you're willing to give up potential pixel accuracy.



Construct 2's collision detection is designed in a way where the more points on the polygon, the more impact on performance you will get when running a collision against the pointy object. However, Construct 2 handles 4 pointed polygons really well.
So what would be a sort of solution (albeit an annoying one) is: Have a "Tile" Sprite and a "Collision" sprite, (The tile being an image of like a 64x64 floor sprite, and the Collision being an invisible 4 pointed polygon rectangle). Run some events so that whenever a Tile is spawned, create a few collision sprites at the right position, and then size + angle them along the terrain (won't be perfect by all means but does the job). This will mean you can use the Layout editor and throw your tiles in and make it look nice, without having to worry about tracing lots of collision blocks along each tile. Downsides to this idea is it's not exactly a straightforward visual easy task, and that you may end up with a lot of collision tiles if you make huge levels (although "Collision Cells" solves this which is an automatic feature).


Reading back through what I'm writing makes me realise how flaky and annoying this polygon stuff really is but it hasn't affected me that much really, and I've been using Construct 2 for a long time now. Hmm...

 

Mind explaining how you can add more points? I can't find that ability anywhere.

 

Clicking on the points just selects them. But, I discovered double clicking on a point forcibly adds another point to the polygon, which is dumb, but it works. That actually solves a lot, and makes C2 potentially viable to host a Sonic engine. It would still be tedious having to manually define all of those collision boundaries, but at least it's possible to create necessary shapes now. The biggest issue leftover is just how expensive collision will be in action.

 

No, and that would be an incredibly stupid idea. Construct 2 already has collision cells, which dramatically reduces the amount of collision checks to within a local area, achieving the same objective but I doubt the engine at the moment is able to take advantage of it, due to the way it works (collision cells need collision checks to be the first picking condition in a top-level event, otherwise it'll brute-force it), and it's difficult to tell whether the way it works now satisfies the requirement.

 

If the collision terrain is made out of polygons, against what shape would they be tested on Sonic's behalf? A ray/line, box, circle?

 

I still really think it's a good idea to avoid using more than 4 points on a collision polygon. I think you would get much better results if you use multiple pieces of 4-pointed invisible collision sprites angled along the terrain/curves/halfpipes.

 

I don't understand what it means by putting collision checks in "top level events". So, I can't have collision checks later in my code, or have too many collision checks going on and then collision checks later in my code or something, or else it reverts back to brute force checking? I'm confused. What am I supposed to be doing with the order or placement or amount of collision checks to keep it in the safe zone of the new collision checking system?