[KOHCTPYKTOP]

Quote

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.

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.

Quote

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.

That does come naturally with Unity 2D, but it's also possible to work around. I'll see what I can do about that.

TruePowerofTeamwork, on 07 March 2016 - 11:20 PM, said:

Edit:
Oh I forgot to ask, are you reading the Physics Guide?
That would definitely help a lot with accuracy.

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:

Quote

One might think that if xsp happened to equal 0.1, and you pressed Left, dec would be subtracted, resulting in an xsp value of -0.4. Oddly, this is not the case in any of the Mega Drive games. Instead, at any time an addition or subtraction of dec results in xsp changing sign, xsp is set to dec. For example, in the instance above, xsp would become -0.5.

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.

Aerosol, on 08 March 2016 - 12:11 AM, said:

Out of curiosity, are you using raycasts?

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.

.Luke, on 08 March 2016 - 02:09 AM, said:

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

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!

[Aerosol]

KOHCTPYKTOP, on 08 March 2016 - 02:33 AM, said:

Aerosol, on 08 March 2016 - 12:11 AM, said:

Out of curiosity, are you using raycasts?

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.

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.

This post has been edited by Aerosol: 08 March 2016 - 03:22 AM

[winterhell]

Green Snake, on 07 March 2016 - 07:05 PM, said:

/>

Unity by itself is utter shit and is using legacy hacks from the last century that do more harm than good.

TruePowerofTeamwork, on 07 March 2016 - 11:20 PM, said:

Oh I forgot to ask, are you reading the Physics Guide?
That would definitely help a lot with accuracy.

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.

Atendega, on 07 March 2016 - 06:04 PM, said:

Quote

It's easy - scripts take advantage of the visual editor wherever possible. Everything but the logic itself can be modified without having to use code. The code, if you do need to change it, is organized and commented.

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.

This post has been edited by winterhell: 08 March 2016 - 06:24 AM

[DigitalDuck]

KOHCTPYKTOP, on 08 March 2016 - 02:33 AM, said:

I am somewhat aware of what's causing the slope skipping, thinking this bit might be the culprit:

Quote

One might think that if xsp happened to equal 0.1, and you pressed Left, dec would be subtracted, resulting in an xsp value of -0.4. Oddly, this is not the case in any of the Mega Drive games. Instead, at any time an addition or subtraction of dec results in xsp changing sign, xsp is set to dec. For example, in the instance above, xsp would become -0.5.

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.

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.

[Atendega]

Mr Lange, on 07 March 2016 - 09:17 PM, said:

Atendega, on 07 March 2016 - 09:12 PM, said:

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.

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.

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.

[.Luke]

winterhell said:

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.

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

[Xeal]

Atendega, on 08 March 2016 - 08:14 AM, said:

and I'm certainly not saying its physics are 1:1 with the classics yet.

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.

[TimmiT]

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.

This post has been edited by TimmiT: 08 March 2016 - 01:51 PM

[Atendega]

Xeal, on 08 March 2016 - 01:26 PM, said:

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.

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.

[Techokami]

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

[sonicblur]

KOHCTPYKTOP, on 06 March 2016 - 11:44 PM, said:

(I'm not able to test on Mac and Linux, so not sure if those'll work - looking for somebody to help out with that!)

The Mac build works fine, thanks for providing it.

Despite all of the negative comments, although it wasn't entirely accurate I thought it still felt fine. Sure, there were a few annoying things, but I thought the camera rotating with gravity was a neat idea.

[Andrew75]

Wish someone would do something like this in Unreal 4 lol

This post has been edited by Andrew75: 23 March 2016 - 07:12 PM

[eighttailedfox]

Razor and Zenon did a short video on the engine. Woo.

This post has been edited by Overlord: 25 March 2016 - 02:16 PM
Reason for edit: Oblig "remove s from https" edit

[Epsilonsama]

First off this is a GREAT idea. A 2D Sonic Engine done on Unity seems like a no brainier. While originally developed to make 3D games, Unity 2D has matured a lot since it was first implemented. Unity it's starting to become a standard for people with more programming backgrounds who want to work with a strong typed OOP language instead of script hacks or obfuscated code done by GUI but don't want to build an engine from scratch. But right of the bat I can tell that if anyone is looking at this for a replacement to Sonic Worlds then look elsewhere this aint it. If instead you are looking to the future where you can use this as a starting point to create something bigger on Unity then maybe there's some promise here.

Anyway to the meats a potatoes of the engine itself.

Sonic controls for the most part as he should. While this isn't a 1:1 with the classics I felt it was competent enough that it could do the job. While I do feel it's important to make sure the physics are as close as possible to the classics but this is a WIP and I'm sure it can be fixed. As for the test level, I agree with everyone that there needs to be a uniform tile system in place. From what I gathered it seems that you mixed and match assets from different stages. That is not professional and while this is not a professional project it's important to practice said things because one day you might want to do so. The tile set doesnt have to be pretty but it should be uniform so you can easily test all gameplay elements without different kinds of art work distract from the task at hand.

Another thing I should add is that the project should have a more formal license going forward. From what I gathered in your first post it seems you want to make this an Open Source project that allows anyone to use it as they see fit as long as they give you credit. This sounds to me similar to an MIT/BSD style license so try later looking into that. And I agree that allowing the engine to be used for commercial ventures is not a bad Idea because personally if I want to get involved in any project I always looking for a way to monetize it and allowing people or yourself for that matter to make a commercial product is good thinking. But you need to replace all of SEGA IP if you wish to do that. I suggest replacing all of SEGA artwork with original artwork, which goes back to my uniform tile set suggestion.

Anyway don't get disillusioned and keep working at this, even if this doesnt pan out you will learn a lot from this and trust me when I say this you will learn a lot working on this.

[KillaMaaki]

Neat project. I had thought about starting my own project in Unity, and then I found the video on Youtube.
I have to admit, I actually really like the structure so far. Having things separated into individual Moves is an approach I don't think I would have come up with myself - gives a nice "plugin" like environment for adding things. I've forked the repo and have been toying around with adding Rush style move classes (boost, homing, etc).

As far as physics, it seems to control almost exactly as I would expect. One thing I did encounter was with those big sliding blocks - for some reason, sometimes I cannot seem to jump while pushing against the block as long as the block is pushing Sonic backwards. I've tried to reproduce it in other situations but it thus far only seems to affect those blocks - I'm not sure if this has to do with the fact that the blocks move or what, I haven't looked at that code too closely yet.

Now, as for the extensions I'm adding, I've hit a few sticking points. I'd like to keep all of my modifications completely separate, touching as little code as possible. I've gotten Boost mostly working - at the moment holding S causes Sonic to boost forward and roll (like a sustained spindash) and decrements a boost meter. Homing should also be pretty simple, looks like I can use the DoubleJump move for reference.
On the one hand, I'd like to know what layer boost should be on - right now, I've put it on None but I wonder if it should be Roll instead (eventually I'll be removing the spin dash move from the character prefab once Boost works)? On the other hand, I'd like to increase the boost meter when a ring is collected, or when an enemy is destroyed. There doesn't appear to be any good way for an event to listen for these situations. The RingsController has an OnValueChange, but even then I don't see a way to know that the value has increased rather than decreased. I haven't checked enemies yet, I'll work on rings first.
Another point is making HUD changes. I'd like to display boost on the HUD, but so far it seems like the level manager contains the score, lives, and rings counters and as far as I can tell I would have to modify that class in order to make it aware of boost - which is exactly what I would like to avoid (modifying core classes).

Quote

That is not professional and while this is not a professional project it's important to practice said things because one day you might want to do so.

This, I wholly disagree with. Keeping level art consistent is the *last* thing I would worry about, definitely after getting the physics and gameplay elements working. And certainly, a "professional" project would actually be no different. Have you seen some of the prototype footage of Borderlands? It sheds some interesting light on the dev process these games take - random models and sounds (if even that) cobbled together just so that the devs can get things prototyped out and working. I'll link an article which contains some footage here, and I'll also quote something from it which bears repeating: "Games look like complete ass for 90% of their production".
So, in short, if I were the OP I would definitely NOT worry about the level's appearance or layout. Get the physics and gameplay working. THEN worry about the other stuff.

EDIT: Giving the UI thing some thought. One thought I might give a try is to implement some sort of model/view separation. Player data model's job is to basically consolidate all data necessary for the UI into one component, and then UI view's job is to take that data and display it on the UI. It may make it easier to extend the UI that way (someone would first create a custom data model subclass which exposes any custom values, and then create a custom UI view class which displays that data, without having to change any of the core code).

This post has been edited by KillaMaaki: 30 March 2016 - 09:01 PM