|
Boz0r posted:I've run into a problem with my rts game in Unity that seems really simple, but I can't really think of a good solution for it. I've got a worker unit and an unbuilt building. I want the worker to move to the building, but if I set the destination to the building's position he walks around it trying to get as close as possible to the position instead of just moving adjacent to it. I'm using Unit's navmesh. Should I continually find the optimal destination or something? Navigate to a location adjacent to the building.
|
#
?
Sep 10, 2019 14:21
|
|
|
|
| # ? May 25, 2024 14:14 |
|
|
if distance2building < x do imhere adjust x to taste?
|
|
#
?
Sep 10, 2019 14:28
|
|
|
Or maybe temporarily change the stopping distance of the navagent to the radius of the building?
|
|
#
?
Sep 10, 2019 16:00
|
|
|
That doesn't really work if the buildings are rectangular, though.
|
|
#
?
Sep 10, 2019 16:18
|
|
|
The problem with picking some position adjacent to building is that you may have to take some crazy detour to get there or it might not be reachable at all, whereas some other point that's farther as the crow flies might be the one that's most easily reached. I solve this like Jabor says by making the building you're moving toward count as pathable for the route generator, and when the pathing agent gets within an appropriate range, consider the destination reached Mata fucked around with this message at 16:22 on Sep 10, 2019 |
|
#
?
Sep 10, 2019 16:19
|
|
|
Mata posted:I solve this like Jabor says by making the building you're moving toward count as pathable for the route generator, and when the pathing agent gets within an appropriate range, consider the destination reached I did this, and made a helper method that calculates the distance from a circle to an axis aligned rectangle. If I want rotated buildings I'll consider just making their bounding boxes circles instead for the simplicity. I think that's what starcraft does.
|
|
#
?
Sep 10, 2019 20:53
|
|
|
Crosspost from the Making Games Megathread, because to be honest I'm not clear on what the difference is between that thread and this one. I'm working on implementing wakes for my ships, and while I'm at it I'd like to keep the ocean waves from appearing on top of the ships like this:  My best guess for how to do this is something like:
So first off, does this sound plausible? Assuming it passes that test, how would you handle a) keeping the special camera from seeing things it's not supposed to, and b) making it render things in grayscale colors where the color corresponds to what direction to push the water in? I can make a grayscale camera easily enough, but one that says "you're a ship, therefore you push water down; you're a wake particle, therefore you push water up" I don't know how to do. If I do get this working though, you can bet I'll be trying for effects like this where the shockwave from the guns firing causes the water to displace.
|
|
#
?
Sep 10, 2019 20:56
|
|
|
I dunno if this is even possible but the first thing I thought was have an invisible cylinder around the ship. Have any water in that cylinder just not render at all. Then have some special computationally expensive water attached to the ship that fills in the area. So you'll have to know where the water is, somehow. And you'll have to do a butt ton of math to make everything look right. But that's only the first thing that came to my mind when I read the problem you are trying to solve. Personally I like the look of things when they're simpler, so I don't mind low poly water flowing over a boat. Treat it like a design choice?
|
|
#
?
Sep 10, 2019 21:18
|
|
|
Boz0r posted:I did this, and made a helper method that calculates the distance from a circle to an axis aligned rectangle. If I want rotated buildings I'll consider just making their bounding boxes circles instead for the simplicity. I think that's what starcraft does. Try it and see how it feels, but I think if you want to get the feeling right when you have melee units attacking a big building, you probably want your "unit arrival" to be pretty accurate. I don't know how starcraft 2 does it, but I'm pretty sure the older blizz games had buildings on a fat old grid where they did a lot of tile checks for this type of thing. Just speculating, but a good way to do it with hitboxes might be to construct a shape that closely matches that of the building out of a bunch of simple (convex) colliders, then when you test your units against them, you can do some rough initial culling via a quadtree or something so you don't have to test thousands of guys against thousands of buildings all the time.
|
|
#
?
Sep 10, 2019 21:54
|
|
|
TooMuchAbstraction posted:Crosspost from the Making Games Megathread, because to be honest I'm not clear on what the difference is between that thread and this one. Rendering to a texture sounds like a lot of unnecessary computation. Why don't you just pass the bounding box direction and speed of the ship into the shader?
|
|
#
?
Sep 10, 2019 22:11
|
|
|
Nolgthorn posted:I dunno if this is even possible but the first thing I thought was have an invisible cylinder around the ship. Have any water in that cylinder just not render at all. Then have some special computationally expensive water attached to the ship that fills in the area. The water flowing over the ship isn't a huge deal, it's just mildly aesthetically displeasing. The lack of wakes though is IMO more significant, since it makes it feel like the ships aren't actually interacting with the ocean (which they aren't, really). Fortunately, Reharakhti linked this tutorial they wrote on how to do ripple effects, and I have basic water displacement working. Now I just need to fine-tune it and set up the appropriate particle emitters on the ships to create wakes. They also mentioned using something called a "stencil buffer" to prevent water from overflowing the ships, so that's something for me to research. KillHour posted:Rendering to a texture sounds like a lot of unnecessary computation. Why don't you just pass the bounding box direction and speed of the ship into the shader? The main reason is that then the shader has to be able to convert direction+speed of potentially many ships into a set of wake waves, which sounds like a pain in the rear end to write. Whereas with the render-to-texture approach, I can fine-tune the wake waves by adjusting a particle emitter.
|
|
#
?
Sep 10, 2019 23:19
|
|
|
With the amount of work you're doing in shaders, I almost feel like it would be worth upgrading your version of unity and using shadergraph.
|
|
#
?
Sep 10, 2019 23:36
|
|
|
It's a possibility. I'm a bit scared of upgrading and ruining everything, but I probably should; there's a fair amount of potentially useful stuff in Unity 2018 that I can't use. Very preliminary wake effect:  I need to tone down that color gradient, it's way more garish than I'd intended and doesn't really do the job I want of highlighting the peaks of the waves. Too bad GIMP's gradient editor is such trash.
|
|
#
?
Sep 11, 2019 01:39
|
|
|
You probably don't care too much about realism in your waves, but on the open ocean, waves are going to be a tiny fraction of the height of the ships. They'd barely be visible at that scale.
KillHour fucked around with this message at 01:46 on Sep 11, 2019 |
|
#
?
Sep 11, 2019 01:43
|
|
|
Yep, you're right on both counts. Like I said, this is super-preliminary, basically the result of four hours' worth of fiddling with shaders. It proves that the concept can work, now I need to fix the aesthetics. For what it's worth though, the Colorado-class battleship's upper deck is, if I'm reading this diagram correctly, about 5 meters above the ocean's surface. Smaller ships would be even closer to the water. Depending on how rough the waves are they absolutely could wash over the deck. So yeah, most of the time, the waves would be smaller, but not always.
|
|
#
?
Sep 11, 2019 01:51
|
|
|
Oh yeah, but that's in a straight up storm and I'd expect the waves to be throwing the ships around at that point. Could be a cool modifier for more difficult levels, but would definitely need to be more than a visual effect.
|
|
#
?
Sep 11, 2019 01:53
|
|
|
TooMuchAbstraction posted:For what it's worth though, the Colorado-class battleship's upper deck is, if I'm reading this diagram correctly, about 5 meters above the ocean's surface. Smaller ships would be even closer to the water. Depending on how rough the waves are they absolutely could wash over the deck. So yeah, most of the time, the waves would be smaller, but not always. IIRC, even big waves in open, rough-but-not-stormy seas are, like, 2 meters. Doc Block fucked around with this message at 05:56 on Sep 11, 2019 |
|
#
?
Sep 11, 2019 05:53
|
|
|
Just to chase this around a little more:Ruzihm posted:No and that sounds pretty rough! Yeah it is. I found some proof-of-concept that is able to save the state machine that's managing the asynchronous state under the hood. It's really hacky, and gives you a nice attack vector to try to have it reload and resume within completely different code. I also couldn't get it to work with this standalone science project I was writing. It was using its very own custom awaiter that it looks like it was using a sentinel. I just couldn't be bothered. I stumbled upon this while pondering how I might manage this with the scripting language interpreter I have. It might actually be more manageable with it. I was surprised at the notion. I could set up the API for managing scheduling with helper calls that are async with an interface that allows for "reissuing." So there's the normal mechanism to do a thing, and then there's an alternate form that will be called when reloading a save that will reissue the same command. The implication is a reissue is meant to connect to an in-flight operation versus a regular call starting from scratch. I'm dabbling with how they might play together. It's odd to me how all this crap I'm messing with gets hung up on serialization. Is this a common enough headache normally with game programming? I can hear a ghost come up behind me and tell me to only save at specific waypoints to a hard-coded structure. Wait, it's also telling me not to do this scripting poo poo. Actually, I apparently should watch it with the coroutines. Oh... yes it also wants me to just kill myself. 
|
|
#
?
Sep 11, 2019 06:56
|
|
|
There's a good reason saves in early games were "What level are you on and how many lives do you have left?" Serialization is hard. Like, I'm a big data consultant and it's literally my entire job to figure out how to best do it.
|
|
#
?
Sep 11, 2019 08:47
|
|
|
tying your state machines up in language control flow is never a good idea if you want to save/restore to precisely where you were
|
|
#
?
Sep 11, 2019 17:56
|
|
|
Any Godot users got tips on better debugging and profiling? The built-in profiler is OK but I get the feeling just function calls in GDScript are pretty expensive and I think having per-line performance info rather than just per-function would help me figure out where some of my slowdowns are. Also the debugger doesn't seem to play very nicely with GDNative - I wrote a C++ library that causes my game to crash in the Godot editor when I instantiate the NativeScript resource, but it compiles and runs OK in a standalone C++ binary. I'd like to find out what exactly is causing the crash there.
|
|
#
?
Sep 12, 2019 17:19
|
|
|
I have a question regarding your profiler question. Why would a line of code be a performance hog if that line isn't a function call? Is it a really big loop? I'm not opposed to per line diagnostics I just think it could be remedied by breaking your code up into smaller functions.
|
|
#
?
Sep 12, 2019 18:09
|
|
|
I had problems with Godot recently related to slowdowns, but mine has to do entirely with using their engine's Tweens for animating very many objects (1000% frame hogs.) Apparently inefficiently self-rewriting an unoptimized system that actually already exists in Godot, using only GDscript, was a pretty bad loving idea.
|
|
#
?
Sep 12, 2019 18:33
|
|
|
Dr. Video Games 0112 posted:I had problems with Godot recently related to slowdowns, but mine has to do entirely with using their engine's Tweens for animating very many objects (1000% frame hogs.) Apparently inefficiently self-rewriting an unoptimized system that actually already exists in Godot, using only GDscript, was a pretty bad loving idea. Imagine! ...actually, I am having a very similar issue. I was blitting tiles onto an image to update the map, but I think maybe I should use a TileMap and Sprites and a Viewport and all that jazz instead. It's probably a much better idea, I just have to take the effort to put it in place.
|
|
#
?
Sep 12, 2019 19:04
|
|
|
Nolgthorn posted:I have a question regarding your profiler question. Why would a line of code be a performance hog if that line isn't a function call? Is it a really big loop? I'm not opposed to per line diagnostics I just think it could be remedied by breaking your code up into smaller functions. Well, that's the question. When I profile individual lines with timers inside the function causing my largest slowdown I get a total execution time of maybe 20 microseconds. When I wrap the call to the function in timers I get a couple hundred microseconds. But in the profiler it's showing the function's frame time as 200 milliseconds. So I wonder where that is coming from, because presumably it's something in the engine backend rather than my explicit code. I have the feeling that maybe I have to redesign my data structure and functions to get good performance, but I don't know what performant good practice is in gdscript.
|
|
#
?
Sep 12, 2019 19:15
|
|
|
Actually writing that out I realise that the big increase is because that function is being called per vertex, so several hundred times per frame. So I guess I need to write something that operates on all verts in a single call rather than one vertex per call?
|
|
#
?
Sep 12, 2019 19:20
|
|
|
big scary monsters posted:Actually writing that out I realise that the big increase is because that function is being called per vertex, so several hundred times per frame. So I guess I need to write something that operates on all verts in a single call rather than one vertex per call? Yeah, you don't normally want call overhead whether CPU or especially to GPU on every item in a frame. If it's CPU-side you want your operation to be inline-able/vectorizable (or call a function that accepts bulk data and handles it as a group), if GPU side you want to group everything and make a single submission out of it.
|
|
#
?
Sep 12, 2019 23:32
|
|
|
I have a problem for which I finally need a robust solution (rather than "good enough" so that I could test other things): waypoint detection. I have agents that use physics forces to flock around in 3d space and avoid each other while trying to path through a set of waypoints, but I don't have a smart method for determining when my agent has reached/passed a waypoint (and my stupid methods have proven insufficient). This seems like the sort of thing that should be a solved problem, but I don't know that solution. Anyone got a hint for me?
|
|
#
?
Sep 13, 2019 18:08
|
|
|
If it’s within X distance of the target waypoint, consider the waypoint reached and target the next one?
|
|
#
?
Sep 13, 2019 22:47
|
|
|
I wasn't thrilled about constantly running distance checks, since Vector3.magnitude is not something I want to be calling (and I'd prefer to not call .sqrMagnitude either, though it'd do the job in this case), but maybe there's just no clever way around it.
|
|
#
?
Sep 14, 2019 02:46
|
|
|
Corbeau posted:I wasn't thrilled about constantly running distance checks, since Vector3.magnitude is not something I want to be calling (and I'd prefer to not call .sqrMagnitude either, though it'd do the job in this case), but maybe there's just no clever way around it.
|
|
#
?
Sep 14, 2019 03:09
|
|
|
Corbeau posted:I wasn't thrilled about constantly running distance checks, since Vector3.magnitude is not something I want to be calling (and I'd prefer to not call .sqrMagnitude either, though it'd do the job in this case), but maybe there's just no clever way around it. Don't try to micro optimise like this. Unless you have literally thousands of groups checking their distance every frame, it's not going to matter. If you don't believe me, generate 10,000 pairs of random vectors and profile how long it takes to sqrMagnutude all if them.
|
|
#
?
Sep 14, 2019 04:53
|
|
|
Oh. Well, I guess this is why I ask. I swear I got burned by this before, but maybe I'm misremembering.
|
|
#
?
Sep 14, 2019 05:54
|
|
|
sqrMagnitude is four adds and three multiplies, it's cheap as chips if you're just doing it once for each agent, especially compared to everything else you have that agent doing. The thing to watch out for is superlinear stuff, like if you were to start checking the distance between each agent and every other agent.
|
|
#
?
Sep 14, 2019 06:25
|
|
|
Don't modern CPUs have a single instruction/single cycle implementation of fast approximate inverse square root? I think GPUs do at least. Like you might as well do it squared, since it doee the same but the actual length/magnitude might not be as expensive as you think.
|
|
#
?
Sep 14, 2019 16:35
|
|
|
It's been a little over 20 years since they were added in the Pentium 3.  GPUs only have the approximations and no accurate div/sqrt hardware. Too big.
|
|
#
?
Sep 14, 2019 18:03
|
|
|
Even if it gets to be an issue you can always throw the check in a coroutine or something and just do the distance calc less often. There's lots of things that dont need the precision of per frame or even per physics update. Spread the load somewhat if it bogs things down for some reason.
|
|
#
?
Sep 14, 2019 18:06
|
|
|
Spatial posted:It's been a little over 20 years since they were added in the Pentium 3. Oh so CPUs have an accurate single cycle implementation? I knew if GPUs had anything it was the approximation because they don't really need anything more accurate.
|
|
#
?
Sep 14, 2019 18:08
|
|
|
Sedgr posted:Even if it gets to be an issue you can always throw the check in a coroutine or something and just do the distance calc less often. There's lots of things that dont need the precision of per frame or even per physics update. Spread the load somewhat if it bogs things down for some reason. Yeah, I'm already effectively doing that with collision avoidance (since it does have to check a bunch of other agents' positions). It's a bit of code that essentially makes the agents stupider and more performant the more of them are in the scene, scaling automatically whenever some agents enter more calculation-intensive states. I guess I get a little hung up on optimization. Mostly because if I don't do it up front, I never ever get around to going back and doing it later.  e: I should have at least tried the straightforward way though. Checking .sqrMagnitude isn't even making the machine blink. Corbeau fucked around with this message at 18:44 on Sep 14, 2019 |
|
#
?
Sep 14, 2019 18:38
|
|
|
|
| # ? May 25, 2024 14:14 |
|
|
Focus on making a fun game instead of an insanely optimized one. When you run into something that needs to be optimized, you'll know it.
|
|
#
?
Sep 14, 2019 18:51
|
|