That pretty much sums it up. Note that some people have created more user-friendly map editors but I can't think of any keys at the moment. Hope this helps

Lesson 3: when your map is good to go, select save at the bottom. This save option will allow you to open the map back in the editor to continue to work on it. SC save will save each individual layer of the map if you want to use it in your program.

The frown face is the undo button (careful, you only get one), and the 0 to the right is degree of rotation. On the far left are the tile placement options ie. single tile, fill area, etc.

Lesson 2: placing bg tiles is as simple as selecting the tile you want and placing it on the map editor. You can rotate or flip tile to get them in the position you want using the button options below the tile selector area on the right. (H)=horizontal flip, (V)=vertical flip.

yes, the program I'm thinking of had the file name of FREE_BGM by RWI...

Lesson 1: the background (bg) consists of 4 layers (0,1,2,3). You can stack bg tiles by placing tiles on different layers. Example, layer 0 can be then ground. Select 0 at the bottom and place grass tiles in an area. layer 1 can be trees, so select 1 and place trees. You can toggle which layers you see in the editor with the "0 1 2 3" on the top screen.

Is this the FREE_BGM program?

you could just copy the sprite over an existing person-sprite and you won't have to

i didn't think that it would matter if the vsync was in a while loop in the def. It isn't called every time either, only when the player wants the sprite to move and if the sprite is allowed to move. i suppose i could break it down into multiple functions...

Good things happening. Arrays + sprite collision = very handy for issuing commands to numerous sprites.

didypu acls before running the program?

there'll also be parameters detailing how many tiles the sprite can move as well

Problem from that comes when there are obstacles on map you don't want the moving sprite to pass through. So it is easier like this and check bg data before writing the move string with bttn input so it prevents target from hitting obstacle and therefore the moving sprite will avoid it

Made a function that a sprite will follow the exact path of the target to move by writing a string with button inputs and reading each of them as the x,y destination of sprite. This will be handy....

set the top left color to 0,0,0

it's intentional

Ah, I know what it is. Also need to correct the wave counter because I fixed the wrong thing. I'll put out another update sometime

EDIT: overlooked some issues. New key: E33K3J9Y

Demo is up! Key: 2R5NW3NJ

*open. "out" doesn't make sense