Tech: Split screen merging in DYO

As you might know, I'm currently working on a game called DYO, where the main game mechanic is merging two halves of a split screen together at will to manipulate the level's geometry. Which looks something like this:

Merging and splitting screens in DYO

The first thing people from a programming background tend to ask about is how the screen merging actually works. So that's what I'm going to talk about in this post.

Choosing an approach

So when I started prototyping this mechanic, the first essential question was how to conceptionally approach merging the screens. I knew what I wanted to happen on screen, but what should happen behind the scenes when the screens were merged?

I could think of two options:

- Actually temporarily merging the level geometry
which I imagined to be the cleaner and more versatile solution, but would require a lot of work up-front

or

- Having players "teleport" between the two screens each time they cross the border
which would be easier to implement, but might also offer less possibilities

Long story short, I went with the teleporting approach. Not because of laziness (at least not primarily), but because I wanted to have a playable prototype as quickly as possible, so we could see if the mechanic would even offer interesting gameplay possibilities. DYO was originally intended to only be a one-month project and I didn't want to waste too much of that time before we even knew if the concept worked or not.

In retrospect, I think it was a good decision. I had a rough prototype working in a day, which allowed the team to start refining the concept and working on assets pretty early on.

This is what a merged screen looks like ingame

And here is the actual level layout behind it

Handling colliders

The main problem with the teleportation approach was properly handling collision detection when players approached the screen border. Simply teleporting the player as soon as they crossed the border only worked as long as there were no walls near the split screen border. There were two main cases I had to account for: 

Two possible collisions that complicated teleportation

- Ignoring collisions that were outside of the camera viewport (1)
In the example in the picture, the highlighted collision has to be ignored, otherwise the player wouldn't be able to walk across the screen border.

- Predicting collisions that would happen after a teleport (2)
Before letting the player getting as far as to teleport, I had to make sure the space he would teleport to would even be free. Otherwise he'd be stuck in the terrain upon doing so. (Or, like in this example, he wouldn't be able to stand on certain ledges)

At first I tried to just hard-code exceptions for both of these cases (once again trying to save some time with a messy solution), but that really didn't work out very well. Especially once we started to introduce pushing and other more complex mechanics. In the end I went with the probably most obvious solution of using two seperate colliders as soon as the player started to intersect with the screen border and scaling them according to the player's position.

The most straight-forward solution: two colliders

This approach worked out fairly well. I had written all of the collision handling from scratch anyway, which made it a lot easier to implement this dual-collider setup. 

I feel like going into any more detail on the topic would probably not be all that interesting, so I'm going to leave it at that. If you have any more specific questions, feel free to contact me. Also, if you want, let me know what you thought about this post and if it was interesting to you. I don't usually post about tech stuff and I'm honestly still a bit unsure about how to approach these properly.

Cheers.