Uh... What? Yes it does. Families are still a thing, and much improved from Classic, and attributes have been merged with behaviours, if partly because they were effectively redundant, if I recall.
I looked this up. No wonder, families are only available in the full version. I'm still using the demo. Attributes are not redundant with behaviors. They worked similar to families, but the difference is, they allowed objects of different types to be grouped, attributes are read only in that you can't apply code to them, only run checks. Also, objects in families all have to share the same private variables. Objects grouped by attributes are independent. You cannot read from objects that share behaviors, they're not grouped as a readable object. So, having families and no attributes is better than nothing, but attributes were still an important feature.
Pretty much everything you said can pretty much be done with families, with the only exception being grouping objects of different types, but that's really not much more work. Not true. Families have their own set of private variables, but individual objects within a family can have their own independent variables and behaviours. You can just have a family with no variables or behaviours, and let all the objects in that family have their own variables and behaviours without any problems. You can just make a family (or families for however many object types you need to check) with that common behaviour to achieve the same effect.
Oh, so two different objects in a family can have different private variables now? That's good. And what if I wanted a sprite and tiled background to be part of a group, so I can check both of them for collision? That's what attributes allowed. So, unless they made it possible to put different types of objects in the same family now, that's still kind of a hole.
Well, you can just have multiple versions of the same family for different object types and check all of them at once in multiple conditions. A bit more work, but it does the same thing.
Well, I sure am watching this topic like a hawk. Construct 2 user here, going to take a look at the version Candescence linked (when I've updated C2, I'm still languishing on 1.78 or so because I haven't used it in months really) and see if I can contribute at all. EDIT Okay, I took a look at this and it's even rougher than the MMF2 version of Sonic Worlds. I wouldn't even know where to start, sorry if I had anyone's hopes up. I do, however, have a few ideas on how to replicate Sonic-style movement using other means. I'll do some tests and get back to you.
You're better off doing that, yeah. I have tried using custom movement to do it, it didn't work properly for some reason. My Worlds porting attempt is hideously unoptimized anyway, and we need something more efficient that can actually run well with multiple players if required.
All in all, the key problem in all of this is collisions. You need to make sacrifices and sometimes skip a collision test under certain conditions or something, especially if you're gonna want multiple players. If there was interest, I'd love to share the base of my Sonic project, as I have made it with performance and optimisation in mind, maybe it could be of use to the community and maybe it could help educate some good practices when working with Construct 2. But it's filled with glitches and I created it without referencing anything at all, I plugged my own numbers in and made my own system using knowledge from what I have learnt the past few years (from reading, looking at Sonic Worlds, hacking, ect.), so it's not exactly accurate with how Sonic actually functions in genesis games or Sonic Worlds. I also didn't make the engine with huge stages in mind, only small stages, so I'm not sure how well it would perform with big stages. I'm at work right now so I can't test anything but from what I know, the engine does not take advantage of collision cells but still maintains a high framerate (over 100fps for sure) on my computer (which is a computer that has a CPU that can't maintain constant 60fps on a full TF2 server [GPU isn't a problem]). I'd say the core movement is only 70% completed, taking into account glitches that need to be fixed, a few more functions that need to occur (and potentially more optimisation), and some big alterations that need to be done to the collision detection (For example, sure there is wall collision, but the angle detection can detect very steep angles.) To be honest, I'm pretty anxious to share anything that I deem as incomplete as I don't want people to reflect an incomplete mess as to what I am capable of.
Right, quick post as I'm about to do grown-up stuff (shopping for boring essentials). I was toying around with a combination of the 'physics' behaviour (to detect precise collisions and affect gravity) plus tilemaps in all the angles; separates, so that there's a 90 degree, a 135 degree, a 180 degree, and so forth so there's eight of them. There's a reason for this; what about adjusting Sonic's gravity (just Sonic - this is possible with the 'physics' behaviour) to match the tiles he's running up if he (a) meets a certain speed requirement and (b) is actually running, that is obviously 0 for the ground tiles, near full unassisted running speed for ceiling ones (with inbetweens for the others). In theory this would work, not had time to implement it yet (since I'm still putting the finishing touches to a certain Dreamcast game I'm making). Just an idea.
Hey Jayextee, I think the built-in Physics behaviour's gravity action affects all physic's gravity for some reason. It's still a good idea to use Physics! :P
I thought you could set the gravity of separate sprites (in much the way they can have separate timescales, so motion can be slowed for Sonic's sprite and not everything else to mimic underwater physics). I admit, it's been a few months since I touched Construct 2 though.
I just checked it out, it's a bit weird and random but: You can't change the gravity of individual physics objects. You get an action called "Set world gravity" in all sprites with a Physics behaviour applied. If you use this action, it will affect all physics objects, even if it's not related to the Sprite, just as long as it has the physics behaviour. You can't change the angle of gravity, at all. Everything can either go down or up. I think the best workaround is to "Set world gravity" to 0 and then manually create gravity at angles and varying strengths manually. (Throw all objects you want to do this with into a family, give the family some alterable values like Phys_Gravity and Phys_AngleOfGrav, then you only have to do 1 set of gravity events!) If you or anyone wants to take the physics route, I'd highly recommend checking out this 3rd party physics plugin, called "Chipmunk Physics", that offers much more functionality (especially when handling collisions). I would have used this but I have physics intergrated deeply in my project and Chipmunk Physics was only in early development when I was beginning my project https://www.scirra.c...physics_t110815
Bumping this thread up a bit: I've made a Sonic Physics behavior for Construct 2, which can be found here, along with a basic playable demo to get the feel of things. It's still very much a work-in-progress, but I believe the essentials are all there. If anyone has any feedback or suggestions regarding the physics, they're very much welcome!
All things considered, that behaviour probably deserves its own thread. As I've said elsewhere, it runs beautifully, all the fundamentals seem to work perfectly.
Holy fuck am I interested in this. I made a little headway on my own attempt with events and behaviours (to wit: the gravity thing I mentioned is part of the platform behaviour, and I was using this for curve-running) and it was looking pretty good, albeit slightly janky. I guess I can quit dicking around with that now though. <3
This is what I love seeing. I know Sonic Worlds is what it is, but we have been seeing people expand upon Sonic fan games recently, and I love seeing the core movement on its own as it just makes me mind boggle with ideas without worrying about the classic tropes. Keeping my eye on this for sure.
I don't quite get where are you coming from. Core movement engines exist for MMF2/Gamemaker as well. People are just too lazy/incompetent to build their games off them.
Everything wrapped up in a behavior plugin is a whole lot tidier, albeit probably far less flexible, but if you're just shooting for a basic Sonic fangame it likely serves the purpose well. A key difference here, besides the convenience, is that Construct 2 works similarly to MMF2 but is vastly superior to it in many ways, and is long overdue for a Sonic engine of some kind.
Considering the guy making the plugin posts here and in SFGHQ, I'm sure he can add some additional functionality to enable additional flexibility. Though, if I recall, I'm pretty sure gimmicks that actually use the physics are few in number. I can only really recall those rolling tunnel things like the ones in Green Hill. Freedom Planet used one of those literally once, and it really served no purpose whatsoever. Though, I think one of the main big advantages of a dedicated behaviour is optimization, alongside just being all-around tidier. It's just a lot faster than doing stuff in events, and Sonic physics can be extremely demanding when done via events in both MMF2 and C2. Now, we just need that Unity engine and a UE4 engine, and fangamers will have all the modern tools they need rather than just being stuck with MMF2 and Game Maker, along with their numerous inherent problems.
It's more that if I were wanting the engine used in say Sonic Worlds, I'd have to strip out a lot now to get down the bare bones and and remove the Sonic staples. But I understand I would be in the minority as certainly a impressive engine with bells and whistles to get you going.
