[-] russmatney@programming.dev 4 points 6 months ago

Excellent! Let me know what you think or if you have any ideas - it’s easy to add more types, I’ve only been minimal so far. Vector3s come to mind…

37

I finally published my first addon, and it hit the asset library today!

Log.pr(...) and Log.prn(...) are intended as drop-in replacements for print(...):

  • colorizes the output data based on type
  • recursively prints dictionaries and arrays
    • (with a sane max count, i.e. not printing 1000 entries in an array)
  • adds a script-name prefix and line-number before each log
    • with different treatment for [src:12]: vs <addons:12>: vs {test:12}: scripts

For me this helps reduce wall-of-text noise and eye strain while reading logs at a glance.

I created a docs site via docsify, and the code is on github.

I'll be adding support for more types and customizing the color choices soon. You can opt-in to pretty-printing with your own objects by implementing a to_printable() function. I'm brainstorming ways to add support for not-your custom types as well (for example, Pandora Entities) - I have a few ideas but nothing implemented yet.

I've been using it in my own projects for a few months now, so it feels ready to share - I'm hopeful that others find it useful!

Try it out, let me know what you think!

[-] russmatney@programming.dev 5 points 7 months ago

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

[-] russmatney@programming.dev 4 points 7 months ago

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.

[-] russmatney@programming.dev 3 points 7 months ago

This template might also be useful: https://github.com/bitbrain/godot-gamejam - e.g. i read through the savegame stuff before implementing it in my own game.

I saw another template the other day… and my last/next project “dino” is available as well, though it’s pretty crazy in there right now: https://github.com/russmatney/dino - i hope to whip this one into shape by june 1st!

[-] russmatney@programming.dev 4 points 7 months ago

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

[-] russmatney@programming.dev 10 points 7 months ago

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!

[-] russmatney@programming.dev 8 points 7 months ago* (last edited 7 months ago)

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]

108
submitted 7 months ago* (last edited 7 months ago) by russmatney@programming.dev to c/godot@programming.dev

Dot Hop launched today on steam! It has some challenging grid puzzles that I think folks will find satisfying.

This game started as a puzzlescript game for the Fediverse Summer Jam hosted by the p.d community - I reimplemented it in Godot, added themes and many more puzzles, and finally released it last night/this morning.

The game's source is available on github and it can be purchased on steam and on itch.io.

Hope you enjoy it, and let me know what you think!

[-] russmatney@programming.dev 4 points 1 year ago

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!

[-] russmatney@programming.dev 5 points 1 year ago

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

[-] russmatney@programming.dev 4 points 1 year ago

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.

[-] russmatney@programming.dev 3 points 1 year ago

Just to share a perspective from erlang/elixir: pattern matching to filter for only happy-path inputs and the principle of “letting it fail” (when the inputs don’t match the expected shape) works really well in some paradigms (in this case, the actor model + OTP, erlang’s 9 9s of uptime, etc). In that kind of architecture you can really only care about the happy path, because the rest is malformed and can be thrown away without issue.

[-] russmatney@programming.dev 2 points 1 year ago

I think of this as interactive development, or repl-driven development. You can work this way today in Clojure (frontend, backend, and lately even for scripting via babashka), and with lisps in general - the syntax lends itself to sending expressions to the repl and returning values to your editor.

It’s really the best way (my favorite, at least) to program that i’ve found for exactly the reasons you mentioned - it’s excellent for debugging and ensuring the behavior of small functions with minimal overhead.

Types are frustrating because they lock things up and they don’t guarantee behavior, which is really all a program cares about. I feel similarly about unit tests… it’s extra code locking up your behaviors, so make sure they’re what you actually want! A general problem with types is that you have to commit to some shape early, which can lead to premature design and basically some arbitrary DSL when you just needed a couple functions/transformations. Feels like the problem of OO at times.

On the other side, the trouble (beyond people generally not wanting to read/learn lisps, which is unfortunate) is that repl-driven dev requires that you take care of your tools, which means there’s a tough learning curve and then some maintenance cost for whatever editor you want to use.

At a career-level scale, in my opinion, the investment is well worth it, but it’s a tough thing to figure out early in your career. I expect most devs with a couple years of js/python see types and feel like it’s a huge relief, which is real, and maybe types make sense at a certain team size…

I think people should spend time in several different languages and paradigms - it makes the ones you go back to make more sense :D

view more: next ›

russmatney

joined 1 year ago