tumblr dot com
roma★
JVL
Love Begins
titsay
The Stonewall Inn
hello vonnie
$LAYYYTER
ojovivo
cherry valley forever
EXPECTATIONS
Discoholic 🪩
todays bird
Noah Kahan
h
sheepfilms
art blog(derogatory)
Product Placement
oozey mess
No title available
seen from Mexico
seen from Germany
seen from United States
seen from United States
seen from Saudi Arabia
seen from Malaysia
seen from United Kingdom
seen from Canada
seen from Mexico
seen from Netherlands
seen from United Kingdom
seen from United States
seen from South Korea
seen from Türkiye
seen from United States
seen from Sweden
seen from United Kingdom
seen from Germany
seen from Mexico
seen from United States
@cloverdaledevupdates
Summary of Tasks for Semester 1
Created the game's dialogue system
Created the game's inventory system
Created the game's interaction system
Created the scripts responding to the player's interaction
Created a prototype for the present minigame
Created the game's flag system
Made adjustments to the scene transition script to match with persistent data
Week 12 - (1/12/2025 - 5/12/2025)
Final Reflections for Semester 1
After last week, we all had a collective moment of disbelief - we'd accomplished a great berth of the mechanics that the game required, and we had two whole levels built out, as well as Reggie's house almost being completed! We were finished for the semester!
Now that I finally have time to truly think of what comes next, my mind is completely filled with everything I want to work on next. The list of things the game will need next semester is still gargantuan, but at least its many small things to implement, instead of designing core systems! One of the biggest priorities to me now is animating the UI and moving the camera in/out during conversations; I feel like this is a small aesthetic choice that will really make the game feel polished, as well as potentially adding customizable camera angles during key conversations to enhance the storytelling and effect desired from the writing.
While achieving this, I also want to edit the DialogueLines SO so that the characters appear in a typewriter fashion as well, and perhaps I can even use that to add audioclips to have characters 'speak' during their dialogue! I also obviously need to finish the present minigame's integration with the game. Lastly, I really want to make a node editor view to make creating dialogue trees easier for the non-coders so they can take part in the designing process as well! I always have the big list I made prior to check if I've missed anything.
I'm really excited to keep working on this next semester! Developing this game, with this team, has been a wonderful experience, and even though there have been lows to match the highs, I'm still ready to face the second semester's work with verve and passion!
Signing off for semester 1!
Week 11 (24/11/2025 - 30/11/2025)
True to Week 10, the only things I really needed to do this week in terms of the project itself was bugfixing that the NewGame Flag wasn't refreshing when the player quit to menu and started a new game - this was easily solved by adding to the code connected to the new game button in the menu and making it set NewGame as true. The biggest point of contention was that at one point during the previous week, I had made a horrible merge to main that almost overrode my teammate's hard work; unpicking the changesets to save back to main and finding which empty shelves were preventing me from undoing those said changesets were a hassle to deal with after having just woken up that day. I think this tells me that exhaustion is not very good for making sound development decisions. Luckily, I was able to revert the error and merge properly, saving all of our progress.
Finally, I also reworked how the Rabbit and Frog moved when Reggie spoke to them, using flags to change their dialogue dependent on whether or not Reggie had spoken to the victim, acting on the feedback we had received at the confusion of why the NPCs reacted defensively if they were spoken to before even speaking to the victim. Now, this response and their teleportation is locked behind speaking to the Goat first! They now move individually, instead of together.
Small but meaningful bugfixes this week! It already feels so much more distinct and professional than it did only a few weeks ago!
Week 10 (17/11/2025 - 23/11/2025)
Milestone : External Testing
This week was when everything I had worked on previously really came together like a game should. After asking for advice on how to manage it, I created a Flag Manager script that would instantiate a Flag Data Scriptable Object when the game was opened. This can be changed later, but right now this is the optimal setup so we can test the flags from scratch for debugging purposes.
By utilizing enums to account for each instance in the game that would require objects in the world to activate, deactivate or change, we have great control of the game's progression and can also replace a lot of the unsustainable methods to facilitate that progression quite easily. I made several scripts to affect change in the game world once flags were set, and scripts that would set flags after an action was taken! This took a while to account for all the different types of things that could happen to make a flag set (or unset), but eventually I assembled all of the previous scenes with these scripts in hand!
These are the current conditions in the game so far:
And here are how they can be affected:
The possibilities really are endless with the Flags in motion! It was very exciting to put things together and see them work so reliably and clearly, a massive difference from the chaos of debugging in the earlier days of the project.
Finally, as a last set up for next year's work, I created a prototype for the present minigame I had struggled with in the back of my mind after all of this time. Now that everything worked better and I understood how the systems would interact with one another, I was finally ready to take a crack at it.
It's basic, but it will be a massive timesave for next semester!
After that, that should be the bulk of the work I have to do this year! Next week will likely only consist of bug fixes instead of adding anything substantial.
Week 9 (10/11/2025 - 16/11/2025)
After the internal testing, we recieved a lot of valuable feedback from the people who tested our game! More importantly for me, I got a bunch of bugs to review and fix. I was still happy to see how much people liked the art and the UI, since Charlie had been able to implement some of Lilli's UI elements into the game, making it look even more polished!
At some point due to the character controller being changed from using a Rigidbody component to another physics-based method, the interaction stopped working. This is because in Unity, a Rigidboy component is needed for trigger colliders to function. This was a quick fix; I attached a Rigidbody component on the Sensebox and disabled everthing that makes a Rigidbody actually effectuate an object.
Secondly, there was a bug where after the player completed the game once and tried it again, the dialogue with the victim at the end automatically played as if the player had collected both of the suspects. This was due to the boolean of that particular Dialogue branch not resetting after the end of the game, so I added a quick addition to the end of playtest script to reset it once the player had completed their task.
Lastly, I reworked how the DummyNPCs worked. Since their implementation was clunky, I decided to replace their function with the Cutscene Manager, which I could use to display dialogue without needing the player to physically interact with anything. I added a 'can Interact' boolean value to the interaction script, changed the interaction condition to whether that boolean was true at the same time that the use was pressing 'F', and then I could disable it when the Cutscene Manager was playing dialogue separately from the Dialogue Manager to avoid having to deal with a double input. Having this work out felt like a total victory! Since the Cutscene Manager's setup was so similar to the Dialogue Manager's setup, it also meant that it was flexible for any future alterations. Things are almost ready for the external playtest!
Week 8 (3/11/2025 - 9/11/2025)
Milestone: Internal Testing
Finishing prep for internal testing
This week was spent testing the progression of the newest version of the game to ensure that everything was smooth sailing for the internal testing milestone. The first thing was, in order to account for the new addition of the city scene, to ensure that the bike scene transition would update itself based on whether or not the player had been to the park or not.
To do this, I used static boolean values to monitor whether or not the player had used the teleport once before, which would automatically switch the string to the city scene's name after the boolean value flipped. This was a very bad idea, and there are better ways to go about this so that you can actually play the game multiple times without needing to close the executable out everytime you want a new working play session, but it would function fine enough for the playtest. It can be made better later, it just needs to work now. Which it did! The transitions were stable.
Next, I set up my DummyNPCs around in reggie's house, in the park and in the city to trigger dialogue as needed.
Then, after I ensured that the logic for the conversation with the victim in the city scene worked well, I added a simple script specifically for the testing that would switch to a new scene thanking the player for playtesting the game, making it trigger after the player stepped on a platform in front of which suspect they believed to be the culprit, these platforms having appeared after the player finished their last conversation with the victim after collecting the suspects for questioning.
I also ensured that the scripts involved in triggering the DummyNPCs locked the cursor as well so that the player couldn't rotate the camera during a cutscene.
After painstakingly sweeping through the game a few times to make sure nothing else was broken, I realized that the way that the DummyNPCs were implemented were a big problem if the player came into the invisible collider at an angle. The core of progressing the dialogue (more importantly, freeing the player from the cutscene after its done) wouldn't be possible if the player's sensebox wasn't overlapping with the fake NPC, which wouldn't happen if you got caught in certain angles. At this point the only times this would happen poorly is in the city scene and the park scene, where we get extraneous internal dialogue from Reggie, instead of the more important context-laden dialogue that we could directly place the player into in the beginning of scenes or once they enter a particular doorway.
Since it was so close to internal testing, I decided to just axe these extra DummyNPCs and keep the more important ones that played more consistently. Again, they could always be reworked later, but if they impacted the playthrough negatively, there was no reason to keep it in.
All in all, I was happy to get over this leg of the journey. Now I needed to think a little more persistently.
Week 7 (27/10/2025 - 2/11/2025)
This week wasn't too productive in comparison with the prior week. Just some more tinkering on the Dialogue Manager, some research and insight into what we could potentially look at implementing next semester, and adding a way to have dialogue trigger automatically in some situations without the need for interacting with an NPC.
I created a large list of all of the tasks that the finished version of the game would likely need, just to keep track of things in the future.
While tweaking the Dialogue Manager, I also went back to the Park scene and updated the Dialogue Blocks with the more recent dialogue that Lilli had shared.
After being more satisfied with the flow of the Dialogue Manager, I began creating a Prefab that I entitled 'DummyNPC', as it contained an invisible trigger box attached to the front of an invisible cube that had the NPCTriggerBehaviour script on it. I added a script to the trigger box that would activate the dialogue canvas and disable the trigger box once it detected that Reggie, tagged with 'Player' entered it. Afterwards, the player need only press F to interact and the dialogue would continue! I used this in tandem with Lilli's concept to contextualize how Reggie would know that a theft had occurred at the park in the beginning of the game, via a TV report. This could also be placed in the beginning of scenes to hear Reggie's internal dialogue.
By this time, the City scene had at least one NPC and all of the placeholder objects, so I assigned the Dialogue Blocks to them and set up the branching conditions, as well as a script that would trigger the Spoken to Target boolean value in the City's Dialogue Branch once two specific NPCs were spoken to.
The script for how the Banana Case would go was also helpful in generating a flowchart of progression for how the player should complete the levels.
I then debugged the scene a little to make sure it worked, even using paper to help the process to ensure I understood exactly what was going on. It seemed that there was another double input bug in the city, but it didn't seem to stem from the Manager's script for once. I decided to learn from the mistake of the past week and call it a day, leaving it to be reexamined with a set of fresh eyes later.
Week 6 (20/10/2025 - 26/10/2025)
Milestone: Vertical Slice
The efficacy and productivity that I expected this week to bring was very suddenly obliterated over the weekend by a phone call from back home informing me of a bereavement of which I had no means to console my family except over a 3 hour time difference on the phone.
So I think it is a little permissible that, for a while, the rate at which I was able to complete my duties became considerably inconsistent.
One of the first additions to the project I made this week was to make a script that had the Interactable interface applied to it, so that when the player interacted with it the scene would be changed to a scene in the project that held the name shared with the string value inputted into the Inspector. Ben and Jess had worked really hard to create a wonderful scene of Reggie's home, a warm and cozy environment that the player would begin the game in, acting as a hub that they can return to in order to consolidate the clues they collect for their big case. The player would then use the bike as a diegetic means of transportation to reach the scenes of each investigation. For the vertical slice, this would be the park.
I then spent the rest of the week up to a few hours to the Vertical Slice showcase setting up the park scene's dialogue and pickups to align with the progression laid out by Lilli. In retrospect, I don't think I went about my process of filling out the scene in a very helpful way; I got frustrated at bugs frequently and ended up pulling an all-nighter trying to address two critical errors: one was that when the player interacted with an NPC, it counted as two interactions instead of one and as a result it was skipping dialogue. The second one was that the branching logic wasn't updating sufficiently when the player returned after picking up the decoy clover and speaking with the second Bear officer
This ended up taking far too long to fix than it should have, and I think my affected mood and disposition were the greatest factors in this, since the time it took to solve issues later on were highly decreased after I started to feel a bit better. On the day of the showcase, I felt deeply ashamed and unhappy with the quantity of work I had managed to display for the week; it could be charitably said that I became quite visibly displeased during the lecture. Luckily, my teammates were completely and entirely supportive of my situation and struggle to accept that the work was not what I had wanted it to be for that time frame. They gave me great comfort and sanity-saving understanding and compassion. It was thanks to their support that I was able to move forward with a less burdened heart and a clearer mind.
Being upset at the problems that arose wasn't going to fix them; systemically testing and debugging to find the source of the problem was. So instead of trying to intuitively find out the single line of code that was keeping the logic of the Dialogue Manager from working the way I wanted it to, I drew generalized lines around which methods could likely be involved in the bugs, and slowly debugged to see what exactly was happening behind the scenes. It was then that I could find out that the Condition checking for Reggie's inventory wasn't happening fast enough (again) for the conversation with the officer.
I tried a few different call orders to circumvent this, but brute-forcing the check in Update if the branch had been tested for once turned out to be the most consistent and effective way of handling it. It was a small but warming joy to see the bug that had just a few hours ago been causing me so much strife disappear from slow and steady work.
This incident made me rethink how I went about debugging this project mentally. I would have preferred it not to have been triggered by events of loss, but I can not effect every aspect of life. I can only control what I do. And for this week I chose to speak openly when I struggled, and to be comfortable, in the case that when steam, power and energy fail, to move steadily, knowing that progress will be reached eventually.
Now that the milestone had ended, it was time to work on the second half of our intended scope for the semester: the first real level of the game. While Charlie was working on reworking the controller and cameras to move more fluidly, the 3D artists were working on crafting the new scene for the case to take place in: a sprawling city street reminiscent of New York. This means a new script, and a new flow of progression to generate and set up. I created Dialogue Blocks and Speaker SOs based off of the script Lilli wrote for the 'Banana Case' and then spent a little more time tweaking the size and range of the Sensebox to better accommodate for interaction, since it was a bit tricky to find the right angle to speak to the officers in the scene prior.
That roughly concluded the work for this week. A new level to work in, a new mindset. Time to continue!
Week 5 (13/10/2025 - 19/10/2025)
This week was spent completing all of the Scriptable Objects I had planned for the Dialogue System, as well as the Dialogue Manager itself and finishing up inventory handling, along with a few miscellaneous tasks. This meant that I could finally retire the placeholder scripts that I had used in project for the Proof of Concept milestone.
For the dialogue system, I created the Speaker, the Dialogue Line, the Dialogue Block and the Dialogue Branch.
This is the speaker object, useful for changing out who's saying what lines at any given time.
This is the Dialogue Line object, which contains a reference for the speaker of the dialogue and the content of the dialogue itself.
This is a Dialogue Block, which is composed of a customizable list of Dialogue Lines and has values depending on whether or not the dialogue is repeatable, whether it branches and whether or not it has been completed.
This is a Dialogue Branch, which contains references to two dialogue blocks based on whether or not the condition of the Branch has been achieved. The Dialogue Branch can evaluate for two different types of conditions: if Reggie has a specific Item in the inventory and if an important NPC has been spoken to.
This is an example of a Dialogue block that will trigger again once the player finishes the conversation and comes back. It also contains a Dialogue Branch reference. When this gets read into the Dialogue Manager, once the dialogue content of the block is concluded, it will execute the Condition checking method in the Manager until the condition has been fulfilled.
Lastly, I completed the manager, which was by far the most difficult part of this undertaking. It holds references to the Dialogue Canvas, and the currently loaded Dialogue Block, as well as containing it's own index to parse through dialogue lines with. When making the methods to load and play through Dialogue, I thought it would be a simple endeavor if I kept everything I wanted it to do abstracted, so that they could be called in a linear fashion. Sadly, the existence of the branching dialogue threw this dream of simplicity and straightforwardness into the gutter for the entirety of the project. So much time was spent having to troubleshoot the order that the logic executed in, particularly in getting the correct dialogue to play without delay when the player returned to the NPC after having completing the quest that the branch required to switch to the Success branch of dialogue.
The final piece to seeing dialogue implemented in a meaningful way was to create the script attached to NPCs that would allow them to have conversations with the player when interacted with. A quick invocation of the Interactable interface and a reference to the single Dialogue Manager in the scene allows interaction with the NPC to trigger the LoadBlock and ShowDialogue methods to allow the dialogue manager to handle the Dialogue Block passed on from rootDialogue as needed. This was obviously much easier to implement after all of the hard work was accomplished in the manager's script, but frustratingly I still had to return this script to rewrite it to fix bugs with how information was being passed to the manager and what methods were called in which orders.
Aside from coding things relating to Dialogue, I also finalized the Item SOs and the code required to pickup Items and sent them to the needed inventory bases in the scene.
Besides coding, I also added some explicit navigation between the item holders in my Inventory UI Page to prototype being able to move through inventory items using the arrow keys. This is definitely something to explore in more detail for next semester, but getting a feel for how it would work is still beneficial while I have the time now. Because of Charlie's work in making a method in the character controller that freezes movement that is also accessible across scripts, I can rely on that work and call that script to disable movement whenever the inventory UI is active, and re-enable it when it's deactivated.
All in all the efforts from this week will be useful to me to set up the plots created by Lilli and the rest of the team and the overall progression of each case, since Dialogue and picking up clues are such an integral part of the game's core gameplay loop and design as a detective game.
The more modular and self-responsible I can make the aspects of the Dialogue System, the less I'll need to overhaul or engineer it in the future, letting me focus specifically on level design. It is an exhaustive process to make it from scratch though, especially since it's already so discouraged when there exists systems that can manage dialogue for you in Unity's asset stores.
Although, there is a greater level of satisfaction figuring out some aspects of this dialogue system from scratch instead of relying on the work and research of others so heavily.
Week 4 (6/10/2025 - 12/10/2025)
Milestone : Proof of Concept
This week was spent developing and refining the systems I had worked on previously, while also setting up the first scene we were going to display for the Milestone.
Before I continued my development on the other scripts, I did wonder about whether or not I should continue work on them or work on a prototype for the present minigame. I already had a few ideas on how it would integrate with conversations, but the logic wasn't really coming to mind the same way the other systems did.
I decided I'd rather have the other systems more polished than try and cram an entire new system within a week.
My refinements began with the Inventory system. I had turned items into a Scriptable Objects format, allowing for easier allocation and keeping track of what clues and objects were in the game. I then created an Inventory system based on a queue that also contained methods that added items, popped items and checked for whether or not an item was contained and returned a boolean depending on the answer. I then created an InventoryBase script so that this could be applied to whatever objects needed access to the items that the player has collected.
The inventory felt both familiar in concept from my secondary school years of Computer Science, since it is based on one of the fundamental data structures. However, I had to do a lot of research to wrap my head around how to make it as modular as I wanted it to be. Luckily, there are a lot of really informative resources on the internet, and I read and watched many of them to ensure the Inventory was up to speed.
I had also struggled with visualizing how the systems would actually manifest in-game, so I spent some time creating rudimentary UI screens to see how the items would should up. I used a Grid Group in Unity's UI system to keep all of the item holders uniform, and then turned the item holders into a prefab and duplicated them 14 times. Lilli helped me pick that number as she said that would be the optimum number both aesthetically and rationally. After applying a script to the item holder prefab that allowed them to hold data from an item SO, as well as displaying the item's description and name in the box at the bottom of the screen.
I also revised the script applied to pickups to hold references to any items in scene that had an inventory base attached to it, so that it would pass the Scriptable Object information to those inventories.
After this was out of the way, I focused on the behemoth that was synchronising the dialogue system with the status of the inventory. I created another script that inherited from the basic dialogue script that checked the player's inventory for a specified Item after exhausting the first set of dialogue lines. If the player has the item, the Success branch of dialogue starts playing, if not, the Missing Item branch starts playing, and continues to do so until the player has acquired the item.
I also assembled all of the dialogue that Lilli had written for the Proof of Concept into the scene onto the models that Jess had created. I marveled a little when loading in the first iteration of the park; I had been working in my own scene for testing, and hadn't seen the work of the others prior, only being familiar with the movement controller that Charlie had created along with the accompanying camera controls. It looked really pretty! I was also happy that the condition checking seemed to work relatively consistently so far.
Of course, whenever that is said something decides it wants to break. Bugs started popping up throughout the week, and when one was addressed two more presented themselves.
After we presented our proof of concept scene, I immediately had things to fix for the next stretch of time, but since I was going to rework the dialogue system anyways, I decided I would just ignore the bugs from the basic dialogue scripts and work on developing the Dialogue Manager, along with all of the SOs related to Dialogue in the game.
I felt a little harried this week due to the milestone, but after getting the go-ahead from our lecturers and touching base with the team, I felt a lot better about the state of the project; the proof of concept achieved what it needed to, and now all I needed to focus on was making things better, which was the plan from the beginning. I was excited to work on the Dialogue Manager to make scripts and objects more single-responsibility, as well as exasperated at the amount of debugging I knew was in store for the future. To the next milestone we go!
Week 3 (29/09/2025 - 5/10/2025 )
This week was the first week of dedicated programming done in this project: After the itinerary for meeting the second milestone was developed, all I had to do was sketch out how the inventory, interaction and dialogue systems would work out and then implement them in code. I created my own branch in the Unity project for the game to test my code in, and got to work.
Interaction was the easiest system to implement: I added a trigger collider cube named 'Sensebox' in front of Reggie (the protagonist's) model and attached a script to it named 'Interaction'. Then, I created an interface named 'Interactable' that I could apply to any script that needs physical interaction to trigger it in any way, like speaking with an NPC or picking up a clue. Using the OnTriggerEnter method, I can check any objects that overlap with the Sensebox and check to see if they contain the Interactable interface. If so, it will trigger the Interaction Behaviour method that each script with the Interactable interface inherits. That's essentially the bulk of the interaction system; now all that's needed is to craft specific scripts for different interactions in the game.
Next, I wrote and looked over notes for the robust version of the dialogue system that I had planned for use in the games development.
It didn't take long to realize that perhaps what I had planned was a little too complex to get comfortably finished before the deadline. Therefore, I pivoted and created a simpler dialogue script for the proof of concept that simply held an array of lines to set in the inspector, that iterated through the dialogue until the index matched the number of items in the array. This would enable me to start workshopping the more complex dialogue system while still having something to present for the proof of concept.
Next, with this logic in mind, I created a simple inventory script that stored the string name of whatever object it picked up, and an object script to attach to pickups that would respond to the said simple inventory and pass along it's information before deactivating itself in-scene. This would also give me more time to make a more modular inventory system, as it would be crucial to link it to UI elements for the player to examine throughout their adventure.
I felt a little inadequate of not being able to put in more robust systems in earlier, but I knew that we had a long timeframe for the project, and that for the moment I just needed to focus on making it basic and functional for now, and that the complexity could increase over time with experimentation.
Week 2 (22/09/2025 - 28/09/2025)
Milestone: Pitch Presentation
At the beginning of week 2, we began to have more detailed discussions about planning our development alongside the time frame that we had. As stated in a previous dev update, we wanted our level design to be as modular as possible so that our development timeline wouldn't be overrun by any unforeseen blockers, and this week was spent examining how development would look across our allotted 12 weeks.
We momentarily discussed having different endings depending on the actions on the player, but quickly discarded the idea as it was unneeded complexity both programming and asset wise as well as unfitting for the tone that we were going for: the story is meant to be simple and sweet!
After we presented our concept, we quickly began drafting the tutorial level and the first real case, as those were what we decided were a good point to end the 12 week development cycle on: By that point we would have developed all of the core mechanics and have at least two completely furnished environments for the player to explore, allowing us to spend the second development cycle focusing on level design with all of the previously developed tools.
We wanted the 'first' case to act as a prologue of sorts, introducing the overarching case by presenting it as a mystery that the player initially solves in the beginning of the game, and then finds out is actually unsolved. I really like this choice as it acts both as an introduction to the main conflict and also leaves the player with a sense of dissatisfaction after having something they had mentally perceived to be 'completed' as 'incomplete' for the majority of the game, spurring them on to complete the quest of finding the real Clover statue.
We mocked up the progression for the prologue, deciding what environment we wanted it to be set in and also what we wanted prioritized for the upcoming Proof of Concept milestone. This gave both programmers and artists tasks to complete and clear direction to move in. We also decided that a good mechanic to have as a part of the core gameplay loop would be a 'present' minigame, where the player would have to present evidence during an NPCs (unofficial) testimony that would prompt new dialogue to appear to progress the case.
We also quickly mocked up what the first level of the game would be like since we were already in a narrative - heavy meeting and decided it was best to get it set up ahead of time.
After our meetings, me and my fellow programmer charlie discussed dividing our responsibilities based on what systems we wanted to handle ingame. We agreed that he would do character movement and camera work, and I would handle character dialogue, interaction and inventory. This works out really well because I hate calibrating character controllers with a vengeance, and love working on more backend systems that can be represented through UI and other visual elements later.
I was a bit disoriented by the order that things needed to be done, but since the next milestone was simply proof of concept, I knew my priorities had to be in the somewhat simple order of interaction -> Dialogue -> Item pickups. Laying out the priorities of what needed to be done for Week 4 helped keep things orderly.
Week 1 (15/09/2025 - 21/09/2025
This was the first week that we were assembled as an official team, and we had a lot of work ahead of us. Our first milestone was to give a pitch presentation of what our game concept was, so we spent an entire afternoon developing the concept on top of the basic premise we had agreed upon during the summer.
We decided on creating a detective game, with 'cases' being different levels, similar to how ace attorney handles its cases in an episodic fashion, but scaled down significantly to account for scope creep. We agreed that if the game had an overarching plot or case that was furthered by completing several smaller cases, we would have greater control of the scope and could cut off the project at any time after our beginning, middle and end were established, adding cases when we had time that integrated into the main plot but not needing to plan a specific amount as long as an odd number was achieved. The structure of having cases as levels were also interesting from a design perspective as their isolation from the other cases could allow for unique mechanics in each case if we wanted.
Another inspiration we decided to use to craft the atmosphere of the game was a previous project that two of us had worked on prior called 'Mystery of Bramblegrove', a light-hearted visual novel about a detective-novel enthusiast librarian who decides to take on the investigative mantle when a theft happens in her small town. The low-stakes and simple crime contrasted with the complexity of the game being concentrated in the character motivations and dynamics across the cast were the main draws for using this project as inspiration for Cases in Cloverdale. I was happy with using this as an aspect of developing the concept, as I had enjoyed working on Mystery of Bramblegrove with my friend Lilli, who was also taking the role of narrative lead for Cloverdale.
The main mechanics we discussed during the meeting were that the protagonist would be able to traverse a world filled with NPCs to speak with and clues to pick up. Then, to align closer to the design of most typical detective games, we decided that we would need to implement branching dialogue based off of whether or not a player had a certain item to trigger dialogue to progress the investigation.
This could be useful for setting up fetch quests and for allowing the player to present evidence that could prompt an NPC to divulge more critical information. The idea of combining the dialogue to advance a detective's investigation with a personalized dialogue system that would work in harmony with the detective's inventory excited me greatly, despite knowing that such a system would be finicky to create from scratch. Having a lot of previous experience with making different inventory systems for a player and having game objects and puzzles react to the presence of specified items in the player's inventory, I volunteered to handle both of these systems together.
Lastly, we decided to lay down the skeleton of the plot so that we had an idea of what we were crafting the smaller cases around.
The gist of the plot would be that a nosy private investigator raccoon, who is frequently mistaken as a detective, is called to action to research the case of the city's missing heirloom: a statue representing the first clover that ever grew in the gardens of the central park. The game would be spent solving smaller cases that are tangentially related to the Clover case by small clues left behind by the culprit, until the player has collected enough evidence to find their suspect.
This would result in the game's finale of confronting the culprit, who would be a 'cat burglar'. However, to keep in line with the low-stakes atmosphere of the game, the PI will choose to let the culprit go in exchange for the clover statue so that everyone can get a happy ending!
Finishing this meeting made me really excited to begin development. After we agreed on the direction of the game and collated all the ideas we wanted to keep in the game, we divided the work of writing up the slides for the presentation based off of what we would be working on. We had also used this meeting to ascertain our roles:
Project Manager/ 3D environment and prop artist - Ben
3D character and prop artist - Jess
Programmer - Charlie
UI Artist and Narrative Lead - Lilli
Programmer - Me
Week 1 of development was over. It was time to get ready to present our ideas and begin working using the feedback!
Pre-Production
Our team came together before the beginning of the project and began discussing simple ideas in order to avoid getting too invested in a concept, only for it to not be within the requirements of the brief. The main conclusions we drew before officially forming as a team was that the game would be lighthearted, narrative-driven and feature anthropomorphized animals as the main characters, modeled in a low-poly 3D art style.
I took this time to review the code from some of my old projects, as I didn't want to commit to creating any systems that may end up discarded, but also wanted to see if there were any basic/generalized systems that could be reused or worked upon later. This also served as a nice refresher of how to set up naming conventions and how to limit dependencies on other scripts to fulfill desired goals.