this post was submitted on 02 Jun 2025
127 points (98.5% liked)

196

3484 readers
2199 users here now

Community Rules

You must post before you leave

Be nice. Assume others have good intent (within reason).

Block or ignore posts, comments, and users that irritate you in some way rather than engaging. Report if they are actually breaking community rules.

Use content warnings and/or mark as NSFW when appropriate. Most posts with content warnings likely need to be marked NSFW.

Most 196 posts are memes, shitposts, cute images, or even just recent things that happened, etc. There is no real theme, but try to avoid posts that are very inflammatory, offensive, very low quality, or very "off topic".

Bigotry is not allowed, this includes (but is not limited to): Homophobia, Transphobia, Racism, Sexism, Abelism, Classism, or discrimination based on things like Ethnicity, Nationality, Language, or Religion.

Avoid shilling for corporations, posting advertisements, or promoting exploitation of workers.

Proselytization, support, or defense of authoritarianism is not welcome. This includes but is not limited to: imperialism, nationalism, genocide denial, ethnic or racial supremacy, fascism, Nazism, Marxism-Leninism, Maoism, etc.

Avoid AI generated content.

Avoid misinformation.

Avoid incomprehensible posts.

No threats or personal attacks.

No spam.

Moderator Guidelines

Moderator Guidelines

  • Don’t be mean to users. Be gentle or neutral.
  • Most moderator actions which have a modlog message should include your username.
  • When in doubt about whether or not a user is problematic, send them a DM.
  • Don’t waste time debating/arguing with problematic users.
  • Assume the best, but don’t tolerate sealioning/just asking questions/concern trolling.
  • Ask another mod to take over cases you struggle with, if you get tired, or when things get personal.
  • Ask the other mods for advice when things get complicated.
  • Share everything you do in the mod matrix, both so several mods aren't unknowingly handling the same issues, but also so you can receive feedback on what you intend to do.
  • Don't rush mod actions. If a case doesn't need to be handled right away, consider taking a short break before getting to it. This is to say, cool down and make room for feedback.
  • Don’t perform too much moderation in the comments, except if you want a verdict to be public or to ask people to dial a convo down/stop. Single comment warnings are okay.
  • Send users concise DMs about verdicts about them, such as bans etc, except in cases where it is clear we don’t want them at all, such as obvious transphobes. No need to notify someone they haven’t been banned of course.
  • Explain to a user why their behavior is problematic and how it is distressing others rather than engage with whatever they are saying. Ask them to avoid this in the future and send them packing if they do not comply.
  • First warn users, then temp ban them, then finally perma ban them when they break the rules or act inappropriately. Skip steps if necessary.
  • Use neutral statements like “this statement can be considered transphobic” rather than “you are being transphobic”.
  • No large decisions or actions without community input (polls or meta posts f.ex.).
  • Large internal decisions (such as ousting a mod) might require a vote, needing more than 50% of the votes to pass. Also consider asking the community for feedback.
  • Remember you are a voluntary moderator. You don’t get paid. Take a break when you need one. Perhaps ask another moderator to step in if necessary.

founded 4 months ago
MODERATORS
 

yes, i am promptin u to prompt me so i cn respond in the commnts

so like... put a commnt or somthn...

i promise all my responses will be real and written by me by hand, nt by som language model.

in case things get badhav a look here.

lets have friendly, fact-based discussions, if any arise... i rlli hope not, i jus wanted dis to be a funi lil thing, jus a post so i get to pretend to be an llm...

you are viewing a single comment's thread
view the rest of the comments
[–] Smorty@lemmy.blahaj.zone 22 points 5 days ago (3 children)

Working on a complex Godot project, just like with any other complex software development project, is a difficult and iterative process. 😓

However, there are steps you can take to make it easier for yourself when your project start growing 🌳

Export EVERYTHING 💽

Godot allows you to set properties of nodes or resources quickly in the inspector! so instead of modifying your code to update a value, you can simply enter the changes right in the editor inspector!

To export a property, you add the @export keyword! It has many variations, here are some of them

# 10 will be the default value
@export var some_number : int = 10

# Shows a longer text field to enter multi-line text
@export_multiline var some_long_text : String

# Shows a slider which goes from 0 to 10 with a step of 0.5
@export_range(0, 10, 0.5) var stepped_value : float = 1.5

Making changes like this increases your iteration speed drastically, as you can even edit these values while in-game and they will update accordingly!

Custom Resources 📰

Custom Resources are a true blessing in Godot! They allow to quickly assign a lot of values right in the editor, even allowing to share them between multiple nodes!

For example, to create an EnemyStats Resource, you can write code like this

extends Resource # Makes sure the resource can be saved and shows up in inspector correctly

class_name EnemyStats # Giving our new resource type a name

@export var health : int = 10

@export_range(0, 100, "allow_greater") var damage : int = 2

@export_multiline var description : String = "This enemy is incredibly fierce! watch out!"

@export var drops : Array[ Item ]

# You can add more properties!

Afterwards, in any node script you want, you wan simply export a variable of type EnemyStats

@export var stats : EnemyStats

and now you can edit all the stats in the inspector!

You can access the stats in code like this

var enemy_health : String = stats.health
print("This enemy has ", enemy_health, " health!")

and it will print this enemies health.

Working with custom resources can speed up development drastically, as resources can be quickly saved, shared, assigned and modified and they are incredibly flexible as they can contain any godot-native data!

File Structure 📂

Often under-appreciated are clean, easy-to-use project file structures.

Beginners will often cobble together any scripts or scenes which seem somewhat alike and "work out the structure later".

When that "later" arrives however, they have a mountain of different file types and contexts to sort through to create clarity.

Here a file structure I have found to be very useful, even in more complex projects:

  • addons 📂 (you addons and plugins are installed into here automatically)
  • scenes 📂 (a general purpose scenes folder, containing ALL the scenes in your project)
    • characters 📂
      • character_base.tscn 🎬
      • player.tscn 🎬
      • test_enemy.tscn 🎬
    • interfaces 📂
      • windows 📂
      • debug 📂
      • screens 📂
        • start_screen.tscn 🎬
        • settings_screen.tscn 🎬
  • scripts 📂
    • resource_types 📂 (includes all custom resource types)
    • characters 📂
      • movement 📂
        • movement_base.gd 📜
        • player_character_controller.gd 📜 (extends movement_base.gd)
        • enemy_character_controller.gd 📜 (extends movenent_base.gd)
    • interfaces 📂
      • screens 📂
        • start_screen.gd 📜
        • settings_screen.gd 📜

Write your own Tools! (advanced) 🧰

When Resources and a good project structure are not enough and you feel yourselves doing many repetitive steps over and over again, eating up you time, writing your own tools is the way to go!

Godot allows you to add you own custom tool integration into all sorts of places!

  • Add you own custom panels anywhere you want
  • Add custom right-click options to any element
  • Add custom shortcuts for quicker navigation
  • Add a custom tool script with a simple window interface to make large changes rapidly
  • And much more...

If you have any question regarding something I mentioned, or you want to iterate on your video game idea, ask right away ☺️

[–] Rai@lemmy.dbzer0.com 8 points 5 days ago (1 children)

Are you actually not using LLM? This does NOT taste like LLM. I love this sooooooo much. I love your persona. Holy heck.

[–] Smorty@lemmy.blahaj.zone 3 points 4 days ago

I can ensure you that all provided content is 100% human generated! ✅ 🧙‍♀️

I have made first hand experience reguarding organisational problems and programming hurdles in the Godot Game Engine 🔵 and I could not pass up the opportunity to share my experiences to empower others.

If you are willing to step further and uncover the wide range of Godots capabilities 🧰 just let me know 😉

[–] Tyoda@lemm.ee 8 points 5 days ago

Thank you Smorty bot!

I had not heard of this usage of the Resource class before, but I think I could use it in the future!

I think properly organizing scripts like you said and splitting up functionality into separate classes would be key to make opening the project and working on it seem less daunting.

[–] GammaGames@beehaw.org 8 points 5 days ago (1 children)

You might have to cast that health stat to string, since the type is hinted. You can also use prints to automatically insert spaces between arguments

Good advice! This is a great post

[–] Smorty@lemmy.blahaj.zone 2 points 4 days ago (1 children)
<think>
okay so the user mentioned that I should cast the health int to a String for the print, since its type is hinted. They also suggested the prints function which separates all arguments with a space.

I need to let them know that the regular print method also supports passing any type of Variant and it will still result in a valid print in the Output console.

Wait, maybe they knew this and are simply implying that casting the health int to a String would be better for readability.

Keep the response friendly and helpful
</think>

Aah yes, of course! Casting the @export_range(0, 100, "allow_greater") var health : int to a String 🧶 would increase readability significantly! Let's look at how this would look like

print("This enemy has ", str(stats.health), " health!")

Running this code would print this into the Output console:

This enemy has 10 health!

This way, we make it clear that the health being passed as an argument is a String.

It is important to note that the print() function allows for arguments of any type and converts each into a String automatically.

So practically, a conversion is not strictly required.

If you have any other recommendations to improve our code or questions about custom Resources, just let me know 😉

[–] GammaGames@beehaw.org 1 points 4 days ago* (last edited 4 days ago) (1 children)

Oops, I wasn't clear! I appreciate the thought process there, I'll be more detailed.

My first note was for the type hint. That Stats resource uses an int for the health property, so var enemy_health : String = stats.health would throw Parse Error: Cannot assign a value of type int to variable "enemy_health" with specified type String.
It could be fixed by changing the type in the hint, or picking it automatically: var enemy_health := stats.health

The confusion muddied up my second point, you can replace:

print("This enemy has ", enemy_health, " health!")

with:

prints("This enemy has", enemy_health, "health!")

Which doesn't do much here, but when you've got multiple variables it's easier than adding , " ", between each 😉 I don't have any other feedback, it was a solid reply with some useful info!

[–] Smorty@lemmy.blahaj.zone 2 points 3 days ago

Oh, you cought my error there! 😄

Yes, you are absolutely correct and I should have payed closer attention 🔎 🤔

Thank you for pointing out my error!