Cursed Dungeon - Dev Log #1

This post is designed to talk about the development of the prototype for "Cursed Dungeon",  a project fully developed by me to be submitted into the Boss Rush Game Jam 2025. This blog post is intended for employers or anyone who is interested in seeing my process in game development. This post is also intended for me so I have something to look back on and reflect on once I get farther into  my game dev journey. 

What is Cursed Dungeon?

Cursed Dungeon is a 2D arcade-style game where the player must complete puzzles regarding a stone mask with a big spinning eyeball that the player must stop at the right time. To be more specific, the player has found themselves lost in this seemingly endless dungeon where in order to progress to the next room, they must complete a challenge to unlock the door. Above every door is a stone mask with a huge eyeball in the center of it that is constantly spinning in circles. During a challenge, the player must stop this eye (with the space key) exactly when it is looking at a floating lock sigil to destroy the sigil and unlock the door. Sounds easy right? The challenge comes where the player has to deal with tons of distractions potentially obstructing the view of the sigil. Also, there is a time limit for every challenge. Finally, the player will continue to progress through fast-paced levels that increase in difficulty until they eventually fail and are given their final score.

Pre-Development

Before I even started working on the actual prototype. I started creating diagrams and a GDD (Game Design Document). I wanted to ensure that going into development I had a pretty decent idea of what exactly I was trying to implement before I even started so that way I wouldn't get lost in design choices before I had even implemented core gameplay features. Below you can see an early sketch I made for the design of the gameplay as well as a diagram I made for the game's states:

The purpose of these diagrams was to give me a rough flow and visual graphic of what the game would look and play like in order to speed up development. The Game Flow Diagram was especially new to me because I have never needed to create a game with this many general states before and I wanted to ensure that every cutscene that played in between challenges of the game had its own state. This felt necessary for syncing reasons, though later in development I would find myself having trouble finding the most optimal method of syncing events that would occur after or during a cutscene. 

Prototyping 

Note: This section includes alot of technical jargon. Skip ahead to Finished Prototype if you don't care.

The prototype for Cursed Dungeon is purely designed to just handle core gameplay functionality. Attached below is a screenshot of the requirements for this prototype as stated by my GDD:

When creating the prototype for this game, given that it was my second game, I was feeling unsure exactly on how to approach script communication and handling the game's numerous states. I understand that I could've used a state machine when creating the game, but due to me not being very familiar with state machines and time constraints to push out an initial prototype I instead opted for a more event-oriented approach. However, this presented a unique challenge of trying to keep my code as decoupled and understandable as possible. In order to do this, I used events very sparingly and in situations where it felt completely necessary.  Below is a Script Communication Diagram that shows how I used events and occasionally references in my GameObject communication.: 

I'm gonna avoid diving too deep into detail about my scripting design choices and instead talk about the choices I made that I believe are the most significant. My biggest challenge with creating events revolves around whether or not making an event for something is necessary or not. In order to tackle this, every time I thought I could create an event to solve a problem I asked myself: "How else could I solve this problem that doesn't involve event usage OR direct references to properties OR adding code that would constantly doing unnecessary comparisons every frame." For example, let's take a look at the most important event I have in this game: OnPlayerStoppedOutcome. In the game whenever the player stops the eyeball, the player needs to communicate somehow of whether or not it has stopped on the lock sigil so the rest of the game knows whether or not the player lost. My original plan was to make an event in the PlayerController that told the GameManager that it had failed or succeeded the challenge, which would prompt the GameManager to tell every other script in the scene that the challenge has ended. However, this felt as if it would be adding an unnecessary extra layer since the PlayerController itself already knows that the challenge has ended once it has stopped and the GameManager is essentially just acting as a relay point. Thus, I created a static event (OnPlayerStoppedOutcome) to relay to all scripts in the current scene that the challenge is over while also passing the challenge conclusion status in the form of a Boolean. This mindset is what allowed me to reduce unnecessary layers of relaying in my prototype. 

Finished Prototype

The final prototype of the game ended up being an extremely bare bones demonstration featuring only core gameplay functionality and no sprites, sounds, or music. I have been working on the sprites and music myself while developing the prototype and I plan to implement them in the next stage of development starting very very soon. At the bottom of the page are some images of the early prototype and thanks for reading my dev log! I will post a new devlog for every stage of development of this project (so two more atleast) so stay tuned! Next dev log will be covering the Beta game where I implement sprites, difficulty, saving, and in-game options.