I mean you will have to be more specific than that but if you figured out the scroll I would start with doing some rnd() calls when you wnat a obj and then using that for the cord.

EDIT:
So I guess a timer and then have it be at the time you want and then do rnd() stuffs

t+=1

if t%60==1 and t~=1 then

 local o={x=flr(rnd(16))*4, y=136}
 add(actor,o)

end

 -- later draw it and make o move towards player? IDK. just some ideas.

I mean if these are rocks it would be cool if you could jump on them and move around?
IDK there's so many ways you could do it, good luck and please ask questions about smaller parts of it!

Thanks for the ideas! I really appreciate it and I'll try to implement something like that. My game idea is that you start off on some clouds in the sky and drop down to earth and on your way you have to maneuver around objects and collect hearts on your way down to earth. I was also planning on going back up once you reached earth. So overall that's my game idea. I wasn't planning on the objects to move towards the player on the way down, but on the way back up there would be enemies that would.

Lots of ideas here: https://trasevol.dog/2017/03/07/doodle-insights-7-step-by-step-procgen/

https://www.lexaloffle.com/bbs/cart_info.php?cid=falling_angel-4
Hey thanks for the feedback. I finished the prototype of my game if any of you guys wanna see what I came up with. It's definitely very flawed, but if anyone wants to give it a shot please go for it :)

Here are some of my thoughts on movement:

Vertical movement seems counterintuitive and out of place. If I'm falling I expect the view to be following me such that the protagonist is reasonably within the viewport. I personally would scrap vertical movement alltogether, but if you want it it shouldn't be so fast, maybe decrease the cap on vertical speed or just reduce acceleration. Currently it feels more like a flappy bird than a falling game.

Horizontal movement also feels off. It seems like when I press the button I move a certain amount sideways, but there is no grid so it doesn't make much sense. You should DEFINITELY change btnp() for btn() on sideways movement, you want to move when the player is pressing the button, not just in the moment it is pressed, and if you decrease sideways acceleration and increase sideways friction it would make for a much more precise control scheme.

I also feel like the enemies are kinda hectic, but that may be just me being bad at games. Keep up the work.

EDIT: I played around with your code and I feel much more in control of my character after changing sideways acceleration to 1 and replacing btnp() with btn() on sideways movement. I also advise you change gravity to .2 and decrease the "fall" button acceleration since it has a lot of impact anyway due to gravity helping it. Another thing you might consider is that some games don't accelerate on jump but set a certain speed upwards. It means that the jump will have the same effect wether the player was falling, stalling or already going up.

Enemies aren't as hard as I thought when controls are responsive, especially with the heart pickups.

You should embed the game in the original post so that it's easier to try it out.

@olus2000 Thanks for taking to the time to write out all your thoughts on the game, especially the movement. I didn't even know about that btn() vs btnp() thing. It definitely makes the game feel a lot smoother movement wise. I'm gonna keep playing around with the numbers and see what feels best.

They can definitely be a little hectic with some of the randomness involved. Sometimes they'll stack up and form giant walls which looks a little jarring and can be difficult to maneuver around, but that's it.

I'll post an updated version when I make some more progress. Thanks again.