First time doing LD here, hopefully it goes well. Only a few hours left :open_mouth:

I have so many ideas, but I can only do one.

My game is a generic match-3 mobile game but also a text-based adventure game. Stay tuned to find out more!

If you haven't tried Oceanscapes yet, feel free to check it out!

I had a ton of fun making Oceanscapes. It definitely wasn't the best game though, and there was a lot of stuff I could have done better:

Graphics

The graphics are terrible. Of course, this was done on purpose - the player is meant to be trapped in a really bad mobile game. However, the graphics were still disgusting, and I don't expect any five- (or even three-)star ratings for graphics...

I wonder if it would have been possible to tie in some actually good graphics elements somewhere, to make it clear that the graphics were made terrible on purpose, and there are good graphics elements to rate me on. I'm not sure how that would work though - maybe the game starts off in a game debugger interface, in which you click "Start" and it pops up an emulator window, and when the game crashes another window pops up...

Audio

There isn't any.

I thought of making a really annoying soundtrack to go with the really disgusting graphics, but it didn't seem like it was worth the effort, especially considering it would be annoying and decrease the fun factor. Besides, I wouldn't be rated well.

If I made some actually good music - which I have no idea how to do - it would contrast the disgusting graphics and confuse the heck out of people.

Sound effects? Not sure how to make those either. Besides, with all the weird hacks I had to do to get prompting to work, it would take a ton of work to make the actual playing of the sound effects work. It also seemed out of place in a text adventure.

Engine

I usually try a new engine every Ludum Dare. This time, I decided to try out Godot Engine, and I didn't have the greatest experience working with it.

First of all, the latest version didn't run on my PC, since it didn't support OpenGL versions prior to 3.3, which my GPU doesn't support. I had to use a slightly older version and that worked fine.

The language was okay. It's called GDscript, and it borrows a lot of syntax elements from Python. Maybe it looked a little too much like Python - the underlying language was quite a bit different, and I occasionally forgot it wasn't Python and tried to do Pythonic things in it, which didn't work at all. (For example, list slicing - which exists in a lot of other languages, not sure why it isn't a thing here.)

The first thing I ran into was a bug in the language parsing. The statement if a and b or (c and d): didn't work at all, and I had to add more parentheses (if (a and b) or (c and d)) to get it to work. The problem was that the block of code starting with the if statement would not run at all - even if all the criteria were true - and it took me a while to debug.

I ran into a lot of issues when I had to prompt the user for input. After failing to get the "signal" feature of Godot to work, I decided to run the prompting code in a separate thread, which was a big mistake. First of all, breakpoints in the Godot engine don't work at all in separate threads. There's an open issue on GitHub about this from 2015 - apparently the developers don't think debugging is as important as releasing a new .0 update that breaks support for old versions of OpenGL.

So I decided to use the good old method of printing a bunch of relevant local variables for debugging. That should work, right? Well... sometimes. Now if someone asks you if printing to stdout works, "sometimes" is never a good answer. I found myself not being able to debug my code at all at times. When I program, I usually take for granted that the programming language I'm using will be mostly bug-free, and bugs I was experiencing were my own bugs, not the language's bugs. I couldn't assume that at all here. It was almost terrifying. (The solution I came up with was to add all the stuff I wanted to print to a queue, and then print the queue at the end of every loop. Sometimes it wouldn't print at all, in which case I would run the loop a few more times until it did print.)

Finally, the function that starts a thread takes an argument which is the name of a function that takes one argument and returns a status code. I forgot to make the function take the one argument a couple times, which would be fine, except Godot didn't give me an error or anything - it silently skipped the function and didn't let me know in any way. This was extremely frustrating, especially when I figured out the problem I was having thirty minutes past the deadline. Moral of the story: use errors, kids.

Even after publishing the game the game seemed to work very inconsistently across platforms. Some players reported random game crashes or the game not starting up at all, while others, including myself, had no problems whatsoever.

Overall, I came away from Godot feeling like I had just used an alpha project. This was pretty frustrating, considering I had just used it for a 48-hour game jam, and the engine, though marked with a stable-looking version number, had serious bugs that made it extremely frustrating to work with - some reported as long as 3 years ago. I wouldn't recommend Godot or ever work with it again.

Was it fun enough?

A user on my game's comments page told me they thought it was too much work to map out the entire level. In response to this, I suggested maybe the level could be shown at the same time as the text-based interface, and I also uploaded images of all the levels to my project page in case people got stuck.

However, other users said that the mapping aspect, and having to analyze the level before clicking, was one of the things that made the game fun for them. I'm a bit divided on this issue, and would love to hear your input.