So the drawing code redraws the entire UI from scratch at each loop. This seems to work OK for now, when the UI consists of printing out a couple of lines to the console.
But what if we wanted a more ncurses type UI, with persistent indicators of the score, current location, etc, and some chrome around them? The impetus to do some kind of change-based incremental updating of the display would get strong, I would think. How is this generally handled in functional-reactive type UIs?
It's definitely true that you can just recalculate and redraw the entire terminal in a roguelike these days with decent performance. I've done it.
However, doing that wastes CPU cycles that you can use for other fun stuff in the game. In particular, monster AI will easily soak up any cycles you want to throw at it, and the more you can, the more interesting your enemies will be.
Yes, it can, actually. Rendering graphics is slow. AI is slow. Doing either one of them inefficiently punishes the other.
AI code can easily eat any free cycles you want to give it: you can always crank up your pathfinding distance or the number of turns your AI looks ahead.
The problem space of a roguelike is massively larger than chess and that can certainly keep a supercomputer busy.
But what if we wanted a more ncurses type UI, with persistent indicators of the score, current location, etc, and some chrome around them? The impetus to do some kind of change-based incremental updating of the display would get strong, I would think. How is this generally handled in functional-reactive type UIs?