Turns Out Making Games is Hard, Actually?
I've been plugging away at my little prototype that I mentioned last time. At the time I said I was hoping to have something to show off at the end of the week. That was a couple of weeks ago, and I don't have anything to show off. Let's examine that a little bit.
I've had a mental screenshot of the final puzzle design for a while now. The coded message on the right, the character conversation table in the middle, and the output on the right. Once it's part of a larger game there would also likely be a button to bring up notes/clues/reference that you've gathered elsewhere. But for the prototype that will be absent.
The only thing I've been spending my time on so far is the underlying encoding/decoding implementation. I've found this slow to complete for a couple of reasons.
As I alluded to in the last post, I'm unfamiliar with the environment. GDScript, the built-in language Godot provides, has enough little differences from my preferred language (ruby) that getting to grips with simple tasks is non-trivial. Consider joining the elements of an array into a String. In ruby that would by my_array.join(","). In GDScript, join is an instance method on String, so you write ",".join(my_array)" which throws me off every time. It also has significant whitespace which is just evil.
I have a bad habit of over-optimising code before even writing it down. My first implementation of the encoding had an array whose values were Godot Key constants, which are integers. This storage efficient, but required extra steps to actually use as the values had to be converted back to printable strings through another lookup table before they could be displayed. Storage efficiency isn't even a good thing to optimise for here! This array will only ever have a couple of hundred of entries at the absolute maximum, so organising it to make it easy for me, the developer, to work with is far more important.
Now I store the actual character I want to print at its corresponding index in the array. so my encoding might be ["a", "b", "c", "d"]. To encode a piece of text I simply run a find for each character, convert the index to its hex value, and throw that into an array. When I've finished I join the array into a space-separated string and I'm done. The reverse is also easy. Split the incoming string on spaces, find the decimal values of each item, and use those to index into my encoding array. String goes in, String comes out, with only one intermediate representation required. Much better.
It's been a longer haul than I expected getting to the stage where I can start working on actual gameplay, but I think it's close now. We'll see. Sitting down to do the work is proving difficult, so I'm not spending as much time as I want on the project and the gaps are long enough that I have to reorient myself each time I start. I'll have to see if I can improve on the frequency with which I spend time on this.