• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1148 Excellent

About DrEvil

  • Rank
  1. Empty nodes in the tree are to be expected, don't subdivide the structure for empty nodes and it shouldn't be an issue.   If your levels are that predictable though you might be using a more complicated structure than you actually need though.
  2. A grid is a tried and true very simple method. Whatever sized your world is, split it into evenly spaced grid cells and then based on where the viewer is in the world, it's super trivial to calculate the min and max bounding extents of the grid to isolate the small subset of objects that are relevant to where the camera is looking.
  3. I would just give the projectiles a random fake height when spawned and the cover objects and whatever else a value for their max height and allow them to go through when they exceed that. It's simple and it will work consistently for all objects in the scene. The height variation can always be in the 0-player height range. 
  4. quake md3-help with animation.cfg

    Are you sure the body parts are actually synchronized? That wouldn't be surprising if they weren't synchronized
  5. Crashes When Character Walks

    What's the value of gPlayer.CurrentFrame when it crashes? Go over the values of all your variables in the debugger when it bombs and you should get a hint.
  6. Crashes When Character Walks

    Also seems likely you AR accessing your arrays out of bounds with current frame too
  7. Crashes When Character Walks

    How big is your leftrect array? <= 8 looks suspicious
  8. A* on large Map

    Something is wrong with your algorithm. 1 second for a 32*32 grid suggests a broken algorithm. You should be comfortably inside 1 second in. A 100*100 or larger easily. Are you profiling in release mode? How are you handling your open/closed lists? Memory allocation?
  9. I work with huge terrains and navigation meshes. We can't even build the entire navmesh due to memory constraints(it uses the popular voxellization techniques), so we built the navmesh in tiles. In order to facilitate long distance pathfinding, which would be extremely slow for long paths, I use the resolution of these tiles as part of the hierarchial pathfinding, which I recommend you do here as well. it's much simpler with tile maps.   The idea is just to group your navigation into larger tiles, and then build a higher level graph on this information. You can do it with a higher level grid or create tile groupings.   http://www.gamasutra.com/view/feature/3000/gdc_2002_polygon_soup_for_the_.php     Depending on the size and complexity of the map, this can simplify the pathfinding hugely. Pathfinding could boil down to a simple search inside the region you are in, and once the search hits the high level sector border, it can skip entirely over all sectors in between, using the cached connectivity of the high level graph. Once it reaches the destination sector, it can fall back down to the tile grid for the rest of the path. Once you have that path through, which includes a mix of high and low level paths, the high level edges would need to be filled in for each tile, but this can be done incrementally as you follow the path. I ended up not doing incremental updates though, because it caused problems such as not having enough path context into the future in order to do my string pulling properly, so I ended up building out the whole path by the time I returned it, but the multi-level pathing is still a huge performance improvement, and filling in those high level sectors is basically a flood fill from the starting polygon/tile until it reaches the next expected high level tile.
  10. Component design question

    You could also use type_info as the map key and void your own key management.
  11. Component design question

    There's no reason to use naming to get components. You have all you need just by the template parameter.   Rather than looping through the components looking for a name match, you can do a dynamic_cast instead, or some other sort of manual rtti, like a ComponentType::GetComponentType() which returns a unique identifier per component type to compare against and you could then static cast. 
  12. Pathfinding with virtual fields

    First thing is to render the vector directions at each node. Whether those look correct or not will narrow down where the problem is.
  13. From the perspective of a client/server I would consider restricting the details of the spell effects to the server side only, and only propagate data necessary for visualization  to the clients. This would allow you to create effects and spells and such that don't need to be communicated to the clients, potentially even while the game is still running. The clients just need to download the visual aspects of the effects such as animations, textures, particle systems, hud icons, and many of those can be shared or mixed and matched between skills. The client need not even have any knowledge of the spell system in general. Maybe the client has only the capability to communicate targeting information to the server and activate spells by an id value, and the server kicks communicates streams of visualization instructions at entity positions to relevant players around those locations in a generic way that has no dependency on the spell system.   Alternately, is your question more about how to structure the definition of a spell effect?
  14. As long as the tile maps aren't huge, if it's dynamic allocation you want to avoid I would allocate a pool of 2d pathnode arrays of the same size as the tile map. Then the only potentially dynamic aspects of the pathfinding is the open list.   The overhead of the nodes is certainly in additional memory, but you gain much more than you lose by being able to thread out the searches, or incrementally update multiple searches at the same time.
  15. The navigator subclass, such as the NavigatorNavmesh, is indeed tied to the navigation mesh. It's an implementation of my interface where it is tied closely to how the navigation mesh stores data. The Navigator is my path finder and my path smoother. This object serves several purposes for me. It represents the state of navigation for a particular entity. The navigators could be updated from multiple threads, modifying their internal search state and referencing the navigation mesh in a read only manner, they could be updated serially in a time spliced sort of manner(allowing many paths to be in progress simultaneously), and it shields the rest of the code from the choice of navigation system I'm using, allowing me to change it easier at a later point. Also, since it maintains its own internal state which may involve functionality closely related to the navigation system, it can handle the dynamic aspects of path following was well, such as string pulling, often implemented in a way that requires regular maintenance of the path which can be encapsulated in the navigator.   You don't have to do it this way. You can just create a function on your map class or something if you want to start simple that solves a path and gives you back an immediate result in the form of filling in a result object or a list of path nodes, etc.   Status TileMap::FindPath( PathResult & resultOut, const vec2 & src, const vec2 & dst, ... );   Path nodes hold the state of the navigation query at a particular state, the code, the parent pointer for reconstructing the path when the goal is found, etc. This is temporary scratch data and doesn't belong in the same objects as your Tiles, which presumably hold a reference to the image used for that tile, whether the tile is solid or not. I think about the tile map in a 2d game as an image, and the tiles as the pixels of the image, the color channels as the data about those tiles. I would not bloat that data with pathfinding search state. Other than bloat, if the tile map, of which there is presumably only 1 copy of, contains the search state, you can only solve for 1 query at a time.   I would suggest, even if you keep it as a simple function call for an immediate path solution and nothing fancy like a navigator, that you keep the search state separate from the tiles.   something like struct PathNode {     int x,y; // coordinate of node in tile map     // search state     PathNode * mParent;     float g, f;     .... }
  • Advertisement