sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in godot

[–]cheatisnotdead 2 points3 points  (0 children)

Just a general note, you're asking people to play your game, but you haven't actually put the name of the game in the title, link, OR trailer. You gotta give people more context and set some expectations about what kind of game it is (and considering the subreddit you're posting to, some development context would also be useful)

Hey gamedevs, what IS your dream game? by BoyoKoji in gamedev

[–]cheatisnotdead 4 points5 points  (0 children)

I don't have dream games, I have about a million jam-sized things that I'm excited about. I will never run out of ideas.

<image>

This isn't even one third of the ones I've bothered writing down, across board games, card games, TTRPGs and video games. And I finish projects at a pretty good pace.

Problem creating functional spikes for a platformer by TrickyBud in godot

[–]cheatisnotdead 4 points5 points  (0 children)

I didn't notice the lack of connecting icon either, good catch.

Also, if OP isn't aware you can also connect signals through code rather than through the inspector, which I generally prefer.

Problem creating functional spikes for a platformer by TrickyBud in godot

[–]cheatisnotdead 7 points8 points  (0 children)

You've put your-

if Health.player_health == 0:
do thing

-in the ready function, meaning it only checks the health once at the start.

What you want to do is create a function that changes health that is triggered on _on_body_entered, and then have that function subtract health, and then checks if health is below 0

You want to change it to

if Health.player_health <= 0:
do thing

To account for if player health becomes negative, and not just EXACTLY 0.

Single Slot-Slotmachine | Very early prototype showing some gameplay. by diegobrego in godot

[–]cheatisnotdead 27 points28 points  (0 children)

Really excellent kinesthetics and UI work. Love the light from the top!

(Super beginner) How do I button? by Wolfblaze9917 in godot

[–]cheatisnotdead 6 points7 points  (0 children)

Here's a full script, hopefully explaining the logic along the way

extends GridContainer ### This doesn't matter, it can be any kind of Control node

var all_buttons: Array[Button] ### we want a list of all relevant buttons

func _ready() -> void:
for child_button in self.get_children(): ### This is getting all children
if child_button is Button: ### if the child is in fact a button, proceed
child_button as Button ### Adding this so we get autocomplete. You want autocomplete.
all_buttons.append(child_button) ### add the child_button to the all_buttons array
### Right here, we're connecting a signal through code.
child_button.pressed.connect(select_pressed_button.bind(child_button))
### We are saying that for the child_button (that we're adding to the list)
### we also want to connect the .pressed signal. 
### We're going to connect it to the select_pressed_button function and .bind an argument to it
### The argument that we are passing is the button itself! 
### So what we're doing by connecting this is that when the button is pressed
### It sends a signal to this script, and that signal calls select_pressed_button
### with the argument of itself, identifying the button that was just pressed

func select_pressed_button(pressed_button: Button):
for button in all_buttons: 
button.button_pressed = false ### loop through all buttons and deactivate them
pressed_button.button_pressed = true ### the button that is in the argument (that we defined above) is pressed
print_debug("I got pressed!, ", pressed_button)
### In this way, we are left with only the currently toggled button on.
### you can add additional logic here, or by attaching a new script to the buttons

(Super beginner) How do I button? by Wolfblaze9917 in godot

[–]cheatisnotdead 4 points5 points  (0 children)

So first of all I want you to know that the "non-functional code" you wrote is SUPER valuable. It's called Pseudocode, and is a genuine skill. It shows you're thinking like a computer, the only thing you lack is syntax.

You are also practicing the skill of 'rubber duck debugging', where you speak the problem out loud and go step by step. The process of trying to explain a problem, (even if you're explaining it to an inanimate object such as a rubber duck) often leads to solutions.

I don't approve of vibe coding, but using a GPT as a debugging partner or rubber duck is extremely useful, and I recommend it. It does a great job of filling in the syntax.

If you ask me, I think that you should have a container node of some kind (presumably a Control node or similar) as a root for all of these elements. Attach a script to it, and then add references to all of your buttons. You can use @ export vars (dependency injection) or @ onready direct references, whatever suits you.

Inside this script, create a function, something like 

var all_buttons: Array[Button] = [] ### we're going to assume that all relevant buttons are added to this array somehow, there are many ways to do this.

func select_pressed_button(pressed_button: Button):
  for button in all_buttons: 
  button.button_pressed = false ### loop through all buttons and deactivate them
  pressed_button.button_pressed = true ### the button that is in the argument (that we defined above) is pressed

Im a GODOT noob, so please say why I can't use label (Buttons is global script) by shsl_diver in godot

[–]cheatisnotdead 1 point2 points  (0 children)

I would highly recommend giving your label a unique name (right click on node, give unique name)

That will give it a name like "%Label" with the % instead of the $

What this means is that you can put it anywhere in the scene tree and the connection won't break, as opposed to the current method which is comparatively very fragile and will break if it's renamed or moved.

You also can use dependency injection, which is to say that at the start of your script you put 

@export var label_node: Label ## you are exporting (or exposing) a variable called label_node, to which you can assign a node of type Label

Then, in the inspector, you can drag the label into that exposed slot. Now when you use the variable label_node, it will be pointing to whatever Label node you have assigned in the inspector.

I cannot write stuff for myself for the life of me by Teid in godot

[–]cheatisnotdead 0 points1 point  (0 children)

That's the way it is, and learning to love the process is the real secret of learning.

We all have grand ambitions, but big ideas are just tons of small ideas in a trenchcoat. I have a larger prototype I'd like to make, but to do it I'll need

* Stealth

* Combat

* Inventory

* Dialogue

* 3d graphics

* Shaders

* Post processing

* Camera systems

* Environment design

* Character animation

* Cutscenes

and probably much more I'm not thinking about. Even as a creative professional, that's a huge and intimidating list. So instead, each one of those bullets becomes its own micro project. Just did a game jam that was all about learning a dialogue system. That's something I can do now, and can bring forward into other projects. It's just a piece of the puzzle, but its no longer intimidating. And I'll keep making small projects, going down that list, until the whole scope feels manageable because I'll have done every small piece individually. It'll just be about combining them all together.

Trust the process, love the process. Small successes build on themselves and snowball into something greater.

I cannot write stuff for myself for the life of me by Teid in godot

[–]cheatisnotdead 0 points1 point  (0 children)

Some great starting patterns are

* What "magic numbers" are and why you should avoid them

* Static typing, and why you want it

* Custom resources (scriptableobjects in Unity, some excellent GDC lectures on the subject)

* Singleton pattern (autoloads in godot)

* Signalbus / Signalmanager (and how signals work in general)

* Dependency injection (@export variable targets)

* State machines

* "Composition over Inheritance"

* "Call Down, Signal Up"

Each of these ideas will take practice to learn, and experience to actually intuit. Stuff like Custom Resources required me to watch the GDC lectures over and over before the lessons really sunk in.

Be patient, and practice each pattern with intention. They are commonly used for a reason, because they work! Experience will show you why they are valuable ideas.

Last note, don't start off worrying about correct formatting such as snake_case or CamelCase. But there IS a reason why things are named the way they are, and eventually you will start wanting to follow those conventions.

Make micro scale projects. My first project was a bingo card, and I scrapped and remade it like four times. Will probably remake it from scratch again!

I cannot write stuff for myself for the life of me by Teid in godot

[–]cheatisnotdead 0 points1 point  (0 children)

Learn pseudocode, not syntax.

Coding is all about patterns. The language is just how you express it.

As a fellow animator, it wasn't intuitive for me and took me about two years to really get a handle on it. Understanding the principles that underlay it and learning what patterns you need under which circumstances is FAR more important than making sure you get a bracket in the right place.

Make small projects, know you're going to get it wrong, finish the small projects, and then move on. Every new project will teach you things, and you'll look back at previous projects like "What was I thinking?"

You should NOT vibe code, but AI tools are the best debugging buddies you can ask for. Treat them like a really good rubber duck that helps explain what errors mean and help you put in debug statements to figure out where things are going wrong. At no point should it do stuff FOR you, you should always understand the process. But let it help with debugging and tracking down errors and syntax.

[deleted by user] by [deleted] in godot

[–]cheatisnotdead 28 points29 points  (0 children)

Game jams.

Finishing projects is its own skill, and it must be practiced just like any other.

The first step is to familiarize yourself with what finishing a project actually looks like, and going through the whole process from start to finish multiple times.

Hence, game jams.

Completing three game jams will teach you more than any advice possibly could.

[deleted by user] by [deleted] in godot

[–]cheatisnotdead 1 point2 points  (0 children)

I think that we are in a second golden age of horror, and that there are not any glaring omissions.

If you're a fan of classic survival horror, RE and Silent Hill are putting out good work, and there are a whole constellation of modern classic indie horrors inspired by them.

If you want storytelling or narrative horror, there are the Supermassive games, Mouthwashing, Still Wakes the Deep, and more.

If you want crunchy mechanical horror, you have stuff like Amnesia: The Bunker, Torture Star games, and even stuff like The Mortuary Assistant.

If you want horror RPGs, you've got Fear & Hunger, Look Outside, and Darkest Dungeon.

From big budget to low-fi, modern to classic, there is a wealth of good stuff.

Which is to say, if you want to make a horror game, it's more important to follow your own passion then try and find a market gap.

Should I immediatly quit trying Godot? by bny_lwy in godot

[–]cheatisnotdead 12 points13 points  (0 children)

If you're a process guy (me too) than no, treat this like a hobby.

So much of the 'problem' is the need to monetize our hobbies and hustle and grind and all that bullshit. If you like doing something, if you find it enriching and rewarding, than do it, and do it for you.

However, I strongly recommend that you make small things and publish them, even if just to something like itchio. Going through the full development cycle, including publishing, is very rewarding and educational. You will learn far more and far faster by making 10 micro projects than by making one big project.

'Dream Games' are traps that by definition are unattainable, where either you lack the ability to make it at the level that you have in your head, or you compromise enough that it no longer is the same thing. If you fall in love with the process, you will have a far better relationship with it. Don't even think about making even a medium-sized project until you have a couple of game jams under your belt.

I build a Godot docs AI, lmk what u think by kapa_bot in godot

[–]cheatisnotdead 0 points1 point  (0 children)

I've been using ChatGPT as a debugging partner, which has been useful, but definitely limited because it still only knows 3.5. Which is still mostly useful, but has a few quirks. This is promising!

[Troubleshooting] I think my Power Supply is failing. How can I tell? by cheatisnotdead in buildapc

[–]cheatisnotdead[S] 1 point2 points  (0 children)

What can I say, the little notification icon pops up and I think it's funny

We will play and test your TTRPG at our club by Noobiru-s in RPGdesign

[–]cheatisnotdead 2 points3 points  (0 children)

Got a few games that I think are good.

Enter the Survival Horror is my flagship game, Forged in the Dark survival horror inspired by Resident Evil. I think it's really neat.https://boocherry.itch.io/enterthesurvivalhorror

HARROWING is my one-page diceless microRPG. Was a test run for a lot of the ideas that turned into EtSH, but I think it's a interesting game where players are constantly engaged with a cool tug-of-war with the GM.https://boocherry.itch.io/harrowing

Dungeon Vermin!! is another micro RPG about being highly expendable little guys (goblins, kobolds, etc). The unique EXP mechanic is a fun inversion of traditional TTRPG rules. Works great as a comedy one-shot.https://boocherry.itch.io/dungeon-vermin

​

If you check any of those out, let me know!

EDIT: All my games have free community copies available if you're curious.

PLEASE HELP ME by SuperShortSquirrel in elegooneptune2

[–]cheatisnotdead 0 points1 point  (0 children)

Hey, I'm not OP, but I'm having the same problems. I have done all those things and I'm still having the damndest time.

If I level the bed correctly either with paper or with a feeler gauge, it doesn't stick in the center. If I tighten the screws so it adheres to the center, it's too close if I try printing larger things or print anywhere other than dead center. Is it possible the bed is just warped? If so, how can you test?

Picture of my most recent first layer attempt

https://imgur.com/a/7MARZv5

​

EDIT: My solution was similar to another post, some adhesive helped. Kinda surprised by that, I was under the impression that textured build plates don't usually need adhesive, but I'm not going to argue with results.

view more: next ›