Game Development Guides and Resources for Those Who Need It

[(In)CelibatePsycho]

Idk how hard it is to make a game using code or using Godot since I’ve never done it before but I do know it’s really easy to make a simple 2d game on a codeless engine like GDevelop

 

[Spas]

Godot sucks doo doo, I advise no one even attempt using it

 

[Soygoy]

Godot sucks doo doo, I advise no one even attempt using it

This genuinely offends me as a long time GODot dev

 

[(In)CelibatePsycho]

Godot sucks doo doo, I advise no one even attempt using it

Why

 

[Spas]

Why

From what I recall from my brief yet unpleasant experience with godot: the raycasting API sucked, and I mean it was just incredibly ugly and unintuitive, I was so appalled I went on googling if this was seriously how raycasting was supposed to be done, apparently some eggheads found out it was astoundingly slow as well compared to the competition, and even compared to it's own nodes! The raycasting node that continuously raycsts from itself forward was more optimized than the in code raycasting! I'm not going to take this node and teleport it around to get my fucking raycasts, what kind of glue and ducktape solution is that? That was honestly the biggest gripe I had with it, along with the rest of the unintuitive node system, the lack of focus on performance and web support, not having sprite masks (godot is supposed to be beginner friendly yet they don't have sprite masks?) and when I tried to create a mask shader I had the opportunity to interact with it's shader system, which didn't go anywhere, for reference I later tried learning shaders in unity and it yielded near immediate results. I didn't like the node system or gdscript (settled for writing in c#) but I was willing to suck it up and roll with it in hopes that I would acquire some valuable knowledge, but you get what you pay for, godot is free and open source so you get a bunch of "coming soon" and bad performance.
I was actually writing a list of things that pissed me off while learning godot because I was getting genuinely agitated and wanted to write down what was causing me so much grief, but there's about 20 papers on my desk and 50 on the other so fuck me if I'm going to go digging for it. Overall the experience of being in godot was much smoother than that of unity, they really did a good job with making the editor fast and light weight, but when it came to actually trying to make something it was just not a good time, I would much rather contend with a clunky, slow editor of unity that can provide me with the necessary tools and performance, as opposed to the contrary

 

[Soygoy]

From what I recall from my brief yet unpleasant experience with godot: the raycasting API sucked, and I mean it was just incredibly ugly and unintuitive, I was so appalled I went on googling if this was seriously how raycasting was supposed to be done, apparently some eggheads found out it was astoundingly slow as well compared to the competition, and even compared to it's own nodes! The raycasting node that continuously raycsts from itself forward was more optimized than the in code raycasting! I'm not going to take this node and teleport it around to get my fucking raycasts, what kind of glue and ducktape solution is that? That was honestly the biggest gripe I had with it, along with the rest of the unintuitive node system, the lack of focus on performance and web support, not having sprite masks (godot is supposed to be beginner friendly yet they don't have sprite masks?) and when I tried to create a mask shader I had the opportunity to interact with it's shader system, which didn't go anywhere, for reference I later tried learning shaders in unity and it yielded near immediate results. I didn't like the node system or gdscript (settled for writing in c#) but I was willing to suck it up and roll with it in hopes that I would acquire some valuable knowledge, but you get what you pay for, godot is free and open source so you get a bunch of "coming soon" and bad performance.
I was actually writing a list of things that pissed me off while learning godot because I was getting genuinely agitated and wanted to write down what was causing me so much grief, but there's about 20 papers on my desk and 50 on the other so fuck me if I'm going to go digging for it. Overall the experience of being in godot was much smoother than that of unity, they really did a good job with making the editor fast and light weight, but when it came to actually trying to make something it was just not a good time, I would much rather contend with a clunky, slow editor of unity that can provide me with the necessary tools and performance, as opposed to the contrary

What kind of game were you trying to make? Raycasting is not typically an issue for me. And "sprite masks" I don't know what you mean by this

 

[Soygoy]

The raycasting node that continuously raycsts from itself forward was more optimized than the in code raycasting!

Marge? What kind of retarded shit were you trying to do? (no offense, I could help you out or offer some sort of explanation, I use Raycast nodes all the time for my stuff and I don't see any issues with it)

 

[Soygoy]

My personal gripes with godot are it's current navigation system which is heavily inefficient and can cause immense amounts of lag if too many enemies use it once. My solution for that though was just to use NavigationMesh2D for navigation instead of tiles. As for you, though, Spas, I feel like a lot of issues you may have with Godot can be solved very easily, especially as a developer like myself. I always use Raycast nodes and honestly, moving the raycasts around in space seems like a way better solution to me, the fact that you don't want to dynamically program a good raycast system just shows as laziness in my opinion. If you're creating a 2D gun game, then IMO the best thing to do would be to spawn raycast nodes when you shoot and if they hit something, damage the thing they hit and queue_free() and also kill itself after a very very short period of time like 0.05, you can achieve this in Godot 4 by using lambdas that connect the _ready() function and the _collided() function to lambdas which do this. You can even use angular pi shit to create shotgun raycasts which form in a cone etc.

I think a lot of Godots """issues""" that people have with it are simply a product of misunderstanding that can be resolved with intuitive design.
Otherwise, it does indeed have a few bugs that are always getting fixed.

 

[Spas]

What kind of game were you trying to make? Raycasting is not typically an issue for me. And "sprite masks" I don't know what you mean by this

Sprite masks are sprites/shapes that are used to "mask out" a sprite, that's to say to determine which part of the sprite should be visible or invisible. Basically dynamically cutting out a part of the sprite

Marge? What kind of retarded shit were you trying to do? (no offense, I could help you out or offer some sort of explanation, I use Raycast nodes all the time for my stuff and I don't see any issues with it)

It wasn't an issue, I could have just put the raycasting node where I needed it, I just didn't like the solution being teleporting around my "raycaster" when I should be able to simply determine the parameters of the raycast (start, direction, length) in code. The project I was working on is the schoolocast game, and while in retrospect the raycasting wouldn't have presented so much of a problem for that specific project (thought there would have been other problems such as lack of masks and lackluster web support and inferior performance) the idea of having to teleport around a node to fetch my raycasts for me is simply something I'm not willing to do

the fact that you don't want to dynamically program a good raycast system just shows as laziness in my opinion

I shouldn't be "dynamically programming a good raycast system", raycasting is something that comes out of the box, it's an essential tool in game development, but instead of giving me good raycasting API, they give me a node for me to fuck around with. Like instead of giving me a hammer they give me a machine that hammers, and I have to drag it around to get it to hammer instead of just using a hammer myself. GIVE ME THE FUCKING HAMMER.

IMO the best thing to do would be to spawn raycast nodes when you shoot and if they hit something, damage the thing they hit and queue_free() and also kill itself after a very very short period of time like 0.05

This is exactly what I mean, it's like the engine isn't open to me, as a developer, to interact with it at a low level, but is instead obstructed and forcing me to basically play scratch with it's node system, rather than programming my own systems using the API. I don't want to be spawning in and teleporting nodes to achieve something I should be able to achieve with a couple lines of code. I don't like that, it feels like a roundabout, weird, unintuitive way of handling something as core and simple as raycasting, it completely made me lose interest for the engine. It feels like a wordkaround (and it is a workaround, a workaround of the shitty raycasting API) and it's not like I have no shitty workarounds in my projects, but it's different when I need a workaround because my own code was short sighted and when I need a workaround for a simple raycast because the engine is dog water.
You mention a shotgun, imagine how scuffed that would look, a loop which spawns like 12 raycster nodes, positions them at the barrel and randomly rotates them, fires them and then has to dispose of them. That just sounds DISGUSTING and unnecessary. or just having 12 raycast nodes just chilling at the barrel, like what the fuck kind of goofy ass game engine make a person do that? Imagine making a script to check line of sight, instead of saying "hey unity, heres point a and point b, does anything intersect?" I'd have to say "hey godot, spawn a raycaster node, position it on myself, take position of myself and the enemy, run some trigonometry to get the angle between us, set the node's rotation to this, then fire off the node, tell me if it hit anything and then delete it". It repulses me.

 

[Soygoy]

You mention a shotgun, imagine how scuffed that would look, a loop which spawns like 12 raycster nodes, positions them at the barrel and randomly rotates them, fires them and then has to dispose of them. That just sounds DISGUSTING and unnecessary. or just having 12 raycast nodes just chilling at the barrel, like what the fuck kind of goofy ass game engine make a person do that?

thats literally normal though and im pretty sure most games do that in some form, like even the source engine would do that, spawn raycasts from your screen and then position them etc.
i find your ability to be repulsed by something that is pretty much nothing to me fascinating. This is literally some shit I could figure out within an hour or 30 mins and let here you are malding over Godot's Node Oriented Programming LOL. (no offense)

Godot is very much a node based engine, you're supposed to do that and if you don't like that then you'll have to switch to something else I guess. And if you don't like what Godot has to offer, try programming in Java, where you have to code everything all by yourself, etc. I don't know much about Unity or whatever engine you are currently using but I personally have my own vendettas against other engines and not Godot, like the lack of proper linux support similar to your gripe with web support, Unreal not focusing on performance, requiring a high end PC just to run it or use it and Unity and Unreal in general not supporting 2D.

Godot is your best option for 2D games and the fact that you don't feel like dynamically programming something that is so easy that I could probably program it right now and upload the code and show you just how long it took me to do is honestly hilarious.

 

[Spas]

thats literally normal though and im pretty sure most games do that in some form, like even the source engine would do that, spawn raycasts from your screen and then position them etc

I assure you that's not the standard. Most engines simply have you use the API, you don't just "spawn" raycasts into the world, for example
raycasthit2d hit (information about a raycast collision) = physics2d.raycast([position, direction, length]);
This is how it works in unity and something similar to this is what godot does behind the scenes, but instead of being able to do what it's doing behind the scenes you have to instead work with it's nodes, for whatever reason. It's abnormal and unintuitive.

This is literally some shit I could figure out within an hour or 30 mins

My issue isn't that it's hard to figure out, I don't know if you think I'm some sort of idiot, I just don't like stupid workarounds

Godot is your best option for 2D games

Hardly, unity is packed with a lot more features (such as the aforementioned masks), it may be 3d focused but it has a robust 2d toolset, richer than that of godot

the fact that you don't feel like dynamically programming something that is so easy that I could probably program it right now and upload the code and show you just how long it took me to do

You're missing my point, it's not about the time it would take me, or the time it would take me to figure it out, it wasn't an issue of me not being able to figure out how to spawn and teleport around nodes. It's a silly and retarded way to do something I would otherwise be able to do by simply using the API. Evidently this workaround is a normalcy for you, maybe you don't even know an alternative way of raycasting, but understand this is utterly abnormal, and besides not wanting to engage with this, who knows what other retarded workarounds are necessary in this engine that I simply didn't have the time to acquainted myself with, and I have no reason to engage with something that annoys me so when I'm basically downgrading from a more powerful engine I am more skilled in.
it's like if I was complaining about how scratch makes me use its node system instead of letting me use the API and you told me "bro scratch is easy what are you on about"

 

[Soygoy]

I assure you that's not the standard. Most engines simply have you use the API, you don't just "spawn" raycasts into the world, for example
raycasthit2d hit (information about a raycast collision) = physics2d.raycast([position, direction, length]);
This is how it works in unity and something similar to this is what godot does behind the scenes, but instead of being able to do what it's doing behind the scenes you have to instead work with it's nodes, for whatever reason. It's abnormal and unintuitive.

My issue isn't that it's hard to figure out, I don't know if you think I'm some sort of idiot, I just don't like stupid workarounds

Hardly, unity is packed with a lot more features (such as the aforementioned masks), it may be 3d focused but it has a robust 2d toolset, richer than that of godot

You're missing my point, it's not about the time it would take me, or the time it would take me to figure it out, it wasn't an issue of me not being able to figure out how to spawn and teleport around nodes. It's a silly and retarded way to do something I would otherwise be able to do by simply using the API. Evidently this workaround is a normalcy for you, maybe you don't even know an alternative way of raycasting, but understand this is utterly abnormal, and besides not wanting to engage with this, who knows what other retarded workarounds are necessary in this engine that I simply didn't have the time to acquainted myself with, and I have no reason to engage with something that annoys me so when I'm basically downgrading from a more powerful engine I am more skilled in.
it's like if I was complaining about how scratch makes me use its node system instead of letting me use the API and you told me "bro scratch is easy what are you on about"

I literally just did it in like an hour lol and I don't understand your issue. Godot is a node oriented programming system, you're supposed to use nodes for everything.
They even encourage you to make your own nodes from smaller nodes. You just expect everything to come in like a handy unique 1 function fits all solution?
Godot is a node oriented programming system and you're getting mad because you don't want to use nodes? Wtf? And you're not using GDScript?
When the entire language is moreso dedicated towards using smaller nodes to create bigger nodes, etc?

IMO, Unity just sucks, bloated, owned by shit company, iffy linux support, hard to use UI and hard to understand etc, not lightweight at all, not open source, etc.
I did it fairly easy btw, only took 40 mins.

extends CharacterBody2D
class_name Player

const SPEED = 300.0

func _physics_process(delta):

    var direction = Input.get_axis("left", "right")
    var input_vector = Vector2(
        Input.get_action_strength("right") - Input.get_action_strength("left"),
        Input.get_action_strength("down") - Input.get_action_strength("up")
        )
        
    $Ak47.look_at(get_window().get_mouse_position())
    velocity = input_vector * SPEED

    move_and_slide()
    
    if Input.is_action_pressed("fire"):
        if $Cooldown.is_stopped():
            spawn_raycast(5,6)
            $Cooldown.start(0.05)

func spawn_raycast(amount=1,range=1):
    var flip = 1
    for i in amount:
        var b = preload("res://raycast.tscn").instantiate()
        b.target_position = Vector2(2000,0)
        b.position = Vector2(-192,-256)
        
        var variablerange = (90 * flip) / amount / range
        b.rotation_degrees = variablerange * i
        b.scale = Vector2(8,8)
        $Ak47.add_child(b)
        flip = -flip

Custom Raycast node:

extends RayCast2D

var has_damaged = false

func _ready():
    reparent(get_node("/root").get_child(0))
    
func _process(delta):
    if !has_damaged:
        if is_colliding():
            if get_collider() is Enemy:
                get_collider().health -= 1
            print("Damaged!")
            has_damaged = true

func _on_timer_timeout():
    queue_free()

 

[Soygoy]

Essentially I just think your opinion is weird because doing this isn't a "workaround" its a fundemental of programming.
In your eyes, coding your own rendering engine must also be a workaround and you need everyone to do everything for you, my strawman tells me to say "might aswell just have a makegame()"
But ultimately, I do not see this as an issue, do you also want a dynamic audio system built in? You want a dynamic raycast system built in?
Just learn to use nodes please. Yes it is similar to scratch, but that is the fundementals of Godot. You use smaller nodes to create bigger custom nodes.

 

[Soygoy]

it's like if I was complaining about how scratch makes me use its node system instead of letting me use the API and you told me "bro scratch is easy what are you on about"

Godot is a node based game engine, stop trying to avoid using the nodes.
Literally everything you do in Godot is done using Nodes!
Strawman Speak: git gud noob. lurk moar. use godot moar.
To anyone else reading, please use Godot for 2D games. Unity or Unreal can have its percs for 3D games, but ultimately, Godot is way easier than a 3D engine like Unity that was never designed to make 2D games.

I can understand your reasons for using Unity if you really don't like Node Oriented Programming, and to onlookers it may seem strange that another engine can do something in 1 line of code that another engine requires some setup to do, but the entire reason why it is like this is for customizability. I can customize my raycast node to do all kinds of things, spawn particles, detect specific players, etc. It's incredibly modular and that's why many people use Godot, compared to Unity with it's "GameObjects"

 

[Spas]

I literally just did it in like an hour lol and I don't understand your issue. Godot is a node oriented programming system, you're supposed to use nodes for everything.
They even encourage you to make your own nodes from smaller nodes. You just expect everything to come in like a handy unique 1 function fits all solution?
Godot is a node oriented programming system and you're getting mad because you don't want to use nodes? Wtf? And you're not using GDScript?
When the entire language is moreso dedicated towards using smaller nodes to create bigger nodes, etc?

IMO, Unity just sucks, bloated, owned by shit company, iffy linux support, hard to use UI and hard to understand etc, not lightweight at all, not open source, etc.
I did it fairly easy btw, only took 40 mins.
View attachment 13893

extends CharacterBody2D
class_name Player

const SPEED = 300.0

func _physics_process(delta):

    var direction = Input.get_axis("left", "right")
    var input_vector = Vector2(
        Input.get_action_strength("right") - Input.get_action_strength("left"),
        Input.get_action_strength("down") - Input.get_action_strength("up")
        )
       
    $Ak47.look_at(get_window().get_mouse_position())
    velocity = input_vector * SPEED

    move_and_slide()
   
    if Input.is_action_pressed("fire"):
        if $Cooldown.is_stopped():
            spawn_raycast(5,6)
            $Cooldown.start(0.05)

func spawn_raycast(amount=1,range=1):
    var flip = 1
    for i in amount:
        var b = preload("res://raycast.tscn").instantiate()
        b.target_position = Vector2(2000,0)
        b.position = Vector2(-192,-256)
       
        var variablerange = (90 * flip) / amount / range
        b.rotation_degrees = variablerange * i
        b.scale = Vector2(8,8)
        $Ak47.add_child(b)
        flip = -flip

Custom Raycast node:

extends RayCast2D

var has_damaged = false

func _ready():
    reparent(get_node("/root").get_child(0))
   
func _process(delta):
    if !has_damaged:
        if is_colliding():
            if get_collider() is Enemy:
                get_collider().health -= 1
            print("Damaged!")
            has_damaged = true

func _on_timer_timeout():
    queue_free()

Again, I wasn't saying that it would be hard to do, I was saying it requires an awkward and inelegant solution. I don't wish to spawn around objects to raycast for me when I could just do the raycast myself with a simple function. And I'm not using GDscript because I hate the python like syntax and I also heard it's slow. Also, I take great offense at the provided example.

You just expect everything to come in like a handy unique 1 function fits all solution?

Not sure where you got that, I just ask to be provided with basic tools, if the engine wants to have a raycast node, fine, but allow me to raycast without it. The API is there, it just sucks and is slow.

IMO, Unity just sucks, bloated, owned by shit company, iffy linux support, hard to use UI and hard to understand etc, not lightweight at all, not open source, etc.

Fair enough, but guess what? When I want to do something in unity I don't feel handicapped, like I do when I tried using godot. It can be finicky and clunky, but it's powerful so I'm willing to put up with it's bullshit.

Essentially I just think your opinion is weird because doing this isn't a "workaround" its a fundemental of programming.

I don't think "nodes" are "a fundamental of programming", it may be a fundamental of godot, and if it's going to "fundamentally" handicap my ability to engage with the engine I will just can it, as I did

In your eyes, coding your own rendering engine must also be a workaround and you need everyone to do everything for you, my strawman tells me to say "might aswell just have a makegame()"

I'm really marging out here

But ultimately, I do not see this as an issue, do you also want a dynamic audio system built in? You want a dynamic raycast system built in?

What do you mean "dynamic"? I Just want a proper API for raycasting that isn't slow as shit! In fact I'd say having a node for raycasting is more "built in" than being provided raycasting API but that's just semantics

Godot is a node based game engine, stop trying to avoid using the nodes.

The issue wasn't having to use nodes, the issue was that it required me to use nodes for something so basic I shouldn't have to use a node for it! Imagine if it asked you to use a "move" node for changing another node's position. You're right in that I didn't like the node system but that's not the reason I canned it.

I can understand your reasons for using Unity if you really don't like Node Oriented Programming, and to onlookers it may seem strange that another engine can do something in 1 line of code that another engine requires some setup to do, but the entire reason why it is like this is for customizability. I can customize my raycast node to do all kinds of things, spawn particles, detect specific players, etc. It's incredibly modular and that's why many people use Godot, compared to Unity with it's "GameObjects"

Yeah you can do that with a class, that isn't exactly a unique functionality. And my problem wasn't that "I can't do this with one line of code", it's not about lines of code, for example your code for orientating the gun towards the mouse is a lot shorter than what I have to do in unity (get mouse position, get character position, calculate the angle between them, convert to quaternions, set the rotation), it's about the inelegance, the stupid workaround that you have to do in order to avoid the slow API. And what's with the zellig level shilling? I just expressed that I find issue with an engine that makes me construct inelegant workarounds for something simple like raycasting due to it's API being fucking dog water, I didn't call it useless, I just hate it

PS. instead of setting text color to black use the "remove formatting" option

 

[Spas]

extends CharacterBody2D
class_name Player

const SPEED = 300.0

func _physics_process(delta):

    var direction = Input.get_axis("left", "right")
    var input_vector = Vector2(
        Input.get_action_strength("right") - Input.get_action_strength("left"),
        Input.get_action_strength("down") - Input.get_action_strength("up")
        )
      
    $Ak47.look_at(get_window().get_mouse_position())
    velocity = input_vector * SPEED

    move_and_slide()
  
    if Input.is_action_pressed("fire"):
        if $Cooldown.is_stopped():
            spawn_raycast(5,6)
            $Cooldown.start(0.05)

func spawn_raycast(amount=1,range=1):
    var flip = 1
    for i in amount:
        var b = preload("res://raycast.tscn").instantiate()
        b.target_position = Vector2(2000,0)
        b.position = Vector2(-192,-256)
      
        var variablerange = (90 * flip) / amount / range
        b.rotation_degrees = variablerange * i
        b.scale = Vector2(8,8)
        $Ak47.add_child(b)
        flip = -flip

Custom Raycast node:

extends RayCast2D

var has_damaged = false

func _ready():
    reparent(get_node("/root").get_child(0))
  
func _process(delta):
    if !has_damaged:
        if is_colliding():
            if get_collider() is Enemy:
                get_collider().health -= 1
            print("Damaged!")
            has_damaged = true

func _on_timer_timeout():
    queue_free()

Also just to touch on the example, rotating the gun and the "cooldown" functions are more elegant than the unity counterparts, they act as neat packages of functionality that I assume you think I want
But the rest is just giving me a headache, you instantiate a bunch of your custom raycast node (instantiating is also generally slow, slower than using the API at least, but godot wasn't designed for performance) then you give them a boolean to regulate whether they should be checking their collisions, because the function is constantly raycasting! THAT IS REPULSIVE. You can't even tell the node to cast a single ray, it just keeps on going until you KILL IT! That's outrageous! And then you just delete it after a arbitrary amount of time supposedly. So inelegant, I would hang myself if I was made to write something like this

 

[Soygoy]

And I'm not using GDscript because I hate the python like syntax and I also heard it's slow

Subjective opinion with an "i heard its slow doe" even though its not

Also, I take great offense at the provided example.

>OFFENDED

if the engine wants to have a raycast node, fine, but allow me to raycast without it

This just makes no sense to me, it's like saying "if the engine wants to have a sprite node thats fine but allow me to render sprites without it"
Godot is a node based game engine, everything you do is done with nodes, IMO there should be no raycasting api and I hope to see it be deprecated.

Fair enough, but guess what? When I want to do something in unity I don't feel handicapped, like I do when I tried using godot. It can be finicky and clunky, but it's powerful so I'm willing to put up with it's bullshit.

So you have the same issues with Unity but you don't want to use Godot just because it's foreign to you?

I don't think "nodes" are "a fundamental of programming", it may be a fundamental of godot, and if it's going to "fundamentally" handicap my ability to engage with the engine I will just can it, as I did

>filtered by da noooooodes

I'm really marging out here

I was speaking from experience as a programmer who's often had to use C and go deep into a subject to get shit working. Not too deep, but I've gotten audio engines ported and stuff like that before, it'll be a while before I made my own graphics engine or something really advanced like that, but stuff like that I guess is extremely low level or high level idk that I'm just okay with it.

I Just want a proper API for raycasting that isn't slow as shit! In fact I'd say having a node for raycasting is more "built in" than being provided raycasting API but that's just semantics

I don't think there should be an "api" for raycasting at all. Just use the node.

The issue wasn't having to use nodes, the issue was that it required me to use nodes for something so basic I shouldn't have to use a node for it! Imagine if it asked you to use a "move" node for changing another node's position. You're right in that I didn't like the node system but that's not the reason I canned it.

I think your issue is that you've used Unity so much that you've taken something for granted and you don't want to learn to adapt to a new engine because you're stubborn. Also, it's funny you should say that because of the Unity Transform object which I'm pretty sure is literally just a "move" node, correct me if I'm wrong.

And what's with the zellig level shilling? I just expressed that I find issue with an engine that makes me construct inelegant workarounds for something simple like raycasting due to it's API being fucking dog water, I didn't call it useless, I just hate it

Alright, Spas. It's in my best interest to not be offensive towards you but essentially I'm saying this because your personal opinions are discrediting the engine for no reason.

Godot sucks doo doo, I advise no one even attempt using it

Why do you think you are entitled to say this? I don't like Unity or Unreal and I don't even think that people shouldn't use it at all, but here you are saying that NOBODY should use Godot at all just because you're unwilling to adapt to the node system? Most of our points come down to subjective tastes so I can understand why you might like Unity and as the shilling, Godot isn't perfect, it has it's bugs, but your points are somewhat strange or unreasonable to me. If you don't want to use the engine, don't use it, but going out of your way to say that nobody should use it is just wrong. Godot is great for 2D and I would advise that everyone try it out and get deep into it to see what the engine has to offer, rather than just listening to us bickering or shitty anecdotes like "I heard it was bad" etc.

 

[Soygoy]

Also just to touch on the example, rotating the gun and the "cooldown" functions are more elegant than the unity counterparts, they act as neat packages of functionality that I assume you think I want
But the rest is just giving me a headache, you instantiate a bunch of your custom raycast node (instantiating is also generally slow, slower than using the API at least, but godot wasn't designed for performance) then you give them a boolean to regulate whether they should be checking their collisions, because the function is constantly raycasting! THAT IS REPULSIVE. You can't even tell the node to cast a single ray, it just keeps on going until you KILL IT! That's outrageous! And then you just delete it after a arbitrary amount of time supposedly. So inelegant, I would hang myself if I was made to write something like this

whoops my bad

just queue_free() after you hit so you only have to wait the specified amount of time if you're not hitting anything

you instantiate a bunch of your custom raycast node (instantiating is also generally slow, slower than using the API at least, but godot wasn't designed for performance)

saaar how fast do you really want your game to fucking be 8000000000 fps?
>muh performance chuds wanting like 10000k fps
also black

then you give them a boolean to regulate whether they should be checking their collisions, because the function is constantly raycasting! THAT IS REPULSIVE. You can't even tell the node to cast a single ray, it just keeps on going until you KILL IT! That's outrageous! And then you just delete it after a arbitrary amount of time supposedly. So inelegant, I would hang myself if I was made to write something like this

i think you're sperging out i dont see the issue in it continuously raycasting

 

[Soygoy]

itt:

 

[Soygoy]

another cool idea i just thought about btw is the fact that raycasts continuously cast, so you can just make the fire button check if your raycasts are colliding and then thats a way more efficient way of checking if they've hit their target once. so on fire would check if the rays are colliding and use that instead of instantiating them and killing them and stuff