Solo Indie Developer


RTX Sweeper is a puzzle game build on the core foundations of Minesweeper with the same rule sets as the popular versions of Minesweeper. This includes highlighting adjacent tiles, planting flags and of course a fancy timer. This absolute bomb of a Minesweeper game takes place in stunning environments, yes, even without ray tracing.




Puzzle, Indie




At my university I learned a lot of new and practical things that I wanted to make use of. I wanted to improve my skills by setting challenges for myself to keep me both motivated and excited for get familiar with different technologies.

In the past I have spent countless hours playing puzzle games with a good friend. She eventually suggested me to create my own Minesweeper, since we wanted more than the available games had to offer. I accepted this as a challenge for myself as well as a learning experience. Besides it had been years since I published a title. 

With this new concept of a project I had a couple of challenges in mind: don't deviate from the core fundamentals of Minesweeper, the entire game must be playable with only the left mouse button (other keys are optional), I have to make use of design patterns I recently got familiar with, and I have to use Unity tools that I am unfamiliar with.

This gave birth to my first iteration on Minesweeper. Minesweeper 3D. This is the basic Minesweeper with another dimension added to it. For this to work I had to create and understand the 2D version first. My end goal at the time was to create 3D Sweeper. 


In version 0.3 I had the first 2D version of Minesweeper fully operational. This was based on the design documents of various popular Minesweeper games such as Minesweeper Online. In this version I had bombs, timer, flags, tiles, mass revealing, and revealing adjacent tiles. The algorithm I had written also did a good job at spreading out the bombs, so I was quite happy with this. In return I mapped this to a third dimension by simply creating the grid in 3 axis: x, y, and z. The rulesets did not change, I just had to write a simple different orientation method. This gave birth to my InputManager.

Development wise I had implemented my first version of an Eventsystem. At this point I had never really used generics, so instead I wrote an object class that stored data, which I then used to pass as an argument for functions that required something. 

In combination with a Dictionary I managed to build an simple method that allows you to easily assign keybinds to Event calls. Best of all, the binds can be easily mapped. You can see the class over here. The basic setup is quite low level. The EventType is just an enum collection used for invoking methods in the EventSystem.

The EventSystem itself has had many iterations and the one in this link is the most recent version of it. This version uses generics in order to make it more abstract and easier to use. Now I only pass data that is actually required instead of a bunch of data.

The EventSystem is the core of my game and pretty much any project I work in these days. The generic setup and ease of use allows me to tie as many actions as I want to specific events. I have reused and improved this many times. In for example Project Hybrid we used my EventSystem to tie various factors to it. This resulted in a fantastic arcade shooter game where the 3 developers (me included) knew what our own code did, but not the code of the others. We did know the results, but not the technical setup. This kind of freedom is what allowed us to make such a large scale project in a short time. More about that on the page of Into the Deep.


3d sweeper 2d 1.png
Prototype / Version 0.1
3d sweeper 2d.png
Version 0.3
3d sweeper 3d.png
Version 0.5


At version 0.55 I felt that it was time to purchase assets. I implemented an asset pack from the asset store for most of the 3D models.

At this point I had done a lot of playtests and brainstorm sessions about what I wanted to add. This is where I decided to create RTX Sweeper. An over the top take on Minesweeper featuring modern technologies such as Ray Tracing. Something I had never tried before. 

The first most important thing was to make the experience more cinematic and more immersive. I did this during the Visual Cinematic Development course at my university. The video shows the tutorial walk through. At this point I was going for a first person player kind-off Minesweeper experience. 

It just didn't feel smooth or okay for this kind of puzzle so eventually I had to kill my darling and I went for the current "linear" movement. This however did allow me to learn about Cinemachine in order to make fancy animations. 

I had written a simple tool that allowed me to pick different dolly tracks for animations as well as how fast I want it to play. In future projects I expanded this simple tool into something that designers could use as well. More about it can be found in Project Hybrid (Into the Deep). After this my focus was on publishing the game on Itch.io as it had grown a lot bigger than I initially anticipated. I had fantastic plans for it as well. A story mode was already there, but I wanted a boss battle as well!

After having implemented the basic necessities I wanted to play test the game excessively. This resulted in weeks of play testing in order to gather as much feedback as I could. This also gave me the evidence that I needed for my game to be intuitive, easy to understand, playable, and stable.

Around version 0.7 I wanted to try something new. I have never worked with data encryption. I did make save and load systems in the past, but never anything that had to go through encryption and decryption. Since this game will become competitive with high scores and a leader board I do want to make it as hard as I can for the average Joe to tamper with the save files.  

Due to this I did some research in various encryption methods and I  how I can utilize them in my own project. My first few attempts resulted in a lot inconsistencies. This was because I didn't properly encode my date before encrypting. When I used Base64 everything seemed to be working properly. I still think that my take on encryption can be a lot more efficient as it is currently done in a couple heavy steps. I settled with using a simple version of AES for encryption in order to build some experience with this.

The first step decrypts a save file. After that it reads the data and updates the data accordingly. 

After the update it stores the new in the save file and finally it encrypts the save file. 

I also wanted to thank the people that have helped me with feedback, customized assets (for free!) etc. For them I made various easter eggs hidden in the game on top of adding them to the credits. The boss fight puzzle for example was an idea from back in november 2021 when I was brainstorming with a friend. For him I created an easter egg fitting his interests in that area. 

After everything came together I had achieved version 1.0. This is the starting version on Steam and the final version on Itch. After 1.0 I will implement Steam specific features such as achievements and more. But this is all for the future.

The final addition to version 1.0 was Ray Tracing. I will be covering this in the next section.





My game is called RTX Sweeper and up to this point it still didn't have ray tracing in it. It doesn't matter if it is optimized or not, I just want to make use of a new technology. This is because in the future it will be a more common thing to work on and to understand the concept of ray tracing might help me out for future projects. 

Since I have already experience with Post Processing and HDRP the entry level for me with ray tracing was quite low. In Unity it are simply just some extra volume options that you get with for example the ambient occlusion due to the different light calculations. 

You also get access to new stacks for the volume that are only available when ray tracing is enabled. 

The first time I had ray tracing fully functional with all the settings tweaked I was really blown away by how easy it was to implement as well as the results. There was color bleeding, incredibly smooth reflections, extremely realistic shadows and so much more! I wanted to share this little moment of joy with Reddit and as you can see people were quite enthusiastic about it. I also received UI related feedback, but I was blown away by the positivity of the community. Within 24 hours I had more than 20k views! I saw my post being shared and I was at a loss for words. 

After testing my build in DirectX12 I noticed a massive flaw. Since it was still experimental I knew that there might be issues, but I had the issue where the game didn't calculate any light data in full screen. In windowed everything worked flawlessly. I did post on the forums about it, however there are no solutions to it yet, since it is extremely specific without any errors thrown. 

I did create some work around methods to it which I hope to release in the next update after some more testing. These should allow people on DirectX12 to play in the game in full screen without it crashing or not calculating light data. I also hope to address the issue where the memory of the graphics card causes artifacts when there isn't enough memory available. As pretty as ray tracing is... it does bring a whole set of new issues with it.

The final image shows the menu in it's final stage. The menu aesthetics are based on the progress of the player throughout the worlds.