just curious because the jam is so simple and open-ended.
i'll probably end up using rpg maker because i love it so much,
but might try coding by hand if i've got some charisma to expend.
looking forward to this jam < 3
So far I've been using the docs and they have been very helpful: https://docs.godotengine.org/en/3.1/getting_started/step_by_step/index.html
The docs are also open source so they are constantly getting updated by the community.
The discord is pretty active as well and has help/question channels: https://discord.gg/zH7NUgz
There are also lots of videos but I haven't watched any so I can't recommend any in particular but it seems they are pretty numerous.
I used an earlier version of TIC-80 to create "The Sky House", it was a fun but at the time there was no way to write the code except from the editor which became a little bit of pain near the end (as there was a lot of code). I think they now support editing the tic file from any text editor. Also, they didn't have a full documentation about a lot of stuff :) But it was a really fun experience :)
I'm after a lightweight Web deploy with a more straightforward API but with good animation, gui, and effect support. Haxe Flixel is the engine I'm most interested in at the moment, but it means I'd need to do a fair bit of prep getting used to haxe and the environment.
The other option is to use phaser so I can code in typescript and take advantage of the large code library I've built up in that environment. If I don't feel like I'm making enough progress with Haxe I'll go that route I suppose.
I'm hesitant whether to do this from "scratch" using a former codebase of mine in C++ and SFML or using something like Unity or XNA/FNA etc mmm... I feel like the spirit of the jam is more about "raw" and "glitchy", which seems closers to the first option. Or maybe (from scratch too) some JavaScript + canvas or webgl combo... Mmm, dices shall be rolled
I'm using arcade for the first time. It's a python library that (I learned after starting) seems to be aimed mainly at classroom environments. I heard it highly recommended somewhere, but so far I'm not as impressed as I hoped to be. I've had to read the source a lot where the docs are lacking, but the source is very readable. It also makes a bunch of choices under the assumption that you are developing a real-time game with moving and colliding sprites, which I'm not.
It was a lot simpler to install and get working than pygame, though.