Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

gist.github.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#41

Post by TylerGlaiel »

LarsDu88 wrote: post #13

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycast…

There's nothing wrong with spamming 1000s of raycasts per frame in a 2D game. They should be very cheap, so the performance impact of that should not be something you have to think about, and if some interaction or mechanic is easy to express with a boatload of raycasts, you should be able to just do that

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#42

Post by hutzlibu »

kaibee wrote: post #36
Kiro wrote: post #26

Earlier quoted context omitted.

Isn't that how you do line-of-sight/shadows, with thousands of raycasts for all pixels on screen?

Absolutely not. There's uh, a lot of tutorials on YouTube about how to go about implementing this kinda thing, depending on the kind of game (top-down 2d, vs 3d etc). Sorry don't have time to do a full write up lol.

But this approach actually also works and delivers different results in 2D space, than doing what you probably have in mind.

This approach in 3D would basically mean live raycasting rendering, which is something I would like to try in the future.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#43

Post by jayd16 »

badsectoracula wrote: post #28
jayd16 wrote: post #7

Earlier quoted context omitted.

>but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++? The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games ev…

> The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me. As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive…

This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints.

But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#44

Post by starkparker »

Kiro wrote: post #26
LarsDu88 wrote: post #13

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycast…

Isn't that how you do line-of-sight/shadows, with thousands of raycasts for all pixels on screen?

That's raytracing. You can do LOS by raycasting only at line segments and points of blocking shapes, especially in 2D, which is the original post's concern. https://ncase.me/sight-and-light/

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#45

Post by bluescrn »

hutzlibu wrote: post #35
ehutch79 wrote: post #24

Earlier quoted context omitted.

Wait. that doesn't sound like you're doing 1000s of raycasts? Just a few, maybe a dozen? also, sounds like you're using JS, not Godot?

Well, I would like to be able to do 1000s of raycast per frame (360 for each bot), but cannot and yes, I do not use godot, but my own engine (with pixijs for graphics and a emscriptem port of box2d for physics https://github.com/Birch-san/box2d-wasm .) Godot uses box2d, too, so that would be convenient, if I switch to godot, but only if it is worth the performance improvement, which it currently does not seem to be.…

The usual solution for something like this is just to spread the work over multiple frames. Most game enemy logic doesn't need running every single frame. Update 10% of your bots every frame.

Also consider whether 360 rays is really needed to begin with, one ray per degree sounds like an arbitrary first-pass value. Can you cast a smaller set of rays first, and only cast the in-between rays if certain conditions are met (e.g. the initial rays hit something close, or their hit distances vary significantly)

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#46

Post by LarsDu88 »

hutzlibu wrote: post #17
LarsDu88 wrote: post #13

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycast…

"If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information…

It's hard to tell without seeing a screenshot or video of the game in question, but there are almost certainly ways to optimize this problem.

If there are on the order of even several dozen enemies on the screen at any given time, you could simply maintain runtime sets of different factions and only do line-of-sight checks between hostile groups within a certain proximity.

There's probably hundreds of better ways to do this than by spamming raycasts. I have a VR space game with dozens of spaceships, and there are generally never more than num_spaceships raycasts getting fired every frame

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#47

Post by stephc_int13 »

I think this type of discussion can help the design team behind Godot to improve their practices and implementation, in the end it would be very healthy for the gamedev community to have a reliable and performance open-source engine as the "standard" for students, indies and AA projects alike.

Godot is better than Unity on many sides, but the internal architecture is coming from a place where they relied too much on naive and inefficient OOP constructs, those can be very hard to optimize later.

Performance should not be treated as a second class citizen when creating an engine, there are always solutions but it can be very time consuming to find workarounds to palliate design issues with the engine, it can also be a real motivation killer for a small team when they discover the framerate of their game on older/smaller devices...

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#48

Post by LarsDu88 »

QuadmasterXLII wrote: post #30
rngname22 wrote: post #23

Earlier quoted context omitted.

If the game is 2D and you can divide space into tiles/blocks and walls/obstacles have their own blocks/tiles (or you can easily establish a grid over your world and determine what cell each actor is in), I wonder if there's way to use BFS in a maze-solving manner to calculate shortest path between a given actor and the target you want to check visibility for, and if the distance in blocks/tiles returned by BFS/pseudo…

(Roughly, glossing over ‘linear in what?’) Good bfs gets close to linear, good raycasting should be way, way sublinear

"Good raycasting should be sublinear" yes, but some folks like to stick 100 raycasts on every character which will kill the performance regardless of what engine your making your game in.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#49

Post by LarsDu88 »

hutzlibu wrote: post #35
ehutch79 wrote: post #24

Earlier quoted context omitted.

Wait. that doesn't sound like you're doing 1000s of raycasts? Just a few, maybe a dozen? also, sounds like you're using JS, not Godot?

Well, I would like to be able to do 1000s of raycast per frame (360 for each bot), but cannot and yes, I do not use godot, but my own engine (with pixijs for graphics and a emscriptem port of box2d for physics https://github.com/Birch-san/box2d-wasm .) Godot uses box2d, too, so that would be convenient, if I switch to godot, but only if it is worth the performance improvement, which it currently does not seem to be.…

It's hard to evaluate this without seeing a screenshot of your game, but 360 raycasts per bot per frame for a basic 2d game is INSANE.

It sounds like you are trying to query every angle in every direction for every character. This is madness.

I have a 3d space game in Unity which uses raycasts for navigation. Each ship fires a maximum of 1 navigation raycast per frame with a sweep pattern. In addition there are anti collision thrusters placed around each ship which fire roughly every second in a staggered pattern to prevent ships from getting stuck

In my fully 3d game, that's effectively ~1 raycast per frame per enemy. To locate hostiles, each ai character scans a runtime set of potential hostiles and does a line-of-sight query roughly once every 5 seconds.

There definitely is another issue going on here with your setup that is independent of the extreme overhead in Godot.

I would recommend Sebastian Langue's excellent boids video to get a sense about other strategies to deal with these types of queries: https://www.youtube.com/watch?v=bqtqltqcQhw

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#50

Post by LarsDu88 »

TylerGlaiel wrote: post #41
LarsDu88 wrote: post #13

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycast…

There's nothing wrong with spamming 1000s of raycasts per frame in a 2D game. They should be very cheap, so the performance impact of that should not be something you have to think about, and if some interaction or mechanic is easy to express with a boatload of raycasts, you should be able to just do that

It depends on the type of game, but 360 raycasts per bot is definitely a code smell that warrants a closer look at how the game is being architected.
Post reply on HN