Re-Solve is a pathfinding puzzle game made for casual audiences where the player has to tap to interact with the environment on their phone to get the character from one place to another. Solve the light puzzles, reach new areas, and turn on the lights in this dark world!
I was responsible for project management, game design, scripting, and UI/UX design.
The Pitch
The concept for Re-Solve started in my Prototyping course at the Academy of Art University. It was the first project of the semester, and we were all required to come up with mobile game ideas to pitch and produce for the first half of the semester. My game pitch was within the top 3 projects selected for the first half of the semester. The assignment was two months long, and we had two weeks for pre-production and two weeks for polish at the end. This was the first group project on a large scale I would manage as a graduate student.
The original pitch slide presentation for Re-Solve.
The first working title for Re-Solve was Pathfinder. When I was brainstorming for this project, I drew inspiration from AR and VR games. Though our game did not end up implementing AR, it still ended up with similar gameplay. I took inspiration from games like Monument Valley, Arise, and Toad's Treasure Tracker. I had developed a fondness for 3D isotropic camera views, pathfinding puzzles, and simple cubic art styles of these games.
After all of the class projects were pitched and voted on, the class split up into teams based on each student's interest in the presentations. I had ended up with a four-person team. Our team had three students who specialized in art, and that left me to be the only person on the team to work on the development of the game mechanics and functionality. The imbalance of skills on the team ultimately lead to us removing AR features from our project.
Pre-Production
We started our pre-production by fleshing out the story, controls, features, mechanics, and other design aspects. In this phase, we were still under the impression that we would be making this game into an AR project. So in our early documentation, there is evidence of that intention throughout.
Project management
The organization was important for our team. We had a very ambitious project to work on, and as a result, lots of tasks to go through. I created a Trello board for our team, and every week I would go through and assign group members to work on specific tasks. At the end of the week, everyone would update their progress on the Trello, and we would have a meeting to discuss our workloads, blockers, questions, or any other updates. We also created a discord channel as another form of communication to get feedback and post updates.
In addition to our time together in class. We prioritized meeting together outside of our course as a group. Either in-person or online for at least an hour. When we met up, we would help each other with tasks, or it would be a group study kind of environment. Out-of-class meetings were a part of my tasks as project manager and game designer. At our meetings, everyone would get the chance to play the current build of the game.
Concepts and Inspirations
Together as a group, we worked on deciding our art theme, story, and character information. We decided to go for a futuristic, neon, cute cyberpunk aesthetic. We wanted to focus on having dynamic lighting and futuristic architecture that was run-down or broken in our environment. As for our main character, we wanted it to be a little robot whose objective was to fix things.
Once upon a time, in a distant future, there was a little droid named Kodi who lived in a lighthouse. His creator had fled civilization and the cities after a great environmental catastrophe. They took shelter in a lighthouse high up in the sky hovering over a coastline. Kodi and his creator fixed every broken thing they ever found. they were built to help repair the old buildings and systems that protected them from the elements. But One cloudy day, after charging Kodi couldn't find his creator, and worse their lighthouse was broken. So, compelled to fix their home, and find his creator. Kodi embarked on an adventure.
Early design concepts.
Production
After fleshing out the most important details about our game such as story, level design, and character design. Our team split up into three sections, and One team member was responsible for Visual Effects, Rigging, and animation. Our other two team members were creating our game's 3D assets, and character. I was responsible for developing the game's main mechanics and in-game functionality. To take a closer look at the C# scripts I created for this project, take a look at my GitHub repository for Re-Solve.
AI Navigation.
Once we decided to move on and adjust our game to be a standard mobile game. It was Up to me to figure out how the player would interact with the world as we imagined it. My first task was making our player follow commands to move to specific positions. I had considered a few options to solve this issue.
My first option was to introduce a semi-transparent UI Controller for the player to use to move. This method is used frequently with racing games or other open-world games that require precise free player movement on mobile. The problems I would have encountered with this solution were as follows. Our environment needed to have an unobstructed clear view. If the player places their fingers onto the screen, it limits gameplay visibility. With such limited screen space to utilize after a player's fingers would be in the way, we would have had to scale things down or find a unique camera solution. Creating a camera solution would be very difficult to do on my own. So I scrapped this idea.
My Second idea for player navigation was to have the player swipe on the level to spin it around and see it from all angles, at their own will. The player will tap the position they wanted the character to move to solve puzzles, hit switches, or go through doors. I decided to put this option into development first. It was an ambitious option to go for, but it allowed for maximum screen space for the level and got us all of the required functionality for navigation.
The third option I came up with is the safest. We would have the player tap onto different areas to have the character move about the scene. To rotate around the level, I would also create some UI buttons or a slider. This option created a happy medium between our two goals and would allow us time to implement, test, and modify this feature.
After a few failed attempts at making the second navigation idea work. I realized that it was out of scope for the timeline and resources of this project. We had some issues with tap to navigate, where the player would tap, and the AI would end up circling almost endlessly if they couldn't perfectly match up with the tapped position. As I iterated on the design, I solved the issue by writing a C# script. Since the AI wanted to stop exactly at the tapped position, I made a buffer area around a tapped position that would act as a stopping area. Allowing the AI a larger target alleviated the worst parts of the tap to move function. Occasionally if the position the player tapped on was very far from the start point. The AI would circle once or twice but would always stop around the tapped position.
The main issue I had with this solution was with mis-clicking or accidental tapping. If the player wanted to rotate the view, they might tap a part of the level. Making their character move in the process. I tried to adjust the rotation, so the player could only rotate if they did not initially tap the level. This way of moving within the scene is similar to how ZBrush navigation works. To accomplish this, I added a collision behind the level that rotated around parallel to the camera's view. Even though this solution did reduce the frequency of the mis-clicking issue, the problem was still present. I couldn't afford to spend more time working on adapting this solution to fit our needs. As a result, I re-worked things to represent my third navigation idea. I was able to salvage the time and work put into the tap to move function. For the rotational element, my first working solution was to add a slider at the bottom of the screen to get a 360 view of the level without interfering with character movement mechanics.
The slider was a good placeholder that allowed me to focus on the other aspects of our gameplay. When we had our other features in place, I went back and re-work the design further. The camera rotation took many iterations to make it feel as comfortable and natural as possible. By the end of our production cycle, I had swapped the slider for left and right arrows that the player would tap and hold to move the camera in the represented directions.
Navigation first iteration.
Doorways and Elevations.
Since our camera's translation values would not change in-game, I decided to design our level to use the camera rotation and various elevations to create different areas. Elevation was also a visual representation of a player's progress in completing the level. The higher up on the tower they made it, the closer they were to solve the light puzzle. Using elevation required us to find a way to get from one elevation to another.
For this solution, I wrote a script that required the player to move the character to the desired door. After a half-second of waiting, the character would appear at the corresponding doorway. To make locating your character easier, we color-coded the doors ways that are linked together to have the same color. I also made sure to never move the character from the front to the back level. Keeping the character within view of the camera when they move makes it easier to locate them after.
When first developing this function, I started by simply teleporting the character to a new area. Unfortunately, the Nav mesh did not like when I manually forced the character to move without tapping. The Nav mesh would break immediately after re-location, and the character's mesh would endlessly teleport between the two doors. To solve this, whenever the character moved to a door, it would delete the prefab character. The linked door would spawn a new character prefab. This solution worked, but if we didn't move the player quick enough, they would keep swapping positions. So in later versions, I adjusted my door script to ignore player collisions if the player spawned from the door they were colliding with. It worked and helped to avoid any accidental door travel when entering a new area of the map.
An early example of door teleporting.
Door Switches and Level construction
After I had player movement and elevation in working order, I moved on to working on the puzzle aspect of the game. The level itself is the puzzle, as the player navigates the world they are working to get to the top. But the game would be no fun if the player could easily reach the final goal. About this time the team's artists had given me all the 3D models for the level. After communicating back and forth with the art team to make adjustments to things like scale, and export settings. I put the level together in the game, and now it was up to me to make the game functional.
So far we had player movement and teleportation working. But I needed to implement the light puzzle into the game. Active doors in the game use a colored light around the frame, and the light color determines where the door will take you. I had to find a way to change the connections of the door at will. So I added hidden switches around the map. Those switches would change the color of the doors and link the doors of the same color together.
The biggest challenge I faced while working on this task, was getting the connection between doors to change according to color. I also had to make some design changes to allow the switches to visually stand out to the player. In one of my original level sketches, I had added sparkles around hidden areas. I worked with our VFX artist and asked them if they could make a grouping of fireflies that would gather around the switches. Once the Visual effect was completed, it became one of my favorite details about the level.
To take a deeper look at the C# code for this project, you can use this link to get to my GitHub repository for Re-Solve.
Lighting
One of my favorite design choices in this project has to be the emphasis on light. from our environment to our character light plays a major role in the design of this game. From early on, I knew that I wanted to have more of a playful cyberpunk aesthetic. and to be one of the main features of that style is the neon lights and how light creates the mood.
When lighting the scene I paid particular attention to the color blue. Blue is a representation of our main character Kodi, The lights on their eyes are blue, the symbols around them are blue, and the feedback from directing them towards a path is blue. So when Kodi hits a switch It made sense to me to make that an activated switch would be blue. And the inactive state of the switch needed to be the complement, orange.
The trees in the game, are holographic with greens and pinks. I didn't want them to overrun the natural night-time lighting in the game, so I requested that our VFX artist make them emissive without casting shadows. But I did add some small point lights to the planter boxes at the base of the trees, to give the illusion of projection and I limited their effective areas to reduce the effect on the surrounding environment.
Since our main character is represented by the color blue, the remaining lighting in the game i wanted to be orange and warm-toned. The saturated red/ orange color signified that there was something with the lighthouse that needed fixing and it created a fun contrast to our character, making it easier to identify them on the screen.
The doors themselves have a few different colors of the rainbow: yellow, red, orange, purple, and green. The red doors were doors that had no connections or were not active yet. There were no blue doors because blue is a representation of our character. But the only light color we didn't use in the level until the very end was white. White light was saved for the top of the lighthouse, to signify that the lighthouse was now in working order and could once again be a symbol of hope for those who have lost their way.
Re-Solve game design progression: Version 8
UX and Visual Feedback
One of the tasks that I ended up taking on in this project was the User Interface and designing the User's experience to be one that is rewarding. Due to the time limitations of the project, I decided to focus my attention first on the camera rotation interface. The slider wasn't the most intuitive choice to keep.
Since my first idea of swiping on the screen didn't work as I had originally intended and the slider is unintuitive. I decided to use buttons to adjust the rotation. I commissioned the art team to create an arrow that matched our theme. I started with two placeholder unity buttons, one on the bottom left and one on the bottom right. the buttons had a 50% opacity. To keep the buttons away from the level, I moved the camera so the level was closer to the top of the screen. I wrote a short script to handle the rotation of the camera, and the speed at which it rotates. It took some time to adjust the settings to get a speed and movement that felt natural.
While I worked on improving the User interface I was working with our VFX artist to come up with ways we could improve upon the visual feedback of the game. First I wanted to have some kind of indicator appear when the player taps to move the character. Next, I wanted to let the player know which direction the character is facing so they can navigate the level easier. I wanted it to stand out, and make the character easier to find on the screen. Together we made a rippling water effect when the player taps the screen. We also gave the character a tear-drop-shaped ring that follows the character's rotation.
The last major update to the visual feedback I made. Was Animating and setting up the events for the light at the top of the lighthouse turning on, and spinning when the character completed the level.
Testing and Debugging
The final two weeks of this project were dedicated to testing, debugging, and implementing feedback from our testers. Some of the feedback we got mentioned that the trees we had in the environment were too distracting. To solve this I lowered the brightness of the emissive materials that the trees had. We also received feedback about making the level and character larger on the screen. To address that issue, I moved the camera closer to the level and scaled up our player a bit more. Most of our feedback was positive, and our testers were very interested in the possibility of a full game.
Since there wasn't much time to add any new features, or artwork. as a Team we focused on polishing the game, removing any placeholder art, and getting a final product that we could all be satisfied with. In addition to debugging and polishing the game, I completed most of the documentation requirements for the project.
Re-Solve Game Design Progression: Version 11
Postmortem
Overall I am happy with this project and I learned a lot about game design, project management, and working in a small group.
Final gameplay recording for the Re-Solve prototype.
If I were to re-do this project from the start, with all of the same limitations and deadlines I would have focused on making two or three levels instead of only one. I also would have adjusted the camera to follow the player's vertical position when they moved around so I could zoom the camera in more and make the level more visible. I would also make a larger focus on accessibility. I think some of our colors weren't colorblind friendly and that if you were you would struggle to play the game.
In a lot of ways I feel as though I had bitten off more than I could chew. Though I am satisfied with the outcome of this project I do wish that I had more help in the scripting and game design aspect. I also wish that I had fleshed out my pitch a bit better, and had more direction from the beginning.