In Morgs Mimics and Mansions Munchables (MMMM) you play as Morg, a mimic who wants to overthrow the current Mimic Monarch to seize the throne! You must amass a large enough base of followers and prove to them that you can provide a steady source of food, humans.
I also worked with GADIG's Design Team to improve the accessibility of the various menus in the title screen.
When we first started making MMMM, I took initiative in becoming the lead programmer in designing each of the various mimics to be implemented in the game. Our Design Team was still determining what the different mimics could do. So, I directed a small subteam of programmers to make a generic, polymorphic mimic interface to be used by all other mimic classes.
This image shows my initial plan for the project's workflow. Because I was the only one on my subteam with experience in Unity and C#. This image shows how I guided my team to start doing research. Because my teammates left due to external circumstances, I shouldered the entire workload on my own.
The difficulty in programming a mimic interface was to ensure it could accomodate for whatever Design Team threw at me. I wanted to ensure there was a baseline of what all mimics could do:
- Look for humans to eat and attempt to eat themThus, I made different mimic 'states,' via enums and booleans to determine a mimic's current state. Each mimic type would likely have their own unique eating and digesting times. So, I made sure to make those values easily customizable. I also included an modifiable attack range for mimics since it could easily be unique to each mimic type.
The first mimic type I got to program was the Skitter Mimic. It crawls across the floor to hunt for its prey.
It was easy to make the mimic move, the challenge was getting it to stop. Whenever a human would get in range of the Skitter Mimc, it should run up to the human, eat, then return to its original position to digest its food and to look for more humans to eat.
There was one problem. When the Skitter ran to eat, it would instead look for more humans to eat from its current position rather than from its starting position. It was a rare bug, but was important to resolve nonetheless.
After analyzing the issue, I solved the bug by increasing the checks to the mimic's current state and the mimic's current position.
The Sleepy Mimic was the only mimic I did not plan to have direct involvement with since one of my original team members was believed to return to the project. To make up for lost time and bring them up to speed, I created this diagram outlining the different states that the Sleepy Mimic should go through in a typical game loop. I made this diagram concurrently while working on the Skitter Mimic.
Unfortunately my teammate ended up not being able to contribute due to external commitments, again.
Luckily, the Sleepy Mimic was primarily about manipulating the different states of the original mimic interface I made at the start of development. This meant I could tackle it myself by taking some extra time to work on the project.
Lastly, by the time I could get to programming the Fungal Mimic, it was already finished by GADIG's Programming Director. So at this point, I was tasked with implementing the Fungal Mimic's animations via Unity's Animator.
This was a simple task with my experiences working on Necronomicon. For this project, I used the sprite sheets for the Fungal Mimic provided by Art Team, put them into Unity's Animation, then used Unity's Animator to create the different animation states. After that all I had to do was incorporate the animation states into the Fungal Mimic's code.
While I did not work on programming the various menus screens, I provided feedback from a User Experience standpoint.
In a main menu, I believe that accessibility is of the utmost importance. For MMMM, this meant granting the Play Button the highest salience by making it larger than other buttons and centering it.
When users look at an image for the first time they typically start looking at it from the center. In the main menu, this means looking at the Skitter Mimic. The gray slits on its eyes guide the user's directly to the Play Button - the most important button to access when opening up any game.
From there, the users eyes will likely go to either the How To Play or Options buttons - buttons that have a lower priority than the Play Button. They still maintain a relatively high priority since newer users might be interested in opening them first instead of the Play Button.
Exit and Credit Buttons deserve the lowest priority since they are only pressed once during a typical user's play session. While arguments can be made for the Exit Button having a higher priority than other buttons due to it being something that should be pressed every session, I think putting it in the upper left corner was the right idea. For the rest, I maintained the ideas of Memory Chunking and the Law of Proximity, to limit the bottom of the screen to only 3 buttons.
