Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 10/01/19 in all areas

  1. 2 points
    Hey all, big thanks for all the responses and ideas, definitely more help than I figured I would get. The weekend has passed, so it's harder for me to spend a lot of time on this, but I want to hit on some general points from the responses, in no particular order: Big point of importance here, the number of possible formation configurations is essentially unlimited. The only rule is that the leader needs one empty space around itself in each direction. Anything else goes, no limits on size and no limits on how far apart units can be. This opens the door to a lot of stupid and game-breaking possibilities when the player creates new formations, and I imagine this could be very confusing to the average player who doesn't understand the underlying mechanics of the game. I wouldn't design things this way if the final product was really intended for anyone other than me. I plan to make the game available to play, but the goal is to enjoy playing the game myself and really nothing else, so I accept the complexities that come with that choice. It's basically the essential core mechanic of the game. Everything else is fairly basic. Anyway, point being, all of the algorithms involved in formation behavior need to be extremely flexible. Using a distance field is an approach I tried, and while I did not profile to get a specific difference in time, it was noticeably more expensive than the current approach, although there could be a way to improve the speed of that, which is something I will think on. I will also profile it alongside the current when I get a chance. The advantage that the current approach has is that, in most cases, it will not do calculations on the entirety of the map, even if it still does on quite a large portion of it. Using a distance field requires running the clear_area function a number of times equal to the area of the map, which is currently 1500 and I would like to increase when/if I get this issue sorted out. A little more on this in the next point. On the point that my map looks fairly static, from which it follows that preprocessing could play an important role, this is a testing map which is not reflective of what a typical encounter will look like. Depending on how large I can get the maps while maintaining performance, I expect 10 - 25 times the number of units running around the map, and I have been working on the assumption so far that all units not in the given formation need to be treated as obstacles during pathfinding. However, your points lead me to consider the possibility that this might not be a necessary assumption, and if I in fact can treat the map as static, only considering the obstacles which do not move, without creating new behavior problems, then I can have a single distance field which updates only in the rare case that a new static obstacle is added to the map, and that would pretty much solve my issue. Will definitely be thinking about this one. Thanks to @Andor Patho for introducing me to the concept of morphological erosion. When I first set out to work on this algorithm, I wanted a concept like this but didn't know how to search for it. I'm thinking it probably isn't the solution here, since we are talking about a number of iterations equal to the area of the map (again, currently 1500) * the number of different structuring elements I need to try. I'm still considering ways I could adapt the idea though, so it could end up being something I use. When I get some time this week, I will do some proper profiling so we can all be more certain about where specifically the slowdown is happening, but I will note that I am confident that the issue isn't in the implementation of my A*, as I have done nothing but crank out slightly different versions of A* with no significant differences in the core logic/methods for the past 6 weekends that behave much better than this. Knowing that the algorithm in question considers ~1300 out of ~ 1400 possible nodes in the worst cases makes it pretty clear to me that the issue is strictly in the volume of nodes I'm considering combined with the extra calculations to calculate the c_cost. Also, I did profile the clear_area and c functions at one point, and I can't remember their specific values anymore, but they were very small. I believe the issue is running what is otherwise a very efficient calculation 1300 times in a single frame, alongside the regular A* calculations. Thanks again to everyone for the suggestions and insight! I'll be updating when I can
  2. 1 point
    Hi ! I would like to share this VIRTUAL REALITY game I am working on right now ! PriVRateer is a breathtaking space ship battle game that you can play alone or with friends ! A beta testing version is available for free (see bellow): Here is where you can download and play the game: https://discordapp.com/invite/Wt8MkJ7 Don't forget to check out my website and subscribe to my newsletter to get some really cool free sounds all along the year: www.ogsoundfx.com And also check out my Patreon page and see all the goodies you could get all the while helping me out: https://www.patreon.com/ogsoundfx
  3. 1 point
    See @Krypt0n's answer 🙂 Which is the normal (haha) way to to calculate normals from a heightmap. It does not solve the fact when something is edited/changed, that part must be renewed. But renewing e texture tile is probably more handy than part of a vertex buffer. Yes. That part i didn't get. 🙂 Thanks Write the z values to a single channel texture (check if your graphics card supports such a huge texture) and sample the texture with texture() or textirelod(). But when values change the respective part of the texture must be renewed, so it would be an idea to portion the texture in tiles of a certain size. Not everything is displayed anyway at the same time. But any change to the texture will have effect immediately. It'll look like this in the vertex shader (you probably don't need the position-to-texture ratio if that is 1:1 and the multiplier). Attention at the edges. The texture should have an overhang of 1. // Intake is displaced position vec3 computeNormalCentralDifference( vec3 pos ) { float leftHeight = texture( og_heightMap, vec2( pos.x - 1.0, pos.z ) * u_positionToTextureCoordinate).r * u_heightExaggeration; vec3 left = vec3( pos.x - 1.0, leftHeight, pos.z ); float rightHeight = texture( og_heightMap, vec2( pos.x + 1.0, pos.z ) * u_positionToTextureCoordinate ).r * u_heightExaggeration; vec3 right = vec3( pos.x + 1.0, rightHeight, pos.z ); float bottomHeight = texture( og_heightMap, vec2( pos.x, pos.z - 1.0 ) * u_positionToTextureCoordinate ).r * u_heightExaggeration; vec3 bottom = vec3( pos.x, bottomHeight, pos.z - 1.0 ); float topHeight = texture( og_heightMap, vec2( pos.x, pos.z + 1.0 ) * u_positionToTextureCoordinate ).r * u_heightExaggeration; vec3 top = vec3( pos.x, topHeight, pos.z + 1.0 ); return cross( right - left, top - bottom ); }
  4. 1 point
    Maybe this is outside of what you want to do or can do, but have you thought of writing the pathfinding bit in C or C++ to increase the speed? If you're interpreting Python, it should definitely be a speed up, but if you're compiling python, maybe there won't be as much an improvement, but it was just a thought. I know, in general C++ is much faster than python https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html
  5. 1 point
    Gaming is more than whacking human hybrids. Since this is in the programming forum - how about you start to learn programming ?
  6. 1 point
    I think at least some of this has been addressed (or at least discussed) in the thread. Regarding formations fitting through gaps, the formations can fit through even one-cell-wide gaps (see the video for an example) - it's just that that's intended to be a last resort. As for precomputing information for different formation shapes, I think the complexity there is that (as mentioned above) formations aren't limited by their shape, so you can't necessarily use (e.g.) a naive clearance algorithm. The complexity is that formations can traverse any path, but should prefer paths for which the formation isn't significantly compromised. That seems to be the particular complexity that Rammschnev is trying to address. Also, I did suggest preprocessing earlier, but in this case that's complicated by the fact that the map may have dynamic obstacles.
  7. 1 point
  8. 1 point
    Couple of ideas: If you modify your test example to force classic A* to find the indicated correct route (by closing off all passages that are smaller than required), and run simple A* on it, is it faster? By how much? If it is, the problem should be your extra "obstacle finding" addition to A*. If it's not, the problem is your implementation. If "classic" A* is much faster (e.g. order of magnitude or more): you could try running multiple A* searches with clearance, with gradually decreasing the required clearance (thus avoiding the problem of not finding any solution), or running simple A* on multiple versions of the map (which you could get by processing your map with e.g. morphological erosion or something similar that gradually narrows "paths"). You could do the multiple maps in preprocessing, although you mentioned dynamic obstacles, which would mean you would need a clever way of updating multiple versions of the map. If you go the route of multiple searches, you can even do them in parallel. you could generate a distance field on you map to have the path "gap" sizes available without searching locally at every node. If "classic" A* is not much faster, then you have to optimize your code. Try measuring with a profiler. I'm not experienced enough in python to spot a performance problem just by looking at your code, but the usual suspect in algorithms like this is using containers suboptimally - wrong type of container, copying containers when it's not necessary, etc. You can also consider rewriting the pathfinding in C/C++ and calling it from your Python code.
  9. 1 point
    The religion Simplicity is not an art to be frowned upon, for it takes courage to stand with the inexperienced and see the world with their fresh untainted eyes. Bless thee who admits having the sin of personal bias and learns common sense, for thou shall ascend into a multi-paradigm programmer. The bizarre We used to have a rule at the company against global functions. Ended up with expressions like "(x.cos()+1).sin()" instead of "sin(cos(x)+1)" because the language's core math library wasn't OOP enough. The developers making advanced algorithms could barely work anymore and it was later replaced with normal math functions again. The milking cow Workers who feel that their skills are no longer needed at the company will always find new ways to pretend that they're doing something useful. Mostly to protect the fragile ego, otherwise they would idly browse Facebook in plain sight like the others. OOP was something that allowed solving complex problems that didn't exist to begin with. One can spend years maintaining bloated frameworks or go around changing the style back and forward while causing version conflicts, adding administrative overhead and introducing defects without having to solve any real problems for the customers.
  10. -5 points
    Why would you answer "no"? That's the most trolling answer. This is my favorite song: I'm gonna listen to this violent song until people answer "yes". P.S. This song is exactly as violence as Call of Duty, Mr. Pickles, and Shrink Ray Island P.S. If you can't do it on flash, then you can do it on Unity and put it on Itch.io Let me get something straight. This is the cat and this is the mouse:
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
    Enes Gashi
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!