A puzzle game about solving tarot-themed clues 2D Rubik’s Cube style
Team Chip Butty
Cryptiks adds the combinatory motion of a Rubik’s cube to take anagrams to a new level. Mysterious clues guide the player as they move letters by sliding tiles vertically and horizontally, uncovering the scrambled message within. One answer is a clue to the next puzzle, guiding players through a combination of cryptic messages.
The idea of this project came from a weekly game prototype created by one of the team members. The initial idea revolved around solving puzzles in a style similar to a 2D Rubik’s Cube. Following this, we pitched our game idea and moved forward. My main role during the stages was mocking up the ideas we had an converting them into a presentable prototype in Figma.
My first objective was to provide a set of mockups for the game pitch. To create these wireframes, my main objectives were to:
1. Provide a top-down version of the game such that the listeners would understand the different areas of the game.
2. Emphasize the puzzle screens to accurately depict our ideas for how solving puzzles would work.
In the images on the right, you’ll see the mockups that I created. The puzzle selection screen is very barebones, but the main objective was to get the point across for the puzzle screen. There are sections for information on the game and solving the puzzle. In addition, there is a way to check the state of the puzzle.
Iteration and Second Mockup
From feedback we received from the initial pitch and group discussion, I iterated on the first set of mockups to improve on the design. At this time, we had settled on the Tarot theme of our game and wanted to put more emphasis on the screens aside from the puzzle screen. This time, I did research online on current mobile game designs for the puzzle selection screen and how they would be most effectively displayed for our game.
On the left, you’ll also see a first pass on the color palette used in our game. The level selection has a defined section for both the arcana selection and stage selection, with the arcana selection on a carousel. The stages would be selected by tapping on the stage twice, and different symbols would be filled in based on completion. The title screen only needed to access the puzzle selection screen, and a mobile game does not need an exit button, so those were factored into the design.
2nd Iteration and Design Convergence
The next set of mockups focused on three main things:
1. Implementing and showcasing the color palette
2. Updating the puzzle screen to feature only necessary information
3. Mirroring the puzzle solving gestures into the level selection
The first point is self-explanatory, and you can see from the mockups on the right. The second point focuses on cutting excess information whilst also providing the most space for the actual solving of the puzzle. The final point involves the puzzle solving mechanic. To solve puzzles, players must swipe horizontally and vertically to adjust the positions of the letters on the board. To reduce confusion, I adjusted the level selection screen to also be operated with these gestures. The screen may be swiped vertically to hide different areas of the screen and to allow more stages and information to appear. The element selection was added, and it, along with the arcana selection carousel, are already operated by swiping horizontally. In addition, to enter a stage, the player must swipe to the right on the stage icon.
Visual Design Clarity
The next set of mockups focused on the clarity of the visual design. First, hiding information when vertically swiping made little sense, so instead the screen would scroll with the vertical swipes. Second, swiping horizontally on the stage did not have enough affordances, so I changed the design to incorporate a ball slider instead. Finally, the clue section did not have enough space in the puzzle screen, so swiping was added to expand the area.
Eventually, the stage selection portion of the screen would be changed during implementation to only swipe vertically when selection a stage such that the element and arcana selection parts weren’t affected.
My final set of mockups aimed to clarify two things:
1. Which set of icons would be the best fit visually?
2. What is our transition from the puzzle back to the puzzle selection screen (or the next puzzle)?
These questions are answered by the mockups to the right. For the first question, we compared the two designs and settled on the top set of element icons. While the minimalist icons looked clean, they did not provide the player with a visual guide as to what each element was aside from the color. For the second question, I decided on two things:
1. To create an overlay that appears once a level ends
2. To implement a back button to return to the puzzle selection screen
The overlay was a natural transition and provided sliders that matched the puzzle selection screen. The back button was different, as it was a controversial element during our design discussions. First, it didn’t match the gestures that were seen throughout the game by requiring the player to tap on the button. Second, it took up real estate in the puzzle screen and imbalanced the screen visually. However, we were unable to come up with an alternative to the button that both felt natural to look at and execute for the player. In the end, we decided that the back button was necessary for proper menu navigation.
Through our team only had half a semester to work on this project, I believe that I accomplished my role well within the team. I set up design objectives and completed mockups based on feedback and literature to match the goals of the team. In addition to this, I helped implement several systems in the game such as the stage selection and icon changes. Finally, I served as a mentor for the sole programmer on the project and provided feedback and helped test and fix bugs. During all of this, we completed the project 100% remote during the Fall 2020 semester.