Some PlomRogue design decisions had to be made right at the start. I'll document them here, and the reasonings I attached to them. Looking back, some of these reasonings seem strange to me now.
My first step was deciding the user interface type: text-only, and to be controlled by keyboard input. Among roguelikes, that's a bit old-fashioned, but still common. To me, it felt like a logical choice: It would be easier to code than, say, fancy 3D graphics. It would spare computing resources for more interesting stuff: AI, or simulating societies and evolutions. There would be less bloat. I'd waste no time on drawing what the player's mind could draw better.
I also deemed such an interface very portable. It should need minimal OS and library dependencies. And text terminals and keyboards are quite universal tools, right? Input-wise, I forgot about iPads, Android systems and such. Output-wise, I thought back to VT100-like displays (i.e. 24 lines of 80 ASCII characters each). Minimally, my game ought to work in these constraints.
I have a toxic habit when dealing with IT questions: I mistrust what I have not built with my own hands. I feel the need to understand how my tools works internally. Only putting them together by myself satisfies that need. In a perfect world, my whole software stack would be my own code. In practice, I rarely start, let alone finish coding anything: To begin, I'd first have to re-write infrastructure to build on. And the infrastructure for building that infrastructure. Ad infinitum. And I avoid shortcuts through other people's libraries. My urge to build everything bottom-up on my own derails me.
For my roguelike project, I could only slightly tame this habit. Its impulse made me refuse roguelike libraries like libtcod. It made me seek low-levelness in the programming language, too. I never understood stuff like OOP anyway. Coding low-level, I'd surely waste less computing resources!
But not too low-level. The year before, I had learned a bit assembly language. Coding everything in that seemed like overkill even to me. And it would not be terribly portable, would it? C seemed the next logical choice moving up from there. This would also give me a reason to actually learn C. (I had dabbled in C before, but not very seriously.)
The saner part of my mind gave Python a moment of thought: Why not code only performance-critical bits in C? High-level languages like Python might get me ahead faster. But I had long forgotten most Python I had learned in the past. I would have to re-learn it from scratch. The need to choose between Python 2 and 3 also put me off. The notion of just doing the whole thing in C frightened me much less. So I went with C.
Terminal Control Library
Using C standard and POSIX libraries felt fine to me. Beyond that, I felt okay with only one more dependency: ncurses to handle terminal input and output. It would abstract terminals' diversity to one interface. Thus, it was excused as a means to portability. That I had some earlier experience using it also helped with the choice.
As ncursesw, ncurses allows for Unicode characters. I considered using these to have more shapes to draw with. They would be more portable than Extended ASCII code pages. Then I read the RogueBasin article on ncursesw. It described ncursesw as "surprisingly difficult to get working with C programs". The details of how to do that sounded scary. So I decided against both code pages and Unicode. ASCII's 95 printable characters were to suffice.