Getting users to initial play and return to a game is of utmost importance when the gameplay is either to continue progression to the end of an experience or short periods of play over long periods of time. It has been observed that there are two main motivation models that contrast from each other the initial operant conditioning, mainly Variable Interval Reinforcement discovered by Ferster and Skinner (1957) this method of giving rewards is unpredictable and due to this the user is more likely to check if they will be rewarded for their actions. Secondly the other motivation type is Self Determination Theory (SDT), this is an internal motivation type that does not rely on external rewards, but instead on the betterment of a skill, social status and the control of ones life (SDT) ...

There is potential within games to use the effects irrational judgement known as cognitive biases. This can allow for players to assign large amounts value to the work that they create within game spaces. It has been observed that humans share a cognitive bias that assigns disproportionate amount of value to objects they have made over ones they have purchased, known as the IKEA effect (Norton, Mochon and Ariely, 2012). Alongside this bias, it has been seen that humans outweigh negative effects such as losing objects or having them taking away from them in comparison to when humans make or find them. This is known as Loss Aversion (Tversky and Kahneman, 1992). ...

Project bounce is a endless game where the player must protect the heart at all costs as the difficulty ramps up. playable on itch.io Here:

PDF of the game design document for the game bauhaus Bauhaus_GDD We released the game Bauhaus on itch.io Here:

As the project is nearing a close we decided that it was time to make the games title interface this would consist of The title screen controls scene credits and a exit button A part of this that we wanted to make sure wasn’t jarring to the player was not being able to see all of the instant transitions to different scenes so we created a fade out controller that once it reaches a timer invokes a method changing the scenes once a scene is is loaded has a quick fade in ...

After we had created the simple UI Elements we began to create a more flexible system to handle more than just a few elements this allowed for more complex UI elements to be imbedded into the UI Soon after finishing the simple UI we began work on 2 separate parts of the UI firstly the system that explains to the player what age they are in and when you change to aiming it shows if you have any objects frozen in time ...

A few weeks have passed since the scene was first built, and the game is finally playable, with all of the prefab objects in a fully working condition. As well as this, tutorial/ side-puzzle zones have been added before and after each of the main puzzles. An additional object added to the scene was a dividing line between each puzzle, that cleared the player’s frozen objects. We added this as we thought going back to puzzles in order to unfreeze objects was not adding to the ludic experience, rather creating annoying and repetitive gameplay. The puzzles were finished, and the game was winnable, yet it was quite clear that the mechanics of the gameplay were still not fully expressed throughout UI elements, and this was the last stage to add before playtesting would happen. ...

A major concern that the both of us have been having at this point in the project is that the player will have no understanding what the inputs are in our game and we both agreed that a big block of text before the game starts explaining what the controls are is bad design so we tasked ourselves with creating a non intrusive user interface (UI) that will convey not only the controls of the game but also what the mechanics of the game are too. ...

A few weeks have passed since the scene was first built, and the game is finally playable, with all of the prefab objects in a fully working condition. As well as this, tutorial/ side-puzzle zones have been added before and after each of the main puzzles. An additional object added to the scene was a dividing line between each puzzle, that cleared the player’s frozen objects. We added this as we thought going back to puzzles in order to unfreeze objects was not adding to the ludic experience, rather creating annoying and repetitive gameplay. The puzzles were finished, and the game was winnable, yet it was quite clear that the mechanics of the gameplay were still not fully expressed throughout UI elements, and this was the last stage to add before playtesting would happen. ...

After Finalizing our designs for the puzzles, we took them from the whiteboard to the scene. With a range of prefab objects, including bridges, boxes and buttons , we assembled the first layout in Unity, for Project Red. For now, not all of the levels are playable, as the prefab objects do not have all of their functionality, i.e. being able to be frozen in time. From here scripts will be added, and variables will be tweaked in order to make the levels playable. In the meantime, tutorial-style and inbetween puzzles will be added in mid-sections, in order to assist with player learning, but also to fill the scene. ...