hello!
tmux rules! let's nerd about it!
russmatney
joined 1 year ago
yup! you can do something like godot -e from the same directory as your project.godot to launch the editor for that project directly
I upgraded without issues… i wonder what kind of scenes these are that aren’t working.
I’d expect manually editing the tscn files could fix it, but wouldn’t know what to change without more info. Is there any detail/errors on why they are corrupted? Sometimes i launch godot on the command line to try to see more error info from the logs/output, tho the same should show up in the editor after startup.
Worst case you might have to recreate them… maybe that’s not too much work? I had to recreate tilemaps in the 3.x -> 4.0 migration, was pretty annoying
Yes! I love using x (and xs) for functions over whatever the thing is (or things are).
Nice work!
Tauri is great. I haven't built a proper app with the nice native backend features, but i wrote a wrapper for passing a url on the command line, which lets you run an arbitrary web app like it's a native one: https://github.com/russmatney/clove
Very happy to have something lightweight!
for sure, here we go with day 2! hoping to get something working quickly today so there's time for polish and level design... tho i'd be happy even to just get some mechanics shipped
Yeah, it's definitely a battle. A mistake i'm struggling to shake is trying to hold too tightly to the theme. I'm trying lately to come up with something that I want to make independent of the theme, and then letting the theme influence it somewhat, rather than trying to forge some theme-centric idea out of nothing.
I'm loving being able to break the docs (script tab) out of the editor!
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....
oh yeah! Getting godot 4.1 all squared away today, excited to dive in tomorrow
I'm always pumped leading up to jams, then distraught when the theme is announced and my doubts set in.... ready to battle through it again!
I'm a week late on this..... but just wanted to comment in support of this style! I think it's worth having a strong pattern of code re-use across projects - your tools should get better as you get better game dev!
I've built games for several game jams in the last ~8 months in the same project: https://github.com/russmatney/dino
The goal is to lower the overhead of trying out new ideas, and make it easy to put reusable library code into libraries (addons), and game-specific code in the games themselves. It's a fertile ground for letting games and addons develop and grow organically - as more games are implemented, the addons get another consumer to test the apis they offer. Maybe one day an addon will be ready to be pulled into it's own project, if it would make it easier for other folks to use it.
(Tho, my addons have grown fairly cross-dependent, so now I'm starting to think of all of Dino as more of a personal framework... we'll see where it goes...)
It's typically alot to ask others to come into your own project and work with it (at any level, really), but if you are productive in there, you must be doing something right, so just keep going!
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!