So, why not doing one ? After all, it is not very complex, and is a good design excercise (especially if you want to make it in order to teach something to C++ newcomers).
So let's see what are our needs
- room display - display informations about the room; the information may change, based on past user actions (for example, a monster can be killed)
- user input should be carefully handled - I don't want the user to type things that will crash the game, and I want the system to be fairly simple (the action set is fixed by room)
- the game model should not be dependant on the console to work (hey, I have preached the MVC in games paradigm for at least one year, and I would make a game that ignore it?).
- room description should be read from a file (the main question is: do I need one file or one file by room ?)
- there is some kind of RPG combat that will need some kind of RPG rules. It is not a real problem, it is just... complex :) Anyway, I prepared a complete article about developing a RPG system (actually, it was about using design principles and design patterns, the RPG system was only to make the article game-oriented; unfortunately, I never finished it [sad]) , so I know the problem rather well.
- there should be some particuler actions - jump over a pit, for example, may require a special test.
- there should be monsters, treasures, hidden treasures and secret rooms. Ah ah ah ah! And maybe a beautiful princess. Unfortunately, it can't be naked - for obvious reasons.
- no need for scripting - I'd want to keep everything simple; as a consequence, the game logic will be entirelly hard coded.
- the user shall be able to load and save his progression.
- the user may undo one operation. Ok, I understand that it is rather powerfull, but when you are killed because of a poisonous trap in the very last room, it can be... well, you know.
- last but not least I should earn at least 20.000.000 bucks with this game. Or I may distribute it for free, with the source code. I don't know...
Of course, there are a lot of other needs (I guess I'd speak about them in subsequent journal entries).
Be prepared to suffer some boring entries about software design again :)