
TheDL
Winters Rush
Grade Achieved: First

Aims and Objectives: The aim of ‘Winters Rush’ is to get to the end of the course before the other 9 people get to the end first. You are pitted against 9 people (10 in total) and it is a race to the finish line. Once the first two people get to the end of the course, the bridge collapses and a 1v1 fight starts! Once the bridge has collapsed, the final two players must compete to push each other off the edge of the final arena, whoever knocks their opponent off the edge first is the winner. There are three main parts to the course, the Ice blocks stage, the Sliding Wall stage, and the pendulum stage.
Mechanics:
The ice block stage is a simple jumping puzzle. There are multiple ice blocks scattered around the area, the player must plan a route and cross all of the ice blocks to reach the other side. However, the player must also avoid the enemy players trying to push them off the ice blocks, and once a block has been touched by players three times, it is destroyed. This allowed us to implement some interesting player interaction, we wanted the start of the game to be a real cluster of action, to show the player that this is a game that is full of spirit and enthusiasm, from the get go the player is thrown into the action. Since the players are all confined to certain routes to clear the ice blocks, there will be a high level of involvement between players.
The Sliding Wall stage is the second stage that is presented. This seems like it should be the easiest of the three stages, lulling the player into a false sense of security. What seems like a simple timing puzzle becomes a lot harder once the element of player pushing is introduced. Players must walk past the multitude of walls that are moving, trying to knock the player into the water. All three stages has ramps out of the water so that you are able to try the stage as many times as needed, the player just needs to make sure they’re one of the first two across the finish line. We implemented the ramps into the stages, as it did not feel fun to attempt a stage, fail, and have to sit there for X amount of time while everyone else passed the stage and continued on.
The Pendulum stage is the hardest of the three, implementing a multitude of swinging pendulums that aim to knock the player flying off the course. Originally this was the only part of the obstacle, however this ended up playing out similar to the Sliding Wall stage. All the player had to do was check for timing, and then cross the bridge when they had found a safe gap to pass. Since this was meant to be the final obstacle, we wanted something a bit more challenging, and also a lot more chaotic. Because of this, we implemented a slowing field on the floor as you pass through the pendulums, slowing the player down to a crawl as they try and clear the objectives. With this, suddenly the obstacle was much more enjoyable, it was also more distinctive as a solo puzzle rather than feeling like an extension of the last puzzle. The player no longer can sit and plan their route, then go and attempt the puzzle, as the slowing zone made it far harder to analyse how your path would go. Instead, the players are encouraged to attempt the puzzle multiple times, especially as other players pushing you will eliminate any proper planning the player attempts. The ramps the attempt the puzzles multiple times were a great feature here, normally this puzzle would have been very frustrating if you could only give it once attempt. However, with the ramps we could lean into killing the player more often. We found test players really enjoying the pendulum stage, finding a lot of fun coming from getting sent flying off the stage from the hazard, and if we had more time we would have liked to have implemented ragdoll physics for when you are knocked off by the pendulum, to add to the fun of getting hit.
Basic Rules:
There are very few rules in ‘Winter’s Rush’. The game was created to emulate the crazy chaos you might find on the playground, and including many rules and restrictions took away from this feeling of chaotic fun.
There are 10 players pitted against each other. Two of them must clear the course first and get to the end stage. Once two players have crossed the final bridge, it will collapse, leaving the two players to fight off in a sumo-style 1v1. The winner is the first player who knocks their opponent off the stage. You are able to attempt getting to the end stage any way you see fit, the only rule is to not be last!
Gameplay:
From the main menu, the players are taken to a main menu. The menu is controlled by the mouse, clicking play will launch the game, and quit to exit. Once play has been launched, the game opens up to will be able to choose their names, where they will be then placed in a lobby with 10 people, there they will be able to choose their colours using the C key.
Once all players are ready, the game will soon start. The game has a straight path layout, consisting of many obstacles the players have to face in order to get to the end. The player is able to walk and jump only, and upon reaching the end zone, pushing too.
Some mechanics of the game consist of: Moving Objects, Destroyable ice, Swinging Pendulums and Snow that slows the player down.
Upon falling off the platforms, the player will be able to rejoin the game by going back to the beginning of the current obstacle they are facing.



Proudest Moment of the Project:
Colour changing was a very tough task that I encountered. The first way that I tried to incorporate colour changing into the game was through the use of the skinned mesh rendered attached to the santa model. I loaded the renderer with 4 additional materials that I created in Paint3D. I set up an array of different materials to be used, and set the active material to new Material[1], however I found that this did not change the active colour. I tried to create new textures to change them instead of the material, but this also bore no fruit. I tried the skinned mesh renderer, and also attached my own renderer to see if that would change the colour, but that also did not work. Since this section of the work was my job, I was reluctant to ask my group for help, so I sat down with Tom, the class assistant, during one of the lectures, and we tried to work on it together. After being sat for the better part of two hours, we found that we could not get this to work at all. He suggested I find a different approach to changing colours, so I created the version that is in the final game.
I am not completely happy with the colour changing code as it is, I would have rather got the initial renderer way working. The current iteration of skin changing consumes more resources than I would like, as it has to render all 4 skins, and enable and disable them each time the skin change button is set. However, I am very glad that I got a version working in the final project, and am proud that I found a way around the initial problem.