User:Bhaak/UnNetHack/DesignGuidelines
These are the original design guidelines (copied from the original trac wiki on SourceForge) of UnNetHack.
Around the time when I started UnNetHack, there was a trend in roguelikes (started by the "Philosphy" (pas-de-faq) section of Dungeon Crawl Stone Soup's manual) to explain upfront the game design philosophy of your roguelike game.
As I only started out at game design at that time, I didn't have a full fledged game philosophy in mind and thus only called this page "Guidelines", fully aware that it's easier to argument away bending and breaking guidelines than violating a philosophy. These guidelines were always meant to be soft but they are already vague enough to obviously not be taken as hard.
I might follow up with a blog post about my assessment on how well UnNetHack followed these guidelines. Also what unwritten guidelines the development of UnNetHack followed as for example one of the most defining features of NetHack (IMO) isn't explicitly on this list (complex interactions of items/objects/dungeon features/monsters).
This page is meant as an unchangeable archive copy as the original page has disappeared from SourceForge.
Randomness
NetHack is a game of randomness.
Every game should be different and unpredictable.
Everything that isn't random should have a valid reason for this.
Challenge
NetHack is meant to be hard.
In every stage of the game it should be challenging.
This can be achieved by closing or removing easy loopholes, by increasing dangerous situations in the game or by adding more dangerous monsters.
Fun
NetHack should be fun although it is meant to be hard.
NetHack has never taken itself too seriously and UnNetHack doesn't want to break this tradition.
misc
A spoilered player shouldn't have an advantage over an unspoiled one only because he knows of some code-specific behavior that can't be discovered in-game.
In contrast to Slash'Em not every conceivable patch should be incorporated but it should be tried to keep a good game balance.
Vanilla bugs should be fixed. The more impact on game play a bug has the sooner it should be fixed.
Items that differ by their cursed, uncursed, blessed state should have clearly different effects when used.