openFrameworks is a c++ framework for creative coding (aka processing for c++)

"OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles"

Similar to Haskell, Functional Programming, but good to 'get shit done'

Accumulation of Haskell Resources

Extensive Haskell Learning Library, Tutorials, Information

Learn from experts at Google how to use Flutter to craft high-quality native interfaces on iOS and Android devices in record time.

The content of the handbook favors web technologies (HTML, CSS, DOM, and JavaScript) and those solutions that are directly built on top of these open technologies. The materials referenced and discussed in the book are either best in class or the current offering to a problem.

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.