It's a proto-mud in erlang
Erlang Ruby
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Erlang Mud

This is an experiment.  I want to learn erlang and I want to try building a mud.

Usage Concepts

Use a parameterized module to represent a player.  This enables the player to play using the erlang shell.  At least, until I get it working enough to write socket based clients to interact with the player proxy class

API from the user's stand point

> * == done
- * player starts in the lobby
- * player_proxy() = player:login(UserName, Password).
- * player_proxy:look().
- * player_proxy:move("north").
- * player_proxy:drop("my wallet").
- * player_proxy:take("my wallet").
- * player_proxy:who().
- * player_proxy:say("Are those cookies?").
- * player_proxy:shout("Looking for group!").
- * player_proxy:tell("Liv", "Can you pass the chips?").
- * player_proxy:whisper("Liv", "Can you pass the chips?").
- * player_proxy:create_room(park, "A park", "Verdant and amazing!").
- * player_proxy:create_exit(park, stable, "east", "A half open dutch door").
- * player_proxy:destroy_room(park).
- * persistent rooms
- * persistent players
- * run as an application
  - * start supervisor
  - * start registry
  - * load rooms from db

- player_proxy need to restart or handle bad commands.
- better clean up DB after tests
- start a mud-lib to load for play

- player creation story
- player_proxy:help().
- text interface for telnet
- items that have actions
- rooms that have actions
- test across multiple instances
- balancing rooms and players across instances

Design thoughts
- Items should be more robust.
  Records that can contain commands (funs).
  I'm not sure they need to be backed by a server
  But behaviors might help them deal with things like
  I can be used to fight creatues, I can be worn, etc.
- There should be a room locator
- There should be a player locator
  locators update information based on events?

Reflections on design to date...
I like the idea of a room being a unit of concurrency
I like the idea of a room coordinator
I like the idea of a player and it's connection as a unit of concurrency
I need supervisors.  To boot the rooms if nothing else.
To really kick the engine in to high gear, I'll need to have three source dirs; Driver, Lib, and Test
When contemplating how to write code to modify the server I can either have an interpreted language, or I can have all code written as behaviors and leverage erlang's hot code loading.  This will require defining rooms as a behavior.
If I want to make items a behavior, I might end up using an item as a unit of concurrency.  Depends on how behaviors work.
are there performance penalties for cascaded behaviors?
Player's shouldn't need their own behavior since they are all the same.
Monsters might need their own unit of concurrency...
I should start out with a decent telnet service...
I need to handle commands and associate them with rooms, items, and maybe classes.
I'm going to start with a non-load-balancing application.
I'm going to have the application see if the global super is there and at least handle connections then.
I'm going to have rooms round robin on connected nodes.

Questions for Former MUD wizards....
how do you handle command arguments with spaces?  Or are there none?
  pickup siver amulet || pickup "silver amulet" || pickup amulet
what are the hooks needed for a room?
what are the hooks needed for a monster?
what are the hooks for an item?
Can you tell I have no idea what I'm doing?