Bloops (GGJ 2025)

Role

Gameplay Programmer, Associate Producer

Contributions

Enabled 9+ complete levels through creating an in-game level editor using C# & JSON serialization.
Created level scoring and state systems, with event-based practices for easy adjustments, and collaborated with UI programmer to integrate with menus.
Gathered everyone's goals in the team of 10, and collaboratievely maintained a task list to finish our polished experience in 48 hours.

Development Time Team Size

48 hours 10

Genre

2.5D Cozy Puzzle Game

Platform Engine

PC Unity 6

Bloops (our team-favorite onomatopoia for the year's theme, "Bubble") was the name of the game we made for the Global Game Jam 2025. (Event Details Here: https://globalgamejam.org) Alongside a team of 10 programmers, artists, designers, and a composer, our team's shared main goal was to make a concise, polished experience.

With this, I think we were able to create something polished, which we got some nice reactions from players from, and a few main key factors helped this.

Taking Initiatives and Using Everyone's Strengths

First, everyone was quite capable and ready to take initiatives in their own disciplines, and even areas outside (like programmers volunteering to find & implement sound effects), and I was quite lucky to be a part of this group. Looking over it, we had enough people to cover major areas of the project, such as a group of 4 artists who were already tight-knit and had worked in fast settings together, and a programmer/ designer dedicated to UI programming, that we were able to iterate the quality of the project, from environment models, to menus, to iterations on the bouncing bubble's behaviour, simultanously instead of one at a time. So, even though there was a rush at the end of the time frame to fill in holes in hooking up the full polished game loop, we had the polished game loop to hook up, and each member's intitiative and expertise made sure of that.

As for my programming contributions, I focused on the game state logic & integrating it with the menus, as well as making a level editor, so that we could support multiple levels, and have a full game loop to iterate on.

Programming Example: In-Game Level Editor

While making a level editor for a 48-hour game jam may sound like overkill, with the rapid changes we were making to the level scene itself, it was clear we needed a way to easily save and load level puzzle configurations, independent of whatever state the level was currently in.

Also, knowing that our game already featured object placing, I was able to extend the system to allow level editing that benefitted from existing code, and the UX improvements to placing/ removing objects that the team was already doing.

Level Saving

To save edited levels, and load them in game, I made a level save file setup using Unity's JsonUtility helpers

To save a level, we didn't need anything too fancy, beyond saving and loading the initial state, so I iterated over the level grid, and saved each object's name, so that it didn't take up too much space in the file, and we could spawn the matching object prefab when loading in.

I also saved the object's position, and most objects didn't rotate, but I added saving the rotation so that the bubble spawner's rotation could be saved.

Then, I saved that information into a file using Unity's JsonUtility.

The resulting file saved to this format

While I knew that this could potentially create quite a long file, our levels had a limited grid size of about 12 x 12, so I tested larger levels to see if optimization may be needed. The maximum size was only around 30 KB, which wouldn't cause any sort of performance or memory issues. So, I kept an eye on it just in case files got closer to 1 MB or above, and moved on. And, further optimization didn't end up being needed.

For loading the level, after troubleshooting on what the options for reading in were, I loaded the levels like this: Reading save data inro a struct, which had a variable for our array of map objects, and eventually, the info for the goals of the map and resources you had available to complete it.

Example of saving a smiley face made of bouncers, and reloading after closing the game in the editor

The result, after testing it with our level designer, and making fixes/ adjustments, as well as adding a few UI buttons and editor hotkeys, enabled our designer create the 9 levels that ended up in the final game. (3 of them pictured below)

The next piece of what I belive helped us to create a polished game, was that we had a clear shared goal of making a concise and fun experience, that we agreed upon in the beginning.

Production Example: Clear vision, and tasks for it

We didn't have a dedicated producer, and just like most of the roles in our team, production was driven by people taking initiative, and communicating as they did.

Finding a Shared Vision

With this, in order to help the team get what they wanted out of the jam, in a pre-jam meeting we had, I first asked what each member personally wanted to get out of doing the jam, and what roles, if any, they wanted to be able to do.

The consensus was that everyone, in one way or another, wanted to make a polished game, and didn't care much about the size of the game as long as it was fun and refined. Furthermore, people didn't have a much of a preference on what type of art, programming, design, or audio that they did.

Knowing this, it helped us scope down our initial ideas, and come up with our MVP cozy puzzle mode, with a stretch goal of making it into more of an endless mode. And, as we found out through the jam, the puzzle mode was enough to be fun, but also plenty of work to create, and this ended up being our final game, alongsite a full main menu, level select with level scores, settings menu, pause menu, and credits menu, to complete the loop.

Task Tracking

To help achieve our target level of polish, during the jam, once we had made our goal game loop, I created a master task lisk, and kept up with the team to check it off, to make sure we fully defined the scope of features we intended to make, could cut features as needed, and to track our progress in one place.

Example screenshots of the task list's A bucket:

And ect.

The list was categorized from buckets from A, B, C, and E, decreasing in prority, with cut tasks in the E bucket. Tasks were further split into categories of mostly the disciplines who would do them, then main areas of the game within those disciplines.

In reflecting on this approach's usefulness for the jam, I have a few key points:

Having it in google docs was a nice and simple format, and also helpful that teammates could leave comments on task progress.
Not everyone referenced the document, so it required at least myself to keep an eye on it to double check if any items were missed, and others checked off items as well.
I think it paired well with our team of people who took the initiative to delegate tasks within their discipline, like gameplay programmers and designers splitting up tasks, the art team splitting up their own tasks, and our UI programmer covering all menu tasks, and communicatng when art was needed for them. I'm not sure how thoroughly the document was referenced by everyone, and a lot of the smaller tasks may already have been communicated about such as between the artists, so I think more specific approaches may be needed for teams that entirely haven't worked together before (our team had a few groups of people who had). But, regardless, having a generally comprehensive list of the project's tasks, like the sections shown above, with tasks separated by discipline, helped us to see that our scope was plenty for the game jam, and that we shouldn't add more to it. And, it gave us a document to come together and check things off of from, to help communicate our progress to each other.

So, for choosing how to manage tasks in the future, at least for a smaller team & shorter timeline project, if given the choice and I was setting it up myself, I think I would keep a similar simple document approach like using google docs. And, I would try to present it to the team as early as possible in the process, and make sure at least one teammate from each discipline was referencing/ adding to the document, to help know that we were all on the same page about the scope of the project, and what tasks existed.

Project conclusion/ lessons learned

Overall, we had quite the ride, and this was the result; helped by having an awesome team that communicated and took initiative in spreading out tasks to iterate on many aspects of the project at once. And, by our concise focus that we all agreed upon from the start.

Personally, this project helped me practice recognizing the scope of a project, and adjust my style of implementating systems accordingly.

And, this jam was also good practice in trusting my gut on what production practices are helpful to initiate, even on a team that's communicating well.

Adjusting implementation to scope: Even with only having 48 hours, the normal concerns for making mechanics/ systems modular to support future tweaking and iteration didn't go away, they just needed to be used wisely. For example, making a level editor did end up being quite helpful, avoiding conflicts and potential redone work with the constantly changing level background, like we had already been having. But, if I hadn't gone with the simple event-based approach to the game state management I implemented before it, and moved on early, I may not have had enough time to dedicate to the level and score saving, and to get those systems to our level designer to utilize.

Production practices that can be helpful regardless: The main examples I tried and found helpful were gathering our personal goals ahead of time to make scoping our shared vision easier, and keeping a master task list that was updated, even when it required some of people's time to group up and check off, so that we could have a place to see a clear full project scope, and our progress towards it.

I had a lot of fun on this jam, and felt like I learned a lot from the short timeline, and from seeing the different initiatives taken by each member of the team to make the amount of polish we did on the game possible. I'm definitely excited for the next chance I get to do a game jam with a team.

And, you can check out Bloops for yourself on the game jam website, and/ or in this trailer below:

Game Trailer

Site link with Game Download:

https://globalgamejam.org/games/2025/bloops-6

Gameplay example, placing a bouncer (highlighted blue) to continue the bubble's path

Level select menu, including saved player scores from 0-3 stars, which I also saved using JSON.

Page updated

Google Sites

Report abuse