After a long, very long hiatus from Ludum Dare, I finally found myself having the time to commit an entire weekend, so I decided to join the compo. While I got back in the rhythm quite quickly again, I definitely noticed that I lost my touch with the tools. A lot of extra time was spent on wrestling my way through the tools, until I decided to do thing my own way, and not the tool's way.

On the one hand, I had hoped to make something much more polished and with a lot more content, but after yesterday's struggled, I started fearing I wouldn't even have a finished product! Somehow it all got together though, and so hereby I present my game: Pineapple Police.

Unfortunately I lacked the time to really have the theme be visually present in the game, but the flavour text will have to do. There is no audio either, but oh well. All in all I am quite pleased with having some result. This weekend was the first time in a long while I managed to spend a whole day just focused on a thing, so I am super glad that I participated.

I will see about joining up with somebody else next time, I would have loved to spend more time on polish, but for now... I am satisfied.

Good luck to all the rest of you still working hard!

First and foremost, you can try out our entry here. It supports web, so no shady downloads involved :wink:

This entry was the first entry where we worked together as a team - and for me the first time participating in a team format to begin with! We made the classic mistake of starting off with too ambitious plans, but we learned a lot in the process. Here are the top lessons we are taking away into the next jam:

• When it became clear that there wasn't enough time to get all the cool ideas we had into the game, we swiftly shifted focus to making sure we got the most of the mechanics we had in place. It's a competition after all, and we didn't want to end up with a "great idea, poor execution".
• We started at a disadvantage. We had done some preparation to learn Godot (yes, we switched from Unity to Godot as well, but we make that decision before it was cool), but ultimately we made some poor decisions which caused problems by the end. Yes, we hear your feedback about the font, we don't like it either! Our UI was a pain to not break in the end. For next jam, we want to prepare some basic helper functions just so we don't have to spend time scripting pretty basic things. The template we'll use next jam is available here. It's still very barren, but it will grow in the build up to the next event. You hereby have our permission to steal any code that you find useful (we may include some branding assets which we'd like you to leave alone for obvious reasons!).
• Start smaller. If an idea relies on any mechanic containing "multiple things" (multiple levels, multiple enemies, etc.) to actually be fun, you're probably already set up too ambitious. We'll be refining our ideas more next time to see if the absolute bare minimum is still good, and only then start thinking about how we can expand on it in the most impactful way.
• Ugly code ftw. We're both software engineers, and over our years of experience we've built up an intuition that makes us do things the nice way. Thing is, they often also require more time to do. In the scope of 3 days, it really doesn't matter if the code is unreadable by the end. So we'll need to start ignoring our instinct, and start accepting that totally butchering best practices is not just acceptable, but even beneficial to get more done in a short amount of time!

Overall, we're really happy with the result. We had a tonne of fun too! Still, there are always things to improve upon, and we hope these tips may be useful to others too.

As you can see, we love learning from our mistakes (and successes too!), so we'd massively appreciate any feedback you leave behind on our entry. We think you'll like it :smiley:

Do you still remember the thrill of graduating from college? Did it involve occupying the body of an imp? Well, you can experience both in Eldritch Vessel Academy!

Play directly here

(Yes, in your browser, isn't that convenient!?)

We love ratings, but we love feedback more, so don't hesitate to leave a comment. Of course, also let us know if you manage to beat our time to finish the game!

Before I go into detail about what went wrong with our game, rest assured: we did actually submit our game and we're proud of the result. We'd love for you to give it a try and leave us a rating, a comment, or both! No web build available unfortunately (more on that in just a second), but you can download the Windows and macOS builds right here.

The game is absolute hopping (if you catch our drift)!

Beware all Godot users, we want to hear your experiences! This is the third time we're participating in Ludum Dare as a team, and the third time we're using Godot. We always run into one problem or another, but usually we manage to sort things out. This time though, the end of the jam put is in a bit of a... jam I suppose. No matter what we tried, the web build just wasn't working. We're both C# engineers from experience, so we're using Godot 3.5 Mono so we can get the web exports (Godot 4.x only supports the web platform when using GDScript). While the Windows and macOS builds worked as expected, the web export runs into an absolutely mind baffling bug: a static class field gets reset to its default value (null) and well, given that this is our central singleton object, everything breaks! Maybe our code name for this project - Bug Chess - had become a bad omen.

We spent several hours debugging and searching online to no avail. Unfortunately, this ate into our time for getting the extra bit of polish out in the end. Even post-submission we spent a few more hours, but we've head dead ends everywhere. Combine this with the editor becoming unstable and crashing regularly, and we didn't end the jam weekend on the high note we were hoping.

For next time, we're considering how to address this. If web builds become a "maybe, maybe not" affair, we might as well switch to the latest Godot and get all of the great new features. We're also considering finally making the plunge and switch to GDScript, which may be more reliable to begin with.

This is why we'd like to hear from you! Have you ever had trouble with web exports in Godot? Maybe even had this exact same issue? Have any of you switched from C# to GDScript in Godot and if so, what were your experiences? Does anybody use the mono version of Godot in the first place?

Once you're done answering, don't forget to still play and rate the game.

P.S. The web build is published right here in case you're a bit weird and love to see a dev console full with errors :smile: