Language, engine, and dubious practices

What language should one learn to learn programming? English.

There's no doubt in that. Not only is the lingua franca between people, but it's the one that has more documentation, and the one that you should use in your code if you want it to be shareable. All this will be even be more dire in the future, specially if LLMs or some other kind of AI grow good enough to do most of the heavy lifting, once again English will be the most used language. Although maybe we will have to take Chinese into account, who knows.

For the programming language per se, it would mostly depend on the engine you use. Some people might limit the engine depending on the languages they know, but it's better to limit the languages you learn depending on the engine you use. Learning more languages, after the first couple, should not hinder you much.

What engine should you use when creating a game? Doesn't matter, you choose.

Of course there are things that matter, you should use Ren'Py instead of Unreal to create a visual novel, but the other way around when creating a FPS. Apart from that it doesn't matter much.

Now we come to the choices I made.

I have more than 20 years of experience programming, but nothing more than small experiments when talking about game development. Thus I have no qualms using whatever language is needed (except for personal preferences). I have plenty of Unreal assets (several months buying free items in the unreal store), C# is one of my favourite languages (Unity uses it), and I love Free Software (free as in freedom) like Godot.

Ultimately my choice was made for me. Currently my only modern personal computer is the Steam Deck. And although I think it can run all the engines, Godot is the only one that works reasonably well, the others were too heavy for it the last time I tried them. So Godot it is.

For the language it was to be GDScript. Even though there's a Godot version with C# most of the information online is with GDScript, not using it would cripple me.

With everthing in place let's jump to the process of creation.

Have you heard about the Spoon Theory? Well, even though I don't have any chronic illness, except life which nobody survives, my energy is not that great, and with personal and family chores my time was to be severely limited. My initial planning was this:

17 - Jam theme on.

17-21 - Think about what to do.

21-23, 25, 29-30 - Programming crunch in the afternoon.

Rest of days, it depends.

Things changed, but mostly I only lost the 21st afternoon programming time.

You got an insight on my brainstorming and decision tree on the first development blog post, and the design was done on a physical notebook, which I transformed into a google doc on the 30th.

So when I got myself to program I didn't have many spoons, in fact I had to fight my fears again, just like the character, before starting. And in order to minimise the energy lost I defaulted to name things in my mother tongue, Catalan. Being a personal project, which I don't think many people will see it will not matter much, and if I refactor the code I will change them to English.

Some of the days, probably because I do use English extensively on my daily job, I went back to my usual default when programming, and did the naming in English. Is that confusing? Yes, do not mix languages.

Let's jump into more dubious practices.

Code is not an example of Spaguetti code, because I feel that Spaguetti code dissapeared the day GOTO dissapeared, but it's similar in concept.

• global.gd 37 lines 6%
• guanyar.gd 10 lines 1%
• menu.gd 10 lines 1%
• perdre.gd 10 lines 1%
• Pensar.gd - unused
• habitacio.gd 56 lines 9%
• Soloer.gd 455 lines 78%
• Total 578 lines

Nearly all the interesting code in in the same script, which affected me because when I wanted, for example, to see the excuses and fears while coding their behaviours I had to either scroll a lot or write them down in the notebook. This is not good practice and if I continue working in the game first thing I should do is refactor the code and send it to the appropriate scripts.

This worked well enough in this case because of two reasons:

1. I'm fairly experienced, so I had a clear mental picture of what was happening.
2. I was working alone.

If any of these were not true I don't think I would have finished the game with as few bugs as I've done. In fact, even though it's lacking on gameplay, I don't know of any bug in the code for now.

Don't do like me, and I've learned my lesson for the next Godot project I make.

Sometimes you need to do things wrong to learn how to do them well.

To be fair, with such a small project, and considering it's probably a throwaway, it could be considered an spike, it's not a bad way to learn.

Too much text? Let's summarise it on a few phrases.

1. Learn and use English for naming things in your code.
2. Plan your usage of time.
3. Organise the code well.
4. Doing something wrong is the best way to learn how to do it well.
5. Don't be afraid.
6. Have fun in your adventures.