Sometimes Foresight is 20/20, Too

I keep trying to come up with really great, really kick-ass ideas for programs that I can sit down and knock out. I want to find that itch that I can conceivably scratch.
I obviously haven't had any.
Every now and then, someone I know will come to me with a "wouldn't it be great if..." idea that they've got, but there's two problems with them. OK, one problem. They're invariably not that great because if they were, I'd have jumped all over it because it felt like that great of an idea and I wouldn't be typing to an empty audience, I'd be dictating this in front of a sold-out crowd at Madison Square Garden because I paid for them to watch me sit here and dictate this tripe to my butler's butler after having built whatever that great idea was.
The second, obviously subjugate, problem there is that I haven't had any great software ideas (of my own or lent to me) that got my juices flowing. I haven't had much more than ideas for the sake of ideas.
Until one fateful day a few weeks ago. I'd gotten back from work and was out on a bike ride to clear my head and stretch my legs out. It was a nice enough late afternoon and climbing the hill, I started to think back to all the silly little programs I wrote when I was a young lad dabbling in BASIC and PASCAL. Terrible "RPG"s and the sort. Cut-rate Ultima Is, minus, well. Everything that would make them playable.
It suddenly became obvious - why don't I write a roguelike in .Net? Since then, I've been kicking around the idea and it's only gotten bigger and, well, dumber. As Google will tell you, the very idea of a roguelike in .Net is a dumb one to begin with. I haven't even started so I couldn't tell you why.
Compounding the shaky base I'd apparently be starting with, some truly awful thoughts have gone through my head.

"Hey, I could write a flexible MVC implementation so that it could be presented by either a web interface or a BBS door!"

Yes, another filthy childish love of mine is olde tyme BBSes and door games. I've tried to come up with a good idea for a door game to produce, but no dice there either.

"Hmm. Since it's online, I could make it multiplayer. I remember reading some design documents for Multihack; how will I handle surreal time? If there's two people on the same dungeon at the same time, how do I handle the dungeon-moves-when-you-say-so aspect of it? Can I fix this?"

Multihack was the multiplayer version of Nethack that never quite saw the light of day. If you've never played a roguelike, the game world doesn't advance until you make your move. You can take a second or a week to make that next move. This presents obvious problems when more than one person inhabits the same level and Player A wants to move NOW while Player B wants to take 10 or 20 minutes to decide whether to read a cursed scroll of levitation or enscribe Elbereth or whatever. Oh yeah, I went there.

"How do I persist the levels? Hmm. Oh, I know - this feels like a pretty relational data model that I'm working with. I'll just install SQL Server."

At that point, a bigger, louder voice in my head screamed "SQL Server for a fucking roguelike? What the shit are you thinking?" Thankfully, foresight finally reared its beautiful head.
If I may, a few words in my defense.
Day in, day out, I write database-backed web applications. I take detours to write "thick" WinForms apps here and there and then multithread them based off of need rather than just because I can (honest) so I've got a really solid comfort level when it comes to, well, ASP.Net up front, C# codebehinds and middleware and SQL Server backing it all.
That said, I recognize that it's more than OK to step out of your comfort zone from time to time. It wasn't comfortable when I took a step back and started to see that what I was trying to pass off as object-oriented code was, being generous, marginally better procedural code with some trappings of objects tacked on as an afterthought. I'd gotten comfortable writing that way as a student and hadn't progressed much since (and coworkers who'd been there before me and had more experience were writing the same).
At a certain point that felt logical to me, I stopped with the parameteritis and the basically stateless objects and started writing object-oriented code they way that I thought it should be written, trying to take care to think about what it was doing and how it would be used now (rather than building things in because you never know), but I think that I'm a better programmer and my software's better and easier to maintain because of it.
It wasn't comfortable when I got started and it was slow going at first, but I'm happy with where I've ended up.
Now that I find myself at the top of a mountain again, do I try to convince myself that I've climbed to the peak of the world or do I take a look around and see that there are other mountains that I should climb?
My class diagrams (which look every bit like a socially inept teenager scribbled them down) for my roguelike can sit in a pile on my desk for a while. A database for a roguelike feels so impossibly wrong that I can appreciate the fact that it's time for me to stretch a bit and tighten up my laces because I've got some climbing to do.