Thanks! I’m hopeful it helps folks as an example godot game. Not that my way is the best, but it’s working for me, so feel free to borrow some patterns!

A steam link would be nice!

https://store.steampowered.com/app/2779710/Dot_Hop/

Got dropped b/c i also included the image, i think [update: realized can edit the original post, so the link is in there now]

I added a more celebratory new-puzzle-set-unlocked screen to Dot Hop yesterday:

Dot Hop is launching March 1st (next Friday)! Originally prototyped as Flower Eater in the Fediverse Summer Jam - now re-implemented in Godot, with ~50 more puzzles (and many more to come!)

Check it out on steam and on github, or watch a short devlog about it on youtube

In my experience, learning a new language makes you much better at the languages you already know, and each one you learn is an easier challenge than the last - it helps me understand what is shared across programming vs what is a specific style (or wart) in a language I already know. So I definitely recommend exploring widely!

In general, I'd encourage you to follow your gut and curiosity - whatever you're most interested in will end up being less effort/more fun, and likely the most/best growth for you - so, scratch that itch!

Some different options that you might take a look at:

My favorite by far is Clojure - it's practical and minimal and can be used for everything (full-stack + scripting), and interactive programming is really nice (vs the typical write + compile/run-the-world loop). Unfortunately, learning to read/write lisps is a bit mind-bending and tooling-intensive, so expect to invest time in your tools before you can really get going with it. (Connecting to a running repl from your editor is an excellent paradigm for writing code, but it's really on you to manage and debug the tools that support that workflow, and that's just difficult at the beginning.)

Elixir is another modern option that'll teach you some new patterns/paradigms, like the actor model (via OTP) and pattern matching. I'd be writing more elixir these days if I hadn't found Clojure :)

Haskell is totally different and quite difficult, but generally worth it. It's especially difficult to pickup without a mentor/team to learn it with. It can be very minimal and will change the way you think about functions and types (it did for me, anyway). I don't find it to be very practical (i've become quite opinionated about strict types), but I know folks who do. I wrote a post about using 'lenses' in Haskell a few years ago, a glance at some of the code will show you how different it is from other languages: https://medium.com/@russmatney/haskell-lens-operator-onboarding-a235481e8fac

Rust is increasingly popular, and for good reason - plenty to find on this, large community, definitely not bad choice at all from the sound of your path so far.

Feedback loops are super important! For momentum, for reducing burnout, for implementing/debugging, everything. I think of it mostly as a tooling problem - the point of maintaining and improving your tools is to maintain/improve your feedback loops.

For me it's about this question: How quickly and easily can you verify that the code is doing what you think it's doing?

This is what I love about writing Clojure - you can write and evaluate abritrary bits of code (functions, expressions) without leaving the editor. Invoke a keybinding to send the current expression to the running repl, and the resulting value is returned, and can be interactively explored/walked in the editor. It makes for a fun interactive dev-loop, and is a nice way to design a solution to some problem. (A caveat is that getting into a working repl is non-trivial, as it's dependent on your editor+plugins. It takes a bit of learning and unfortunately isn't beginner-friendly.)

Vim and emacs are also excellent for improving you feedback loops - both take some investment and some discomfort in the beginning, but ultimately you get out what you put in, and soon you can imagine and realize better workflows without much effort (adding your own functions, keybindings, hydras, etc). VSCode and other editors are also hackable, to some extent.

Mostly I think it's important to hack on your tooling on a regular basis, at least once a week or so.

My old boss used to say he expected us to keep 'sharp knives' (as in cooking). I think companies should make time for the devs to work on tooling to improve these feedback loops - it's the hiccups in the workflow that build up and lead to burnout/fatigue. Smooth workflows can actually be energizing instead of energy-draining!

every time i'm playing some old guilty pleasure that isn't 'actually good' (think: just wanted to play a jock jam for a moment), i worry about the influence on next week's discover weekly....

I’m liking wefwef, as a PWA it feels pretty much just like Apollo

I knew I'd seen something like this, and was very happy to find this in my notes from a few years ago: https://devchallenges.io/

There are a few full-stack 'challenges', ultimately building up to a twitter and then trello clone. Maybe it's the kind of thing you're looking for? I'm not sure if the submit + review portion of the site is still a thing, but w/e, you can still take the ideas and build your own thing.

Here's a quick article on it from the creator: https://dev.to/nghiemthu/8-projects-with-modern-designs-to-become-a-full-stack-master-2020-14j9

One thought I had when looking through these is that keeping the project small (e.g. an image uploader that adds a filter and renders it) might be preferrable to an otherwise larger/never-ending project. OR you could do more design work for a larger site if that's the part of software you want to practice.

You might also look into coding 'kata' or something like advent of code, tho that's definitely a different direction and lower-level scope.

Building stuff is fun! Good luck with it!

Godot is excellent! Would definitely recommend it.

Whatever you choose though, my advice: a great way to get better at writing code is just reading code (example projects, github repos, etc), and trying to understand what each line is doing. The skill is really learning lots of patterns, but focusing on reading lets you discover good/bad patterns more quickly than trying to arrive at them on your own.

excited for this one, thanks for putting it together! And thank you for not overlapping with the GMTK jam :D

I was curious about writing one-off scripts in Godot, so here's a tiny example for doing that in Godot 4.

./hello-godot.gd (also in my dotfiles):

#!/usr/bin/env -S godot --headless --script
extends SceneTree

func _init():
  print("hello godot!")
  print("args", OS.get_cmdline_args())
  quit()

Note the first line, which invokes godot and includes the --headless and --script arguments. You can read more about these args via godot --help.

Once the script has executable permissions (typically via chmod +x hello-godot.gd), you can run it in a shell like:

./hello-godot.gd "some arg" "some other arg" 123

That should output something like:

hello godot!
args["-s", "/home/russ/.local/bin/hello-godot.gd", "some arg", "some other arg", "123"]

This kind of thing can be useful for running tests via something like GUT (which is where I started digging into this), or exporting games in scripts/CI.

Which makes me think I should look into how some of those godot CI docker images run - maybe there are other arguments/features/best-practices there to build on.

Anonymous functions and callables have been a really nice step-up for GDscript.

Lots of formerly annoying things are much cleaner now, like getting away from connecting signals with strings, and using map and filter, etc.