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…

Thanks much!!

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.

[edit: sorry, this whole answer I thought the question was asking about Dot Hop, not Dino! Re: Dino, I’d started the project much earlier, but paused development on it at the beginning of this year to pursue Dot Hop first (much smaller scope). I’m moving back to Dino now that Dot Hop is released, targeting a launch before June!]

Yeah, Steam charges $100 per title - if you earn enough (some high number, maybe 1000?), they give that 100 back, but I’m not necessarily counting on that (not soon, anyway). My goal is make enough money to keep doing game dev full time - i’m hopeful to make it work across steam/itch/patreon/other stores. (Hopefully Dot Hop mobile/Switch releases later this year!). To me the dream is to make enough money to make the rent and make the next game.

But! There are definitely other less-directly-monetary reasons for the release:

• getting exposure and feedback from more people will help me improve as a game dev/designer (this might be the biggest reason, really - I don’t expect commercial success from my first game, so instead it’s about all the intrinsic value I can get out of it - experience, motivation, validation, learning all the annoying marketing/steam/etc overhead)
• having a deadline and ‘proper’ release definitely motivated me to raise the quality bar of my work (before this I was submitting scrappy games to game jams)
• regardless of the project’s monetary success, it’s now a useful portfolio piece for future game dev teams/interviews, which I might need if/when the solodev thing isn’t enough

In general I’m intending to get multiple quality games into “stores” as soon as possible (hopefully this year), and then decide what to do next - I think the experience along the way is the best thing for my growth and will inform the next move (some larger game, find/build a team to work with, start applying for studios, etc)

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!

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]

In fact i did not know that! Thanks for the vid, will check it out!

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!

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.

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