NAME

Acme::MUDLike - Hang out inside of your application

SYNOPSIS

use Acme::MUDLike; 
my $server = Acme::MUDLike->new;

# ... your code here

$server->loop;  # or call the Event or AnyEvent event loop

Connect to the URL provided and cut and paste into the text box:

/eval package sword; our @ISA = qw/Acme::MUDLike::object/; sub new { my $pack = shift; $pack->SUPER::new(name=>"sword", @_); }
/clone sword
/i
/call sword name
wee, fun!  oh, hai everyone!
/eval no strict "refs"; join '', map "$_\n", keys %{"main::"};
/call Acme::MUDLike::player=HASH(0x8985e10) name

DESCRIPTION

Multi user chat, general purpose object tracer, eval, and give/drop/take/clone/dest/look.

Adds a social element to software development and develop it from within. Chat within the application, eval code inside of it (sort of like a simple Read-Eval-Parse Loop). Call methods in objects from the command line. Create instances of objects, give them to people, drop them on the floor.

The idea is take the simple command line interface and extend it with more commands, and to create tools and helper objects that inspect and modify the running program from within.

It fires up a Continuity/HTTP::Daemon based Web server on port 2000 and prints out a login URL on the command line. Paste the URL into your browser. Chat with other users logged into the app. Messages beginning with a slash, /, are interpreted as commands:

/look

See who else and what else is in the room.

/mark

/mark 1

/mark torch

/mark foo::bar

/mark 0x812ea54

Select an object as the logical current object by name, package name, number (as a position in your inventory list, which is useful for when you've cloned an object that does not define an id or name function), or by memory address (as in Foo::Bar=HASH(0x812ea54)).

/call

Call a function in an object; eg, if you're holding a toaster, you can write:

/call toaster add_bread 1

The special name "current" refers to the current object, as marked with mark.

/eval

Executes Perl. $self is your own player object. $self->inventory is an Acme::MUDLike::inventory object with delete, insert, named, apply, and contents methods. $self->environment is also an Acme::MUDLike::inventory object holding you and other players and objects in the room. The environment and players in it all have tell_object methods that takes a string to add to their message buffer. Calling tell_object in the environment sends the message to all players. Objects define various other methods.

/who

List of who is logged in. Currently the same /look.

/inventory

Or /i or /inv. Lists the items you are carrying.

/clone

Creates an instance of an object given a package name. Eg:

/clone sword

/take

Pick up an item from the floor (the room) and place it in your inventory. Or alternatively /take item from player to take something from someone.

/drop

Drop an item on the floor.

/give

Eg:

/give sword to scrottie

Transfers an object to another player.

/dest

Destroys an object instance.

new()

Each running program may only have one Acme::MUDLike instance running. It would be dumb to have two coexisting parallel universes tucked away inside the same program. Hell, if anything, it would be nice to do some peer discovery, RPC, object serialization, etc, and share objects between multiple running programs.

continuity

Optional. Pass in an existing Continuity instance. Must have been created with the parameter path_session => 1.

port

Optional. Defaults to 2000. This and other parameters, such as those documented in Continuity, are passed through to Continuity->new().

password

Optional. Password to use. Everyone gets the same password, and anyone with the password can log in with any name. Otherwise one is pseudo-randomly generated and printed to stdout.

HISTORY

0.01

Original version; created by h2xs 1.23 with options

-A -C -X -b 5.8.0 -c -n Acme::MUDLike

TODO

(Major items... additional in the source.)

Test. Very, very green right now.

Telnet in as well as HTTP.

JavaScript vi/Acme::SubstituteSubs integration.

Multiple rooms. Right now, there's just one.

The JavaScript based vi and file browser I've been using with Acme::SubstituteSubs isn't in any of my modules yet so development from within isn't really practical using just these modules. There's some glue missing.

SEE ALSO

Continuity

Continuity::Monitor

Acme::State

Acme::SubstituteSubs

Acme::State preserves state across runs and Acme::SubstituteSubs. These three modules work on their own but are complimentary to each other. Using Acme::SubstituteSubs, the program can be modified in-place without being restarted, so you don't have to log back in again after each change batch of changes to the code. Code changes take effect immediately. Acme::State persists variable values when the program is finally stopped and restarted. Acme::State will also optionally serialize code references to disc, so you can eval subs into existance and let it save them to disc for you and then later use B::Deparse to retrieve a version of the source.

The Todo comments near the top of the source.

AUTHOR

Scott Walters, <scott@slowass.net>

COPYRIGHT AND LICENSE

Copyright (C) 2009 by Scott Walters

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.9 or, at your option, any later version of Perl 5 you may have available. By using this software, you signify that you like llamas.

Includes code by John Resig:

jQuery 1.1.2 - New Wave Javascript

Copyright (c) 2007 John Resig (jquery.com) 
Dual licensed under the MIT (MIT-LICENSE.txt)
and GPL (GPL-LICENSE.txt) licenses.

$Date: 2007-02-28 12:03:00 -0500 (Wed, 28 Feb 2007) $
$Rev: 1465 $

Includes code by Awwaiid (Brock Wilcox)

cpanm Acme::MUDLike

perl -MCPAN -e shell
install Acme::MUDLike