Prism Rush has been released
Hello, this is Yuu!
As I mentioned in my previous post, there were some issues when submitting the game, but it was successfully featured in the online category of js13kGames.
Prism Rush
Collect as many gems as you can in 90 seconds! Lock on, chain nearby gems together, and release to capture them all at once.
This time, I’d like to look back on the game and talk about how it turned out.
The basic rule is simple: collect more gems than your opponent to win.
A real-time whack-a-mole game by itself wouldn’t be particularly interesting, so I added a few ideas, such as penalizing players for repeatedly pressing the button and allowing them to collect nearby gems as a combo.
While my first game was themed around “growth,” I wanted to focus more on competition with this one.
I didn’t have much time to fine-tune the game balance, but even when playing locally, I could win some matches and lose others, so I think I managed to capture the casual nature of the game fairly well.
Now, about the implementation. It’s been four days since I finished the submission, or about a week since I finished the game, so I’m already starting to forget some of the details.
The online implementation behind this concept isn’t the kind of authoritative online game where a server maintains the state of both players. Instead, it uses a P2P model. Because of that, it’s not possible to completely guarantee that players A and B will always see exactly the same result on their screens.
For that reason, it was important to eliminate random values as much as possible, minimize differences caused by the environment, and make sure that the same behavior could be reproduced mathematically from the same inputs.
For the online category, I was able to use Cloudflare’s relay servers. However, the values sent to the relay server are fairly simple, so I needed to make sure the game could reproduce its behavior using only those values.
This also led me to things like bit masks, as well as implementing edge detection for lock states and button press/release states.
Since this was an attempt to build an online game by myself, I wasn’t able to experiment enough with situations where both players had significant latency. In that sense, there was still a bit of a gamble involved in how well it would actually work.
I was also able to submit this game earlier than my previous one. Also, while my previous game was completely driven by ideas I personally wanted to make, this time I referred to several other games during development.
There was a game called Rainbow Rumble, and I used its code as a reference for the online implementation.
The idea of using the unicorn’s horn rather than moving the unicorn itself was also inspired by some of the other games featured in the competition.
Since this is a game jam, being able to actually use other entries as references was a refreshing experience.
On the other hand, the 13KB limitation meant that I couldn’t put as much effort into the UI as I would have liked, which was a little disappointing.
The amount of code increased compared to my previous game, so I split it into multiple files, but this time I didn’t compress the size as aggressively as I did last time. This means I still have enough room to make changes if I find any issues with the implementation.
That said, there isn’t enough room to add a significant amount of extra content, so I decided to skip the wavedash implementation this time.
Still, I do wonder whether I could have made a game I was truly satisfied with if I had been able to use sprites as much as I wanted.
Over the past month, I’ve managed to make two games under the 13KB limitation, for better or worse. But I can’t deny that I’m starting to feel like I’ve run out of ideas.