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

51–60 of 83 posts

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

#51

Post by Cyphus »

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…

> inefficient raycasts aren't some sort of pathological edge case.

You're right that raycasts aren't an edge case in terms of usage, but Juan Linietsky's point is that the inefficient path used for this API call is a rare exception to the efficient paths used by the vast majority of the API.

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

#52

Post by pelasaco »

db48x wrote: post #19
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 doing thousands of raycasts per frame in any game, 2D or 3D, then something has gone wrong. Raycasts are very general, and there is often a more specialized way to get the same information that won’t require as much work.

I don't think how it can be wrong. I wrote a beaten-up game, 2.5D. Player(s) + Enemies + NPCs + Weapons + Bullets.. I can imagine that in some moments, we were easily doing a few hundreds of raycasts per frame.

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

#53

Post by pelasaco »

Xeamek wrote: post #25
jmull wrote: post #9

Strong response. I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters. It seems to have been that author who chose the FUD-ful title "Godot is not the new Unity". I guess there a…

Common now, the original article is perfectly reasonable one, and that includes its title as well. For the past few days everyone is talking about Unity, and I don't think it's exaggeration to say that Godot has become the de facto alternative in low to mid level game development. Godot itself will (if not already is) benefit from that status a lot. Article that brings highlights parts well Godot is lacking compared…

> Godot itself will (if not already is) benefit from that status a lot. Article that brings highlights parts well Godot is lacking compared to Unity is perfectly valid criticism to have.

And that's because the author didn't even touch the "in-app" purchase and "in-app" ads capabilites from Godot x Unity, which is the way the studios complaining about the new Unity pricing, generate their income..

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

#54

Post by rcme »

hutzlibu wrote: post #38
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…

Well, the world is destructible, so when there is a small hole (of dynamic size) in a wall, then a enemy bot should really only see the player, if there is no rubble blocking the path. Meaning tiles are waay too big for my simulation and raycasting the most straightforward way, also some enemies can evade projectiles and obstacles, but also have to scan them first. And it works already the way I want it. It could jus…

And, additionally, raycasting should just work in a good game engine. “You don’t need raycasting” is a seriously weak argument.

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

#55

Post by hutzlibu »

LarsDu88 wrote: post #46
hutzlibu wrote: post #17

Earlier quoted context omitted.

"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…

"but there are almost certainly ways to optimize this problem."

Sure, I optimize what I can. But there is only so much I can do, without hurting the core game mechanic. Which is a arcade shooter, but also a hacker game, where you program your bots. So the bots are mostly limited to radar distance information by design, to work out their position in the world and what to do next (but to make this work with many bots, I already had to cheat a lot).

And it is unreleased, in case you are wondering .. but I hope to ship an alpha, soon. So it already works and it is fun. So I won't change core functionality, but I am still optimizing wherever I can. 3 months ago, it would only run on gaming hardware. Now medium mobile phones (a big market) are within reach.

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

#56

Post by hutzlibu »

rcme wrote: post #54
hutzlibu wrote: post #38

Earlier quoted context omitted.

Well, the world is destructible, so when there is a small hole (of dynamic size) in a wall, then a enemy bot should really only see the player, if there is no rubble blocking the path. Meaning tiles are waay too big for my simulation and raycasting the most straightforward way, also some enemies can evade projectiles and obstacles, but also have to scan them first. And it works already the way I want it. It could jus…

And, additionally, raycasting should just work in a good game engine. “You don’t need raycasting” is a seriously weak argument.

Yes. I just expect raycasting to work allmost as good as possible, not on 50% to become a unnecessary blocker. But they say, they are going to fix it with some priority.

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

#57

Post by hutzlibu »

LarsDu88 wrote: post #49
hutzlibu wrote: post #35

Earlier quoted context omitted.

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…

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

It is just a different game than yours, so maybe don't judge?

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

#58

Post by GranPC »

LarsDu88 wrote: post #49
hutzlibu wrote: post #35

Earlier quoted context omitted.

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…

It's possible that they are building a game in which players can program bots that only know the state of the world by performing raycasts, as if it were a sensor of sorts. That would be a valid reason to require such an amount of raycasts per bot - although I probably would not run them every frame, but rather spread the load throughout multiple frames.

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

#59

Post by hutzlibu »

bluescrn wrote: post #45
hutzlibu wrote: post #35

Earlier quoted context omitted.

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 m…

"Can you cast a smaller set of rays first, and only cast the in-between rays if certain conditions are met "

Yes I can do this. But my case is really special as in basically the players have to do this by themself. As it is (also) a hacking game, meaning they have a limited scan budget and need to figure out to spend it the most useful for their bots.. but since they also want to evade projectiles and other bots, they want to scan as much as possible to not miss a threat.

So it works the way it is. Just would scale better, with better raycast performance.

I probably should have hinted more above, why my case is really special, but that was kind of my point, there are always special cases. And I do not want to limit my design, because of a bad raycast implementation.

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

#60

Post by hutzlibu »

GranPC wrote: post #58
LarsDu88 wrote: post #49

Earlier quoted context omitted.

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…

It's possible that they are building a game in which players can program bots that only know the state of the world by performing raycasts, as if it were a sensor of sorts. That would be a valid reason to require such an amount of raycasts per bot - although I probably would not run them every frame, but rather spread the load throughout multiple frames.

Yes exactly. But the projectiles are moving every tick, so the evading logic wants to run every tick as well. But optimizing that will be up to the player..
Post reply on HN