Fuxi Game Jam, Autumn 2023 - Cannons of the Great Revolution

Day #1 - 6.10.2023

The theme was announced and we begun to plan.
We first had ideas related to dance dance revolution, or some kind revolution aftermath simulator, however eventually we settled on something else.
The final idea was a game similar to angry birds and mechanically fairly uninspired, but with a hidden story about one of the developers "revolting" against another who took control of the project and "ruined it."
We wanted the game to feature intentional "bugs" which showcase how the project started degrading after the developer took authoritarian control over the project.

Once the planning was concluded, we got to work. Jesper and Ville beginning to create demo assets, whilst I programmed the initial "sling functionality" for the cannon.

Day #2 - 7.10.2023

On the next day I got right back to work, at first fixing a couple issues one of the other participants had caused.
The main features added on this day by me were: level selection, "glitch levels", ammo count, enemies, an indicator for the force youre firing with, and implemented the assets provided by my companions.

Day #3 - 8.10.2023

On the final day I mostly worked on fixing bugs with the level selector and making new stages, although I also utilized a shader asset I'd previously purchased to create more visually strange environments for the "glitch levels."
Aside from that I made a couple visual assets to spice up what the other developers had done, such as the background "grid" effect, and I of course implemented their visuals and created the particles which we still needed.

On the final hour we had issues trying to export the project, but thankfully one of the tutors managed to solve the issue, and we managed to export and send it in time.

Because in the game we wanted to have "glitched" levels appear when you perform certain actions, the way we decided to handle it was to have a public string called "whatToDoAtEnd"
The way it functions is that at certain times, the game sends a managementSignal to see what to do next. If what to do next is not empty, it looks through a list of if/else statements to see what it should do.
For example if whatToDoAtEnd equals "ResetScene" it simply reloads the current scene.

This system combined with another public string "lastBug" which keeps track of what the last "bug" the player encountered allows us to trigger events under very specific conditions.
For example, one of the bugged levels in the game shows up after you beat the first stage for the first time. When you do the game appears to give an error and reset back to menu. However if you now try to replay the stage, lastBug would be set to "TutorialGlitch" which means that instead of loading the actual tutorial it loads a glitched version of it.
Then once you complete the glitched version, it performs "returnToMenuReset" which resets the current bugs to null and allows unlocking the next stage.

It should also be noted, this manager script is always kept open as a seperate additive scene, which allows it to retain values and other useful functions regardless of the current scene.

Though the entire script is too long to include, I figured I would also describe how the cannon's firing is handled.
In essence the cannon ball is an invisible kinematic rigidbody, that instantly attaches itself to an invisible spot at the end of the cannon's pipe.
When you click on the star rendered over the invisible cannin ball, it starts tracking your mouse location and moves the cannon ball to it.
Once you let go of your mouse, it then proceeds to turn the rigidbody into a dynamic one, and since the joint instantly tries to pull the cannon ball toward it, the cannon ball launches at high speeds toward it, but once the distance is short enough the script destroys the joint while maintaining it's current velocity.
As the joint breaks, it also turns the cannon ball visible and hides the star, and without the joint the ball is able to fly free with unity's built in physics handling the rest.

All sounds of the game are handled through this simple script. It simply has a public function which receives an audioclip and then through PlayClipAtPoint plays it.
This method is admittedly inefficient, mostly since other scripts contantly need to do expensive operations to send files to it, however under the limited time of the Game Jam, we decided it was worth more to pay this cost in performance to save time and gain benefits from it's flexibility and easy to understand nature.