Dungeon Mole Dev Logs

This is a collection of my weekly development updates for Dungeon Mole. The game was developed as my Capstone project for Game Studio Production at Columbia College Chicago. I have been the main designer and programmer for this project so much of my tasks were related to creating and desinging gameplay elements along with communicating with a team of artists to create assets for the game. Each week we would post on a Microsoft Teams page what we were working on, and then a follow up before we met the next week. After 10 months of hard work we were happy to release the Dungeon Mole Demo on Itch.io in May of 2025.

Week 1 and Earlier: The Prototype

Leading up to the first week of the semester, I created two rough prototypes of game ideas to choose between and pitch to the studio class. One of those two prototypes was a top-down 2D version of Dungeon Mole. The choice to do 2D was a safe bet, as if I wasn't able to get any 3D artists on the project, I could handle making the spirtes. It also would simplyfy the process of dealing with physics and quickly protyping visuals.
Once I pitched the project we had 3 artists; Evelyn a concept artist, Larry a 3D modeler, and Kyle a general artist. Oliver who was another programmer in the class also had an interest in the project, yet also still wanted to work on his own game idea.
As a result we had 2 teams formed, one for Dungeon Mole, and one for Olivers project "Arcana Forge". While Oliver and I mostly stuck to our own projects since we were the only programmers for each respective game, the three artists would bounce between projects as was needed. However, Oliver did come in to assist every now and then when I was dealing with things outside the class.

Initial Pitch:
You are a Gardening Mole seeking to protect his garden home from the underground insect threat. While you cannot attack on your own, you can plant defenses throughout the underground dungeon to defend and destroy enemy defenses. But be careful, the insects will make large pushes on the exit every so often, so make sure you head back to defend before the next wave arrives. Explore the dungeon to find many unique seeds, discover powerful plant combos, and defend the garden from insect annihilation!

Week 2: Transition Prototype to 3D

Main focus for me is working on getting a new version of the prototype built in 3D.
Specific things I'm aiming to get working for this week:
Basic Test Room
Working Player controller
Getting Slingshot plant working
I'll be creating the repo and project file on Tuesday once I figure out what version of unity we should use.

This is what I got so far in terms of the 3D prototype. Just have movement, basic camera, and the sling working in the 3D environment. Wanted to also get the root wall plants but had an idea to make them grow out and cover more ground so I'll need some more time to get that working

Week 3: Basic Enemy AI

Main focus is going to be getting basic enemy AI implemented and getting more familiar with using Navmesh. Currently having some good results so I’m also going to look into getting the blockade plants set up. I’m thinking instead of having the blockade plants only take up one unit, I want to have it grow and block up to 3 spaces, either randomly or chosen by the player

Heres the current state of the prototype, got the root wall plants working and reworked them so they can grow in the 4 cardinal directions like a snake. I also have enemy pathfinding and spawners working, will need to rework to stop spawning after they have enough enemy's on the field. Next focus is probably going to be getting the planting working with some sort of UI element to select what seed to use

Week 4: Finish Prototype for first Milestone

Get the prototype done! A lot of the content is in there but the big thing I want to focus on is getting the planting system working with a ui element to select what seed to plant. I got the ui working so now it’s going to be about defining which tiles are dirt tiles that can be planted on. Not sure exactly how I want to do that but I have some ideas regarding tile pallets and colliders

This is the current state of the project. Got the planting system working but could use some refinement down the line when it comes to the tile selection system. Also not fully committed to using unity grid maps to place dirt, but is the best solution I have currently found

Week 5: Aiming Plants

Create a component that can be added to a plant and the player to show where the player input it aiming. This component should be scalable and able to be put on any object so it doesn't need to be built for each and every plant. The component should also have different modes of aiming, like a line for the Sling shot, or tile aim for the planting and root walls.

Got aim working as a component we can add to stuff like plants to render an aim icon. Currently has two modes: Linear and Grid. Linear shoots a straight line from its origin in the given Aim direction, while grid highlights the grid tile at the aim position. It can pretty easily be added to plant scripts so this should be easy to add to stuff down the line

*Note: Weeks 6+7 I was busy working on Corner Store Lobotomy so no videos were made*

Week 6: Digging up Plants and Managing Seeds

Main goal is to get digging working for the player so they can dig up plants that are in the game world and get their seed back. This will then be stored and managed in the inventory manager script to determine what players can plant

Week 7: Enemy Wave System and Catching up on last weeks task

Main focus of this week will be getting a enemy wave system in place so we can get one step closer to give the player a win condition. In each room there will be a set number of enemy spawners that will activate when the player gets a set distance into the level. Since the rooms will be made as predetermined individual prefabs we can place these triggers by hand with colliders instead of tracking time or player distance. Once all the spawners are taken care of then the door to the next room will open up. This will be different from the bosses which will be dealt with in a future week.
Due to scheduling issues outside of school, I was not able to complete last weeks task, so in addition to the wave system, I will be also implementing the inventory system and seed distribution.

Week 8: Designing Battle Economy / Adding in Fertilizer Powerup

This week I will be experimenting and starting to plan out a RTS style economy focused on the gameplay loop on a per-room basis. Last Friday we had a discussion with David about how the player gains power when fighting in a room, and how to encourage a more defensive play style.

Current Idea:
In each room there will be mineral deposits scattered around the room, these can be mined to gather a fertilizer that can be spent to power up the plants you have out on the field. These deposits can be chipped away at, rather than mined all at once. As the player chisels at it, pieces will break off that the player can pick up, but over time the deposit will shrink and eventually run out, forcing the player to look for other deposits. The fertilizer can be used on a "per-plant" basis, meaning that fertilizing a plant will only affect that single instance of that plant. For example, if I have two projectile plants and I fertilize one of them, that one will be powered up while the other projectile plant will not. Fertilized plants will have better stats, range, or even special abilities, and will remain powered up until they are dug up. The idea behind this is that the player will walk into a room, be drawn to the nearest mineral deposit, throw up some basic defenses, and start digging away at the deposit while fighting off the early weak waves of enemies. After they build up enough fertilizer from the deposit, they will start powering up their plants to make a push and attack the enemy spawners.

This will take multiple weeks to fully execute, but this week will be mainly focused on adding the mineral mining mechanic, tracking how much the player has gathered, and giving the player the ability to use this on the plants (Plant evolutions will come later).

Heres a video demoing the work I got in this week with some extra explanations, but in summary here's what I got:

Plants can now be dug up to get back their seed
Item drops that the player can pick up when near
Mineral deposits that the player can mine with their shovel to gain fertilizer, but will eventually run out
Reworked inventory system to work off Scriptable Objects

Next week will revolve around getting the plant power up system working where the player can use fertilizer to powerup their plants. Next play test will be focused on seeing if the players will actually build bases near the fertilizer deposits and how effective the loop of "Set up, mine, push/attack, repeat" really is

Week 9: Plant Upgrades w/ Fertilizer (Also UI updates)

This week is a continuation of last weeks task where I will be focusing on creating a system to fertilize plants and have them evolve. When the player evolves a plant it will gain stat increases and change visually. Like stated last time, evolving a plant will only change that instance of a plant, so it wont change any other plants of the same type, and when you dig up an evolved plant, replanting it will revert it back to its basic state.
I will also be adding in the new UI elements that Evelyn is making this week and making sure it updates as their values change (Health hearts decrease, item icons swap around, etc.)

Heres a little update video of how things are coming together, still got a lot of balancing and performance fixing since ive been seeing a lot of lag spikes? Anyways I should have everything ready on itch by tomorrow

Week 10: Fix and Iterate on major Play test finds

My goal for this week is to go back and fix as many of the issues found in this past weeks play test notes as possible.
Since I was not present for the play test on Friday I want to organize my own play test session next week where I can see first hand how players are interacting with the game world. I want to refine the current prototype just enough to the point where I can gather accurate data without bugs or performance issues being in the way.

From my investigations on some of the bugs listed in the notes doc, we have some issues with how we are using the imported room model. First thing I noticed is that when we use the mesh collider, it sometimes auto generates in a way that literally cuts corners. I included a picture of how this shows up, with the dark blue lines outlining the mesh, while the red is the autogenerated collider based on the mesh. Along the same lines, I discovered the issue where the player clips through the floor on the sling is a result of the player clipping into the room collider and going right through due to the dirt areas having a slightly raised section with the dirt layered on top. This also interferes with the enemy AI as the nav mesh cant always navigate onto that

This is not on the fault of anyone, but I think we do need to change up our strategy to make sure we are in control of the colliders. Going forward the room mesh and the colliders of the room object should be separate objects that share a parent obj like the enemies and player objects. I know we haven't had a defined plan for level design and how that workflow will look like, but with some of the major features almost in place, I think we should start planning for that. For Friday I'm going to try and grey box a new smaller room that is designed with the newer mechanics in mind. From there I want to see how easy it would be to separate the grey box mesh from its colliders, see if we can export those meshes to Maya for Kyle and Larry to model over, then export that back into Unity. If everything works out we should be able to keep grey box collisions to use in the final room model to save on time, and keep the geometry simple and in our control.

Here is a grey box room I made with the new mechanics in mind. I wanted to play with the idea of having bridges being blocked off by the wall plants so you can control the pathing of enemies, and I like the idea but there isn't much of a way to take advantage of it other than just making the enemies take longer to get to you. I also tried thinking of where the players are going to be setting up base, which can depend on what path you take. One bridge is a bit harder to navigate sine it has less dirt space, but can flank two hives and put you right next to an ore deposit. I'll be interested to see how this works in play test, feel like it will point out a lot of holes in the design and give a good idea of where to go going forward

Week 11: Simplify Inputs, Reactionary UI, and Tutorialization

This week I want to focus on getting a concrete idea of how I want to teach the mechanics of the game to player, reduce the amount of things the player has to do, and make it easier to quickly understand what each action does, and what interactions are occurring in the game. This all comes together under the task of tutorializing the game and thinking of what first time players are going to be thinking. I honestly doubt all of this will get done within the week, but I want to start thinking of how this is all going to come together and creating a plan since this will be put in peoples hands in a few weeks.

Heres my weekly demo video. Main things to take note are the Ui changes, the player aim reticle, and the input changes

UI Changes

Selected items pops out when swapped too next and previous item slots are greyed out to be less noticeable and show they aren't immediately ready to use
Fertilizer counter pops out when value changed

Aim Reticle

A semi transparent arrow is now positioned infront of the player to show what they are aiming at and what action they are about to perform
when an interactable object like a plant or mineral deposit is infront of the player, the reticle arrow will snap onto the top of that object based on its center

Input Changes

All actions bound to either A or B on the controller (see main post for the positive and negative input explanation) and changes depending on what the player is or isn't selecting
The dig action has been changed from an item to the B button option for any object that it is applicable too (ie. plants or minerals)
Fertilize is still a seperate button however, and is bound to the trigger. This may change to be the A button action for the sprout stage of plants if the plant evolution method is changed or removed.

*Note: Here I mention the Columbia College Gala which was a showcase event held at the College that featured student work and Dungeon Mole was one of the works featured*

Week 12: Input Command UI and Highlight Reel

Since it's the holiday this week this will be a bit more of a smaller week in terms of scale, but still a very important one! With the new inputs in place and the actions more finalized, I want to start adding a UI overlay that will give important info to the player depending on what they are doing

Selecting an object will display the commands the player can make and their respective button
Selecting a plant will show a dial that indicates how much fertilizer it needs until it evolves to the next stage
When the player picks up an item, a sprite will pop up above the player that shows how much they have gained (+1)

This will help a lot with teaching the player how to play the game and not have to halt action to remember the controls. While this probably wont be an issue after the player has played for a while, it will help save time when playtesting and introducing the game to new comers.
I will also be working on a short 30 - 60 second long high light reel for the Columbia Gala, showing off the game and it's current state. Since the dead line on that is 12/1 I will be working on that first and thus will probably not include some of the features listed above. However the UI additions are not for visual aesthetic, rather more so just instruction for the actual Gala event so I'm not too worried.

Here is what I have for the highlight reel! Im also going to use this on our itch page for now as a small video trailer. No sound but might change that once we start to get stuff from the sound team

Week 13: Ready build for Gala (Tutorial Level + Visual Input Commands)

This week is going to be focused on getting a ready build for the Gala on Thursday! Main focus is finishing up this initial tutorialization phase of production by getting a tutorial room set up that will teach the player the basic mechanics of the game and getting the Ui Input command popups working.

Tutorial Room
This room will be where the player spawns in and learns the mechanics of the game. Basic progression is 1) Teaching the player how to dig fertilizer. 2) Teaching the player how to use fertilizer on sprouts to grow them. 3) Interacting with plants to attack targets. 4) Digging up plants and replanting them. My goal is to use as little text as possible to communicate the mechanics, just visuals and level design.

Visual Input Commands
I've been wanting to get this working in the game for the past few weeks but have been a bit stuck in how to go about implementing it. Ideally I would like these UI elements to be entirely iconography rather than using text by having a symbol representing the action and the button it is tied too ( / ). Main issue is that getting all of those action visuals designed will take some time and I feel like using text would be the safer option for the Gala build. I will be creating an asset list for the artists soon so I will be including those icons to use down the line.

Here is the tutorial level for the gala demo I made, people seemed to like it and more people were able to get the hang of the mechanics and controls.

Playtest Notes:

Should probably teach players how to plant before showing them how to interact with them. Had a lot of points where players would walk up to the first plant and press B to dig up the plant, and then were confused on what to do next.
players were overwhelmed by the spike in difficulty once enemies are introduced, probably will make the first hive or two only spawn one enemy to help players adjust
Second challenge with the hive was a bit hard to teach players, as the only solution was to plant a shooter and turn it in such a way to bounce off a slanted wall. Good puzzle, but probably not the second one to show the player

For the most part I feel good about the content that is in place. There are still some bugs to iron out but design wise seeing people who have never played video games before pick up the controls, mechanics, and gameplay loops was a relief.

Week 14: Final Polish and New Build

Since the Gala was this past week, most if not all of the content I wanted to get for the final milestone for this semester is implemented, so this week is going to be going back through the demo scene, fix any bugs that will get in the way of the player learning the mechanics, change some things with the notes from the play test (See W13 Post), and get the final build onto Itch with a new dev log.

Here is the link to the new Itch dev log with the newest release! I'm going to update the screenshots to show off the new scene and add the trailer but the new build is live! Thank you all who were involved in this project, very happy with where this is going and excited to see what next semester will bring!

Week 15: Half Way Point Reflection

Over all I am very proud with how this game has shaped and developed. It has been a rocky process and I had to wear many hats durring this first stretch of development, but I'm really excited for the future. Over the course of the past 15 weeks I feel like I have really been challenged to really develop my skills as a producer and project lead, while also testing my design prowes.

This was my first time leading a team of this scale and having to figure out how to effectivley manage my time, and the time of my team mates. There were also a handful of disruptions this semester, like spending the most of weeks 6 and 7 working on Corner Store Lobotomy, attending MDEV on the day our second milestone was due, and basically having the third milestone done 2 weeks early to be ready for the Columbia Gala.

I am very greatful for the team I got to work with on this process, everyone has put in a lot of work and has been amazing to work with. Our artists Evelyn, Kyle, and Larry have all really made this idea come to life and have really brought a lot of excitement to the project, and Oliver has been a great source of advice and has really helped me shape the design of this game.

Speaking of which, this game has been a real design challenge when it came to figuring out the core gameplay and how to effectively teach players gameplay mechanics. A lot of the past 7 weeks have been devoted to this and thus is why there wasn't many new art assets. I had a lot of trouble figuring out how to define my basic core gameplay loop and identity of the game. Some of the original ideas were scrapped or put on hold like the floor timer and slingshot plant, but from that emerged a much stronger core system. Thats why I feel like the next 15 weeks of development are really going to be focused on expanding on this core gamplay and having a lot of fun making new plants, levels, enemies, and much more! We also have a sound team who will be working to get sound effects and music made for the game which is really exciting!

To sum it all up, this has been a challenging stretch. But now I feel like the project is set up to really take off in this second half of development and a lot of the early design work is going to pay off.

Week 16 pt. 1: Create Art + SFX Asset lists for Milestone 4

With the increased number of people involved in this project, and looking back on last semester, I want to start this stage of development by getting some defined lists of what needs to be done so I can make sure there is a steady line up of thigs to do. In the ladder half of last semester I got really caught up in the design of the game that I didn't have much time to get things for artists to do. Now that we have more designers and programmers interested in working on the game, and with the extra time, I want to focus more on honing my producer skills and making sure that we have a good plan for each milestone and can ship something in May.

For the art asset list, I want to have this all within its own spreadsheet to keep it all centralized for that team, and also since the artists aren't working in GitHub until near the end of the assets creation. However this will not replace GitHub Issues. From my experience from the last few semesters in studio, the GitHub issues are a good way to track what people are actively doing on a week to week basis. This asset spread sheet would be more so for planning out long term production, having something that people can pull from and then bring into GitHub as we reach each milestone. I did some research to figure out a good format, and found a good example from Joshua Bresler on Art Station that seems to fit the timeline of the class structure that I will be referencing.

For the Sound Effects list, I did speak with Dani about how that will be formatted, since they have already started production so I will be in communications with them about how to format it.

Right now I want to focus on the goals for Milestone 4, which I feel should be focused on honing in our aesthetic styles. Safe bet would be just have the demo but with refined art assets, no grey boxing, models for plants, and some core sound effects, but I would like to still showcase some new gameplay features or levels if we can get them done in time.

Heres the link to the spreadsheet with the asset lists for 3D Models, VFX/Shaders/Particles, and Sound:https://docs.google.com/spreadsheets *Note this document has since been updated*

This is most of what I want to see for the first milestone, starting to showcase the visual style of the game in the scope of the last demo. I'm going to speak with the artists on how to best plan this out and if there are any other assets we need to add. I'll be continuously updating this doc through out the semester, but this will be the only post I make for it.

Week 16 pt. 2: Rework Wall Plant

So for a while I have noticed that the wall plant hasn't been really been adding much to the gameplay. The controls are kinda awkward, the use for it isn't obvious, and there are a lot of technical challenges with it. I got really caught up in the idea of having them grow and wiggle around like actual roots and vines, but it is too slow and doesn't combo with any of the other plants. I also had this issue with the sling shot plant, but decided to just scrap it since I felt its mechanics over complicated its use. However I do feel like we need a wall that the player can set up to defend them self, and also manipulate the battle field in a way to attack the enemy.

Over the break was thinking a lot about peoples reactions to the bouncing projectiles, and the puzzles that formed from that. All of those puzzles used diagonal walls naturally found in the level, but I realized that the player should have some way to set up diagonal walls to create their own projectile paths around obstacles. However the main issue with this idea was how do you set up a diagonal line in a square grid? I had ideas for dedicated plants that took up one tile but had a diagonal edge, but felt like that would be hard to effectively hit and set up. But then I came back to the idea of the sling shot plant and came up with this idea:

The main idea is that it takes the aiming concept of the sling shot and lets the player grow the wall out in the direction in one go. This idea would theoretically be quicker, and easier to learn than the original wall growth pattern. However unlike the sling shot aiming, I want this to be restricted to 8 directions as this will make it really easy to set up projectile bounce paths and make it easier to predict what tiles will be considered "open" to planting. Since I want each end of the wall to land on the center of a tile, the length will vary between diagonals and cardnal directions, but I want to try and aim for the wall to jut out ~3 tiles from the main body.

I also had the idea of having the growth animation also deal damage to enemies that are in the way, creating kind of a pseudo melee attack, giving the wall this duality both as a defense plant and an offensive one in a pinch. I also want to create a aim reticle for this similar to the line renderer but not as long

I got the prototype for the new root wall mechanics that I am currently dubbing The Root Spike (not sold). I don't have the UI inputs working for it yet but it works similar to the sling shot where Clay goes behind it to aim, but I took away the inverted stick control thing so the aim arrow lines up with the stick direction. I also added in the damage aspect to the spike so when the wall grows out it deals damage to enemies in the path so the player can have a sort of melee attack thats good with groups of enemies up close. But even aside from that I can see a lot of fun puzzles and levels comprising of just this and the shooter plant so I feel pretty good about these changes

Week 17 pt.1: Updating the Input Action UI

We have found some bugs with the current UI Input overlays and have ideas for some new additions to further help the player understand what is happening:

When the player grows a plant the UI doesn't change to the plants control scheme
Each control scheme is hard coded in and difficult to expand upon for specific scenarios
A fertilizer tracker that appears above a plant to show how much it needs to grow. This would most likely be a dial like indicator that fills up as it gains fertilizer
Enemy Spawner Trackers that appears above each active hive on the screen, and when there is an active hive off screen it will stick to the edge of the screen and point in the direction of the spawner

Heres a demo video showcasing the UI changes and updates I made this week. Big new additions are the object trackers I have set to the enemy spawners, and the dial trackers over the plants to track how much fertilizer they have. I did forget to mention in the video but the object trackers could be used to track other objects if we want and have a different icon and such, could be useful in the tutorial area to guide the players attention. Regardless let me know what you guys think or if you have any suggestions

Week 17 pt. 2: Aiming with the Right Stick

Many people have pointed out that the aiming for planting seeds and interacting with objects is a bit hard as you need to line the player to directly face that object with just the move stick. This will allow the player to rotate around like in a twin stick shooter to aim their character

Quick video showcasing the aiming I added to the player so now planting and selecting stuff is a lot easier! One thing I want to talk to animators about is how we want to go about animating Clay when he's looking one way and moving another since it does look kinda awkward. I tried experimenting with having the animation reverse when he's walking backwards but it kinda looked weird. I wouldn't worry so much about so much how to get it work but do you think we should have the top half of the body separate from the legs or have different animations for the 4 cardinal directions and interpolating between those. Those were just my ideas and we can talk more on Friday but this does look a bit funky

I also briefly showcased and talked about some updated I made to the fertilizer dial to make it a bit easier on the eyes. TLDR; Going to have the dial fade away when the player is far away and then become full size when they are near.

One other small thing to keep in mind is that I did add the timer to the test projectiles so they will be destroyed after about 4 seconds of being in the air since someone mentioned that last week.

Week 18 pt.1: Enemy Barriers

This week is going to be a bunch of smaller reworks/adding functionality to existing features based on some of the feedback and discussion with the level designers to experiment with

First up is getting the enemy barriers set up as their own prefab object. So far the barriers have worked by just having them as a child object of the Hives that are destroyed when the Hive dies. However it was pointed out that this limits us to only having one Hive per challenge, and people did have ideas for having multiple hives in a section to create danger from different directions. So I want to go ahead and make it its own object with behavior script to add more flexibility to the gates. I have also been told that the sounds for said gate are made so hopefully after this week we would just need the final model and its good to go

The barrier ended up being pretty simple, but allowed the level designers to really start to experiment with mechanical combos and setting up proper challenges

Week 18 pt.2: Extra Sources of Fertilizer

During our greybox review, one of the most important talking points we had was an issue that has been looming over my head for a while was the issue of running out of Fertilizer. We took some time to discuss some potential solutions and I want to try and prototype some of those ideas to bring into next week and discuss as a group.

Enemies and Hive's drop fertilizer on death
- This felt like a pretty popular idea within the group, however this does have some potential holes. While the enemies can spawn from hives forever, creating a theoretical infinite source of fertilizer, if the player has no defenses then they won't be able to kill the enemies to drop the fertilizer.
Big Fertilizer Deposits Regenerate
- The idea with this one was that bigger fertilizer deposits, or at least some sort of variant of them can regenerate at a very slow rate. This could be something to pair with the enemy drops to avoid the aforementioned soft-lock situation, however we didn't like the idea of a player sitting next to the fertilizer deposits just waiting for them to regenerate
Smaller Scattered Deposits
- As a way to add some more details and guide the player to certain areas, it was suggested that we could have some more smaller fertilizer deposits that are more frequent and scattered through the level. This is similar to an idea I have had for small item crates scattered through out the level. Those crates would be kind of an analogue to Zelda pots, where occasionally they spawn a random item when broken. However, I personally don't like the idea of the player having to walk up each small little crystal and pressing B to dig them up, so I want to experiment with another solution. In Enter the Gungeon there are a lot of set dressing props (like crates, pots, chairs, etc.) that the player can run into and break. They don't drop anything, and other than blocking a single bullet they are pretty useless, but it is so fun to just run through them and break them! I had that idea for the item crates in this game and will most likely do the same with these small deposits

Heres a video talking about some of the ideas I implemented that could be potential solutions to the fertilizer problem based on what we discussed last week. I'm a bit rambley so sorry for the tangents about plans for the next few weeks, but I do plan on making a new pass on the pickup items in the coming weeks. Main additions this week are the Small fertilizer deposits, Deposit Regeneration, and dropping fertilizer on object destroy. Small Fertilizer deposits can be quickly ran into to break and gain a small amount of fertilizer, and can be placed around the map to have a smaller passive source of fertilizer. Deposits can now have the option to regenerate at a specified rate, creating time for resources system. And new component has been added which will drop an amount of fertilizer within a range of values when that object has been destroyed. This is used on both the enemies and the hives in the test scene, but can be used on any object that has a collider.

Week 19 pt,1: Trailer for New Release and Itch Updates

So the big thing this week will be getting things set up for the Milestone patch release next week. This will involve updating the main page with a new trailer going over the big changes/improvements in this update. I'll also be making a itch page documenting changes more thoroughly.
Here are the Main features for this milestone:

Sound implementation
New levels focused on different mechanics
New models for the enemy spawners (H.I.V.E.s) and item drops
Refined Item drop animations and spawning
UI improvements

Week 19 pt.2: Improve Visual Effects for Item/Resource Flow

For the next demo, I want to rework some issues I have been seeing in regards to understanding the flow of resources as the player makes actions. While this was tackled a while ago with adding the pickup visuals and UI animations, there are some new features and changes that I want to fix:

Item Drop Animation + Delay
One thing I mentioned last week was wanting to improve the way the Item Drops behave in game. Currently their objects just spawn in at a position, and instantaneously disappear when near the player. From the start I wanted the drops to have more personality and animated, but when first implemented I was more concerned about making sure everything was working before the aesthetics, but this led to some confusion on where drops are coming from and where they are going. Main things I want to do is have the items be thrown out from their spawned position so they spawn with some movement, and also add a delay to the player picking it up from when it spawned, so the player can see the item drop before it is collected

Fertilizer Use
When the player is fertilizing a plant, I want there to be a visual line of fertilizer arch from the player, to the target plant. This will communicate not only the direction of fertilizer flow, but also the rate. Rendering the line in an arch might be a challenge but I am sure it is capable within Unity using line renderers.

Grid Visualization
While not necessarily a resource, I feel like better visualizing the world grid plays a part in this, since it's information that will help the player more efficiently use their resources. Up until now we have been using the Probuilder grids to visualize the world grid and calculate how things line up in gameplay, however probuilder textures aren't going to be making it to the final game, so I feel like it is time to figure out a good way of rendering that to the player in a way that isn't overwhelming or noisy. Could probably figure something out with shaders to make it only appear when the player is close.

Heres a video showcasing some of the visual changes I added. Really happy with the grid shader and the fertilizer arch, since I felt those where things we really didn't communicate well so having this in the game makes me feel a lot more comfortable.

Week 20 pt.1: Start Transitioning to Cell Shade Rendering for First Lighting Pass

Now entering this next stretch of development, and with some models starting to get textured, I want to begin to transition our default rendering to the cell shaded style that is already present within some of our models. However the fast majority of our game so far utilizes the default URP set up, and does not reflect the final product that we have in mind. So the main goal for this week is to set up a lighting reference scene (most likely based on the tutorial scene) that better reflects the rendering style, with a basic first pass on lighting to get a better idea of what direction we should be going with the aesthetics.

First pass on lighting with the Toon/Cell shading plug in we have! It's been a little funky to use and definitely needs some work to make sure things are balanced, mainly I think adding volume to light. From my research there isn't anything built into unity/URP that can do volumetric lighting so either I'll have to learn to program that shader, or find a plug in. I am more inclined to do the latter for times sake, but still need time to look into options.
For now though this first pass was really interesting and switching everything over to toon shaders wasn't as hard as I thought. We do have some weird discrepancies going on, mainly having a Toon shader - Copy that some of the materials derive from which messed up their shading. That was the case with clays model, so after switching it over he looks a bit different, with flatter shading and an outline. Also small change, clays glasses have an unlit shader attached to them so they will glow in the dark!
One other think I should mention is that I turned on the pixel camera again, I believe it has been off for the past few mile stones, and for the time being it is going to be at HD resolution (1920p x 1080p) so we get some nice crisp edges on the pixels rather than anti aliasing blurring them together, more so an aesthetic touch.

Week 20 pt.2: See Player Through Walls

Making the grid renderer the other week combined with the playtest notes I got, have me invigorated to finally make a renderer system that will allow the player to see clay when there is a wall between them. I have debated between having this be a silhouette as to preserve the detail of the wall and make it a bit more "secretive" in nature by hiding the other contents, or a full cut out that literally cuts a hole in the wall to show what's on the other side. I went with the latter as I feel it is needed to show the whole level, when the gameplay revolves around placing things in your environment.

Heres a video demoing the cut out shader working and how to set it up. It has some quirks that I talk on in the video that I have found in my testing, mainly aesthetic stuff like fading in vs the zoom transition. I'll be tweeking that stuff to better fine tune it but all in all the functionality is there and should be easy to implement into the final textures and models when we get those made

Week 21: Replicate Paint Over Lighting

Working to replicate the lighting as seen in the paint overs Evelyn made so we can flesh out the lighting system and nail in the style we are going for.

paint overs here

Credit to Evelyn Rodriguez

Here is the first version of the lighting I got set up to mimic the paint over. Leaning a bit darker just because I worry if it gets too bright people wont pick up on the cave vibe. However I feel like the crystals on the walls help outline the boundaries of the rooms so I think it can work. Had to fake some of the emission stuff by upping the bloom in post processing, and adding a light inside the crystals to get it to glow on the toon shaders. Also the spot lights now have volume but that is also a trick of just using a mesh. Definitely a simple and kind of hacky work around, but for the sake of time and lack of resources this will be the best strategy

Quick new pass, upped the fill lighting, made the volumes of the sky lights cylinders over cones to prevent them from looking like stage lights. Made the crystals smaller, worry that if we made them too small and bunch them together the overlapping lights will make it too bright so maybe we go for having larger ranged lights that cover multiple crystals?

Week 22 pt.1: Plant Withering Mechanic

This week I'm going to be working on adding the withering mechanic to the plants. We have thrown around the idea for a while but feel ready to commit to it. Basically plants will lose fertilizer charge over time once they are grown, and when it runs out it will enter into its withered state. For now this will just be a general model that it will change too, but once we get closer with texturing the plants and animating them, we can probably have it be its own animation state that changes its color to a dried plant

The rate and causation for losing fertilizer charge will be different depending on the plant. For example, the shooter will lose fertilizer at a constant rate over time, but the root wall should only lose it when an enemy runs into the wall and dies. This will most likely be implemented within the parent class for all plants, so this will be forwards compatible with future plants

The plant withering mechanic is implemented and live! Really interested to see how this pans out in the playtesting, but its something I've thought about for a while and I think it turned out well!

Week 22 pt.2: Add Hostility Bar

With some of the changes with fertilizer made this week, I want to prototype out the enemy hostility bar that represents the amount of fertilizer the enemy insects have stolen from the main fertilizer deposit. Nick is going to be prototyping the movement and stealing mechanic, while I add the basic UI overlay functionality and game over sequence. To give an idea of how it will look, I included a picture of the "Impatience Bar" from Against the Storm. This bar charges over time and slowly approaches the skull, but rather than over time it is tied to the enemy insects stealing the fertilizer and then putting it into the Hive machines. I will probably have a +1 fertilizer icon popup over the bar when the enemy returns a piece to the drill, much like what appears over Clay when he picks up an item. My main worry at this stage is how to teach the player this is bad other than trial and error. I think that overlay may help and using basic iconography, but I do worry if we might need tutorial blurbs at some point to effectively teach the player this mechanic. For now this will use place holder art that I can get my hands on, and then pass it to Evelyn to make it pretty

Week 22 pt.3: Add in Animations to Hive

Going to work on getting the animations that Larry made for the Hives working in synch with the behavior script. Previously this was just a simple animation clip that raised the model for testing sake, so these will be the finalized animations.

Got the animations hooked up, for the most part everything looks great! There were only two things I had of note to talk to Velazquez, Larry about that I touch on the video. First is a slight change to the drill up animation, at the very end when the wasp rail pops up, the wasp shouldn't pop up with it in order to better match the spawn system. The claw on the rail should still pop up, just empty handed. Second is a texture for the hole model that will make it look like a hole. At first I thought maybe just black, but I remember you showing me that shader that created fake 3d space so maybe we can apply that here? Lmk how things look and if anything is off (I'm moving the tracker so its out of the way too)
I tweaked the scripting to better line up with the animations and give a better view on the animations. I linked the first spawn to the drill up animation, however I don't have the spawn animation looping like you said. It could in theory, but the issue I had was what if we need to change the spawn rate away from one ever 2 seconds, or how does it stop when it reaches the spawn limit? Basically I just added a state where it is just the claw empty in a static state, and then when an enemy spawn request is made it goes down and grabs it. I'll probably come back to this at a later time to figure out a way to have the enemies "jump" off the top of the drill and onto the ground. Don't have time for it now since that would involve playing around with the physics and navmesh systems

Week 23 pt.1: Lighting Pass and Finalization

Durring the playtest there were a few issues discovered and pointed out when it came to the lighting shown off in the demo. With some of the feedback I want to do another pass with a few goals in mind

Figure out what causes the artifacting on shaded surfaces and how can it be prevented
Figure out what causes the artifacting on shaded surfaces and how can it be prevented
Remove Outline effect, as a group we felt like it would most likely be best for both aesthetic purposes and technical

I also want to create some prefabs with variations on some shapes to make it easier to set up for the level designers once ready for their lighting pass

Heres a video of me talking about some of the changes and discoveries I found while reworking the lighting setup and how to achieve what I feel is, or is at least very close to our goal for the visual style of the game.

Spot lights now have a much harsher fade off to the point where it almost instantly fades to darkness
The Toon Environment shaders can have the amount of shades changes for the rolling cloud effect, which should be at a higher number to create softer shades
Outlines on objects have been removed, as they were too unpredictable and hard to control
Began Modeling environment with the Terrain Blocks (found in prefabs folder). The present grey box renderers should be turned off as to preserve the collider information that we know works, and then to overlay these on top of the colliders to create the visuals, as the terrain blocks have no collision information.
Possible Issue: the amount of shades that a Point Light produces cannot be controlled on either the texture or the light, which kinda looks off when next to the spot lights, possible solution might be by creating a custom render texture to use as the cookie, but want thoughts from others.

Week 23 pt.2: Camera Focus, Control, and Animation

With the extra time I have with the break, I want to get to work on creating a system to give us and the player more control over the camera and what it is focusing on.

My goal is to create a component that will be tracked by the Game Manager instance that will allow scripts to call for the camera to move and focus on certain things. This is mainly to treat the issue we have had with players not understanding what actions lead to what outcomes, so this will be able to let us force the players attention to certain parts of the level to see certain events. For example a button can call for the camera to focus on the door its tied to to show that it opened up. This will end up with us having a basic cutscene system, and with that in mind I might look into Unity Timeline to see if that could be of help, but from my understanding that is for more static cutscenes rather than something dynamic like this.

Some goals to hit:

Have the script be accessible through the game manager, that way it can be referenced from any script at run time without finding objects or components
Take control away from the player, and prevent them from taking damage, preferably also stopping enemies in their path.
Create smooth camera movement when focus changes
Tie events to specific points in the camera focus animations so actions can be called when the focus starts, when the focused object is in frame, and when the control returns to the player

Got the cutscene manager working with the basic Focus command that I talked about. You can now from any script call for the camera to focus on an object, taking away control from the player and entering a cinematic view. I talk about how to add this into your scripts and how it works in the video but if you want help figuring out how to use it or if there are issues let me know!

Week 24 pt.1: Unwrap and Base Colors to Props made

Since I now know how to do basic texturing and unwrapping of 3d models, I am going to take over the work on the prop models that Larry and Kyle made so they can work on getting the plants made! I want to focus on getting just base colors, since we know we are going to lose a lot of detail in the low res camera pass through, so I'm curious to see how far we can get with just base colors to make these look nice? Other games like Tunic and A Short Hike that are references for the visual style have pretty flat textures. Regardless I want to get this started to both practice my own skills as a 3D modeler and give Kyle and Larry a head start on the Bigger stuff

Week 24 pt.2: Wires through Levels

As a continuation of my work to better communicate to the player what elements of the level connect to each other, like switches and doors. I've had the idea of having wires placed through out levels to physically connect the two, and show if it is active or not. Going with wires also is in theme with the technological nature of the level. My goals with this are as such:

Drive the placement of the wire with a Spline Component, that way the coordinates can be quickly placed, and then place the wire models programmatically
models should switch between an on and off state depending on what it is attached to, this would be like an internal part of the wire glows yellow to mimic energy going through the wire
Could also be used for Enemy pathing or at least follow along with it to better represent the path of the enemies?

Here's the demo and instruction video on the wire object I added to connect to switches and doors or whatever to better display the active state between interactable objects! In this scene I just have the wire set up between a switch and a gate, and when the switch is hit, the wire turns on, and the barrier goes down. Generating these wires happens in editor, not run time. I set up a custom editor script to add a button to the Wire Generator inspector component, that will take the specified points in the spline component, and generate the line mesh. This mean you will have to specify the points in the spline container, then hit generate to see the mesh to save on resources constantly updating it. There is a weird bug with the action however, which is that not all of the old line mesh will go away when refreshing it. Seems to be an issue with how unity calls these events in the editor vs run time, and restrictions on how you can destroy the objects, but if you click the generate button a few times it will clean it up. Lmk if you guys have questions or notice any other wierd quirks

Week 24 pt.3: Global Audio Management

Dani brought up this issue when we tried to get UI sounds added in to the last milestone; It is hard if not impossible to have audio events trigger and then carry into the next scene loaded. From this I want to set up a manager to handle more non-diegetic audio that doesn't originate from any specific object in the scene, like audio, ambience, Ui effects, etc. I'm also taking this as a chance to FINALLY learn Fmod implementation so I can help out and better communicate with the sound team about how to implement the effects

Ok so I managed to spend some time learning about how Fmod integration with Untiy works thanks to this video by Shaped by Rain which cleared up some issues that we had with audio not playing and such. I recorded this video of me explaining how I think we should handle the audio integration moving forward in a resource effective way.
In summary I want to have as much of our sound references made in the Global Audio Manager script, that way we aren't making new instances of events for every object if we don't need to. Currently I have this working with One Shots, but I think for Time lines we need to keep with the Emitter Components we have now, however I want to try and control those in scripts as much as possible and not rely on the built in triggers. I show in the video how to call these but for timelines you would have a reference to the emitter component and then call emitter.Play() and emitter.Stop(), and then one shots would be RuntimeManager.PlayOneShot
(GlobalAudioManager.eventName) for a non spatial sound, and then RuntimeManager.PlayOneShotAttached
(GlobalAudioManager.eventName,gameObject) for a spatialized sound that emits from the passed in game object.
For the music I moved the control over that also to the global audio manager, so music nicely fades and carries over when changing scenes. I did have some questions that I wanted to talk with the audio team regarding how we want to set up the music system. Currently we have the main level music and hostile music set up to fade in based on a float, which works, however what do we want to do when moving to another track? Would we want to have different level themes have different hostile themes? I know this is a big large scope, but I would at least like to think about that when we implement, and ill talk with dani more about this tomorrow

Week 25 pt.1: Ui Visual Improvements

We got some new assets from Evelyn for the Ui, and I'll be working to get these implemented and adding in more visual complexity through scripts. After this all we would need to do is finalize a font (which I will also explore this week) and the Main Gameplay UI will be finalized.

Change the Heart Icons to final sprites (Waiting on decision from group over which version)
Update Seed Icons to the new version that reflect their final designs
The fertilizer watering can will have a layer of liquid similar to the current fertilizer roots, that will gradually fill up as the player gains fertilizer
Swap out the old Hostility bar with the new one and have the charge bar change colors from blue to red as it fills up

UI is all updates to what should be pretty close to the final UI, there are a few things like the font that needs changing once we decide on one, and then some color tweaking on the fertilizer counter and hostility bar. Changes are pushed lmk what you guys think

Week 25 pt.2: Aloe Health Plan

This week I will be getting the new plant, Aloe, modeled, animated, textured, and programmed into the game. I've already had a bit of a head start on this so I should be able to do this within the week. Basically the plant will be grown up like any other, but when dug up it will heal the player by 1 Heart. No seed will drop, so the player will have to go out and find more seeds to grow into these health plants to regain HP. This takes inspiration from Atomicrops where they have a similar mechanic with the Heart Beets, where it combines the planting and growing mechanic with the Health system, which I believe will nicely implement into our system.

Aloe plant is modeled, textured, animated, and programmed! Really happy with this as a solution to healing, giving us another exploration incentive, and how it integrates with the gardening system! This is all good to go in levels so lmk if you guys need help adding it in

Week 26: Hole Warping and Fast travel

This week I want to get in the fast travel functionality we have talked about when discussing travel between areas of each level to prevent backtracking and traveling to different levels entirely. We came up with the idea of having Clay jump into the holes the Hives leave behind to quickly warp to different areas. This works thematically with Clay being a mole, and also naturally fits in with the design of the levels, as the player needs to return to a central area in each level after defeating a hive. I also will create a version of this that is just the dirt hole warp point without the Hive so we can use them for other shortcuts, and also warping between levels. Some things I want to hit:

Animation for Clay jumping in the hole and a fade to black cutscene
UI input action tracking so the player knows what button to press and what it will do
An arrow that points into the hole when the player can jump in

Heres the demo video on the warp holes. Every thing seems to be working but there a re a few things I need help with to finalize this thing. I want to speak with the animators about how we want to animate Clay jumping into the hole, preferably if we can reuse old anims if possible. And also I know me and Larry were talking about possible ways to texture the holes so that they look 3D and have depth.

Week 27 pt.1: Resource Depletion Visualization

This week I want to work on better visualizing and communicating when the player is low on a resource

Creating a Ui effect to react when the player is low on health. This would included a red vignette that appears when the player is on 1 heath, and I'd also like to have an audio change as well where the audio gets a bit muffled and a heart beat plays
Having the hot bar flash red when the player tries to plant a seed when they have none
Have the fertilizer counter flash red when they try to use it on a plant
Have the input action overlay cross out the button when that action wont lead to the desired outcome, but the button and action is still visible. This idea is a little experimental so I will judge its effectiveness as a group

Week 27 pt.2: Implement Shooter Model and Animations

With the Model and Animations created for the shooter plant have been sent over from Larry, I'm going to go ahead and set up the animation controller for the Shooter in the project and hook it up to the script.

Heres a demo showing off the new animations and model hooked up to the shooter plant! The animations programatically fire and speed up/down depending on the shooter settings so we can still have flexibilty with balacning. Really happy with how it turned out, larry did a great job on the model and animations

Week 28 pt.1 : Get the Itch page ready for Release

Final stages! I'm going to get the itch page ready for a release by drafting up the blog post to commemorate the launch of the demo and updating old assets to better reflect the final product. Main things this would include would be revisions to the games description, changing the thumbnail with the new title graphic, updating the background off of the webpage, and getting fresh screenshots of the game. These assets will also be some of the content I am going to send the publication team for manifest

Week 28 pt.2 : Title Screen and Putting Levels together

Title screen needs some work and now that the visuals of the levels are near completion, I want to setup the title screen to have camera shots of some points of the level in kind of a minecraft esq montage in the background. I also will double this with making sure the levels will transition from one to another. This is something I want to ask the Level Designers about, since I wanted to know if yall think we should keep the first half of the current tutorial level that I made that teaches the basic mechanics of the game, but cut it off right before it gets into combat. I believe I brought this up a while ago but wanted to briefly touch base. From what I saw in the mineshaft level, it does teach the player how to plant and fight, I do worry about overwhelming the player at once. Having the tutorial level act as a no steaks buffer where there is no threats to teach the player, and then reenforcing those teachings again at the start of the mineshaft will help ease the player into combat. This wouldn't require any work from you guys, just want to get opinions.

Heres the credits scene (background is animated) and a video of the title screen reel, lmk what you guys think or if I misspelled your name

Week 28 pt.3 : Root Wall Model and Animations implimented

The model and animation for the Root Wall/Spike plant have been finished up by kyle, so Im going to go ahead and get that set up in the engine. Should be simple since I wont need to work with an animation controller, the spike animation is driven by a sfx component that can be played, and the current code will handle the scaling and rotation

Week 29: Demo Launch and Manifest

On May 16th 2025 we released the full Demo of Dungeon Mole on Itch.io for Windows! That same day we showed off the game at Columbia College Chicago's Manifest event held in downtown Chicago! It was a blast to finally share the game with the public and see and talk to people at the event. In correlation with the launch we also released a Launch Trailer for the demo to better advertise the game.

Week 30: Post Mortem

This project took up the large majority of my life for a good 10 months, and to now look back and see what we were able to make is amazing. Dungeon Mole was the first time I really made a game in a team, let alone being my first time leading a development team. While looking back my main contribution was programming the majority of the game, looking back through my weekly tasks I realized how many hats I wore through out development.
In all I made the UI which I don't have much experience in UIXU design, worked with implimnetaiton and creation of sound, animation, and modeling, and ended up being sort of a marketer for the game and going to outside events like the Columbia Gala and gamebIITes at Illinios Institute of Tech to show off the game. I believe this comes from my history of being a largely solo dev, where I did have to do anything and everything to make as cohesive as experiences as possible with only my time and patience to learn.
Part of me did enjoy being the sort of glue sticking together everyones work, but in the end it I really did strain myself to get this project done. This was mainly due to lack of resources, no money in the project and didn't have many people on hand to help fill the holes in our skill sets.
There were also some conflict during development about game direction and scope. Originally I wanted to have 5 levels, a boss, and a few more plants, but my art team had a sit down with the team and explained their concerns and criticism of how while the design side of that would be achieveable, we had the level desingers to make the levels, and the infistructure was there to make the plants. But the artistic design would enevitably be lost and that with our resources it would be impossible to reach that much content without sacrifices. But from there we listened to concerns and spoke as a group, and came up with the final plan for the demo we have now released.
Now a week after release, I'm proud of what we made, and how I have grown from this project. I could go on for a lot of the "I wish I could have done x y and z" but at the end of the day, seeing the people who came out and played the game on my last day of college, I think it came out good.

*Dani and Rey are here in spirit*