Making a 2D platformer is basically broken down to 2 major components: your player movement script (aka your platforming), and the scene manager (aka, your platforms). The player script is easy to make, literally just mapping movement to input, most of your work here will be tampering with the public variables in the Unity editor to fine tune the mechanics. Extra movement features like grappling hooks or double jumps is basically just discovering the appropriate script and adding it to the player script, then tampering with public variables again.

Scene manager will either load premade levels, or you'll have to learn how to perform procedural generation. Which is much easier than it sounds, they have a tutorial that explains how to implement simple procedural generation for a turn-based top down that you can easily rewrite for a platformer. Most of your work here is either building the levels, or tampering with the procedural generation so that all levels it generates are beatable.

Always finish player script first before the scene builder in a platformer. You're asking for trouble to invert the order, since you'll inevitably need to revisit the scene builder again to make sure the movement is compatible with the levels if you do go in the opposite order. Much easier to define the movement, then troubleshoot the scene builder as you build.


There are no tricks to scripting or coding. You only learn by doing it. You only get better by staring blankly at your screen at the same goddamn error for hours until you fix it. All of programming is how much time are you willing to spend tearing your hair out in frustration, because any program worth its while will result in you spending the same amount of time testing, if not more, to the time you spend coding. Bugs and error messages are your day to day life.

Time I'm willi... Okay I'll have you know on Minecraft I spent 3 hours looking at one line of code in computer craft, when the error was somewhere else. Oh I'm willing to do it. That's not the issue. Also thanks for the tips, I get the basics though a little, but this explained a little more. You broke it down for me.

I would say learn debugging. It is the most useful tools for fixing errors and bugs. You can place a break point and pause execution of the program. This will allow you to step each line of code and eventually you will see how things work and proceed with fixing from there.

Debugging is so rough though, you mess up one thing, fix it, ness up something somewhere else. It's like a big loop in the end. Then the issue was actually somewhere else the whole time.

Just a wee bit of an update;
I coded a nice little CharacterController from scratch! It's First Person, and is pretty easy to use. If people care enough, or need it, I'll add it to the original post. Most people, for jumping, use the "isGrounded' bool, which returns true at an unreliable rate. So, I use a Raycast attached to an Empty GO that shoots down, gets the distance from the object hit, and use a teeny bit of math to figure out if it is in between 2 numbers (so if the object was .1898979 away while I was on the ground, I would test for dist >= .1 && dist <=.2), and if that's true, set public bool Grounded = true. Then, only let the player jump if that bool was true. It's 150% more reliable this way.

That's a pretty overkill way to implement jumping. You could have just assigned all your floor game objects on a layer, then used "isTouchingLayer" (or something along those lines) for your boolean check. Also, using your way, a player could, theoretically, never touch the ground again since the jump is tied to distance being smaller than or equal to a number that isn't equal to 0, or jump off objects that you aren't intended to be able to jump off of.

isGrounded is intended to check if your character is in a stable position. This is to prevent, for example, a player from spamming jump up an incline that should be too steep to travel.

? I really don't understand this at all. It's a proper method that works 110% of the time for what I need.. This method works for people who want the player to be able to jump off of anything, NOT just things with a specific layer. If my player manages to jump on top of a car, then wtf happens? I can't put the car on the ground layer, because it isn't the ground. He can't jump off it which is ass. but using this raycast, it doesn't matter what he is on, he can still jump.

Just pointing out the limitations of what you've chosen. Any implementation needs to be tested at the edges. Of course what you've chosen will work to jump off anything, but that's also a potential problem. All the raycast will check is distance until collision with an object. Specifying what kind of objects prevents bugs like jumping off game objects that are untouchable for the player, but still detected by the raycast, since raycast looks for all objects with colliders by default.

The reason I bring up the layer is because I know raycast can result in some weird interactions if you aren't careful. Using just:

if (physics.raycast(position, down, MAX_DIST))
Grounded = 1;

as how you decide if you can jump leaves room for possible errors if the raycast hits, say, a bullet object that has a collider. Fixing that would be as simple as assigning all bullet game objects to a "hazard" layer or something and specifying the raycast should ignore "hazard" layer objects. raycast has that feature already implemented.

Obviously making a 2D thing is fun and all using pixels, but shat if you want to make a 3D thing, you'd have to use voxels, how would I make a game that is 3D platformer?
Like a park our game or something.

Hey! Thanks for that. That'll come in handy sometime. I didn't really think about that.

Anybody got any projects they wanna share? Once I am a little bit further into the development of this, I'll be sharing mine a bit.