Game jams are kind of like a roulette of good and bad luck; you never really know how a game will turn out until the jam in question is over. I participated in the 132nd Trijam, a couple of weeks after my last submission, Bug Bounty, thinking I’d have a relatively smooth experience like the last one. I was mistaken; this particular game jam took a quick turn in the direction of surprise.

The theme of “package delivered” couldn’t have been more perfect, as it provided many possibilities. I decided to take my background in Swift and use it as an inspiration for this game, where collecting packages to deliver them to a fellow Swift developer is the main goal.

For this project, I decided that I want to try out a few things:

• Keep all game jam ideas, roadmaps, concepts, etc. in a single place with Notion;
• Write the game in a different language, preferably Swift;
• Collaborate with someone on the game.

Keeping everything in Notion was very handy; I have been trying out the service for a while to keep track of projects and other developer logs, and it was great to write everything in a single place. It also came in handy when sharing it to other collaborators.

Initially, I wanted to write the game’s code in Swift instead of GDScript, the default language Godot uses. I tried using the godot-swift package created by kelvin13 a couple of days ago, but I couldn’t get it to run correctly on my MacBook. It’s being worked on, however, and I anticipate I will be able to do so in the future. I also considered trying out the Kotlin port a là the JVM, but I didn’t want to risk using it since it might have taken much longer to even learn it. Eventually, I settled on something close enough to Swift: C#.

Huge mistake. What would’ve taken me a a couple of hours, maybe even less, took almost four hours to write. It could’ve been that I was rusty in C# (the last I used it was about four years ago), but I felt that I was going much slower than anticipated. Ranging from problems with writing the code necessary to generate obstacles and move the player to debugging issues with the C# solution and getting Mono to work correctly, it felt more like I was fighting with the language than I was creating the game. Not even Rider could help me entirely, though I do give props to the JetBrains team for making a kick-ass IDE for C#. I decided to scrap everything I had, reset the timer, and try again the next day.

At the same time, I contacted Raseruuu, the artist responsible for the sprites in my previous commercial game, Unscripted, to join me and create the main menu artwork. They seemed to have a pretty easy time with drawing the sprites, finishing it in exactly three hours on Sunday. I’m pleased with the results, and I’m sure everyone else will be, too.

As I was rewriting the game, I implemented some power-ups to make the game a little more interesting, learning from the last time with Bug Bounty. I had to refactor the random generation code to make sure that everything worked out decently, though I could’ve spent more time on a better algorithm rather than relying on Godot’s devices. I designed the game loop in such a way that when the player reaches a certain point on the may, they teleport back to the top, and everything is re-generated on a random basis. The only way I could get it to look remotely seamless in the time that I had was to compromise by not having the player start at the top. Sometimes it’s not that seamless because the obstacles can generate in the region where teleporting occurs.

I decided to make a playable testing build and get feedback on it to make any adjustments before submission, like what I did with Bug Bounty. Sadly, the amount of feedback I received was very little, with a suggestion to improve the random generation so that the player was not immediately placed in front of an obstacle. I did some minor adjustments, though it might not have been enough. Regardless, I had to make do with the feedback I had, add in the last visual assets and audio assets, and submit the build. Thankfully, I was able to have Snapcraft and Ubuntu Touch builds out of the gate by copying over the source from my other games and modifying them.

It’s just been about a day since I published the game, and I have received some feedback on the game. On the front of Ubuntu Touch users, reception was overall good, with one reviewer having slight difficulties with the game. At present, the Itch.io jam submission page had slightly different reviews, some of which would’ve been nice to have known before submission. I did have to write some clarifying information to justify the decisions made, but I do acknowledge that the game could use improvement, especially with the random generation algorithm and the endless mode glitches such as the time power-ups.

In summary, here’s what I have learned from participating in this jam by making Package Resolved:

• I will personally never use C# for game development for a long time. While the C# support in Godot is pretty robust and Rider works really well with it, I find it too verbose and less efficient. I may try using the Kotlin JVM port in the future or even the Swift package when I can get it up and running, but for now it seems that GDScript is the way to go. I’m sorry, Microsoft Java.
• Start early to get feedback. I believe that part of the issues surrounding feedback resides in the fact that I had made a build just a day before submission to ask for feedback, so this might improve the situation. By contrast, I was much earlier in my building for feedback with Bug Bounty, and I got plenty of suggestions.
• Assemble the team early. The sooner I can assemble a team before a game jam starts, the sooner work can get done. This isn’t particularly important given that Raseruuu worked pretty quickly, but any bit helps in the polish.

I may make some minor updates in the coming weeks to address the issues I’ve noted, after Rocknight Studios streams everyone’s submissions on Twitch.