2D Platformer: No Unity Physics or Animator Controller. Possible?

Goal: Make a 2D platformer with complete control over movement. I need that old-school, stop on a dime Nes/Snes movement.

I need to:

Bypass unity physics.

What is an alternative method for movement?

What components must be included to work without physics?


Bypass Animator controller.

Can I manually code states without the Animator controller?

Can I still use animation clips?

Will animations and states be able to work if handled only by code?



I don't want to use the built-in State Machine or use it's parameter system

 

Alternative to using physics for movement is raycast based collision with your own movement math. Take a look in here for some in depth explanation: http://overdevelop.blogspot.it/2013/12/2d-platformer-collision-detection-in.html

Even if you don't use physics you may still need to use colliders, to test against them, no need to run any physics, but Triggers won't react without a rigidbody on the object that enters them.

For the state machine you can do your own. For animation clips you can use the legacy system which just runs anims without so much else, add Animation component instead of Animator, then just call animation.Play ("whateevertheclipsicalled");

More on it here: http://docs.unity3d.com/ScriptReference/Animation.html

 

Thank you for your reply!

How would a state machine be implemented if you aren't using unity's?

Also can you handle animation clips without the legacy system?

 

Here some tips and explanation to do your own state machine, is a bit long to explain and it depends on your needs:
http://gameprogrammingpatterns.com/state.html

As for animation clips, no you can't directly manage them without an animation component, you can read the animation curves, but still you need to make your own animation framework to play and time frames. For my needs I did a simple animation framework based on coroutines, it just run a coroutine and change a sprite of a component from a List cycling trough indexes, so what exactly you need to do with animations in your case?

 

I don't know why people resort to raycasts so much. You're still working with the physics engine then.

How do you think most platform games worked before everyone started getting really lazy and throwing entire physics simulations into the mix, must for the same of it being 'easy' to do collisions etc?

Typically you have to set up some kind of grid or collision system containing tiles or environment pieces, and then move the character based on the surface shape or whatever, and handle it all in your own scripts. Then you have to do your own collision detection, bounding boxes etc, pixel detection, and then probably have to fake the appearance of realistic responses or reactions. You can get something that looks fairly physics-y without a big physics simulation but once objects start having to rotate or bounce off each other its gets more complicated. That's why unity physics makes it easier... it's kind of an overkill but the benefit is it's quick to implement and quite advanced.

 

Thanks for posting Imaginaryhuman

The whole reason I want to avoid Unity's physics is because Ive been reading about how hard it is to get the level of control that an old-school platformer should have when using physics. I want to avoid the headache. I planned on using box colliders/triggers and script the rest. I don't want to have to continually slow down a character to stop them, I want complete control.



Neurological, thank you so much for posting these resources. To answer your question, I want to animate using sprites and be able to code their states. I was under the impression that Unity's Mecanim and it's State Machine are inseparable. As in, you can't use the animation clips and manually code the states. I thought I had to do the whole, "Click on one state, make a transition, and then create a parameter to make that true" I wanted to just code the whole state interaction strictly with scripts and still be able to use animation clips created in unity and have it work correctly.

 

Sadly for many things Mecanim is closed with scripting interactions, I wanted too to be able to add and manage states and clips by scripting, but it turned out to be more of a headace, thats why I opted to do a custom animation system, I have a custom animation clip class that only retain a bunch of indices and time stamps then an atlas class which contains the sprite collections for animations. The atlas class is pooled to be sure there is one instance of it only, then with a custom animator monobehaviour I start coroutines looking up the indices and time in the clip class, return the right sprite from the atlas class and apply to the SpriteRenderer.

Sure this way I can say goodbye to smooth transitions and all the features that mecanim have, but I don't need anything else than just animating a sprite sheet in sequence. This way I can also reuse animations isntead of having specific animations for each sprite component.

 

What you have described just gave me some Neurological problems

I guess my first order of business is to better understand how components and scripts interact. Frankly, I don't even know where to begin on the scripting side of things. The more I find out, the less I know. It looks like a long uphill battle to getting even a semi-workable game.

 

you should be able to do pretty much anything with unity physics... e.g. using kinematic to immediately stop an object, etc. but it can logically be a bit simpler to grasp or control from a scripted approach.

 

Hmmmm sounds like you want to do what I did. I'm making a retro styled platform game and wasn't happy with the "floaty" physics of Unity so I went for simple Rect Overlaps to check collision. I also wrote my own SpriteAnimation class .

Result:

 

Oh sorry didn't mean to confuse eheh. But yeah first get

Thats very nicely done.

 

DSSiege11, thank you for posting, that's exactly what I want to do!

Would you be willing to share some insight?

If not, would you be willing to point me in the right direction with some resources that helped you along your path?
I would very much appreciate it. By the way, that gameplay movement is solid and the pixel art is wonderful.

 

I can sure help you further PM me (Can't PM you cause you have it disabled)

 

This tut series is pretty awesome. It only covers the physics part of your question though... http://deranged-hermit.blogspot.com/2014/01/2d-platformer-collision-detection-with.html

One thing to note is the author is using Unity's 3D components for the beginning of the series... he eventually transitions to the built in 2D components a little later on... I'm assuming that's simply because the version of Unity he was using earlier didn't have the 2D stuff yet.

 

Thanks LiberLogic969!

I appreciate the resource and thanks also for the heads up regarding the transition in the series.

 

May want to slap some prototypes together for testing purposes before basing your decision to roll your own on other people's opinion Just a suggestion to see if you can control a character as much as you need to and see if the limitations you have read about are as limiting as you think. I've seen a lot of fast paced 2D platformers around here that use the built in systems to create great results.
I'm not trying to discourage you from creating your own systems nor talking down about the much more knowledgeable devs who have commented before me - just seems like a big decision if you don't have hands on experience using the systems that are already built.

Interesting topic.