• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • 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. Are you sure the body parts are actually synchronized? That wouldn't be surprising if they weren't synchronized
  5. 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. Also seems likely you AR accessing your arrays out of bounds with current frame too
  7. How big is your leftrect array? <= 8 looks suspicious
  8. 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. You could also use type_info as the map key and void your own key management.
  11. 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. 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;     .... }