Radix prison was a portal inspired puzzle game with a set of puzzle rooms with modular components such as lasers, crates, pressure plates, and robot guards that would shoot laser bullets. the aim of the game was to complete the objectives pushing crates onto pressure plates and diverting lasers and defeating the warden to escape the prison.
Barely two levels were completed of the planned 3 + boss fight, almost all features that were intended to be implemented were successfully made functional, apart from the boss fight, and the laser reflectors. Some of the features that were created were, crate pushing, lasers, pressure plates, laser receivers, crate breaking, metal crates, portal damage mechanics, guard turrets, debug screen (for developers), and the end level door.
The project wasn’t successful in being a game but it was a great learning experience. There are a few ideas I have about how I would code some mechanics differently to make new level creation more flexible. That would have the added benefit of being simpler than the original approach.
During development there were a million different ways that the crate pushing mechanic was done and re-done, as well as adjustments to the walk speed to make it work better. It was a piece of very finicky code that never worked sensibly, and it was a nightmare figuring out how to make it collide with the wall without the player sliding through it. After finding a magic inbuilt function that checked if the space was free and making the walls and crate solid by ticking a box the code magically worked. It’s pushing behavior never behaved though, and only worked after the tolerances for the pushing collision detectors were made so big it looked like the player was using telepathy to push it.
That wasn’t even the biggest challenge that was face during this project. The hardest thing to implement was the room completion code. Put simply the code that would detect when all the necessary conditions were met for the level to be considered complete and the door to open to the next level. I wanted the whole thing on my end to be like plug and play, I also didn’t really know any other way to make it at the time. I spent a few days or weeks trying to create a piece of code that would set two variables. one would be the number of objects in the room that had to be satisfied. The pressure plates, laser receivers, and or whatever else I made like that. The other variables was how many of them were satisfied. Pressure plates with crates on them, and laser receivers that were… well receiving lasers duhhh! those two variables would then be compared, if they were equal then the door would do a cool slow opening. This was simple in concept but was way harder to get working in practice. It was moderately easy finding the function that counted the number of instances of an object, the difficult thing was checking if they were happy, tragic I know. after a while I figured out a solution that didn’t spam the console, detecting the animation change within each instance. Getting that to work took a bit as well but when it worked I thought, hey what if I want two doors within one level? I proceeded to switch the polarity and realize the molecularity of my reality was not made of dreams. Because I had wasted too much time on getting that working.
If I were to start this project again I would try to pick up the pace, thought I enjoyed going at my own pace I would have gotten a lot less lost in problems and would have been more creative with solutions. I would also apply some new idea that I now have like the room completion code. Using wire sprites that carried the signal from each component toward their respective door, this should make the code simpler and would allow for that two doors idea I had earlier. I don’t know what I would do with the damn crate pushing system, hopefully developing it from the ground up will remove the weird inaccuracies that were in the hit boxes. Don’t just go thinking that I just “missed something”. I checked the code for the sizing like 12 times, If that code was steel bullet proof vest I wouldn’t wear it because it would act like liquid when I wasn’t looking.
If I were to start this project again I would try to pick up the pace, thought I enjoyed going at my own pace. I would have gotten a lot less lost in problems and would have been more creative with solutions. I would also apply some new idea that I now have like the room completion code. Using wire sprites that carried the signal from each component toward their respective door, this should make the code simpler and would allow for that two doors idea I had earlier. I don’t know what I would do with the damn crate pushing system, hopefully developing it from the ground up will remove the weird inaccuracies that were in the hit boxes. Don’t just go thinking that I just “missed something” I checked the code for the sizing like 12 times. If that code was steel bullet proof vest I wouldn’t wear it because it would act like liquid when I wasn’t looking.
Representation of collision boxes for the pushing code were supposed to look and act like. both boxes are the same size and line up with the boxes boundaries precisely (red is only bigger because of inaccurate drawing)
Player feeling damage. The screen would get more red with more damage and slowly fade away when the player wasn’t taking damage. If the screen got red enough the player would die and the level would reset.
Acknowledgements
Dev – suggestions for clarity in component animations to make their on and off states clearer to the player.
Project file
IF YOU ARE PLANNING ON PLAYING READ THIS
Pressing the number keys will disable the debug screen and they will also navigate levels and activate completion flags I would tell you which ones do what but I forgot, have fun.
You will also need a computer, this is not a board game.
