Hey! Get ready for a butt-load of questions, if you can help me out and answer one or two, that would be way cool. If not, then that's cool too! Just... Not WAY cool. :)
Anyways, my questions...
1. Where do I create a background for a side scrolling game?
2. How would I load said background into a program?
3. Where do I create my sprites for characters and objects?
4. How would I load sprites those into a program?
5. What are some of the commands I would have to use to make a side-scroller?
6. Is it a difficult sort of game to make?
7. How detailed can I make the sprites?
Probably a little more difficult than you would think, but not too bad. My main concern on PTC would be performance if you had too many enemies and physics calculations at once.
The one thing I'll tell you is it helps to have a firm grasp of Newtonian physics (don't worry, that's the easy kind.) if you wanna get started just make a basic program rendering a sprite on a black screen or whatever, and try to code accelerate and decelerate functions to get the sprite moving naturally. Mario doesn't just stop on a dime, or get up to full speed immediately. Then add gravity and try to make the sprite jump and fall in a way that feels right to you. If you can do that, you're off to a great start.
Sorry I can't help with the background stuff as I haven't delved into custom resources yet. You'll wanna do something akin to UncleSporky's Dragon Warrior demo, but you'll only have to worry about scrolling on the X axis. (unless you want something like in SMWorld where the player can fly up and the camera pans up with him. In the original Mario if you went to high you just went off the screen.)
This is sort of what it takes to make a side scroller, roughly:
You need a virtual map. Not just the stuff you draw on the screen, but an array of numbers in memory that represent the map. You have to design it yourself, decide what numbers mean what. 0 is the sky, 1 is the ground, 2 is a ramp going up to the right, 3 is a ramp going up to the left, 4 is a rock. Making the maps can be a big hurdle. If it's a large, complex game it is always a good idea to make a map editor so you can draw it easily, convert the drawing to an array of numbers, and export that somehow to your program.
You need to have sets of data for all the stuff that can move around or is interactive. A monster might need things like an ID number (which monster is he out of 10 possible at any given time?), a monster type (bat, wolf, goblin?), an X position, a Y position, an X velocity, a Y velocity, an AI state (is he asleep, is he fleeing?), hit points, magic points, a counter to refer to how long he will keep doing something, an animation frame identifier, and possibly a lot more. Even a simple bullet needs an ID, a type, X, Y, VX, VY, maybe a counter to say when it should explode or disintegrate. Typically you have all this in arrays. MONARRAY(10,10), where the first number is which monster out of your 10 monsters is the one you're referring to, and the second is which bit of data about that monster you want to look at or change. You just have to remember what the number means to you.
You have to be good with loops. Loop through all the monsters and update their positions, loop through and see if any are touching the player, loop through and find an empty monster slot so you can spawn a new one. Loop through the bullets and see if any are hitting the monsters. etc., etc.
If you want it to be any good, you need to have a rudimentary knowledge of physics. You can't make a good platformer by just adding numbers directly to objects' X and Y values. You'd end up with a guy whose jump is floating straight up for a second and floating right back down at a constant speed. No, you have to use variables for velocity, gravity and friction. Gravity is trying to move the player downward at all times - in other words, you are always trying to increase his Y value - but if something is in the way like, say, the ground, the program doesn't let him move downward. To jump, you give him a negative Y velocity, and then gravity can decrease that every frame by a certain amount...but he also needs a maximum falling speed so things don't get too crazy. You also need to let him build up some speed but pull his horizontal speed toward 0 at all times, with just the right amount of force. You don't want him stopping on a dime, but you also don't want it like he's sliding around on ice all the time.
You need a complicated drawing engine that can take care of the difference between your virtual map data and the camera. You are literally drawing the screen onto Petit Computer's 512x512 BG layer, maybe you're at 32, 57...but virtually, maybe the map tile in the top left corner of the screen is 72, 3 in your map array, and multiplied by 16 pixels it's as if you're at 1152, 48, if your level was a huge picture in MSPaint. You have to be able to account for this difference and draw everything in the proper place. Maybe with the camera pointing at 72, 3 there should be a goblin who is spawning on a platform at 88, 10 on the map, so you do some math and figure out that means you have to draw him at 288, 169, just off screen. Then when the camera moves an instant later you have to calculate where he should be drawn again. You have to program this to happen automatically and quickly every frame.
There's a lot more to it than that, too. A program state engine, for example...
There are definitely some simpler ways to do these things, but you wouldn't call it much of a platformer without them. Almost all of them are an integral part of even Super Mario Bros. 1!
Also, because I can't sleep I just wanted to add that a lot of it is about learning the right mindset to program in.
When the player pushes up, you don't just move him up, you change a variable to indicate that he would like to move up. When a monster is supposed to move to the left, you don't move him left, you change a variable to indicate that he wants to move left. In both cases, you then test if they can do that thing, and if so, you let them do it. Everything in your program should ask permission to do stuff, rather than simply doing it. This even applies to the camera as it moves around - it might go off the edge of your map data and you'll get a syntax error. Instead, use a variable to ask "can I really do this safely?" first and test it.
And try not to simply use numbers. PLAYERX=PLAYERX+1 works for simple programs, but when you get more advanced you need to have more options, and variables let you do that. PLAYERX=PLAYERX+XDISTANCE, and that distance can be anything you want. It might be 1, or it might be 0 if you decided the player is blocked from moving sideways at the moment., or it could be -5 if they're being knocked back. It's more flexible.
I know this isn't specifically side scroller related, but when a monster hits a player, don't do:
IF MONSTER$=="slime" THEN PLAYERHP=PLAYERHP-5
IF MONSTER$=="wolf" THEN PLAYERHP=PLAYERHP-8
IF MONSTER$=="bossguy" THEN PLAYERHP=PLAYERHP-10
IF SHIELD==TRUE THEN PLAYERHP=PLAYERHP+5
Instead, make a broader system that could take advantage of code like this:
IF DAMAGE<0 THEN DAMAGE=0
If you get what I mean. Keep things abstract and flexible with variables. It's probably more readable that way anyway.