Hello again everyone! Today I'll be going over how the camera is handled in The Manse on Soracca. There will be some minor spoilers, so if you haven't picked up and played my latest game, you can do so at https://moonmuse.itch.io/tmos! I'd recommend playing for a little bit so you have a better understanding the mechanics we will be diving into today.

In TMOS, players move from room to room by simply walking into the edge of the screen. If you've used GMS2 before, you may assume that these are all discreet 'Rooms' or 'Scenes'. But, if you've played TMOS, you'll know that certain.. entities can follow you from screen to screen. If these were discreet rooms (that is to say, if they weren't one continuous space), it would be very difficult to accurately have these entities follow and track your position. So, one can deduce that each floor in the Manse is one connected space.

Here's a zoomed-out view of the first floor of the Manse (pay no mind to the colored boxes right now, we'll get to them later)

Players start in the bottom-center cell of the map, the Entry Hall. If you look closely, you'll see a black gap to the north. This gap separates the Entry Hall from The Foyer (the room with the red circular rug). Let's take a closer look and see what's going on between those two rooms.

At the very edge of the screens, you'll notice two long, pale yellow rectangles. These are "Move Zones", a type of game object that I have classified as a 'Zone'. I use Zones to dictate certain actions that happen when the player comes in contact with them. On this screen, you can also see blue "Inspect Zones" and red "Dangerous Event Zones", but we're not here to talk about those today.

So, when a player reaches the edge of a screen, they will collide with one of these Move Zones. What happens then?

The game runs the scr_changeRoom script, a script that handles the data that needs to be passed along to various game objects as players move from room to room. The arguments passed to this script are set in the game objects 'Creation Code' for each individual instance. Note, this is not set up in the 'Create Event', as that means you would need to create a different object for each transition (which would be patently insane).

Let's break down this script. It takes five arguments. Arguments 0 and 1 are the coordinates for where the camera object needs to move. The basic code for my camera is simple, but it's a bit cluttered with effect code, so I won't confuse you with that. Just know that the step event basically says

Argument 2 is "Move Type". This argument dictates which direction the player is moving. Remember those black spaces between rooms? This argument tells the game which way to shunt the player so they pass straight over those rooms. Without this, the player would simply walk into darkness, then hit the next Move Zone and send the camera back to where it started. Not good.

Cases 0-3 are used for basic movement. Case 4 is used for fringe scenarios where I need to move the player out in to the void so they are neither visible nor trackable by monst-- er, tenants of the Manse.

Arguments 3 and 4 are used for data management. Argument 3 feeds a string to the GUI that displays the new room you're in. This displays in the top left of the GUI along with the floor name. Argument 4 is feed to the Position Manager, a data well that is used for tracking your position on a numeric level so that data can be easily accessed by.. things. Events. Nothing suspicious or dangerous.

All of this culminates in a clean, smooth room transition. But, what if I need to move the player somewhere that isn't within a few pixels? What if, say, I miscalculated and made this floor a particular size, used magic numbers like a fool, and now I need just one more little room to the north? Well, I'd have to put that room somewhere else in the world, but not directly adjacent to the room it should be next to in the game space.

Well, obj_moveZone doesn't allow this kind of movement. So, I made another one, but this time it's more adaptable. "Move Zone Ext" is how I handled these kinds of scenarios.

This is a simple iteration on the scr_changeRoom function. Instead of feeding a direction to move the player (as we did with Argument 2 of the original script) we give the game specific coordinates to translate the player's position.

Now, why don't I use this for all movement functions? It's simple: most of the time, I don't care about changing both x & y. Simply pushing the player in one direction is enough, and any more would be an over-engineered solution.

This concludes this week's devlog! Let me know if there's anything you would like me to elaborate on or other topics you would like to see in the future. If you haven't already, please consider supporting my work by picking up a copy of The Manse on Soracca on my Itch page at https://moonmuse.itch.io/tmos. Any support is greatly appreciated, even simple comments mean a lot to me!

See you next week!