The purpose of this document is to conceptualise and store any ideas regarding the mechanic. This includes sketches, notes, moodboard etc that may become useful in the development and iteration process.
The main gist of the mechanic is to do with a sort of colour manipulation/control. All objects with a corresponding lens will disappear for the player once the lens has been enabled.
Rough representation of the lens functionality.
As shown, for example, if the red lens is enabled then any/all objects that are also red will both be invisible and their collisions will be disabled.
Only one lense can be put on at a time, and when lenses are switched, then objects that were previously invisible, will be instantiated into the world once more.
With objects appearing and disappearing (being deactivated as a whole), the gameworld can be interacted with in a number of different ways. With core features being implemented, it would really come down to puzzle/level design on how the mechanic is utilised.
Visual representation of possible utilisations.
The above image depicts different possible ways the mechanic could be used to interact with the world (these illustrations are not representative of the features that may or may not be implemented) - From blocking paths to more complex puzzle design.
In this prototype, the mechanic will be controlled via a UI screen accessed under a comfortable (quick access) button on the keyboard. The UI piece will consist of buttons that will each have direct control over elements tagged in their respective colour i.e Red button will enable/disable blocks that are tagged as 'red' in the scene. It will not be possible to disable 2 or more colours at once. If the player disables red for example, and then switches off a different colour - then red will come online automatically (restrictions will be put in place to only interact with 1 colour at once). Blocks that correspond to the colour that has been selected will either disappear and have their collisions disable or appear and collisions will be enabled respectively.
Blocks can be assorted into prefabs with the script pre-assigned. This means that afterwards puzzle design will become easy (essentially plug and play). Any engine functionality that does not require any new code being implemented will be able to work coherently with the prefabs without any redesign (speculative, this may not be true, requires testing).
The Lens mechanic could be used in a wide range of scopes. It could either be utilised as a main focus (similar to that of some games I have used as inspiration). Or, it could be used in game with a much larger scope, as one of the many tools that the player would have access to, working along side other mechanics such as shooting etc. **Once again Im putting an emphasis on the 'tool' aspect of the mechanic.
The intention or world interaction of the mechanic can also vary. For example, it may be used to control the terrain around the player to their advantage if the game is combat focussed (something similar to that of Half Life's gravity guns). However, my intention is to use it for exploration and challenge. Primarily through various puzzle designs that commit the player to think of certain solution through visual feedback i.e distinct colours.
The main Issue that I speculate could occur, that would impact the mechanic overall is the way its controlled. As planned, the ideal control system I have in mind would be through a interactive UI system. However, without proper testing it is unclear if such a solution would be 'comfortable' or egonomic. Although (from research) such a system has been proven to work i.e in Crysis 1, while controlling the 'Nanosuits' different abilities. However, if in my prototype, it proves to be 'awkward' A potential solution would be to use a simple keyboard/mouse input system. In a game with a larger scope, this would have to be further reconsider to avoid confusion between other mechanics.