I am recommending you read the old 80s book"Write your own Adventure Programs for your Microcomputer" on the usborne website, it is a free (but hard to find) download and it is really short. The code won't run without changes on SmileBasic, but you only really need to look at how they structured the code. Map in an array, how the input is processed, that sort of thing.

Reading input looks good, but I am worried about input validation. If I were to type "SMASH ALL THE POTS" for the first section, it doesn't tell me that I typed something wrong, and keeps running through to @2. With everything structured with GOTO, I am afraid you may end up with more of a choose your own adventure book than text adventure.

You may also be wanting something like IF LEFT$(PUNCH$, 1) =="P" THEN to only check the first character.

A screenshot of your code might help find the problem. I am guessing something is wrong with how you are reading PUNCH$ from the keyboard.

You could do something like: INPUT "WHAT WILL YOU DO" ; R$ : IF R$ =="P" OR R$ == "PUNCH" THEN ... If you just want to pull in keystrokes without waiting on INPUT try looking at INKEY$.

Hopefully the attached helps. You want to show or hide the sprite based on if it should be on screen or not. When it is on screen its location is relative to what part of the background you have moved to.

If you go to atariarchives the book creating adventure games on your computer has a some text adventure games. I got werewolf and wanderer working. usborne books has some 80s type in adventure games you could try converting too. I am currently working on the mystery of silver mountain. Write your own adventure programs for your microcomputer looks promising too. Good luck.

Finally part 4 showing usage. If you want a download, Q34443GD has a file called PLATFORM, with a slightly earlier version of that code in it.

Part 3 of my map loading code

Part two of my map loading code

Part one of the code I use to load maps

on lines 15 and 16 you need to check if the result is "A" or "B". The repeat should be before the input so you loop until you get a valid response. Don't want then player sending garbage to your code.

To transform from world to screen subtract the background offset from the world location. Then show/hide depending if its screen coordinates are on screen or not. You have to keep track of world coordinates separately. Same thing goes for the player sprite except set background offset relative to their position (bgofs the background layers when changed too). Then draw at its screen coordinates.

It sounds like you may be having problems with world versus screen coordinates. For a single screen game they are the same but when you have a scrolling world you have to map one to the other. In slimebump2 I have bgofsx%, and bgofsy% that are the x, and y pixel offset that the top left corner of the screen is from the top left of the map. To transform from world to screen coordinates subtract

Q34443GD has my samples folder. Inside is a file called platform which is a primitive Super Mario work alike. You may want to look at that and slimebump2. They have lots of comments but are quite lengthy. I hope that helps.

I think you want something like the attached. Unless you are doing something fancy like button presses or menu selections.

#A, and #B are constants used to check bit flags from the Button() command. Button() and #A for instance will be 0 if [A] is not pressed and a non zero value otherwise. So you want a different variable like say ret$. The other problem is you are asking users to type in two values. You don't want that. Instead ask for one variable then check that against "A" or "B" to get the right course of action

Attached is my circle pad demo. If the sprite moves to slow you can multiply the result by a scaling factor, I like 3 myself.

Here is some code I made to draw a saved image to the screen. Is that the sort of thing you are looking for? Oh and that while 4 loop looks like it is going to cause you problems. Is an infinite loop intended?

Thanks, I was hoping people would use the platform demo code as a basis for new games, so if it helps make you game better, I certainly don't mind. I have some sprite collision in slime bump and slime bump 2 in the same samples folder hopefully that helps. Now a days I like to put sprite handling in a callback function and have it handle itself. I probably just fill a local x%, y% in the handler.