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!

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.

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.

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.

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!

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!

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’m liking wefwef, as a PWA it feels pretty much just like Apollo

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....

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.

These are great! It's cool to get a feel for which instance the community is from at a glance

Indeed! I pulled a few below (too many?) from my current project, Dino, which is on github if you want to dig into more.

Some of these make use of custom autoloads, but should still show the idea. Note the use of bind in places as well, which is making use of the same func/callable improvements.

• Inlining a setup_fn to be called on the player after they're respawned:

func on_player_died(_player):
  Game.respawn_player.call_deferred({setup_fn=func(p):
    Hotel.check_in(p, {health=p.initial_health})})

• Inlining a hide_fn predicate in a list of data (these dictionaries eventually get mapped into buttons)

var menu_scenes = [
  {label="Start Game", fn=Game.restart_game.bind(SuperElevatorLevel)},
  {label="Dino Menu", fn=Navi.nav_to_main_menu,
   hide_fn=func(): return not (OS.has_feature("dino") or OS.has_feature("editor")),
}]

• Gathering a list of resource_paths from a list of levels:

var level_paths = levels.map(func(l): return l.resource_path)

• A basic inline connect:

player.ready.connect(func(): player_ready.emit(player))

• A more interesting connect:

func on_player_spawned(player):
  player.died.connect(on_player_died.bind(player), CONNECT_ONE_SHOT)

• Creating a bunch of actions that use predicates heavily:

I have a general actions system, so it's nice to be able to implement small functions to describe some behavior rather than create a fully named function for every piece of logic.

var actions = [
  Action.mk({label="Open", fn=open_door,
    source_can_execute=func(): return state == door_state.CLOSED}),
  Action.mk({label="Close", fn=close_door,
    source_can_execute=func(): return state == door_state.OPEN}),
  Action.mk({label="Unlock", fn=unlock_door,
    source_can_execute=func(): return state == door_state.LOCKED,
    actor_can_execute=func(actor):
    if actor.has_method("can_unlock_door"):
      return actor.can_unlock_door()
    }),
  Action.mk({label="Jostle", fn=jostle_door,
    source_can_execute=func(): return state == door_state.LOCKED,
    actor_can_execute=func(actor):
    if actor.has_method("can_unlock_door"):
      return not actor.can_unlock_door()
    return true
    })
  ]

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

There are a few collections around like: https://github.com/adi1090x/rofi

These things tend to imply dependencies for how they're implemented plus whatever they are integrating. The UX is definitely the right one tho! Rofi is great for working on custom dev tools - you can pass lines in as stdin, it sends back the selected item on stdout, then you exec the matching output command.

I started a project called 'ralphie' to do this with babashka a couple years ago, but later i absorbed that into a monorepo called clawe - you can see the rofi namespace here: https://github.com/russmatney/clawe/blob/3987390ffe538d878045e9d886190542fb111b9e/src/ralphie/rofi.clj#L146-L156

This was a cool talk on teaching programming gradually (with a lang called hedy) at last year’s strangeloop: https://youtu.be/fmF7HpU_-9k - might be some useful takeaways for you in there

A fun one!

yeah!

reminds me of https://github.com/a-little-org-called-mario/a-little-game-called-mario

I don't think it's that crazy - and it'd be fun to collaborate on something low-key, and maybe it grows into something?

I can’t finish anything without an external deadline. Otherwise i just keep refactoring and tweaking forever.

Game jams, a self-imposed deadline, promising other folks a demo on a certain day…

Sometimes i pick something as a reward, like playing some game (lately, TOTK) only after having delivered a new feature for whatever game idea.

Another thing that helps is setting smaller goals - a basic first version as 1.0, then small features to bump to 1.1, 1.2, etc. Bigger features can go in later versions! Don’t turn yourself off trying to do it all at once.

I think game dev is prototyping lots of ideas - then at some point you look back and decide one of them is worth a more serious time investment. In the mean time, keep prototyping!

Cool! Thanks for open-sourcing it!

Makes me think maybe the fediverse jam could be a place to build fediverse-tools, not just games - or maybe there's a different opportunity for building fedi-tools similar to the Godot Addons Jam