Today I put up the official home page for the game Neohack.  The home page is here .  Because the text on that page will change whenever there are updates, I’m also putting the current version of the text here (at http://www.dillingers.com/blog/2014/09/17/neohack/) )as a blog post.

So…  what is Neohack?

Neohack is my contribution to the “next generation” of roguelike games.  It should be released in some form early in 2015.  This is  the first time I’ve mentioned an actual release date.

If you haven’t played roguelike games before, the basic idea is fairly simple.  You are a fantasy adventurer, and your chosen task is to penetrate deep into an underworld of chambers, passages, and caverns to find a legendary item and retrieve it.

The most straightforward way to do this is to slaughter those who guard it,  force your way into their stronghold, defeat an end boss, and take it by force. Simple, right? Well, maybe not.

Neohack is a tribute to and remembrance of the early computer roleplaying games and the people who initially developed the whole idea of playing games on computers.  Just as importantly, they developed the idea of procedurally generated games, as games that people would want to play again and again, rather than scripted games, as stories that there’s no point in experiencing more than once.  I intend to continue in that tradition, and I’m first going to use this architecture to revisit a lot of those very earliest games, in many cases re-creating their monsters, treasures, and game mechanics in subgames, branches, or minigames.

What Neohack inherits from virtually all roguelike games.

• It has randomly generated maps, treasures, and monsters. This means that it will constantly throw new stuff at you, even if you’re just playing the first level and you’ve played many first levels before.
• It has pure turn-based play. That means, when you don’t enter a command, nothing happens in the game. You can take as long to think about your next action as you need. When you take an action, time passes in the dungeon. As time passes in the dungeon, monsters get to take actions too.
• It is a single player game. Multi-player games are inconsistent with the goal of pure turn-based play, and in a game that requires a lot of thinking to play well, pure turn-based play is a necessity.
• It is strategic as well as tactical.  That means you are making decisions that affect not just the next few minutes, but the rest of the game, all the time.  A decision you make now will put you in a different situation all the way to the end of the game, and could even make the game unwinnable, although there will be no easy way to detect that the game is unwinnable.  So you have to think about each decision.
• It has permanent death. That means, when you die the game is over. Most single-player CRPGs have the ability to restore and continue after a failure, but that’s because, since they have predetermined abilities, events and plot points, it would be boring to play the first part again. In a roguelike game, the maps, monsters, and treasures are randomly generated, so every game is different and presents new chances and new challenges. Also, because most CRPGs are tactical  but not strategic the players don’t have to worry about the kind of long-term strategic mistakes that are possible in roguelike games. In a roguelike, because you’re responsible for strategic decisions, restoring after death mostly just means restoring games that are already in an unwinnable state, and therefore wasting more time before you start a game you have a chance of winning.  Character death is merely a moment of transition from one game to the next.
• It is played in the console using text for a graphical display. This isn’t terribly important to the game itself, but it means that there’s a lot of flexibility in how the game can be used and, hopefully, will help make it easy to support additional platforms. As a modernization of this idea, there is full Unicode support.

Design choices Neohack inherits from some of the better examples of Roguelike games, mostly Nethack, Adom, and Dungeon Crawl Stone Soup.

• Monsters have inventories and can use items just like the player can.
• Autoexplore and similar game-automation features to make large levels manageable.
• Autotarget, Autofire, and Autocast reduce most ranged attacks to a single keystroke.
• Items and item types can be named.
• Command-to-key mappings can be changed.
• Persistent Levels. The map and monster populations of each level are determined once. Monsters that have been killed remain killed, tunnels that have been dug remain dug, and walls that have been built remain built. None of these things will change just because you leave a level and return.
• Inventory size is limited by weight and size, not by number of different item types. Small light stuff will make it possible for you to carry more stuff, just as in real life.
• Players have a character class and a skill level with respect to that class which increases during the game, and the combination of class and level determines many of their primary abilities.

Things Neohack brings to roguelike gameplay that are new, or at least unusual:

• There is no tactical or usability advantage to the player in limiting the console to 80×24 characters, so Neohack doesn’t do that. Make the console as big as you want, or within limits as small as you want, and Neohack will adjust its display to use it. A 250 column x 80 line console is entirely readable and usable on modern displays, and Neohack will use that space if it’s available.
• Because character cells on consoles are about twice as high as they are wide, because consoles are typically more pixels wide than they are tall, and because modern displays allow a heck of a lot more character cells than ancient hardware terminals anyway, Neohack assigns two console characters to each dungeon tile. This doesn’t put the nearest out-of-sight squares any further away, because the display will still typically be more dungeon tiles wide than it is tall. It allows the game to display additional and crucial information about the creatures on the visible dungeon tiles. The second character cell is used to show what each monster is equipped with, if anything, which gives you a chance to notice potentially important information such as the fact that one of the gnomes is carrying a wand of death rather than a shortsword.
• Dungeon time in Neohack is continuous, not discrete. Moving diagonally takes a bit longer than moving orthogonally. Individual actions can have the amount of time they take modified by items like speed boots (which make walking faster but not attacking) or a swift sword (which makes attacking faster but not walking). There are few if any integer ratios of movement that you can count so a lot of cheesy tactics based on exploiting simplistic timing just won’t work.
• People often complain that roguelike command sets are too big and too hard to discover; but those huge command sets can be used to support depth of play, and I didn’t want to reduce them at the expense of reducing the depth of the game. Neohack aims to reinforce rather than dilute the strengths of the roguelike genre, and the ability to choose to use items in many different ways is a fertile source of depth, so I made a deliberate choice to support a large command set. Therefore I considered it obligatory to try to make learning the command set easy. That is why Neohack does two things: first, it scrolls a help line across the bottom of the display that shows what the commands are and says what each command does. So if you’re not sure what command you need, all you have to do is wait for it to scroll into view on the bottom line. Second, I’m trying to put a “logical” control schema on the command set, where lower-case letters and digits are for simple common commands, control letters for commands related to your character’s special abilities if any, and upper-case letters for more complicated commands where you may need to make configuration choices or select actions or items from submenus.  To the extent that this is successful, players when uncertain ought to have better chances of guessing commands correctly, or at least of knowing which guesses won’t cause a potentially disastrous immediate action.
• Neohack’s Data-Directed architecture easily and without touching main game logic allows complex interactions and multiple-use items which are not possible in most roguelike games and achievable only through extensive case-by-case patching of exceptions into main game logic in other games.  Also the code is well documented internally and comes with a “modders guide” which serves as an introduction to the code base and architecture. This affects the ability to modify, maintain, expand, and improve Neohack. From the perspective of players, this means that bugfixes, balancing changes, and new features should be routine and quickly releasable rather than rare and riddled with new bugs.
• Rarities. Certain items and monster types in Neohack are designated as Rarities, with very small chances per game of appearing. That means that even when you’ve won, or played a hundred games and know perfectly everything you’ve ever encountered, you’ll still occasionally encounter new things you haven’t seen before. In many roguelike games, there are “artifacts” – items of such great power that the game limits their appearance to preserve game balance. Rarities are a related idea, but not the same idea. Rarities may appear at any point in the game, and may or may not be particularly powerful. The appearance of Rarities is limited to add flavor and uniqueness to each game, not to limit the potential of ultra-powerful items to break game balance.

Things that interest developers and engineers:

• License: I’m using the Artistic License, which is very close to making a public domain release except that nobody other than me is allowed to release an updated version of Neohack.  If you want to make a new game using all of this code, the only thing the Artistic License requires is that you call your game something else. If you want to extract some of the code and use it for something else, or use parts of it in a different game, that’s completely fine. I make no demands, or even requests, about how you license something that contains code you get from this project; if people find it useful, that’s awesome. And if you put restrictions on your project that they don’t like, they can still get it without restrictions from me.
• Language:  C.  Just plain C.  Old-fashioned, hardcore, dangerous, type-unsafe C.  Because I like the old-fashioned, hardcore, dangerous type-unsafeness of it, for reasons that will become clear in the next paragraph.
• Coding methodology:  Mainly Data Directed, with some Object-Oriented bits.  Yes, I know C doesn’t have built-in support for DD or OO programming.  C also doesn’t get in my way when I do DD or OO programming.  Every other language I know (except Scheme, which I decided against because it would require lots of users to install a new language runtime) that supports either of these methodologies very strongly supports one in a way so hamfisted that it either makes the other difficult or forces me to do the other in a way that’s wasteful, inefficient, or stupid. In particular, so called OO languages get so pushy about making control flow depend on the type system that they make it impossible to have control flow that depends on individual values as DD requires unless you make every single value be the only member of  its own type.
• Platform: I’m using Linux development environments, and I expect Neohack to compile and work on all kinds of Linuxes and Unixes without modification. I have no Windows or Mac box to test on so I’m not going to make those binaries. That said, I’m using only the standard C libraries and the widely available ncurses library. As far as I know I’m not relying on things that happen to work on GCC and Linux when those things aren’t standard for C and POSIX.  So to the extent that I’ve been successful in avoiding platform-dependent constructions, and to the extent Microsoft and Apple faithfully implement POSIX, it should compile for those platforms without significant modification. Anyway, when I make it available I’ll be putting up a 64-bit Linux binary and source code.
• Mouse & GUI stuff: I will probably add mouse support sometime after the initial release, because a lot of people like that, even though I personally find mice pretty irrelevant as game controls. As time goes on, there’ll probably be a graphical version too, assuming Libtcod or NotEye pass muster in terms of quality, reliability, and not getting in the way. For now making one is an even lower priority than mouse support.