The Python standard library, especially the later stuff, is a good place to look. (Some of the earlier stuff is.. non-standard these days). It really doesn't matter what the problem domain of the code is, more that it is well written, well structured, documented, clear, concise, has good test coverage with tests that are non-trivial.
Don't get hung up on methodologies. OOP is just another methodology, works great some places, not so well in others. Same with Functional, or any other methodology. You can apply the same thing to Agile practices, though some are pretty much "must do's" such as unit testing and refactoring.
As a roguelike dev, you'll mostly be working on your own. That does not mean you can skimp on documentation or unit tests, to the contrary, unless you have perfect photographic memory - you're going to need those doc string comments three months from now when you try to use or modify that great nifty map generator you wrote last week. Python is exceptionally sensitive to the needs of both documentation and unit tests because it is not only a dynamic typed language but also a very open one.
Don't be afraid to use abstract classes as interfaces, or to write Mocks, or stub functions and classes. Those things are tools that help keep you focused on the task at hand which enormously helps the look and feel of your codebase. I mean, how can you write code that doesn't look like spaghetti, if you write it in a scattered fashion? Make notes, in code. // TODO: FIX THIS (and explain what this is that needs fixing)
It also helps a ton to have some sort of requirements doc. Even just a page or two that informally describes what you're trying to achieve, what you want the end product to be able to do. Refer back to it often, update it, flesh it out as you go. Make a habit of reading it at the beginning of every session.
Try not to jump on bandwagons or trends unless they prove their value to what you are doing. Even then, in moderation. I could probably write pages on the evils of pattern-first design. Frankly you don't even want to look at design-patterns until the second or third refactoring. By then you might be able to see patterns in your own code that *might* benefit from seeing how other people have solved similar patterns.
Keep things simple. Short. To the point. Above all, YAGNI - You Ain't Gonna Need It. Don't stick code in until you need it. Never write code thinking that well, I might want to do xyz someday so this will.. no.. just plain no.
I'll keep my eyes open for larger projects on the net in Python that might be worth a look and maybe post a followup later.
Hope this helps
Brian aka Omnivore
