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…

streets of rage 2!

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!

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

Indeed, the problem with gui apps is when you can’t script them!

I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….

We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it

Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?

I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.

I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.

types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.

Fair! Naming is hard, but maybe that’s no excuse for not defining a thing

I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!

You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.

Sounds like a frustrating issue - feels like salesforce shouldn’t be enforcing that number vs string in the first place, because it could just get coerced later on. But, it’s out of your hands for sure, and there are tradeoffs for them making their API “easier” to work with.

And yeah I’m being a bit obstinate in this hot take - it’s easy to get away without types when working on smaller projects and in more modern languages, especially for low-stakes dev tooling. In larger projects, types can help improve confidence during large refactors.

I just want less code to maintain in general…

Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade’s influx of typey-langs and -devs.

I think most love for types is folks being happy they don’t need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It’s hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you’ve even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It’s also frustrating b/c types don’t guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it’s like pleasing the wrong boss, or some metaphor like that.

I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages… similar to type-favoring opinions suffering b/c of langs like typescript.

Nil-punning makes me very happy - that’s a hill I will actually die on. Almost every project i’ve worked on, there’s no reason to go out of the way to specifically handle every case of not the right input or oh-no-it’s-null! Whenever you have null, you just return null from this function too, and guess what, everything’s fine - no need to crash and blow up b/c one thing wasn’t there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.

Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.

100%! It was mind-blowing to realize lisps are actually syntactically simpler than all the non-lisps so popular today

Takes a bit of love from editor standpoint unfortunately, so most devs will just never attempt that hurdle