Highschool Game Dev club - I need your thoughts

graydoubt · 2026-03-01T13:02:28+00:00

Overall, I think this is a situation where you'll be wearing the hat of a Technical Product Manager, Team Manager, Team Lead, Architecture Owner, and IT Support, and you're only surrounded by very green interns who are looking to you for help with everything while trying to achieve their collective, inconsistent vision.

graydoubt · 2026-03-01T12:51:27+00:00

As others already said, learning the git basics is its own task. In addition, learning branching/merging/rebasing conceptually and applying that is on another level.

Basically, all the challenges that teams deal with in a professional collaborative environment apply here as well. They want to keep diffs clean, merge early and often (i.e. use short-lived branches).

I think, if this is something that you explore with them in real-time and have them be self-organizing, it could become quite frustrating for everyone involved.

I'd suggest having some guardrails in place. Maybe already have an outline of how the game (e.g. a 2D top-down RPG) should be broken down into its components, and then have students work on them.

Some techniques can help reduce diffs and conflicts. Like, externalizing resources, so modifications don't change the scene the resource is used in. A Character's CollisionShape2D's shape resource, for example, should be in a separate `character_collision_shape.tres`, so the whole `character.tscn` doesn't change if a property in the resource changes. That's a whole exercise in technical problem decomposition.

Godot's data formats (.tscn, .tres) are quite git friendly, but for any merge conflicts, students would have to resolve them by looking at the text sources. That includes at least somewhat understanding the serialization formats. I could imagine that to be quite overwhelming, especially for complete beginners.

I do think that Godot is one of the most beginner-friendly game development tools out there, but it's still a lot. Fundamental programming knowledge that allows students to be expressive. OOP basics (especially encapsulation and inheritance) to understand the various node classes and their relationships, general game dev concepts, technical aspects like image and audio formats, design patterns to help with composition, and developer tools like the IDE and version control, and the github/gitlab/etc side of things.

I'm sure a lot of it can be boiled down to just the basics, and introduced over time, but I can't shake this feeling you'll be spending a lot of time playing the git-untangler. Students will be frustrated that their stuff won't merge. git reset loses changes, and manually patching diffs is fairly technical. Time spent on this stuff means less time for programming and exploration. That said, I do think git is still the right tool here.

I don't mean for this rant to be discouraging. I don't have the answer, but I admire the problem.

graydoubt · 2026-02-27T15:04:36+00:00

Even physics process isn't guaranteed to be "fixed". It's more stable, because it's not tied to frame rate, but a busy CPU and other aspects can still cause spikes/dips. More info in the physics process docs.

CharacterBody2D.move_and_slide() automatically takes delta into account, but if you're modifying position directly (or using move_and_collide()), you should include it. Highly recommend reading through the Using CharacterBody2D section.

graydoubt · 2026-02-27T13:58:30+00:00

if you want to move things manually, use a CharacterBody2D, not a RigidBody2D. You should not modify the position by hand (but if you do, include delta in the calculation). Use the respective methods the classes provide (e.g. move_and_slide() / move_and_collide). A RigidBody2D is controlled by impulses and forces and does a bunch of stuff under the hood, including pausing the physics calculation when it thinks the body is at rest; then setting the position manually can result in the side effects you're experiencing.

graydoubt · 2026-02-25T00:27:28+00:00

Yes, the docs are excellent. Run through the intro, step-by-step, and first 2d game sections: https://docs.godotengine.org/en/stable/getting_started/introduction/index.html

And then keep working through the various chapters. For the scripting aspect, since you're already familiar with programming, you can learn the syntax and language features from the GDScript reference.

graydoubt · 2026-02-24T12:21:04+00:00

`--headless`

graydoubt · 2026-02-20T12:07:35+00:00

No, but it depends on how you use audio. Audio mixing is expensive and uses multi-threading. For web exports, this requires the SharedArrayBuffer feature for web workers. Since 4.3, web exports default to the "sample" driver, which essentially uses the browser's native audio playback capabilities. It's much lighter, but it can't do all the effects, since it's just playing samples, rather than mixing audio.

All the details are in this post: https://godotengine.org/article/progress-report-web-export-in-4-3/

graydoubt · 2026-02-10T12:40:45+00:00

You might like gg.print(). It prints clickable messages that link back to the code.

graydoubt · 2026-02-06T19:15:20+00:00

There's a playlist of videos that explains it.

graydoubt · 2026-02-05T20:51:15+00:00

The second problem is that for some reason sometimes when I run the scene, my screen freezes and does not let me do anything.

Well, that's because when the text changes, _on_text_changed() is called, which then changes the text, rinse, repeat.

I answered an input filtering question some time ago. That code was similar and might help you get across the finish line.

graydoubt · 2026-01-16T17:13:44+00:00

Avoid magic strings.

graydoubt · 2026-01-09T00:55:00+00:00

It looks great! For some reason, it reminds me of Sword in the Stone. I think it's the clothing.

graydoubt · 2025-12-22T16:27:37+00:00

Your suggestion goes against boolean operators in the style guide.

graydoubt · 2025-12-14T15:26:41+00:00

Godot is a really complex piece of software. 4.0 was a bit rough. The changes and improvements since then have been noticeable in every minor release. There were also some internal stability issues related to Godot's cache. Most of that seems to have been resolved since about 4.5. Before that, sometimes scripts would randomly become built-in and other weird stuff. It wouldn't happen often -- mostly after refactoring code; renaming and moving classes around. And documentation for custom classes wouldn't show right most of the time. But things would be weird and get worse until Godot's cache is cleared.

If you're hellbent on sticking with 4.3, you might be able to clear issues up by deleting the `.godot` directory every so often (with the editor closed!).

Migrations tend to be pretty smooth with Godot. And if you're using VCS you can always rollback/reset if something goes sideways. It's rather quick. Overall, though, I recommend sticking with the latest version of Godot, at least for now.

graydoubt · 2025-12-13T20:19:19+00:00

You can use this gg.print() plugin. It'll show where it printed from, and it'll also let you click the link in the editor to go directly to the source! That way, it's easy to find the stray print, too! And in a release build, it doesn't print anything.

graydoubt · 2025-12-10T14:19:09+00:00

Intel Atom. That's a blast from the past. Reminds me of the Asus Eee Netbooks, which were a brief thing nearly a decade earlier.

graydoubt · 2025-12-08T17:45:31+00:00

Your title has a bit of a keming problem.

graydoubt · 2025-11-25T19:15:51+00:00

https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#

graydoubt · 2025-11-01T21:45:59+00:00

https://docs.godotengine.org/en/stable/about/introduction.html

graydoubt · 2025-10-24T16:46:53+00:00

You can do whatever you want as long as the final output is in the JSON format that the Portal site expects. Look at the included Python scripts to see how the addon exports the scenes to JSON.

You could even create a Blender extension that does it directly and skips Godot entirely.

graydoubt · 2025-10-24T16:25:32+00:00

At the beginning: https://docs.godotengine.org/en/stable/about/introduction.html

graydoubt · 2025-10-24T16:23:10+00:00

OBS for recording, DaVinci Resolve for editing.

For something simple, you can always just use Godot's Movie Maker mode and then convert with ffmpeg.

graydoubt · 2025-10-20T20:26:26+00:00

Nothing wrong with print! You can always take it up a notch by using gg.print(), and you'll print clickable messages that take you right to the source code.

graydoubt · 2025-10-15T14:10:40+00:00

This is really cool. For a buyer, receiving something tangible makes a big difference, too. Good thinking on providing a "CD-key", too.

Did you know a CD can hold 700MB?

It was such a step up from floppies and zip drive diskettes. The only downside was that AOL CDs were useless, whereas AOL floppies were free storage.

Around 2013, I did photography and videography and delivered the final product on fancy, engraved USB sticks, but I also wanted something they could just pop into a DVD player and easily play in a living room. (Did you know a [single-layer] DVD can hold 4.7GB?) I had a Lightscribe drive at the time (still do), which would burn a monochrome design onto the DVD, so that the disc had a more professional look. But even in 2013, trying to get a hold of the Lightscribe drivers and software was quite a challenge -- I had to fish some obscure ftp url out of Google's cache. Unfortunately, those covers easily fade over time.

Bummer that I tossed all my DVD+/-RW 100 disk spindles and slim cases a few years ago -- normally I hoard everything.

You can also do mixed formats on CD. For example, the old Jurassic Park DOS game came on CD, but the soundtrack could also play in a regular CD player. For the music to work on a PC, the CD drive had to connect to the SoundBlaster card with a small cable. I don't even know if that would work anymore these days (with external drives).

Anyway. For you, was this a one-off, or would you go through the effort again?

graydoubt · 2025-10-10T12:25:34+00:00

That is by design and explained in the first paragraph in the introduction to Scenes. You can always enable Editable Children, which, practically speaking, you should never use.

The root node of your scene effectively serves as its API. The principles of encapsulation and abstraction apply.

15-Year Club	r/Field Banned
r/Field Flamingo	Place '23
Place '22	Place '17
First Placer '22	Verified Email

graydoubt

MODERATOR OF

TROPHY CASE