Lens Mechanic

One of the very first steps taken before jumping into a basic design phase, was to work around the blank page. I collated a small handful of mechanics from existing games that were of large interest to me.

• Crysis (Nanosuit)

• Driver: San Francisco (Shift)

• Mirrors Edge (Parkour)

• Snow Runner (Car switching)

Each one of the mechanics were loosely analysed in terms of their general aesthetics and connections to the overall gameplay, with personal and market annotations as to what made them interesting.

The anylsis was concluded by identifying the correlating factor between the mechanics which would function as a basis for further work.

The general reflective analysis can be found here: Link

Continuing with the same thought process, in order to narrow down the basic content and technical requirements of the mechanic, a brainstorm diagram was created. This identified that the general premise behind the system was to explore an analogue and intransitive approach to interacting with a 3D environment.

The use of MoSCoW technique assisted this.

At this stage, a major influence was the game 'Hue' which followed a similar basic premise of interacting with world through colours.

The final step of research before full design and development work began, was to create a general technical breakdown page of the same mechanics previously mentioned.

This time however the approach was much more structured and would focus on the technical aspect.

The following guidelines were used to assist the task of breaking systems down:

• What are the general controls of the mechanic, inputs etc?

• Use of MDA:

  • Mechanic - What are the rules of the system, actions that can be performed by the player?

  • Dynamic - What impact does the mechanic have on other game elements?

  • Aesthetic - What are the potential (or intended) emotional reactions of the player when interacting with the mechanic. Consider visual and game feedback systems through game-feel etc?

  • Implementation - Speculative breakdown of how these systems potentially function.

The purpose of this task was to create an understanding of the functionality and impact of these mechanics in a wider game context, which could be later referenced during development as a measure of success.

With all the required tools ready, the first step was to begin designing how my own system would function and what its general dynamics would be.

As identified, the mechanic was intended to make use of a switch-case Red Green Blue logic gate. When one lens is initialized, then the colours (objects) corresponding to it will disappear and those that dont will appear. A series of basic sketches were used to visualise the concept.

Subsequently, the design process would entail identifying all the components of the mechanic through enquiry led and open-ended questions such as: "How does it work?", "What is its purpose?" etc.

A similar process to the technical mechanic breakdown approach was used here. The mechanic underwent a pre-emptive MDA evaluation that would help solidify its function within a theoretical game concept.

Each one of these components was sketched out and expanded upon individually.

To get a more more in depth overview of the general mechanic design have a look at the following page.

Mechanic design page: Link

The implementation and development was largely iterative and heavily relied on informal player testing. Any and all issues that would occur would result in a reconsideration in the design and re-evaluation on how to go about solving them.

Initial steps were to create a basic functionality which on the press of a button disables and enables pre-fabs that correspond to the "lens" that's currently being iteracted with. Over time, this would expand into polish with elements of game-feel etc.

An example issue that began to occur was whenever game-feel elements in the form of gradual object fading were implemented, objects would not re-appear.

In order to fix this, I referred beck to my initial implementation designs and considered a lens object controller script. This way, a sort of lever system would enable and re-enable all objects based on rock-paper-scissor conditions. While not the most effeciently coded, it would insure that regardless of any future additions to the system it would always function.

In order to test the system, a small series of basic levels were created. Their intention was to insure that the mechanic not only works, but also to explore the practical application of the it in a game-like scenario. From the get-go, the system was designed with game-designers in mind. Puzzles/levels should be created without the need of any further implementation - a sort of plug and play.

Each level was initially sketched out, and later implemented in engine.

As the mechanic was being finalised, it was evaluated in the form of a post mortem video that went over the general design and reflected upon the things that worked and the things that didn't.

Additionally to the core design documentation, a large blog/progress diary was created that also made note of the entire development process less formally.

The blog can be found here: Link

As part of a self-development module, I wanted to addres my skill gaps of level design.

I decided that it would be a good opportunity to also further expand on my lens mechanic and test its potential in a much larger prototype.

Similarly, one my first steps before jumping into design was researching level design theory as well as looking at potentially related games in order to broaden my understanding of the topic.

Once again, a handful of games were analysed in regards to their level design - the games were selected based on their relatedness to my core mechanic.

The analysis page can be found here: Link

The theory research page can be found here: Link

Following the same train of thought, the next step was to begin creating a design repository.

Based on the functionality of my mechanic, the initial approach was to determine a general flow, intended player journey and premise for whatever the level was intended to provide.

The core idea was to create a false sense of freedom. The level would be semi-open, allowing the player to explore but ultimately be led to the same goal.

The implementation of the level was once again very much iterative, building out from a basic grey box to a more detailed map.

Play testing was utilised to particularly observe how players would navigate around the level and how they interacted with the mechanic within each puzzle. Based on comments, or observed emotional reactions - changes were made to accomodate.

In order to solidify the intended player journey, the following researched techniques were used:

• Signposting

• Landmarking

• Positive/Negative space

• Verticality

• Corridor Language

• Mixture of open and intimate spaces.

A major limitation of the mechanic was made clear during testing. As a lens was enabled ALL objects corresponding to that specific colour would disappear within the world. This meant that puzzles that the player hasn't reached yet were being interacted with.

The mechanic was updated in the form of localised trigger boxes. Only objects attached to a given proximity that the player is within will react to the mechanic.