It doesn't help your credibility a lot to essentially accuse people of lying. I love the classic Sonic games, and this engine is plenty close. It's not perfect, but it certainly isn't as bad as you suggest.
Oh god... the physics aren't THAT bad. I think something even worse broke when I fixed the the bug Aerosol brought up. Hold up, let me take a look and upload new builds.
It is not plenty close. It is as bad as we suggest. If you love the classic Sonic games then go play them more and pay better attention to how they function. Either you're played little, payed little attention, or you can't perceive differences or faults in gameplay.
As Natsumi and Mr Lange have said, and I will reiterate. This needs work. Sonic doesn't respond well when going up slopes (which makes the entire gravity switching segment a pain), he doesn't slow down when rolling on a flat plane, and roughly 99% of the time when I launch this, the button that is used for down is constantly in the state of as if it was pressed, so I can't do anything but roll around. Spin dashing also seems to be released by pressing the up button(???). Don't know if that's related to the aforementioned down button problems. This is no where near the point that this can be called a replacement for Sonic Worlds, nor as something that should be used for fan games or for making something that's meant for retail release. Also:
Hoo boy, I can feel the flames from here. I expected bad impressions, but not this bad. I've uploaded another demo that patches up the frictionless movement introduced with the prior demo, and I'll make sure to test my last-minute builds more often.
These aren't flames. These are criticisms. You fixed the broken roll but everything else is virtually the same.
I know, I know, just being metaphorical. Reading the criticisms I did feel flustered at first but they're all valid. That's about all I can fix with just a few lines of code, then. Just want to wrap up here before I go back to the drawing board - So it looks like the engine is polarizing. It's clear that my grasp on Sonic physics isn't close to what I'd thought, and I should have looked for more feedback and testing before releasing outright. Lesson learned! The interface needs work, too. A lot of work. I won't lose faith in it, however, and in due time I'll return with something better. For now, what's out there is out there - there's no backsies, so maybe someone will see potential in it. This is the first project I've really put out there, so it was a good learning experience and a great deal of catharsis personally. Thanks again for the feedback, and see you soon!
I agree with Lange and Green Snake, there are still lots of oddities. I've done a lot of research on how the classics work, and there's definitely still a lot of issues. Sonic kinda skips up and down slopes sometimes. I wasn't able to get a good gif of it, but it feels incredibly awkward. Sonic also tries to go up 45 degree angles at slow speeds as shown here: https://I.gyazo.com/150cfbdd2a04896e0d6a5b90cc59f292.mp4 It seems you may have an input lock timer in place as slowly walking up quarter pipes works closer than a lot of engines, but it should lock when the angle is greater or equal to 45. And if it is in place it seems too short, it can't remember if it was 30 or 32 frames. Aside than physics there's other problems too. When I started the game and created a file the dialog asking to confirm, always had NO in yellow as if it was selected, so if I moved to YES, NO would stay yellow. This eventually went away. The other problem is graphics related, which I think is actually a problem with Unity 2D. The pixels aren't perfect at all, they also have strange oddities. Pixels are always warping while moving, and when moving slowly objects will appear 1 pixel away from each other for a frame or two. https://I.gyazo.com/02c8632de4e27b8b275aef7eb5fd4f91.mp4 (Look at the background near the end of the clip, this happens with level tiles too) I really don't like Worlds or MMF2, but I would never recommend this over Sonic Worlds. MMF2 and Worlds are an absolute pain to use compared to Unity, but Worlds is far more accurate and doesn't have all these strange oddities. Edit: Oh I forgot to ask, are you reading the Physics Guide? That would definitely help a lot with accuracy.
I should remember that being a dick can be justified as long as I'm being a helpful dick :v: Out of curiosity, are you using raycasts?
Any reason Sonic keeps looking up when no input is given? Movement along slopes gets pretty sticky at times too. And I kinda have to echo the others here. While it's nice you have a bunch of features packed into this thing, little of that matters without solid collisions and movement to build on top of them; the physics should come first. (Also, watch out for Feature Panic. It's the scourge of quite a few game projects.) Was the excitement too much to contain? This is something I see happen a lot with people working on their first big project. There aren't any 2D Sonic engines for Unity, so everyone's expectations were high, no matter what the version number is. Years ago, I had a Game Maker Sonic engine with lots of "features" to boast too, (Didn't finish it, though.) but I never put it in the wild. Why? It wasn't ready, and I was aware some Retro members were working on something much better. I didn't put my little Shantae engine anywhere until it was remotely decent either. That said, it's a good effort and can only get better with time, as long as you're willing to take in some feedback. I wasn't expecting this to be on Sonic World's level yet in terms of polish anyway.
First of all thanks for recording the bugs. You too Lange, it's really helpful. I erroneously made the horizontal control lock apply at 50 degrees and up, and for only 16 frames. That does come naturally with Unity 2D, but it's also possible to work around. I'll see what I can do about that. I am indeed using the Sonic Physics Guide as a reference but also took a lot of liberties with the engine. For example: - Physics units are converted: pixels to units (100 px/unit), and frames to seconds (60 fps). - The "four modes of movement" are gone - instead the sensors are just always oriented down perpendicular to the current surface. - All angles are relative to the current direction of gravity, in all parts of the algorithm. - The current surface angle is based on both ground sensors, but also knows when to ignore one of the sensors' surfaces if it's too steep, etc. I wanted to generalize the formula and make it more open-ended, but it seems something got lost in translation. I am somewhat aware of what's causing the slope skipping, thinking this bit might be the culprit: So there's a sudden increase in speed when trying to accelerate from a standstill against slopes that cause you to decelerate. But it doesn't happen in the originals, so there's something I'm doing wrong. Linecasts, which are pretty much the same thing. I get a list of all platforms hit by the linecasts and filter them using triggers, which can decide whether or not they want to be solid to the given collision. That's exactly what happened. I knew I had big shoes to fill, and in my echo chamber I convinced myself that I could fill them right then and there. Sour mistake that I definitely don't want to repeat. As for the input problems, that's something I'll have to test on other machines. Thanks for the kind words!
I wish I could remember why, but I recall being unsatisfied with the performance of linecasts. I know that they get wonky with edge cases, and Sonic games have quite a few edge cases. I meant to try what I was doing again with actual objects acting as sensors, but I never got around to it. Now that I've had time to test it, I have a few more thoughts. I know you know this already, but I think you need to take another look at how Sonic is adjusting to angles greater than 45 degrees, and how the sensors are detecting angles and such. I tried walking off of a mushroom, and Sonic tried to cling to the side of it. I also think the camera is a bit lazy. It's way too easy to lose the camera with just a spindash. Also, I think your sensors for Sonic's height are off. As mentioned before, I was able to jump on top of a platform when I hadn't cleared it yet. I was also crushed by a box, but the box had already covered Sonic by 5 or 6 pixels before he was deemed crushed. The last thing I've noticed is that Sonic can get really fast, really quickly. Faster than I'd expect, really. I rolled through a booster and lost Sonic within a second. Sorry I can't be more helpful with a recording right now, but if I can remember to, I'll record these things tomorrow. Like I said before, this is pretty good so far and, for the most part, Sonic moves as I would expect him to.
Unity by itself is utter shit and is using legacy hacks from the last century that do more harm than good. In a way its very disrespectful to imply the possibility he hasn't been using the guide. I would think there is something terribly wrong if he got this far on his own using the disassemblies and/or reverse engineer the physics himself but to not be aware of the guide. There is a good reason that people are using MMF2 and GameMaker to make games. Actual programming is rarely if ever something artists do and vice-versa. How many games can you list that are done by a single artist that is 'scripting' in C#? I don't know what your definition of scripts are, but the code in Unity is compiled during the build, and not from external files during runtime. Throwing around the word 'scripts' instead of 'code' doesn't make it easier to write and belittles the efforts of actual programmers.
That has nothing to do with slopes - it refers to pressing "left" while moving very slowly right, which makes you accelerate left for that one frame more quickly than you should. You should not be using dec for slopes at all.
I'm not just inanely babbling here, and again you're resorting to questioning my love of Sonic, which is frankly insulting. All I'm trying to say is that, as a heavily unfinished engine, this shows a lot of promise. I'm not trying to suggest that in its current state it is fit for use, and I'm certainly not saying its physics are 1:1 with the classics yet.
Krita would like a word with you. Quite a few of the programmers working on it can both draw and code, and the program benefits from it by having interfaces designed/written by artists for artists. It's wonderfully intuitive and fast. And programming can be done with Game Maker, unlike MMF2. GML gives you tons of control over a game, and extentions help more so. GM's still currently more realistic for 2D than Unity, until Unity's 2D offerings improve. (Which *will* happen, so Yoyo Games needs to get things in gear if they want to stay relevant in the industry's future.) Unity is still more powerful and flexible, though, and uses real, strong-typed programming languages instead of glorified javascript. I'm just putting that out there; not everyone using Game Maker touches those hacky, awful action blocks to put things together. A lot of us can code and/or are transitioning to something better, because GM's limitations were getting in the way. I'd like to move to Unity myself when their 2D functionality is better; really interested in C#.
Yet you said the physics were pretty close. Sonic Worlds is pretty close. This is not. Also I wouldn't take Lange'a questioning of your love for the classics as an insult, as if it was something you did love it'd be something you'd pay attention to and notice if something felt off. It's like saying you love the classics and how the physics worked but you then grab a controller and play the classic Sonic levels in Sonic Generations and say you can't tell the difference between the two, so Lange's criticism is correct.
Let's not make this thread about if Atendega knows how Sonic physics work. That and the problems with the physics in Generations' Classic Sonic are far, far more noticeable than in this, so that's not really a fair comparison. And I could easily see how someone could think that the physics in this are like the physics in old games. I only took a quick look at it and while it's not really suitable for people to develop games with yet (others have already pointed out why), it doesn't control as wildly different as others make it out to be. I do think it's a good first attempt, but it does really need work. I hope you don't find the other posts in here discouraging, it'd be great if you continue work on this cause I could see this turning into something that's pretty useful. Definitely keep their criticisms in mind though.
I consider Sonic Worlds 1:1 with the classics. Any differences there are so minute that pointing them out is just nitpicking. By pretty close, I'm saying that it has obvious flaws (lurching up and down slopes, sticky ground, etc.), but is ultimately promising. It does feel off, I don't deny that, and I'm still feeling pretty insulted. Regardless, TimmiT is right and we should stick to constructive criticism that will help KOHCTPYKTOP improve the engine. In regards to that, I'm experiencing a REALLY weird bug. When I picked up the lightning shield, Sonic was cloned.
Yeah, this really needs to go back into the oven. There's a lot of bizzare issues (like broken XInput support! Can't use D-Pad, reads the stick in bizzare ways that leaves Sonic constantly looking up and down at the same time), physics innacuracies (seriously! Read the Physics Guide!), and graphical rendering issues (what happened to the regular shield? It's not supposed to be a blocky mess!). Also, reiterating and building off one criticism from earlier in the thread: the level assets are a total mishmash. It looks... really lazy. And some stuff isn't properly aligned? I suggest you take some time to make a placeholder tileset, like Worlds Delta or HCGE's Sonic Template. This provides a clean, consistent tileset that not only serves the purpose of giving the sample level structure, but can be reutilized as a template for users to create new tiles to use for their levels, while still being able to maintain a lot of the iconic geometry (like loops and ramps).