++ed by:

1 non-PAUSE user.

Scott Walters


Acme::MUDLike - Hang out inside of your application


    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
    /call sword name
    wee, fun!  oh, hai everyone!
    /eval no strict "refs"; join '', map "$_\n", keys %{"main::"};
    /call Acme::MUDLike::player=HASH(0x8985e10) name


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:


See who else and what else is in the room.

  /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 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.


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.


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


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


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

  /clone sword

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 an item on the floor.



  /give sword to scrottie

Transfers an object to another player.


Destroys an object instance.


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.


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


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


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.



Original version; created by h2xs 1.23 with options

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


(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.



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.


Scott Walters, <scott@slowass.net>


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)

6 POD Errors

The following errors were encountered while parsing the POD:

Around line 758:

'=item' outside of any '=over'

Around line 777:

You forgot a '=back' before '=head1'

Around line 793:

'=item' outside of any '=over'

Around line 805:

You forgot a '=back' before '=head1'

Around line 807:

'=item' outside of any '=over'

Around line 827:

You forgot a '=back' before '=head1'