Archive for May, 2011|Monthly archive page
Richard Tew, aka donky@MudBytes, recently put up a mirror of the old Imaginary Realities mud zine, containing some of the collective wisdom of developers such as Raph Koster, Richard Bartle, and others; incidentally, a little over a year ago he created an mbox archive of the mud-dev mailing list, covering ten years of mud development discussion.
Mudlab sticks around, like a quietly humming tape drive, full of mud dev ideas; and of course hundreds of muds are out there, some as empty as unmanned lighthouses, but their light still flashing if you care to look for it. Rom, Merc, Mush, Cold, LP…decades of ideas expressed in code and (perhaps) source documentation, waiting to be found again.
It rather reminds me of the endless questions you see on stackoverflow and Hacker News on how to learn programming. Usually the answers revolve around which languages to learn and what books to read. But very, very rarely will anyone suggest what programs to read or what software to use (beyond learning version control or one of the canonical text editors). Would anyone tell an aspiring author they just should read Stephen King’s book on storytelling and a manual on Microsoft Word and get cracking?
In mud forums developers will discredit anything with a DIKU stamp as hopelessly antiquated — yes, old code rusts, but then again, all that glitters isn’t gold.
If you continue the analogy with the writing world you see part of the problem with reading code rather than just writing it; most writing isn’t that good, and a lot of it is terrible. But it seems like it’s a lot more work to find the good code compared to finding the good writing.
Maybe that’s because code is not just meant to be read, but to do useful work — and while it may be less elegant to hammer a trim nail with a framing hammer than a finish hammer, you still get the job done (as I can well attest).
What’s more, the better you are at hammering, the less it matters what kind of hammer you have. Indeed, there’s a bit of pride involved in making rough, crude tools do fine work, and I’d guess it’s even more fun to do it yourself, rather than throwing some expensive (in terms of effort to learn or obtain) tools at the job.
I don’t deny it’s necessary for people to reinvent old ideas, but my opinion is that the successful developers will have an acute awareness of what’s come before them. At a certain point, if you’re serious about what you’re doing, you need to dive down deep.
Have you seen a hundred people gathered in one spot? A hundred people
is a lot of people! If you, as one person, can make something a
hundred people enjoy, is that not an amazing achievement in itself?
Especially, as often in roguelikes, that the hundred people aren’t
just friends and relations pressured into “enjoying it”, but instead
random individuals with theoretically better things to do.
I would never advocate intentionally limiting your audience. You had
expressed dismay that a game had only reached 10,000 people, however.
While we can all likely agree it would be better to reach 100,000, it
isn’t necessary. And one shouldn’t feel dismay.
Turn it around – there are only so many games *you* can play in your
life. So how many people can expect to have you be a player of their
game? In some ways it would be tragic if all games hit 1 million
players, for that would mean there would only be a few thousand
games! Us humans are way too diverse to limit ourselves that way.