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

Another much shorter answer is, once you pay the steam fee, you can easily play your game on the Steam Deck, so it helps a ton for playtesting (both myself and putting the games in people's hands).

And otherwise, the Dino page is up now in the hopes of starting to collect wishlists sooner than later.

Excellent! Let me know if you have any questions!

I’m working on some devlogs that will share parts of the implementation - I’m happy to dig into whatever directions are useful

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

https://godotwildjam.com runs every month for the last …60+ months?! Feels like a long time!

Anyway, It’s a great community of godot game devs!

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

Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.

Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.

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.

Interesting, syncing history across machines is pretty cool. While writing this I went looking for my yabai logs helper as an example, but of course, it's on my other machine, haha

Security (sharing secrets from that history) comes to mind, so I feel compelled to mention that adding a space before a command is a pattern for preventing it from being stored in history, though I think I had to opt-in to that in my zsh config: setopt HIST_IGNORE_SPACE

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!