>>718277084
>boundaries
Boundaries of what kind, may I ask? Camera bounds? World bounds? Bounding boxes for collision? Speaking of which...
>collisions
I'd suggest looking into AABB collisions. The idea is to create a rectangle structure (x, y, width, height) to represent bounding boxes, then check if they overlap (if the sides of one rectangle are inside the other). If they do, this means you've got a collision on your hands. The dumbest, simplest way to resolve collisions is to not move the player on the next frame if there is one when you're trying to move in a direction.
>screen change system
Do you mean like rooms in UT, or different screens for the different game states (eg. overworld, battle, title, special cutscenes)?
If it's the former, pretty much every room can be updated in the same way. The only thing that will be different are what game objects are in each room, so you'll need to store an array of your objects and update each one. The contents of this array will change depending on which room you're in, since each room will have different objects.
For the latter, what I did for one of my projects was have a variable that holds the current screen to update. Then in my main update loop, depending on the variable's value, I'd defer to a screen specific update loop (eg. UpdateOverworld, UpdateBattle, etc.)
This is just a crash course on the basic ideas from someone else who's still learning, but put together some basic prototypes in the past.
I learned most of what I know from looking at Raylib examples and a little bit of Lazy Foo's SDL tutorials. Now these are obviously tailored towards different languages and libraries, but if you're comfortable translating, they could serve as example implementations of these concepts.
Hope it makes sense, I'll try to answer any questions you might have