Pretty consistently, path-finding is the most CPU intensive part of roguelikes. Whether A* for exact point-to-point traversal, or variations on Dijkstra maps for mass movement - iterating the whole play-space is typically a lot more expensive than most other gameplay elements. There's lots of ways to keep this constrained (cache paths, don't look them up each turn - only update Dijkstra maps when something is different, etc.), or hide the complexity (I've had good luck previously with making path-finding async, and having a small delay while an entity finds its way) - but it can be pretty heavy. It can also scale pretty badly as you add actors, if they are all looking for where to go (again, this is readily mitigated).

Games that do physics (think Dwarf Fortress and similar) tend to spend a lot of CPU time figuring out things like fluids, temperature and collapses also. Fluids and collapses are definitely numbers 2 and 3 on Nox Futura's CPU budget. (Fluids used to be; I offloaded it to the GPU recently).

On a few games/demos I've worked on, visibility gets up there in terms of CPU usage also. Particularly for games in which it matters exactly what an entity can see (think stealth games, or playing cat-and-mouse with an archer in a forest!), it's quite easy to end up running a lot of visible profiles. My old 7DRL TechSupportRL had this problem at first; a LOT of the game is staying out of sight of customers/managers/employees in order to avoid having them making you despair of your IT break/fix life - so a lot of entities were keeping track of what they could see. I ended up adding some code to stop distant entities from updating.

permalink embedsave reportgive goldreply

[–]GerryQX1
2 points 7 days ago 
Another option to save time on Dijkstra is to just apply it in a small local area, so monsters you can see will pathfind credibly. If you even want monsters to track you across the whole map (and really, do you?) you can find other solutions and/or hacks.