the method

 I’ve been learning Godot and GDScript for a week now. my motivation is, naturally, really high and I think constantly about what I’ve been learning and how can I tackle some problems in Godot.

 the method I chose was to go head-first into this, knowing nothing of GDScript and very little of game engine interfaces. the idea was to apply the little knowledge I had from C language, and learning out of necessity: if I couldn’t figure out how to do something, I’d google some answers.

 I would take it as far as I can (but for no more than a week), and then downshift gears and get some theory down - to avoid going around aimlessly for too long.

 another important factor was to choose as the first prototype a board game adaptation. which meant that I wouldn’t need to figure out the logic of the game, but “simply” how to get it into code.

1. the pros of this method seem to be:

• I learn precisely what is important for this project and avoid wasting time learning general concepts of a new language and a new game engine.

• I seem to be able to understand better what I’m learning, by having to try to figure out how to do it first - as opposed to simply be following a tutorial on how to do it

2. the cons are several - albeit expected - and make the whole process slower:

• I don’t know the syntax of the language, which leads me to a lot of trial and error. for example: it took me a while to figure out how to pass a node as a parameter

• whenever I’m looking online for a solution to do ‘x’, I don’t even know if ‘x’ is something possible in GDScript.

• even if that ‘x’ is possible, most of the times I don’t know which correct term should I use to refer to it

• with my unfamiliarity with the engine, I end up implementing overcomplicated solutions, to later find out that Godot has optimised solutions for simple problems