The pet itself, called "Bomo", is a core mechanic to this game. We wanted to have a balance between being cute and annoying, and I feel we did an okay job at that. His primary functions are aiding your impaired vision, and freezing the monster. While he is healthy, he can freeze the monster in place for a set time. This will drain his bars more quickly, though. Additionally your player character has blurry vision by default, and can only really perceive their surroundings through the e-pet screen. This means your ability to see the world around you is dependent on the status of the pet. Bomo's hunger and sleep bars will deteriorate over time, at different rates. When one of these bars drops below a configurable threshold, he will leave the "base" state and enter the "warning" state. While in the warning state, he will block up the screen and disable all actions, including freezing, for a set amount of time. After that time he will return to the base state. If the bar continues to drop past the next threshold, he will enter the "crisis" state, meaning he will begin crying and completely lock down all actions as well as blocking your vision. The only way to escape this state is to address the issue, be it giving Bomo food or letting him sleep. Both of these have their own states, "eating" and "sleeping". When Bomo eats food, there is a short amount of time where he plays his eating animation and locks all actions. After which time his bar is filled and we resume back at the base state. During the sleeping state, the screen is blacked out entirely as Bomo gets his rest. These states are generally intended to be used in safe areas but we also intended to force the player to sometimes risk it and take a quick nap somewhere dangerous and hope for the best. This state machine was designed by me and implemented by TJ.

The map went through a lot of iterations and grew alongside the project. The map got its first draft as a simple maze for playtesting. After that our level design guy, Adam, sketched out a rough layout for the map, shown here. This layout came with notes outlining the intentions of certain areas and mechanics we would need to make it work. He also included a video of himself walking through a rough 3d layout of the level and explaining the encounters in more detail, which was hugely helpful. Using that, I took all of that information into Hammer and created a full 3d layout of the level that we could walk through and playtest more directly. After that, I took the textures from our art guy and I implemented them in blender after patching some holes and issues with the mesh. After that I started creating and placing props around the level to make it feel more lived in. Fences, sinks, pipes, signs, etc. Anything to fix the industrial kinda vide we had imagined. Finally we did a pass implementing all the mechaincs, volumes, triggers, spawn points, pickups, etc. After that we playtested and tweaked countless times before finally pressing build and exporing the project. 

The documents are one of two core central mechanics in this project. If you think of this game as a sort of cooking game, the documents would be the recipes. Clients will enter the shop and request a certain document. You then need to go back to your desk and draw that document using your mouse. Tj managed to get the gesture recognition system working with this video as a guide. Once the gesture recognition system recognizes which document you wanted to create, it will spawn it in your hand. You then staple the document to the client's head and they pay you and leave. You also have Power Documents, which are special one-time use documents. You are given the ability to create one new Power Document for free every night, and each one has a distinct effect. Some are triggered by delivering the document to the client directly and others need to be activated in the mailbox. Getting these documents working took a handful of interaction systems all working together in tandem, and I think it ended up in a good place.

The clients had pretty straightforward goals, but ended up being surprisingly complicated in execution. The majority of the AI work was done by TJ, I handled the damage aspect of the clients. The clients will spawn as either a bad or good clients. Good clients will simply enter the shop with a document they are desiring. There is a timer ticking for each client before they will give up and leave. They will patrol the office and engage with any available distractions, such as sitting in a chair, looking at art, or talking to the assistant. These distractions increase the client's patience. If these good clients are attacked, they will simply leave the shop in a panic. When they are given the correct document, they pay you and leave. Bad clients are either vandals or thieves. The vandals will spray paint on your walls with various tags that will increase your stress level that you must remove, and the thieves will simply steal money from your safe and leave with it. Various upgrades allow the player to interrupt these bad clients and send them packing. When clients are attacked they enter a "wallsplat" state, where they will fly across the room and slam into whatever surface they run into before getting up and leaving the office. We felt this was a good way to really sell the "Power" aspect, as we thought that interactions should try to feel really impactful. This same ethos is what also inspired the stapling the documents to the client's heads. 

Getting the balance just right was another very complicated process that took a good degree of mathematics. We are still not sure if we are 100% there, as it may be a bit too difficult, but we think it is overall in a pretty good spot. The starting point was that the final goal is getting $1,000,000, but you also have daily quotas you must meet that increase over time. These daily quotas add up to $800,000, so if you just do the bare minimum that will not be enough. So the starting point as $800,000 divided over 10 days in a way that increases over time. After that we had to add more on top of that to compensate for a budget for upgrades as well as some extra to give some leniency. Then this daily budget was divided up by the amount of clients that would spawn that day. Towards the endgame, there are so many clients that there is no way to help them all, but the extra income you get from upgrades and power documents should boost you enough to make that daily quota. After this starting point we playtested and tweaked, buffing the amount that clients give you and balancing power documents many times. We have received a mix of feedback on the balance, some saying it was too hard for them and others saying they found it a satisfying challenge, so ultimately I think it could be softened a bit, but it was certainly meant to be a challenge.  

We wanted to go with a Chulip styled camera, a top down camera that switches to set camera positions in certain areas. This was my first time doing a camera system like this, but I ended up very happy with the implementation. My main concern with it was that when you moved between camera transitions and the movement controls changed to be relative to the camera, you could get stuck moving back and forth between camera swap volumes. Other games handle this by maintaining your original movement vector until you change your movement direction, then it updates to be relative to the camera again. Out of concern for time, I decided to instead just try my best to not rotate the camera too drastically, and primarily make the camera moves zooms and angle changes. This worked in this projects scope, but long term I would definitely take notes from games like Devil May Cry or Resident Evil to get that feeling better. 

The inventory system and crops system pulled heavily from my existing Inventory System that I had started up previously to make future projects easier on myself. It had to be heavily modified not only to be usable on this project, but also to be more human readable for my teammates to be able to use it as well. It still has some ways to go on that front, but I think it did the job fairly well. The biggest modifications to be made were adding the ability to "craft" objects within it. I kept this super basic for the sake of the jam, but dragging two items on top of eachother inside a planterbox would check if those two together made a recipe.
For example, a bamboo stick and a kiwi seed made a kiwi plant, since the kiwi vines needed something to grow on. Another example of this was the blight + cure recipe, which effectively just crafts nothing. This allowed the cure to clear blight out of that inventory slot. We then had a master script checking these inventory boxes every time change in game and growing the crops accordingly. Each scriptable object had parameters such as "GrowsInto", "HarvestsInto", and "CraftsInto" which determined what would happen to those objects in those given scenarios. 

It seems like this project's strongest point was it's aesthetic, as we have received a lot of positive feedback on that. I had a lot of fun designing the overall look by designing levels, creating and modifying textures, creating art exhibits, and animating characters in the somewhat over the top cartoony style we had envisioned. I pulled some inspiration from games like Snake Eater, Hitman, and Zelda throughout development for systems, but as far as the aesthetic we were looking to stuff like this fight from Samurai Jack, or Bad Apple. Basically just anything with a really high contrast, almost 1 bit aesthetic. We did end up adding more detail and some shades of gray, but I still ended up very proud of the look. 

I took a lot of lessons from my previous project, MECHROIDVANIA, and made the movement here a lot more basic and snappy as well as placing less of an emphasis on platforming. The movement pulls from Metal Gear Solid 3: Snake Eater quite heavily, but I added a lot of my own tweaks and adjustments that I feel make it more unique. You have a walk, run, jump, crouch, crouch walk, and roll. You can use these abilities to sneak around and stealth past enemies. 

As this game is a Metroidvania, a large focus was the upgrades. We had a toal of 10 upgrades. These included a shield upgrade, a health upgrade, and a battery upgrade, each split into 3 pieces and hidden throughout the levels. We also had a dash upgrade, a sword upgrade, a missile upgrade, an electric prong upgrade, a long distance electric prong upgrade, a homing missile upgrade, and a vertical boost upgrade. All of these upgrades were fully implemented, with puzzles and scenarios designed to test your understanding of them. These upgrades all also physically changed the way your character looks, with the robot looking more and more bulky over time. 

The character movement in this project was something I was overall happy with, but also could use some improvements. I went with a more chunky, heavy style of jumping for the character. The movement was based on the general movement script I outlined here. On top of various tweaks to get it working well with a third person character as well as cleaning it up to work within this new project, I made the character have lower air acceleration, and I made two different styles of jump. If you jumped while moving, you had a more horizontal focused, forwards jump. This was good for clearing small gaps. If you jumped while stationary, you had a more vertical focused jump, which was good for scaling tall obstacles. I did all this to made the robot feel more weighty and to made every jump feel deliberate and technical. The character's movement also changes throughout the game via upgrades the player collects. In particular the dash upgrade, which also unlocks the ability to do a dash jump. The dash jump was received very well, and was a highlight during playtesting for me as well. 

I think the puzzles generally ended up very effective. Since I had a lot of tools to work with thanks to the wide variety of upgrades we had, I had a lot of choices for how to test the player. I think that a lot of the secret areas tested the player's memory, as many of them required you to come back with the proper upgrade later. Some of them also tested the player's ability to combine these upgrades and use them simultaneously, such as dash jumping around a corner to shoot a target with a missile. Overall, I seemed to get good reception with the puzzles. The only place I feel they got a bit too confusing was in the ship level with the gravity swapping segments. I also feel that some of the puzzles are far too simple and end up being more just platforming challenges than anything else. 

This section of the game was centered around moving throughout the map using a grid based, simple movement system, avoiding enemies, collecting extra dice pickups, and opening up routes to the ending of the game. The grid based movement was partially a time restriction compromise, and partially an excuse to experiment with alternate movement systems outside the first person controller we had used for the previous two projects. I think it actually worked quite well, and if I revisited this project I feel I would leave the movement system in-dungeon conceptually intact, just upgrade and iterate on it. We also developed a dynamic camera system that allowed each grid to have the option to have its own camera angle, allowing us to make the introduction of enemy encounters more interesting while also leading the player to important areas. The goal of the player throughout this section is to explore and reach the ending of the game, which requires the player to have a minimum of 250 dice to pass. This goal is presented somewhat soon to the player to encourage motivation.

The puzzles in this game were quite interesting, as the world shift mechanic is very open ended. It lends itself well to a wide variety of uses, and I feel like we just barely scratched the surface here. Nevertheless I am quite proud of the ideas we came up with and implemented in the 2 levels we created, you can read more about them here and here. Here's an example of how the world shift can be used for puzzles. If there is a solid wall in the real world you want to get on the other side of, but an opening in Holl, you could simply shift to Holl, walk through the opening, the shift back to the real world to get on the other side of that solid wall. This idea is pushed further in practice. The key here was getting other objects to interact with the world shift in interesting ways. Making platforms that are only visible in one realm, objects that can or cannot be carried with you into the other world, doors that only open in one world and not the other, getting these systems to all work together was key in designing puzzles. 

This game also had a good mix of platforming, although at times it was harder than I intended it to be. On the platforming side there were a lot of ways to make the world shift interesting, like arranging platforms in a way where you have to world shift back and forth between each platform to make it across, or falling down a pit where you have to world shift to avoid certain obstacles along the way. The character controller had to be modified a bit to make it work with this system well, as well as adding a new mechanic entirely, "The Hunger Dive". This dive allowed me to extend platforming challenges even further. Often times though, the puzzles and the platforming were happening simultaneously. 

This section of the game was host to the Cowboy AI and the trick or treating mechanics. There was some light platforming and puzzling for you to navigate through, but the core of this area was avoiding the cowboy AI that constantly hunts you down. Each house has some sort of decoration, inside joke, or gimmick. They also always had an inhabitant, who you could talk to once per cycle to gain a random amount of a random currency. 

This area was host to the currency trading part of the game. Here there are various vendors that all give you one type of coin in exchange for another. There are also some NPCs to talk to, as well as the bank and the shop. This area is pretty purely mechanical, the meat of the game is here is just thinking through your trades and knowing your goal. For example, if you want 10 Polar coins to unlock the double jump, you would find the vendor that sells you Polar coin and see what he asks for. If you already have some of that coin, you would just straight up trade him and receive your Polar coin. 

If not, you would look for the vendor who trades the coin you need to trade with the Polar coin trader and trade for that, then go back and trade for Polar coin, so on and so on until you have traded all your coins into that one type of coin, then hopefully by that point you have enough. If not, you can store your coins in the bank, but the bank only takes one type of coin and that coin changes each cycle. So once again you will need to do some trades to be able to store your coins away so you don't lose them all when you re-enter the neighborhood.