I expected coding this to be a lot harder than it actually was, though I guess my implementation is a bit hacky. (One could argue, however, that making games in MMF is a hacky process)
Haha, you can say that again. I'm curious as to how you implemented that. Perhaps the animation frame for Sonic changes as he collides with specific track parts?
It'd be a thousand times easier to just check Sonic's height in relation to the loop and determine the animation frame from there. Easier still to just sync the animation speed with the speed of running through the loop, though obviously that would involve some trial-and-error.
Yeah, there's so many ways to do it. I'm still rather new in MMF2 so I wouldn't have guessed the first one. ...or the second one.
I certainly haven't used MMF2 extensively as well, but I figure if you can't do those two at least for whatever reason then maybe one should rethink their choice of MMF2 for a project of this nature :P
I actually use a method somebody at SFGHQ suggested (Nitemare, I think). This is my template object: It's an active object that gets turned invisible at runtime. This is what checks to see if Sonic is "in" the corkscrew. Also at runtime, several objects are created relative to the position of this template object: These two are separate; one is under Sonic and the other is over Sonic. These should be obvious. The one that makes it work, though, is this object: Turned invisible at runtime, this is what Sonic "stands on". Whether or not it's solid depends on a number of factors: If Sonic's X speed is below 2, it becomes non-solid. If Sonic is not touching any floors, it becomes non-solid. When Sonic is completely overlaying the corkscrew template object, his animation is changed to the corkscrew animation, which is 13 frames long. The frame of the animation is forced based on his X position in the corkscrew: To break it down, This handy little thing basically means that if the result of the calculation exceeds the number listed, it'll start counting from zero again. So "(0) mod 13" is still 0, but "(14) mod 13" is 1, "(15) mod 13" is 2, etc. At least, I think that's how it works - I'm awful at anything more than simple math, but this is how it was used in Sonic Worlds, and that's how it has continued to work for me. This produces the distance between Sonic's X position and the left edge of the corkscrew template. Since this is going to be a big number and our animation is only 13 frames long, we're going to need to divide it by something, so we divide it by 26 - which is 13 * 2. I'm still playing with it, but yeah, that's the implementation I'm currently using and it works. Edit: And if you need to know what it looks like when the invisible objects are visible:
I'm saving that post in case I ever feel like creating a Sonic Fan-game. Nice explanation. It's broken down even for noobs like myself.
ah, the invisible solid object is certainly a good way of forming the path of the corkscrew. Also, as far as mod goes, just go alllll the way back to your elementary school math class when you use to do long division with the quotient and the remainder. mod performs a standard division between two numbers and returns the remainder rather than the quotient. And yeah, its primary utility is for dealing with counters that cycle within a given range.
Doesn't that mean that way Sonic gets drag from the invisible slope object? Personally I'd have a mode where Sonic isn't affected by gravity and just have his Y position be a function of his X position relative to the control object's X position. If that makes any sense. No need for multiple objects or invisible collsion masks or anything of the sort. I'd probably implement the animation in a similar if not identical fashion, though.
Of course, another way to do the corkscrew thing would be to use the path movement object. But that's extremely newb-tier, and would probably take more trial and error than it's worth. + - AKA, what I would have done and struggled with incessantly.
Shouldn't he, though? It looks correct enough to me: http://i36.tinypic.com/8ze1b9.gif If he doesn't, it's probably not very difficult to simply turn off the momentum/drag stuff when he's overlapping the corkscrew object.
Wouldn't it be better to just set Sonic's Y coordinate according to the distance from the corkscrew's left X coordinate, using a cosine wave? That way you won't be restricted to many objects.
Heh. That actually seems physically correct, since when he's coming back down gravity should be lending a hand and speeding him up a bit. I'm pretty sure Sonic 2 doesn't do it, but this might actually work BETTER than it.
Code (Text): Y= base + amplitude*cos(freq.* X) base - in this case, the corkscrew's Y(should be aligned at the center). Amplitude - Distance from Y to Y top. Corkscrew's height/2 (Not exactly accurate, though). freq. - Needless to say. The bigger the corkscrew is, the smaller this is. X - Distance. I just don't like how Sonic gains speed when he's going down the corkscrew. It looks a bit unnatural to me.
I love how that works actually. Sonic gaining speed when going down is awesome, and makes more sense than him staying the same speed the whole time.
