[CommandanteStreakTH]

Alright, I'm trying to see if I can make a Sonic game on Construct 2, but it doesn't have the pre-built Sonic engine like Gamemaker has. I mean, there was Sonic Construct Worlds, but the link is down... does anyone have it stored on their hard drive? If you could please kindly link a copy here, you would be doing the community a huge favor />. Or, are the physics and platform behaviors adequate enough to be able to make a Sonic game? (If so, could you give a tutorial how to make it behave like a Sonic game?)

If not, does anyone have another Construct 2 Sonic engine they've made?

Thanks




EDIT: Candescence did us a great deed and posted a link of SCW2. Rejoice!

This post has been edited by CommandanteStreakTH: 17 December 2014 - 10:25 AM

[Mr Lange]

(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....%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.sonicret...c_Physics_Guide

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

[CommandanteStreakTH]

Mr Lange, on 15 December 2014 - 07:11 AM, said:

(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....%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.sonicret...c_Physics_Guide

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

Ah, very useful info. However, I still don't have the engine to compare it :s.

What are the problems that would arise due to the collision detection system? Is it merely when accounting for enemy collision or is it something to do with the physics of the game itself? Could using a shaped polygon with a decoy sprite overlayed on top of it be a viable workaround? (other additional info: I'm not looking for a perfect replica of Sonic-style gameplay, especially not in terms of combat, and I plan on using hi-res drawings instead of pixel-based sprites).

Oh, and what about Construct 2 or an engine thereof, compared to Gamemaker?

[Mr Lange]

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.

[CommandanteStreakTH]

Mr Lange, on 15 December 2014 - 07:36 AM, said:

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... so the problems in the collision detection is with the terrain, not the character models, thanks for clearing that up. I guess the only workaround for that would be to make levels with few complex shapes. (the latest iteration of Construct 2 has a higher polygon point limit than 6)

(The problem with the link is that it doesn't exist, says the 404 error :s. That's why I'm asking here)

What about Gamemaker, what's the best engine that can work with Studio so far?

This post has been edited by CommandanteStreakTH: 15 December 2014 - 08:26 AM

[Mr Lange]

CommandanteStreakTH, on 15 December 2014 - 08:05 AM, said:

Oh... so the problems in the collision detection is with the terrain, not the character models, thanks for clearing that up. I guess the only workaround for that would be to make levels with few complex shapes. (the latest iteration of Construct 2 has a higher polygon point limit than 6)

(The problem with the link is that it doesn't exist, says the 404 error :s. That's why I'm asking here)

What about Gamemaker, what's the best engine that can work with Studio so far?

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.

This post has been edited by Mr Lange: 15 December 2014 - 09:08 AM

[Candescence]

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.

This post has been edited by Candescence: 15 December 2014 - 10:36 AM

[CommandanteStreakTH]

Candescence, on 15 December 2014 - 09:57 AM, said:

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.

Well would you lookit that, the creator himself showed up to answer me. Still though, because of those performance issues, it would be advised to not overdo the complex shapes, unless it isn't really that bad...

Well, could you at least give us a testbed engine to see what's wrong so far? Or are you going to release it later?

Anyways, keep up the good work then lad!

[Candescence]

CommandanteStreakTH, on 15 December 2014 - 11:44 AM, said:

Well would you lookit that, the creator himself showed up to answer me. Still though, because of those performance issues, it would be advised to not overdo the complex shapes, unless it isn't really that bad...

Well, could you at least give us a testbed engine to see what's wrong so far? Or are you going to release it later?

Anyways, keep up the good work then lad!

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.

[Jase]

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

This post has been edited by Jase: 15 December 2014 - 04:52 PM

[Mr Lange]

Candescence, on 15 December 2014 - 09:57 AM, said:

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.

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

This post has been edited by Mr Lange: 15 December 2014 - 06:41 PM

[CommandanteStreakTH]

Candescence, on 15 December 2014 - 01:11 PM, said:

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.

You sir, have done a great deed to humanity! You should update the links on the threads you've made. And now... time for MAD SCIENCE! MUAHAHAHA!

The collision detection works pretty fine even for the minimal amount of polygon edges in each curve, but the amounts that need to be calculated are grinding on the speed of the game. (also, Mr. Lange, did you click on the points instead of the edges? Construct 2 is weird like that) Have you implemented a feature to destroy objects once they're off-screen and spawn them at certain points? Either at invisible objects or their absolute coordinates. It'd be a pain if you're trying to make a game with extra features.

Other than that... well... I'm still using the demo version of Construct 2 so I can't really say... I would increase Sonic's speed...

But otherwise it's still rather workable.

[Mr Lange]

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.

This post has been edited by Mr Lange: 16 December 2014 - 12:30 AM

[CommandanteStreakTH]

Mr Lange, on 16 December 2014 - 12:29 AM, said:

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.

Rather quite, but it might be solved by spawning the collision objects only as they appear on-screen. Not sure which is the most effective way to do that though

[Candescence]

CommandanteStreakTH, on 15 December 2014 - 11:59 PM, said:

The collision detection works pretty fine even for the minimal amount of polygon edges in each curve, but the amounts that need to be calculated are grinding on the speed of the game. (also, Mr. Lange, did you click on the points instead of the edges? Construct 2 is weird like that) Have you implemented a feature to destroy objects once they're off-screen and spawn them at certain points? Either at invisible objects or their absolute coordinates. It'd be a pain if you're trying to make a game with extra features.

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.

This post has been edited by Candescence: 16 December 2014 - 01:06 AM