Eye of the Erime
What I Did
- Designed and implemented the tutorial
- Led the settings and accessibility options for the game
- Led external playtest data gathering and deciphering
- Designed the plantable flowers and planter spots
- Created all UI layouts, including the majority of its functionality
- Chose and implemented each colorblindness option
- Created and implemented functionality for custom controls
- Created and implemented player HUD elements
- Helped puzzle designers test puzzles for user experience and player communication
- Provided feedback on puzzles and level design that needed improvements to user experience and player communication
- Playtested each puzzle and assessed their level of challenge at each point in the game
- Chose the default controls layout for both keyboard and controller
- Wrote, discussed, and maintained spec docs
- Used Jira for my task management
- Collaborated with others towards a shared vision
Game Summary
Eye of the Erime is a 3D puzzle game where you solve puzzles of an ancient civilization, the Erime, in order to save your mother from the same aliment that eradicated the Erime. In Eye of the Erime players play as Quin searching for his mother who got lost in a cave. While exploring the strange and fascinating caverns, players will uncover remnants from the Erime and the ailment of entanglement. Players will solve puzzles using their modified camera to take pictures of entanglement flowers which cause different effects depending on the type of flower.
Ephemeral flowers will cause attached objects to become intangible, allowing the player to see, walk, and take pictures through it. Binding flowers will cause attached objects to freeze in place, unable to be moved by any force applied. Echo flowers will cause the attached object to create a time clone which when the photo is deleted will cause the attached object to return to the time clone’s position.
The player must master entanglement in order to solve puzzles so Quin can save his mother.
Gameplay Controbutions
The plantable flowers and planter spots was an idea I had part way through our alpha milestone. An issue at the time was that our puzzles had little to no experimentation, meaning letting the player try something. Back then if there was a flower, the player would take a photo of it and it would be the correct move. One way to add experimentation was allowing the player to place their own flowers in designated spots. This way we can keep the same game mechanics while allowing for the question of “what flower would work best in this situation?” This planting mechanic added depth to our game and it operated similar to how puzzle designers were already applying flowers to objects, we just gave the player the ability to do it as well.
Internal and external playtests were conducted frequently. Internal happened the most, but external playtests gave fresh eyes on the game which helped tremendously.
Discuss how I contributed to gameplay with the idea of the planter and plantable flowers, also discuss how the internal and external playtesting effected the game.
In-game Tutorials
I led the tutorialization of the game. I wanted something simple to understand and not too intrusive, but noticeable enough for the player to know what they need to do or can do. With these goals in mind and with the help of a programmer, we created the tutorial system displayed in the images to the right.
There are a two types of tutorials and a few ways of displaying them. The first show a control icon and what that control does. The second simply tells the player what they should do to at that time or to progress. Tutorials either appear to tell the player about a control for a short period of time or wait for the player to complete the action.
One way to display tutorials is by having them appear under the reticle, indicating that this tutorial is preformed by the player. Another is the tutorials appearing on objects themselves like the button, these tell the player that this object needs to be interacted with in order to progress. The final way is through tips, tutorials that appear after a short amount of time if the player has not progressed like the tutorial for IRIS (the machine) which will appear after the player has been next to IRIS for a few seconds. IRIS also has particles which I added as a way to draw the player’s eye to something story related that they need to interact with to progress.
HUD Iteration
I designed the player’s HUD which for this game required a rather large region of the screen be used for taking photos. I wanted something that did not take up too much space and resembled a real life camera reticle in order to help the player understand that these are the bounds of the picture. With these goals in mind, I started the iteration phase.
The camera reticle to display the bounds of the photo went through over fifty iterations and tweaks. Displayed in the images to the left show case some of the iterations and the final in game product. Ultimately I went with a more simplistic yet refined look shone in the final image.
The most challenging part of designing this camera reticle was making sure that it was prominent enough on the player’s screen so they knew the boundaries of the photo they were taking, and keeping it thin enough so the player is still able to see beyond it to play the game. Also the player is able to select the color of the reticles from the settings.
This design was used as a reference for the shapes of several other UI elements, most notably being the buttons. All buttons in the game have similar corners to the camera reticle as the camera reticle in order to subtly connect visuals between the UI and the in game camera.
Problem Solving
Use this section to talk about the issue of key binds for keyboard and mouse and controller, talk about how controller influenced the decision to have the secondary interaction be a hold.