Neohack

Neohack
Alpha Project
Developer	Ray Dillinger
Theme	fantasy
Influences	NetHack, UnNetHack, SLASH'EM, Crawl, Moria
Released	not yet
Updated	15 Oct 2012
Licensing	freeware
P. Language	C
Platforms	Linux
Interface	ncurses, Unicode, Keyboard
Game Length	12-30 hours
Official site of Neohack

Overview

Neohack is implemented in C using a Linux development platform, because I like the old-fashioned hardcore-ness of C. I'm trying to keep the code portable enough that it will compile easily elsewhere.

Neohack has what some will see as a distinctly "retro" style. Because I wanted to make a game that makes network play easy to offer, its primary interface is a plain shell window. A tile interface should be fairly easy to add because I've kept the UI separated from the rest of the game, but it won't be in the first version.

It is unapologetically hard, and it supports a large number of keystroke commands that allow your character to use things in many different ways and modify them in at least a few different ways, because I am deliberately invoking emergent complexity.

Despite deliberately invoking emergent complexity, I seek to limit the advantages of reading spoiler files. It is designed to appeal to people who think other roguelikes have gotten too tame, predictable, and simple.

Status

Neohack is not in Alpha yet; The current version as of this writing is not a full playable game. Development has been on haitus since January 2012 because, bluntly, after setting myself an unrealistic goal date or deadline, I pushed a bit too hard and got burnt out on it.

Features

As of now it's a fairly complete "engine" in the sense of a means of scheduling and executing highly general events and handling any possible interaction based on those events, handling a map and movement, adaptively handling a curses display including reconfiguring itself when the window resizes, getting user input, handling menus of choices, providing help/display of the menus, etc.

But it still needs "meta-content" (ie, implementing most game mechanics, specific event types and interactions between them, and status effects) and "content" (ie, specific items/creatures/locations described in terms of capabilities, events, and status effects).

UI

The Neohack UI, as has already been mentioned, is distinctly retro in that it's an ncurses shell interface. That said, I want it to be the game that's hard, not the interface. I'm trying to build the best console interface that I can, and I guess it's up to the players to tell me whether it works.

Discoverability

One problem with interfaces that use a large number of keystroke commands is that the user has to somehow learn and remember them. I'm trying to make discoverability easy by adding a help line. The help line moves slowly, like a ticker across the bottom of the console window, whenever the game is waiting for input. If you're ever stuck you can just watch the scroll line until the command you need comes into view - or hurry it along by using the spacebar.

Resizing

Shell games used to be limited to a particular size (usually 80x25 or something like that). But modern UNIX shells can be run at any size within the boundaries of your display. I figured there was no good reason not to take advantage of that, so if you resize the shell window, Neohack will resize its interface elements to take advantage of the new size.

Unicode

Modern UNIX shells handle Unicode characters now. So I've decided It's time for roguelike games to make the transition. Accordingly, Neohack uses Unicode characters in its interface, rather than making assumptions about what code page people have loaded.

Double Cell Tiles

Since modern monitors and shells allow huge shell windows, and most console fonts are just about twice as high as they are wide, I've decided to use two character cells to represent one map tile. This allows you to see one character for the monster and a different character for its main wielded weapon, so you could have a reasonable chance to notice when a gnome is carrying a wand of death instead of the usual shortsword.

Interface Automation

I'm providing Autoexplore and other game-automation features to make the medium-large levels manageable, as well as Autotarget, Autofire, and Autocast features to reduce most ranged attacks to a single keystroke.

Naming

Items and item types can be named, as in Nethack; individual items can be inscribed with messages. Eventually Inscriptions should work with command macros as in Angband, but that won't happen until a later version.

Game

Persistent Levels

Neohack has persistent levels, which means that there is only a finite supply of items and monsters. You can make "stashes" where you store equipment, etc, that you're not using, leave the level where you made the stash, come back, and the stash will still be there (unless it's been looted by another creature since you made it).

Continuous Time

Dungeon time in Neohack is continuous, not discrete. Moving diagonally for example takes an odd fraction 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.

Variability

Most items in Neohack are variable. Different items, even of the same type, will have different maximum ranges, different areas of effect, do different amounts of damage, have different side effects or timing characteristics, etc. Ideally, every item you find in a game will be different from every other item. This is to limit the advantage of spoiler files, and also to enhance replayability and allow occasional rare, interesting, remarkable, or memorable items to be generated.

Rarities

Certain items and monster types in Neohack are designated as Rarities, with small chances per game of appearing. If a given Rarity type exists in a particular game, it may be common, with high odds of being generated many times in that game - but will not appear at all in most games. This is to provide an incentive for replay as opposed to savescumming - a new game will have different Rarities, hopefully including several you haven't seen or played with before. But it is also to limit the value of spoiler files -- you do not start any game knowing exactly how many different types of magical ring there are, for example, so "process of elimination with spoiler assistance" shouldn't be a viable way to identify things.