Game Development Guides and Resources for Those Who Need It

here u go spas way better system i cooked up just now
Generate the casts on startup or simply make them in the editor, then only check them when you fire and check them once. otherwise do the timer thing I did and pressed if you want rapid fire.

Code:
extends CharacterBody2D
class_name Player

const SPEED = 300.0

func _ready():
    spawn_raycast(5,6)

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_just_pressed("fire"):
        for i in $Ak47.get_children():
            check_cast(i)

func check_cast(node):
    if node is RayCast2D:
        if node.get_collider() is Enemy:
            node.get_collider().health -= 1
            print("Damaged!")

func spawn_raycast(amount=1,range=1):
    var flip = 1
    for i in amount:
        var b = RayCast2D.new()
        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
 
Subjective opinion with an "i heard its slow doe" even though its not
I watched some videos and read some articles about godot having performance issues, watched some benchmark tests too and they didn't paint gdscript as very excellent
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.
Because I don't think of raycasting as sufficiently complex to require me to use a node when it could be easily done using the API, if the API didn't suck ass. As the example I gave, imagine using a move node to set position of objects, imagine using a rotate node to set rotation of objects, it would be absurd. Also good bait at the end, but with how shit it is it's basically deprecated already
So you have the same issues with Unity but you don't want to use Godot just because it's foreign to you?
No, those are specifically different issues, are you just baiting me at this point?
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 still don't see how that relates, I'm not asking for low level access to the engine nor am I interested in reinventing the wheel, I just want proper API
fair enough
Unity Transform object
That's not an object, it's more so an inherit property of every object (contains position, rotation and scale), but the point is, it would be stupid if I had to add a node (or object) to "unlock" a basic functionality such as changing an objects position (or in the case of raycasting, raycasting)
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.
I'm entitled to say it because I can, I hated godot and it was a very unpleasant experience, I don't wish that on anyone else for what is, by the looks of things, a subpar engine. Not that I care, really, but you do have to understand the theatrics of saying "I advise no one even attempt using it". It's the advice I would give myself but as far as I'm concerned people should give it a try so they can see I was right decide for themselves.
>muh performance
Yeah, muh performance, do you know what a pain in the ass it was getting schoolocaust to run ACCEPTABLY on browsers (by acceptable Im talking above fuckin 30)? fucking headache that was, I tell you. It's bad enough having to worry about performance, I would hate working with an engine that would further fuck me over in that regard
i think you're sperging out i dont see the issue in it continuously raycasting
Well yeah sure, at least in this example there is no issue; raycasting isn't really hard on performance, or so I've heard, so having a single node do it constantly instead of once every once in a while isn't going to affect much, but it's just repulsive, having it constantly raycast even when you don't need it to? It's wasteful and inelegant and takes control away from me which I personally despise, I can't contend with that
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
Yeah exactly this, it's constantly raycasting even when you don't need it to. why would I have it constantly raycast if I only need it to raycast once, at the point of firing? I can't abide this shit, intolerable
 
For the sake of example, imagine a game with a lot of entities that all want to raycast every once in a while
If I can just call the raycasts through API it's no problem, but what about godot? Do I just give them all a node that is CONSTANTLY raycasting? Probably not going to be very conducive to good performance. What if I need multiple raycasts done at one frame? Do I just instantiate another raycast node for this and then delete it? What if every entity has a constantly changing list of entities towards which it needs to periodically raycast? This wouldn't be an issue using API, it would be elegant, easy and efficient, but no matter how I envision it in godot it just looks wasteful and inelegant.
Now sure, "what a stupid example that is" but what if something like that was required? I don't like the idea of having insufficient tools to solve problems efficiently
 
schoolocaust to run ACCEPTABLY on browsers
it must run in browser it just has to okay?!?!
The issue is not Godot, it's browsers that are known for being notoriously shit performance wise.
I don't wish that on anyone else for what is, by the looks of things, a subpar engine.
just objectively wrong honestly also can your raycasts do this doe


they can see I was right
clitty status: leaking
As a Godot user myself, honestly I still don't even understand your viewpoint, it's not awful or subpar at all, it's an incredibly capable engine that can do almost anything Unity can do. Infact, if you would like to, give me a challenge that you think Unity can do that Godot can't and I'll do it >inb4 unity can spawn 10000000000000 ducks and godot can only spawn 100000000000

Genuinely your performance concerns are not Godot's fault its you making a game for fucking web browsers, its 2024 who the fuck plays games in their browsers nigga.
Atleast be supportive and optimistic and just say that you hope it gets better someday instead of zelligly hating it
 
Do I just give them all a node that is CONSTANTLY raycasting?
if its such an issue you can just
1719480057477.png

and then
1719480067176.png

when you need to use it ie when you press the fire button or when enemy attacks
 
>da performance is baaad
1719480830395.png

>OH MY CLITTY NO DONT DO IT SOYGOY
>NOOOOO
1719480902393.png


1719480972083.png


lags at 10k raycasts: "see i told you the performance was shit"
needs 100k raycasts award
1719481153394.png
 
it must run in browser it just has to okay?!?!
Yes, I needed it to run in a browser
The issue is not Godot, it's browsers that are known for being notoriously shit performance wise.
Being notoriously shit performance wise is something you have to account for when making a game you want to run in a browser, want me to fix the entirety of all internet browsers instead? I want a versatile and reliable toolset I can be confident in regardless of what problem I need to tackle, that's why I prefer unity over godot
also can your raycasts do this doe
Yeah, I don't see what makes you think it couldn't
do almost anything Unity can do
Except for sprite masks I guess
give me a challenge that you think Unity can do that Godot can't and I'll do it
Not going to waste your time with that, most limitations are only met once you encounter them head on, and there's hoping you never do
You know what? Sure. How about you make a 2d scene with light sources that cast shadows over obstacles, add a player and an enemy and make it so the enemy is only visible when in player's field of view (like what I did in the schoolocaust game)
Genuinely your performance concerns are not Godot's fault its you making a game for fucking web browsers, its 2024 who the fuck plays games in their browsers nigga.
Atleast be supportive and optimistic and just say that you hope it gets better someday instead of zelligly hating it
Well hey, glad the solution for my issue is "just don't do what you want to do lol". I love it when limitations of my toolset determine what I will be doing, thanks godot! I hated having agency anyways...
I actually dug up one of the articles I read at the time which helped cement my unfavorable opinion towards godot: https://sampruden.github.io/posts/godot-is-not-the-new-unity/
I'm sure people can make great games with this, no doubt, but as far as I'm concerned it's inelegant, unintuitive and subpar. The only thing it has going for it, in my opinion, is that it's light weight, and open source, neither of which are particularly relevant to me. I don't much care about being "optimistic" or "supportive", it's really nothing to me
its such an issue you can just

and then
and again, what an inelegant way of going about things
lags at 10k raycasts: "see i told you the performance was shit"
needs 100k raycasts award
Games aren't isolated raycasts, really not proving anything with a blank project doing 10k raycasts. All the little inefficiencies can add up until the game is noticeably underperforming on lower end machines (or browsers), I don't want to think about that, I want a robust solution, I don't want to settle down for a 2nd class game engine
 
Games aren't isolated raycasts, really not proving anything with a blank project doing 10k raycasts.
true but if anything this proves that raycasts are not a fucking issue like at all
I actually dug up one of the articles I read at the time which helped cement my unfavorable opinion towards godot: https://sampruden.github.io/posts/godot-is-not-the-new-unity/
if you read that then I'm sure you read linetsky's response, eitherway I'm sure that not liking something, so going to read other opinions on why other people dont like the same thing you like just so you can feel justified in hating something because a small amount of people agree with you is not normal behaviour and i encourage you and all others including me to stop doing that, especially with godot, personal experience matters a whole lot more (though inexperience can cloud your judgement) and as a dev who pretty much doesnt make web browser games, then yeah no shit i like godot, you picked a pretty hard task in my opinion.
Being notoriously shit performance wise is something you have to account for when making a game you want to run in a browser, want me to fix the entirety of all internet browsers instead? I want a versatile and reliable toolset I can be confident in regardless of what problem I need to tackle, that's why I prefer unity over godot
This kind of reasoning would be completely justifiable if you are making a browser game and support for browsers with Godot is limited. You have to use compatibility instead of Vulkan so ofcourse it's going to be slower.

1719482446202.png


But to tell people to not use the engine entirely just because it has poor support for web browsers is retarded. Most people don't play games in their web browsers and I'm pretty much objectively correct with this position, you cannot judge the entire engine just by it's inability to perform well in browsers. For that reason, you'd be better off picking an engine that performs better in Web Browsers. I won't comment too much on the state of browser gaming in general, but it should be known that browser gaming in its current state is not at it's peak, atleast not until Vulkan support or complex web assembly. Most web based game engines I've come across all use JS in some way, some flash player emulators even convert flash to javascript instructions so honestly, I am confident in my opinion that Godot is not entirely in the wrong for it's lack of support in Browsers. If Unity is better in that field, then you should use Unity.

You know what? Sure. How about you make a 2d scene with light sources that cast shadows over obstacles, add a player and an enemy and make it so the enemy is only visible when in player's field of view (like what I did in the schoolocaust game)
Except for sprite masks I guess

Godot has sprite masks.​

>filtered by godot 3 award
Yeah, I can do this. As for sprite masks, i'm pretty sure Godot has that now, if you last used it in 3.5, well, here.
This is a sprite mask, is it not?



The only thing it has going for it, in my opinion, is that it's light weight, and open source, neither of which are particularly relevant to me. I don't much care about being "optimistic" or "supportive", it's really nothing to me
You come from a pretty bad faith mindset if you ask me. But I can list a ton of reasons as to why Godot can be more preferable than something like Unity.
  • Extremely lightweight and very performative on most PCs (My games run on my moms crappy laptop at 60 fps, even in 3D)
  • Easy to develop for once you get into it (my opinion)
  • Cross Platform, supports Windows, Linux, Android and even consoles though you need a license for that stuff so you have to give your project to a third party. Which I suppose is more of a con, if you're a console gamer.
  • Completely free and open source, no company saying you cant sell your game for money or wanting a cut or some shit etc.
  • Very helpful community, free open licensed shaders, free assets for use etc
  • Intuitive and helpful user interface that frequently helps you not get lost in what you're doing, etc.
  • Pretty much can do anything Unity can do and is a great alternative to Unity if you want to make games without a shitty company fucking you up
But yeah, let me try that schoolocaust idea.
 
true but if anything this proves that raycasts are not a fucking issue like at all
And perhaps they aren't in this example, but I don't want to do benchmarks on every feature to see if it unpreforment ENOUGH to affect the final product. It's much less sweat off of my back to just chose the faster engine. Edgecases can break projects
going to read other opinions on why other people dont like the same thing you like just so you can feel justified in hating something because a small amount of people agree with you is not normal behaviour
On the contrary, I think that's how most people operate
But to tell people to not use the engine entirely just because it has poor support for web browsers is retarded. Most people don't play games in their web browsers and I'm pretty much objectively correct with this position, you cannot judge the entire engine just by it's inability to perform well in browsers. For that reason, you'd be better off picking an engine that performs better in Web Browsers. I won't comment too much on the state of browser gaming in general, but it should be known that browser gaming in its current state is not at it's peak, atleast not until Vulkan support or complex web assembly. Most web based game engines I've come across all use JS in some way, some flash player emulators even convert flash to javascript instructions so honestly, I am confident in my opinion that Godot is not entirely in the wrong for it's lack of support in Browsers. If Unity is better in that field, then you should use Unity.
I didn't even bring up the browser example to bash on godot's lack of it, but to point out how sometimes, in edge cases, you really DO need excess performance. Aside from the one browser game I made, I also think performance is paramount in order to accommodate old hardware, and I also recall something about godot not running well on older machines, something about opengl/vulkan. And you don't have to agree, but I think of slight performance inefficiencies as contingencies that may block out old machines. I don't like that so I'm autistic about performance and culling fat where ever applicable.
This is a sprite mask, is it not?
I don't much recall what was going on (this was like half a year ago) but that didn't work, I needed a sprite mask that was outside of the inheritance hierarchy (I was instantiating objects I needed to mask with those present in the scene) but yeah, that is the effect I wanted to achieve but couldn't fin da good way of doing (I also needed a sprite that would only be visible outside the mask)
You come from a pretty bad faith mindset if you ask me. But I can list a ton of reasons as to why Godot can be more preferable than something like Unity.
  • Extremely lightweight and very performative on most PCs (My games run on my moms crappy laptop at 60 fps, even in 3D)
  • Easy to develop for once you get into it (my opinion)
  • Cross Platform, supports Windows, Linux, Android and even consoles though you need a license for that stuff so you have to give your project to a third party. Which I suppose is more of a con, if you're a console gamer.
  • Completely free and open source, no company saying you cant sell your game for money or wanting a cut or some shit etc.
  • Very helpful community, free open licensed shaders, free assets for use etc
  • Intuitive and helpful user interface that frequently helps you not get lost in what you're doing, etc.
  • Pretty much can do anything Unity can do and is a great alternative to Unity if you want to make games without a shitty company fucking you up
most of these seem applicable to unity (you're also not paying any shekels to unity unless you're making bank, and even then, what are they? The taxman? I ain't telling them shit nigga, I live in Serbia)
 
You know what? Sure. How about you make a 2d scene with light sources that cast shadows over obstacles, add a player and an enemy and make it so the enemy is only visible when in player's field of view (like what I did in the schoolocaust game)
done
1719486727002.png

albeit doe not even configured properly should have used the same settings in this tutorial
but here
1719486751749.png

1719486764157.png

heres an example vid



All of this works on Compatibility renderer too btw

To conclude I think you'rre ignorant and stubborn because you used the engine when it didnt have the features you needed or you were clueless and couldn't figure it out and I genuinely think you should return to Godot to see if things have gotten better and see for yourself. Alternatively give me all of your assets and I will port "Schoolocaust" to godot in the web browser and you will see that performance is not an issue.
 
Last edited:
done
View attachment 13929
albeit doe not even configured properly should have used the same settings in this tutorial
but here
View attachment 13930
View attachment 13931
heres an example vid

View attachment 13932

All of this works on Compatibility renderer too btw

To conclude I think you'rre ignorant and stubborn because you used the engine when it didnt have the features you needed or you were clueless and couldn't figure it out and I genuinely think you should return to Godot to see if things have gotten better and see for yourself. Alternatively give me all of your assets and I will port "Schoolocaust" to godot in the web browser and you will see that performance is not an issue.
Didn't do what I asked albeit, the cone of vision doesn't get blocked by any obstacles
1719491237833.png

this is what I requested, blue being an obstacle, red being the field of view, and red ball being the thing that is getting masked out by the obstacle
In second picture (aside from the shadows looking all wrong) I shouldn't be visible at all since I'm behind the green box
Holy shit this was possible since 2022 how the fuck did you not be able to do this
I'm 99% sure I watched that exact tutorial when looking for ways to mask things but this wasn't an option in the version I was using, which was the most recent one (supposedly the engine was getting an overhaul or some shit so some things were missing), this was also before I even wanted to implement a field of vision (more like circle of vision as it is currently implemented) so this wasn't for that, I never even attempted to do that in godot as that was a tacked on idea later down the line after I went back to unity. I watched this while looking for ways to make a rectangular mask independent of the inheritance hierarchy (similar to the one you showed earlier)
To conclude I think you'rre ignorant and stubborn
fair enough
I genuinely think you should return to Godot
Not ganna happen, I hate it with a passion (and they have a gay discord)
Alternatively give me all of your assets
sorry goy, intellectual property
 
Didn't do what I asked albeit, the cone of vision doesn't get blocked by any obstacles
View attachment 13934
this is what I requested, blue being an obstacle, red being the field of view, and red ball being the thing that is getting masked out by the obstacle
In second picture (aside from the shadows looking all wrong) I shouldn't be visible at all since I'm behind the green box

I'm 99% sure I watched that exact tutorial when looking for ways to mask things but this wasn't an option in the version I was using, which was the most recent one (supposedly the engine was getting an overhaul or some shit so some things were missing), this was also before I even wanted to implement a field of vision (more like circle of vision as it is currently implemented) so this wasn't for that, I never even attempted to do that in godot as that was a tacked on idea later down the line after I went back to unity. I watched this while looking for ways to make a rectangular mask independent of the inheritance hierarchy (similar to the one you showed earlier)

fair enough

Not ganna happen, I hate it with a passion (and they have a gay discord)

sorry goy, intellectual property
Could work on light issues to show a better example later.
Can I play your game atleast?
 
Godot and Unity are both for shitskins and Unity is also for cucks.
White man builds his own engine.
 
You can! it is hosted on the zarty on it's /v/ board, thanks to it being a browser based game it's only 2 clicks away
>ongezellig
oh no no no no

I'll be honest, performance wise, it runs like shit and stutters. Do I consider that your fault? No. Unity was never the best thing for performance either, it runs okay enough I suppose. Still interesting atleast. I'll play it when I get the time, what are you supposed to do, just kill everyone?
 
Back
Top