A cheeky little idea to make a chaotic physics based match 3 puzzle game for the holiday spirit, that turned into good fun and an unexpected highly competitive social event between the company, associates, clients, family and friends.
Development Highlights
During the development of this game I got a lot of freedom on how to approach the project. Other than the designs of the christmas ornaments and the UI, I was able to do all the game design myself, and develop everything to my own content.
I refined my personal post processing effects library during this project, which are all combined in a single pass fragment shader. Only using the depth buffer to create Depth of Field (DoF) and Ambient Occlusion (AO). Since this game was for the holidays, I decided to have the lens shutter for the DoF effect shaped like a 5 point star.
Next to this post process pass, I also did a single screen-space render pass with just the christmas ornaments as stencil masks using their solid colors. Then for each ornament material I wrote a custom shader that uses this rendered buffer to simulate reflections from surrounding objects using the surface normal as the direction the reflection is coming from. This worked surprisingly well without any complicated triangulation math. I used the same technique to create the reflection of the ornaments on the floor, by offsetting the screen space UV based on the angle of the floor plane.
Setting up the basic gameplay went pretty fast. It's just some simple 2D circle collision math, confined in a 2D rectangle. But as soon as people started play testing, a lot of small issues popped up.
Getting the right balance of chaos and control over the board, and proper difficulty pacing so games were not too long, took a while. But when it all finally clicked together, people at the office started to play it constantly, giving me a lot of data to improve things even more.
When everyone started to get really competitive, the request for a centralized high score board came soon after. I said that properly setting up a server to handle high scores is a lot of work, especially when it comes to security to prevent cheating. So initially I declined the ask. But after days of "relentless asking" from different people, I caved and gave it a shot.
I still had some rudimentary server side gameplay validation code somewhere. This code was rather simple and made for a game that had limited variables in gameplay. For this type of game I had to add a lot more checks and rules. Most of these rules needed some sort of flexibility percentage built in to account for edge cases. We did a lot of testing to find the right tolerances and overlap between rules to create a solid validation system that was hard to manipulate.
When a local game session starts, the game asks the server for an unique seed that is connected to the local session. This seed determines the order, color, size and spawn location of the balls. Then every time the player scores, the entire board layout, player actions, and miscellaneous gameplay data is saved to a data object.
At the end of the game, this game progress data object is sent to the server with the unique seed, and checked for data validity. The server replays the entire game and checks if the game is valid with the seed provided.
The server side game instance checks:
Progressed time per score compared to game time, shots fired and ball spawn rate
Angle and strength of shots and the difference between each shot
Positions of the balls based on their spawn time
Ball numbers match the seed and spawn time
Balls positions radii are in a acceptable distance from each other
A bunch of other critical stats and values that I keep hidden to avoid manipulation attempts 😉