The ngMUCK project is a flexable MMOG (massively multiplayer online game) framework. It handles a game database, client protocols, and a script interpreter. You build the rest.

Here's how it works

Game Database

The ngMUCK software runs as a server daemon, handling all the game connections and processing, but it's doesn't do any useful work on its own. Your game exists inside ngMUCK's game database. The game database can be held in a number of different backends, such as a PostgreSQL database system, to store a hierachy of 'game objects'. A game object can be defined simply as something that can move around inside the database (reparented), and contains a set of name/value pairs called 'properties'. But these objects can be used to represent any number of game concepts, from players (Parented by a room, with health values, strength values), to rooms (Parented by an 'environment' object, with terrain values, description values), and even game script objects.

Client Protocols

Client protocols are hard coded into the game. Typically the protocol you'd want to use is telnet, allowing you to create MUD style games. But you're free to modify ngMUCK's open source code to create your own custom clients, protocls, and data-types.

Script interpreter

The script interpreter is what ties it all together. It's code is both contained within the game database, and manipulates the game database, allowing a truely dynamic environment as clients connected to the game can be capable of modifying its behaviour, and developing your custom game environment in real time. It has access to I/O functions which allow it to read in commands, and output events to connected clients.

Why is it called ngMUCK?

• Short Answer: Because the first project for the ngMUCK langage is a clone of the FuzzBall MUCK online MUD software. The 'ng' stands for 'next generation'.
• Long Answer: FuzzBall MUCK was also the inspiration for the structure of the ngMUCK game database, and in general, the inspiration for the creation of ngMUCK. It's ngMUCK's goal to be at least 90% compatable with the @arc output from FuzzBall MUCK to facilitate porting already created game structures back and forth between ngMUCK and FuzzBall MUCK. Although some code from FuzzBall MUCK may have been used in ngMUCK (They're both distributed under the GNU GPL), ngMUCK is not fully derived from FuzzBall MUCK, this makes it unline any other FuzzBall MUCK alternatives.

The current status of the ngMUCK project

ngMUCK is a work in progress, and we're always looking for developers to help out. The 'scripts as game objects' structure of ngMUCK makes delegating tasks easy, and you should be able to see rewarding results quickly. Also, if you've made yourself some custom scripts (Or even a game engine) in the ngMUCK scripting language, please feel free to donate it to the ngMUCK project. For more details on contributing, see the Documentation page.

• The build environment
• Working binaries, and command line arguments.
• The first set of custom datatypes. ('locks' and 'dbrefs')
• The database interface.
• Running as a daemon.
• The network handling code.
• The telnet client interface.
• The script engine. (lua)
• Interprating code from the game database
• Getting the script engine to respond to telnet commands.
• Cloning the general functionality of the FuzzBall MUCK software. (The ngMUCK-basicmuck project)