The Pokedex cover was an exercise to replicate the list-recalling and getting familiar with scriptable objects.
Role: Solo
Duration: 2 Weeks
Tools Used: Unity
Genre: System Cover
Basically, the idea for this project was to understand what it took for the Pokedex system to function correctly. Through replication through scriptable objects and recreating the infrastructure, I built this with the process of 1. Pokemon are locked (Undiscovered), 2. Discovered Pokemon become unlocked through if it’s seen (Discovered), 3. Pokemon can be caught and once caught give more information (Caught).
This translate with the player to these basic player intentions
The player experience for this project was to put yourself in the shoes of a dog owner who owns a mischievous dog that barks frequently at the expense of your own productivity.
Immersion:
The goals for immersion on this project were to make the players feel like they actually had to give a dog attention while simultaneously balancing work. I knew I needed to set up animations and barking in a way that was distracting yet visually interesting. I set the room for a "late night" work feel to add to the experience of trying to quiet a dog at night. The lighting and clamped look focused the intention of the space which validated the immersion. During playtesting, I learned that even though immersion had to be realistic it proved challenging due to the many factors of the dual challenges of the game.
Storytelling:
On the storytelling side of things, I wanted to set the story to put the player in the shoes of a new dog owner who has just adopted a dog. This was crucial because building the relationship takes time and I felt it would be more appropriate to have this setting. I felt encapsulating the environment as a home office and the narrative prepared before the player takes any actions would build the narrative. A pretty important design decision made was creating a narrative sequence before the player actually started playing. This was the first time I used a sequence to tell a story while simultaneously planning for a tutorial. This decision was validated through the positive feedback received during playtesting which proved successful with most playtesters smiling and showing more investment in the story.
User Experience:
The user experience needed to have solid player feedback. To me this was incredibly important and done so through petting the dog which calmed the dog, allowing you to get more work done. I think setting up the UI also allows the player to remember they have these options and also reminds them they can't get too annoyed which really adds to the experience. Although I do think the execution of the final prototype didn't achieve a flawless experience, I do think planning accordingly helped transition to a result that helped with the User Experience. The UI showing when a player could or could not make an action helped validate the reason for having that feature. Playtesting helped reinforce the User Experience of the agency that a player takes.
System Design:
The system design for this was relatively simple. I first prototyped what exactly the goals were for this project then I created a system diagram to help me figure out how I saw it in my mind. The decision to preplan and create three states in the system diagram helped validate the game concept being more engaging.
The mechanics are separated into two systems. One is clicking the screen games computer screen, "doing work", and the second is getting the dog to calm dog. The dog’s gameplay mechanics rely on which state the dog is in. If the dog is alert, the dog must be snapped out of it with a treat, if the dog is playful, the dog must be played with, and if the dog is needy, the dog must be pet. These three game mechanics are all balanced with what state the dog is in.
Core Game Mechanic #1
Ideation:
The core mechanic is balancing your dog’s attention with your annoyance meter, if your annoyance meter stays too high you will lose it, every time your dog barks your annoyance meter goes up. Your annoyance meter goes down when the dog stops barking which is done so by giving your dog attention. Petting your dog and giving your dog a treat is a way to get it to stop barking. This is the core mechanic.
Research: Nintendogs.
The most important learnings from this project were bug control in C#. Encountering so many bugs helped me understand where I needed additional checks and balances when action was executed. This project allowed me to explore gates in relation to coroutines which helped bug control tremendously. I learned how to clean up my state machine which allowed efficiency in execution. Another important learning from this project came with the setup of such a project. This was the first time I used Figma to map out UI and actions/triggers which allowed me to execute the game before I even touched the unity project. Using this method of planning and visualization helped me organize my intention which made this project more grounded. I think I was able to connect two game concepts into one project by using this method.
The challenges presented for this game were the following.
1. Set up a start menu.
2. Set up a narrative to introduce a story
3. Make a first-person game that locks and clamps the position of rotation.
4. Set up tutorialization images from UI.
5. Utilize physics and rigid-body to flick the toy.
6. Set up animations to respond to dog states.
I managed to complete most of the goals through this project. For me, the biggest takeaway was realizing the core player experience had been fulfilled with only 2 actions meaning I could cut the third due to time. I think approaching the project with goals I wanted to complete was a meaningful process. This had been a project in which I completed the game in the systems and UI mock-up before I started coding it which provided tremendous success.