Candescence's Forum Posts

  • PROGRESS! Ashley has let me know that my suspicions were correct. Turns out that RotateAngle() is basically the same as C2's "Rotate towards angle" action, which required me to change some things and introduce a new 'angle sensor' purely for the sake of replacing the 'pvAngle' variable so I can take advantage of this.

    The result, as you can see in the .capx, isn't perfect, but it's getting there. The angle isn't spazzing out, but there seems to be some odd delay at times, which makes me suspect that there is indeed collision issues.

  • Pretty much! Proper slope detection is a must, methinks. Might as go all the way if you're aiming to do that, since there's an entire framework already there to base the behavior on. :p

  • Tokinsom: Well, the platform behavior can move on slopes, but it can't automatically rotate on them, nor is it capable of properly traversing curves. But, yeah, general improvements are a good idea all round.

    JohnnySix: To be fair, using two separate sprites is a well-known technique. And crouching is easy, make a separate animation for while the player holds down. :p

  • Believe it or not, Ashley, there's actually an entire guide on how Sonic physics works. The page linked in PixelPalette's post above is just one page in the whole thing!

    Sonic Physics Guide

    Plus,you can also check out the Classic version of the Sonic engine I'm trying to replicate in C2 (with some difficulty). The physics, to my knowledge, are quite accurate, so it's a good reference as well. Best to look at both, since the event-based engine works a bit differently when it comes to stuff such as rotations, due to the guide being based around methods used in the Genesis/Mega Drive Sonic games.

    Really, creating a more advanced Platform Behavior based around Sonic physics may seem hard, but Sonic fans have spent years figuring out how it works. Obsessive, but it does have benefits. :) Build a solid framework based around those physics, and then provide users with options to be as flexible as they want with it, and then you have a behaviour that will let you do more than what is there right now, I think.

    Speaking of which, Ash, did you get that PM I sent you about anglelerp() and RotateAngle()?

    Edit: Fixed the links. And just to note, even Mario could run on walls at times in Super Mario World. Food for thought.

  • I know there are obviously other things that you want to do first, Ash, and there is a lot on that to-do list, but I do feel the need to point this out.

    The platform behavior is neat, but the Classic behavior has some things that the C2 version doesn't:

    • Variable jumping height
    • Air speed options
    • Inverse control
    • Bunny hopping option
    • Being able to fall through platforms (would be nice to be able to do it with a custom key, too)

    But I also think that the behavior has some other limitations that could be addressed that limits what people can do with it. Namely, rotations. Some platformers (Sonic being one of the first examples) allow platforming characters to rotate on slopes, walk/run on walls, that sort of thing.

    I've tried to do such things with the custom movement, but I'm pretty sure it's extremely difficult to do, because methods from Classic don't work very well at all. Physics... Just as difficult, if not moreso. And the only other alternative is making your own movement through pure events, and that can get very complex indeed (especially if you're trying to create something momentum-based like Sonic).

    I think it might be beneficial to create an "Advanced Platform Behavior" that gives users much more flexibility and options on how they want to make a platform character to move. Do they want rotations on slopes, or not? How about being able to slide or roll down a slope to pick up speed? Stick to walls and ceilings, or fall off if there's not enough speed? That sort of thing.

    It would unshackle more than a few of the limitations of the behavior while also giving users the option to start off with the "basic" version, and moving on to the more advanced options if they want them. Slope rotations, believe it or not, would go along way to extending what a platform character can do.

    With that in mind, I imagine an "Advanced Platform Behavior" (or just an improved regular behavior) would have these features:

    • Slope Rotations
    • Slope acceleration/deceleration
    • Collisions based on objects/families as well as the Solid/Jump-Thru behaviors
    • Toggling collisions with particular 'solid' objects on a per-instance basis (rather than turning off the actual solid itself)
    • Some other stuff I can't be arsed to think of right now

    Long story short, if you can faithfully recreate Sonic platform physics using such a behavior, I would say that would be the point where you can say 'mission accomplished'. Can't be that hard, surely. :)

    I know there's a LOT on your plate, but I guess it really can't hurt to make suggestions.

  • Uh... I've already done that, actually. That being said, "else" isn't compatible with the Function plugin, but that's not my main problem right now. *Points at my last post*

  • ALRIGHT. I've isolated the angle problem to TWO main possible factors. It can only be one or the other, not both, I presume.

    a) The anglelerp(a, b, x) expression. It's supposed to replace the RotateAngle() expression from Classic, but I have a feeling it's not working right. I'm gonna ask Ashley about it via PM.

    b) The collision detection system might not be working properly in this instance, though I can't see how it would cause spontaneous and virtually random changes in angle.

  • I do think I'll need an "else" for the function, yes, at the very least. Placing a function inside a function, as I said in the function topic, may not actually be at all necessary, and should logically be unnecessary in my opinion.

  • Alright, let's go with implementing "No triggered function" for now. For all we know, putting a function inside a function may not even be necessary. It was structured that way in Classic probably because putting an else as a non-sub-event caused an error in this case for no apparent reason.

  • Ashley: Sounds reasonable. I'd especially like to have "Else", "Or", and official Function conditions. No offense to Rexrainbow and his Function plugin (which isn't bad), but there is certainly room for improvement on that end.

    In fact, there's a custom Sonic-style engine using just events that I'm trying to port over from Classic, but I'm running into problems due to the lack of Else, While and certain function-based features. If you'd like, you can use the .capx as a testing bed for the new event sheet features. It's an open-source engine anyway, so go nuts. :)

    inkBot: Actually, with tile map functionality, IMO, I'd have the tile map load in the layout editor proper, and when you double-click the tile map, it shows a different set of tools for tile map editing.

    And, since we're talking about tile map features:

    • Having tile sets as "objects" with their own variables, behaviours, able to be assigned to families, etc. Good for being able to place solid tiles alongside non-solid tiles in tile sets, and stuff.
    • Being able to change tile maps at runtime, and save the changes to a new file so the original tile map is preserved.
    • Being able to place objects in the tile map editor. Ctrl+C and Ctrl+V is nice and all, but being able to place stuff with just a click would be lovely.
    • And all the other stuff I described in my tile map topic.

    Shame it's lower on the list, though, according to the poll.

    rexrainbow: I am aware of that, though it doesn't really change the fact that it has to be inputted manually rather than read from an external file. Though I suppose it can't be helped until the devs develop a way to read from an XML file.

    Speaking of which, Ashley, we need an XML plugin, ASAP! XD

  • Candescence

    Tile map supported -- TMX importer And a demo

    I'm aware of it, but it has some limitations that I really don't like, such as having to input the data manually into an action rather than reading it off an XML file, and only showing the actual tile map at runtime rather than in the editor as well. Among other things.

    It's neat, but it's not very practical at all, IMO.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • More event sheet features is good, but I personally believe better tile map support should be a priority is a good idea, as well. Online multiplayer... That shouldn't be as important, IMO.

  • Checking the tweets related to Spriter, it seems you're attracting attention from Japanese guys as well. Nice.

  • Thanks! I would really appreciate it! :)

    Also, I think I discovered the reason why the Construct Classic version of the engine I'm trying to replicate placed a function within a function - for some reason, the "else" wouldn't work unless it was sub-event! Hilarious, really.

  • How about "Function <Name> Not Called"? Might be better names for it, but it's the best I can think of right now.