The opening screen. The entire game was made with the limited 2-bit b4sement palette.
The draggable window mechanic in action.
Screen-Crossed Lovers is a 2d singleplayer sokoban puzzle game made in Godot, where the player moves around and resizes a pair of computer windows to push blocks between them.
The game was made in 96 hours for the 2024 GMTK Game Jam, where the theme was BUILT TO SCALE. This led me to thinking about relative scale, and the idea of changing the size of two worlds to manipulate the size of objects going between them, which felt like it would work great as a sokoban puzzler.
Aside from some friends helping with sound, I created this game entirely solo, handling design, level design, code and art.
The game's final community rankings in the jam, all results out of 7620. It got a lot of praise in the comments!
I've struggled with overscoping for the GMTK Jam before, so I wanted to make something simple, a single system, with a lot of depth and room for expansion. I also wanted to test my level design skills in 2D.
I thought that intentional limitation would be a great way to do this: it's just two 4x4 sokoban grids, which you can move around, and each edge can be full size or half size. Crates can pass between the grids, but each grid has its own player, and they can't pass between.
This system alone took me a couple days to code (mouse controls continue to be my enemy), but I was repeatedly sending out sandbox builds to friends to get feedback. The win condition for each level was the last thing I designed: I tried out four different possibilities, but decided that needing to get particular green 'victory crates' to fill marked spaces was the most interesting task for this system.
Once code was mostly finished, I built a proper test level and playtested it with a lot of people before continuing - this level proved very difficult, and I realised that the system required the player to do some really weird lateral thinking to navigate it: resizing worlds feels very unfamiliar. I knew that I had to introduce and teach the system slowly.
I built an ordered list of every quirk of the system, and figured out how and when to teach them to the player in a sequence of levels, with some puzzles to test them every few levels. I really enjoyed doing level design for this game, but it ended up harder to make the easy levels! I made sure to playtest my levels often, and things I expected to only require 20 seconds of thinking could take minutes. At the end of the jam, the game had 7 complete levels, including the tutorial levels.
My schedule for the jam timeframe.
Planning out the sequence of levels, and what parts of the system to teach the player in what order.
The rescaling mechanic in action.
The final level. How would you solve this?
I'm overall very satisfied with this game: I think it's sharply presented, interesting and unique. I really like some of the puzzles I've made, and the 'a-ha' moments they inspire. This is definitely the most polished video game I've made yet, and I'm really happy with how much I got done in 96 hours.
It's definitely not a game for everyone, however. It still ended up harder than expected, and though some players pushed through and really enjoyed getting to know the system, others bounced off the early levels and didn't get to see the game's depth. The mouse controls also remain fiddly and awkward.
I should have slowed the difficulty curve with more levels to teach things more gradually, rather than teaching multiple things per level, and tested those small pieces of understanding more regularly. A level select screen would have also worked great, allowing players to jump to more difficult puzzles to explore the full depth of the game, or skip puzzles they're stuck on.
However, I think with more time and more tweaks, this could be really strong. I've already been building a library of ideas for more levels and twists, and I'm hoping to, at some point, spend another month or so seeing where I can take it.
