Steadtler

Members
  • Content count

    1819
  • Joined

  • Last visited

Community Reputation

220 Neutral

About Steadtler

  • Rank
    Contributor
  1. Trouble with Recast/Detour

    Then you're down to good old debugging Make a simple map with only a flat square surface. Then step in the method and see while it fails.
  2. Trouble with Recast/Detour

    Do you have debug display to show the resulting mesh ? Tools are important.
  3. CoH's solution seems nice. If you dont need the information to be so dense, you can use a quadtree instead of a dense grid. That would reduce the memory, and the cost of pathfinding, line-of-sight checks, etc. Im not sure why your string pulling is so expensive, it should be very cheap to do on a grid, as all you need to do is intersecting a vector with axis-aligned lines. If you are sure your maths are optimal, then there is also the fact that you dont need to smooth the whole path at once. You really only need to smooth up to the next "corner", its useless to smooth a whole path that is likely to change.
  4. Efficient Line of Sight Algorithm

    You seem to be in 2d. If you just build a simplified representation of your space (navmesh, or since you seem to be grid-based a quadtree) should make your line of sight checks negligible. There is no reason you shouldnt be able to do hundreds of those every frame. Also, looking at your original code up there, it seems you're working in polar coordinates (angle/distance). Believe my experience when I say its evil. Work with vector algrebra.
  5. Always shrink your navmesh for agent size. We have tested this problem at work and we found that generating several navmeshes - as JT suggest - is far more efficient (less memory AND less cpu cost) than generating one navmesh that supports several agent radii.
  6. Navigation Graph Generation

    Of course you realize that a voxel generation is the 3d generalization of the binary image representation in your article The steps are actually quite similar. From talks to other people in the industry, almost everyone has made the shift to voxel-based generation in the last few years, and Mikko sure has a big responsability in that. I can confirm you that it works with massive levels with high-precision, as long as you're being smart about it.
  7. My Sid Meiers Civilization 5 Review

    Honestly CIV 5 is more of the same: Its a superp 4x game with an AI that can't play it at all. From CIV 4 the game got better and the AI got worse. So even if you play the game really well there is no challenge because the AI will try to attack your tanks with spearmen even though they could build tanks of their own. I beat the game on every difficulty level and I never had a fair fight past the middle ages. Its like the AI doesnt know it can upgrade its units. Its a shame because I love the design. I must admit I was surprised at how slow the gfx engine is. I play on my work computer, which is a *beast*, and I had to lower the gfx settings. I think the great variety of textures must be whats killing it.
  8. Growing plants in games - examples you liked?

    Its not what you want but you need to try farming in Dwarf Fortress hehehe
  9. How do you create a simulation program?

    Quote:Original post by Waaayoff And once i do get the input, it's just a matter of solving some equations right? Its not about solving the equations. Its about finding the right equations to solve...
  10. Simple first person shooter AI

    Quote:Original post by Antar3s Ok, thanks a lot. I'm trying with A* and it seems a very good solution for my case. Actually, I have to debug some code, but it should work well. Now I'm thinking about the test to decide when a bot sees the player. I prepared a boolean function, but I don't know how to define it. What should I test? I could take the distance between player and bot positions, but there could be a wall on the way, even when they are close enough to fight each other. Is there a common way to solve this problem? Thanks again. Yes, the common way is a line-of-sight test, which is usually done by doing a "raycast" in your physic engine. Basically you cast a line from the AI's eyes position to one or several of the player's bodyparts, and check if it intersects anything. Its a costly test cpu-wise, so you dont want to do it every-frame for all of your bots. An cheap, alternate solution in the case of a 2d game is to check if you can trace a straight line from the bot to the player on the navmesh...
  11. Seattle Area?

    I lived close enough to Seattle for a while (Vancouver) and I had a good impression of it. The city has a nice vibe to it (downtown anyway) and I love the west-coast fresh air. Plus its Shadowrun's main setting! I didnt like the techno-suburb (Redmond & co) tho... looks so artificial. And traffic did look like a pain. While I think of it, if you like the north-west, you might want to consider Vancouver.
  12. See kids, this is where GA/DP/ANN leads: semantics arguments over ill-defined methods that gives poor results and takes so much time and hacks and tweaks just to make it work that you could have coded a straightforward solution a hundred times over instead.
  13. crossover just mean you look for values in the neigborhood of two samples - and gradient descent/hill climbing was never limited to only running one at a time. Im not saying hill climbing is good, Im just saying GAs are not any better. It runs pretty much the same and attempt to patch the same flaws with doubtful hacks. noppanit, sorry about the crossfire here. Im suggesting you study the basis - including operational research and numerical algorithms - until you see why its a bad idea. Besides the argument above about whether its anything better than a hill climbing, there are other reasons not to use it in game AI - notably the difficulty (some would say impossibility) of debugging and tuning the behavior of the AI when its all based on a regression.
  14. Quote:Original post by alvaro Quote:Original post by Steadtler Quote:Original post by Alvaro where computing the partial derivatives of the fitness function is impossible and where the only thing you can even try to measure is the relative fitness of a setting of the parameters with respect to another setting of the parameters Doesnt that sound like a finite difference? :) Actually, no. Imagine you are trying to optimize the strength of a poker bot. The only measure of strength you have is matching one bot against another for a number of hands and seeing who makes money off of whom. I don't see what a finite difference have to do with anything. Because of the mutation step in GAs, the other bot will most likely be a neighbor in the search space. I say most likely because GA are very loosely defined and thus can end up being just about anything. In its most basic form, a GA takes a point, find points in the neighborhood ("mutation"), then compare those points and keep the best(s) according to some test ("fitness"/"selection"). Like I said, a sugar-coated gradient descent. The more they deviate from this formula and the more they look (and perform!) like a random search.
  15. Quote:Original post by InnocuousFox Notice he said "genetic programming" rather than "genetic algorithm". One modifies data, the other modifies the code itself. Yes, because doing a gradient descent over the space of all possible code makes much more sense that over the data space :) But yeah, I shouldnt have written GA, but my comment stands. Quote:Original post by Alvaro where computing the partial derivatives of the fitness function is impossible and where the only thing you can even try to measure is the relative fitness of a setting of the parameters with respect to another setting of the parameters Doesnt that sound like a finite difference? :)