What is this game?

Chasing the Spotlight is a first-person platformer where the goal is to get as many points in three minutes by standing under a spotlight that disappears and reappears in various locations on the map. This was a solo project done for Full Sail's first ever game jam during Hall of Fame 15 in which I had roughly 24 hours to create a short game. When the results of the game jam were announced, it was revealed that I won the best solo dev award. Even if I didn't win that award, I was still proud since this was the first project that I completed that was outside of my time in the Game Developer Bachelor's and Game Design Master's program. This post will go over things I felt went right during development, what went wrong during development, going over my though process on how I went about the project and why, as well as what I plan on doing in the future for both the game and in general.

Why?

After submitting Chasing the Spotlight and being able to talk with the in-person judges and other jammers about it, there was a theme that I got from the questions I was asked or statements that were made when I would talk about it. From that there were three 'why's that I wanted to go over before diving deeper into the game:

Why Godot?: When using a game engine during my Bachelor's and Master's programs, I've used both Unity and Unreal for both group projects and solo projects. I've messed around with Godot here and there, but those projects ended up not going anywhere either due to low motivation or no real start point plotted out. I've recently heard about the Func_Godot addon and how it allows Godot  to load maps made in Trenchbroom, a level editor primarily used for Quake mapping. Since I had recent experiences with it, I wanted to use Godot as my go to engine for this project to have a project to showcase for Unity, Unreal, and Godot.

Why Trenchbroom?: Utilizing the brushes in Trenchbroom allowed me to make a map layout with some complex geometry fairly quickly. Level design is one of my weaker areas in game development, and being able to use a program that allowed me to make a complex level rapidly make me want to use Trenchbroom with this project.

Why Solo?: Going into the game jam, I knew I wanted to use Godot, Trenchbroom, and Wally, a texture software also used for Quake mods. Since I didn't have a team going in, if I was to be in one it would be with people who may have experiences in multiple engines and software. Asking other people to use an engine, mapping software, and an addon for the engine that doesn't play very nice with source control that they probably don't know much about would lead to a lot more issues and hang-ups that would have lead to an unrefined end product. Knowing that, I decided to go solo since I'd rather have the time limit of the game jam be the only stress point. This decision also gave me the opportunity to work on areas like level design and texture work that I have very little experience in from previous projects.

What Went Right?

It was Nearly 100% Original: Most of the game code and assets were created by me either in Godot, Trenchbroom with Func_Godot, or Wally. The only asset not created was the sound effect for the spotlight. While the quality of each asset varied based on how experienced I was in those areas, I personally feel proud that I nearly created a game with all original assets.

Expanded Knowledge: With only having some experience with Godot, this was my first time creating more complex scripts, loading another scene, and utilizing the control nodes for UI. I used tutorials online to get a decent idea on what to do, but I was able to expand on what those tutorials would show off. One point I would mention is how similar Godot's UI workflow was to Unity's UI workflow which allowed me to quickly create the UI with very little issue.

Great Time Management: Outside of one pain point that I'll go over later, I was able to get most of the game logic working before the rooms for the game jam would reopen at 8:30 AM on Monday. I still had to add a few features into the game and it was only a 7 hour gap since I stopped working around 1:30 AM, but i was able to add those features, debug the game, and export and post it 50 minutes before the end time.

Feedback, Feedback, Feedback: With a lot of my experiences with game development and design focusing more on UI and UX, I wanted to have a major focus on the readability of the game, the ease of use with the controls of the game, and prevent as many misinputs with the UI. I added features like having the UI buttons glow a different color when hovered, having a sound effect play where the spotlight will be to allow players to preemptively move to the new location, and turning a directional light on and off whenever the spotlight was hidden and revealed respectively to make it more noticeable when it was active to best ease players into understanding the game. I also added a help section on the menu going over the controls and goal of the game. With the game being only 3 minutes long per playthrough, I'd rather add roughly one minute to that to read up on the help section rather than adding four or more minutes on top of it due to a difficult to understand menu.

What Went Wrong?

Diving Deep With No Suit: Before and during the initial presentation for the game jam, all I knew was that I wanted to make a first-person game in Godot and that was it. I had to think up of a gameplay loop on the fly that not only could be done in the time limit but was also able to be scaled down to the 1-3 minute gameplay time that was recommended to aim for. I luckily came up with the spotlight mechanic by thinking back on the simulacrum game mode in Risk of Rain 2 where players would have to stay in a bubble to not take environmental damage that would occasionally move to different locations. While the process of having to think up of something on the fly is normal for game jams, I feel like I spent too much time thinking too much about that.

Too Much Ping-Ponging: After setting up Func_Godot, I ended up bouncing around on trying to get as many features done and leaving some on the back burner. For example, I worked on making the level, then I worked on the player, then I worked on adding stairs, then I worked on adding stair detection for the player before realizing I could just make a ramp and make the "stairs" have no collision, then I worked on the spotlight visuals and collision, then I added a game manager to add game logic, then I added an in game HUD, then I added the ability for the light to disappear and reappear, etc., etc., etc. Since I was working on all of these features on my own, I always had the thought of "What if I don't work on this and end up having it unfinished?" which caused all of the bouncing around when developing the game. Although I'm not 100% sure this was the case, but I believe that this led me to cut the timer that would display how long until the spotlight would stay active or inactive for on the in-game HUD. While this wasn't an issue once I was nearing the submission time, a big factor that helped was that I ended up making a list of the final features that needed to be added.

Weird Code: This wasn't a major issue since it functioned fairly well when showcasing it, but there was some code I wrote that either I knew was risky or after taking some time to dwell on it after the fact going "What the hell was I thinking?" One example of this was the spotlight movement logic that would roll a number represent a spot and reroll if it was one of the previous two rolled spots stored in an array. When writing it, I knew there could be a risk of having the game stall on from some edge cases. When going through the in-person judging process Alejandro García-Tuñón, one of the judges for the game jam and an inductee for Hall of Fame 15, suggested having an array holding unused spots and rolling based on that mentioning that same issue as the reason for the suggestion.

What Now?

For Chasing the Spotlight, an update will release shortly that fixes a few issues that I noticed after submitting the game as well as implementing the suggested spotlight movement logic that Alejandro mentioned during the judging process. I was going to also add in other features such as reintroducing the spotlight timer for the HUD, but after recently talking about doing that when talking with Tom Todia, he mentioned that sometimes it's fine to have a project be finished and not complete mentioning that some things aren't meant to be worked on forever. Thinking on that, I was planning on making it so that both the updated version of Chasing the Spotlight and that original version for the jam, warts and all, would be available for download. 

On top of the update, I was also going to add comments onto all of the scripts I made for the project and linking the GitHub repository so that anyone interested in Godot, Func_Godot, Trenchbroom, or the game logic in general could take a peek at the code and mess around with it. Even though it's not a super advanced project under the hood, I believe that it can be used as a springboard for those who want to try out Godot. I'll also add a text file going over how to make it so that Func_Godot in Chasing the Spotlight and your own Trenchbroom download can work in order to look at the level with the latter since I will reiterate that Func_Godot has been known to not play nice with source control.

As for future projects, I plan on making similar small games or test cases in Godot since there's a lot of ideas for features that I've been thinking of on top of the possible ideas I wanted to add onto Chasing the Spotlight. I'll make sure to improve on some of my weaker areas by applying a few ideas for them like having a checklist for game features and having a more formulated idea on hand before staring it.