What is a MUOOP?

MUOOP (which I pronounce moo-p, a bit like what a cow does with a p on the end) stands for Multi-User Object Oriented Programming.  A MUOOP is a telnet based programming environment, where multiple users can log on, and build things, run programs, and generally have fun. It's a cross between a Multi-User Dungeon (MUD), a talker, and a text-based programming environment.

What is BFlat?

BFlat is the working name of my MUOOP.  It started out being called BC mud, after a inter-family joke. When I expanded on the idea, I was going to call it BC+, after the way the C language was named, but then decided on BFlat as in not C#.  If I am referring to my particular MUOOP, I will call it BFlat, otherwise I will use MUOOP in general. I may, however, get confused between the two, so please bear with me.

How does it work?

Well, you start off with a SQL back end. This stores the objects, properties, methods and events that make up the MUOOP environment.  There is also a super-sub table, which represents the hierarchical connections between different objects, but I'll deal with that later.

Then you have a VB engine, which has three parts. The first part is a database manager, this handles all the connections to the SQL, and in later versions will deal with caching of data, etc.  The second part deals with the telnet connections to the MUOOP, ensures that input from each connection is handled in a reasonable time, and the third part, which is a scripting engine. The scripting engine is what makes this a programming envionment. This engine is planned to allow people to write methods and event handlers to attach to objects, which run code modules written in VBA (Visual Basic script), JScript, or possibly even Perl. Currently only VBA is supported, but I am on the first part of the design cycle (Make it work).  Later versions (make it work right, make it work fast) will probably extend to JScript and/or Perl, allowing different users to program in their own preferred script.

Finally you have the MUOOP itself. This is what the users log on to.  It is currently assumed to contain the base object (known at present as BFlat), which has five child objects: code, location, exit, thing, character.  Character has two child objects,  NPC and PC. From this, almost anything can be built. You want to create a house, fine. For each room in your house, build a child object of location, name it, add it's description. Create exits to lead from one room to another. Now your character can wander through the house, looking at the descriptions. To create things in the house, such as tables, chairs, televisions, etc, create child objects of type 'thing' and put them where you want them in the house.

Perhaps you want to create a radio which will 'sing' lyrics from songs to you. Create a child 'thing', give it some properties such as song lyrics. Add an event handler to deal with the 'turn on', 'turn off', and 'change channel' events. Create a script which will send the lyrics as a text stream to the room the radio is in when it receives a particular event. Congratulations, you now have a working radio your character can listen to.

So, that is the basic idea behind a MUOOP. However, as a system it is much more flexible than that. Because any 'thing' can have custom methods and event handlers attached to it, and each of these is dependent on user written 'code', you can build a fantasy area, a science part, a teaching environment. Whatever you can conceive of, can probably be built using this system. And because more than one person can be coding on it, then you can collaborate with people from all over the world to create an environment as rich and varied as human imagination and ingenuity allows.

How about hacking?

As with all computer environments, some people will try and exploit weaknesses inherent in the system to cause trouble.  At present we are trying to implement a signature system, whereby each piece of code, object, property, method, etc, is 'signed' by the person who created it. Then each time someone tries to use it, their signature is checked against who has permissions on that object/code, etc.  Objects which are added in by the creator of the system, commonly called god, are useable everywhere.   Objects which are put in by the admin team, are useable almost everywhere. (Only god can create a member of the admin team, for example.) Objects which are created by users of the system are useable only in areas created by that user, and have a temporary effect on other characters.  This means that any one person can only 'hack' in a limited area.

Hopefully, this will ensure that 'hacking' of the system is limited, and won't cause significant harm to the system, or other user's code.  Of course, I expect it to take some time to settle in, and I would suggest you check back in two or three years after the system has gone live to see the changes which have been implemented by then.

How can I enter the MUOOP?

Well, currently there is no MUOOP up and running, as it is still in alpha design phase.  As soon as I have a stable system up and running, with miniumum objects incorporated, I will add telnet instructions here to let you log on and see what it is like.  Until then, you can only imagine what it looks like.

Can I create my own MUOOP?

Yes. Once I have the code finished, I will be releasing it under the GNU public license.  The most up-to-date files will be accessible from here, and development files from SourceForge. The only thing I ask is that you let me know where your MUOOPs are accessible from, any problems you encounter with the program and especially any significant alterations you make to the VB engine.

I understand that you may be concerned with telling me about your MUOOP, for example you want to only allow certain people access to it, and are worried I will publish information about it, or log on myself. I don't hope that this will be a useful product which will be used in a wide variety of places for a lot of different purposes. I'm not planning on visiting them all. With what I usually do, I doubt I'll even have time to visit many of them anyway. I just want to keep track of who is using my work, and for what sort of purpose. If you are opening a public MUOOP however, then there is a posibility that I might drop in and see how yours is being used.

Where are the documentation/help files stored?

Currently, the documentation is being put together, and is not accessible to the public. I may release a number of different documentation packages, to cover different scenarios. For example:

• The quick start guide, for people who want to get a MUOOP up and running as quickly as possible, and don't want to read any more than they have to.
• The hosting guide, for people who are running a MUOOP and need to know how to create new objects, environments, commands etc. This is where to go if you've done the quick start guide, and now want to learn a bit more about dealing with your new toy.
• The player guide, for people who just want to explore the environment without creating their own code. This may, itself, come in two flavours:
• Basic commands. These are the commands which are essential to the running of the MUOOP, for example look, movement, help.  They are, for the most part, going to be universal across all MUOOPs, with at most only local variation.
• Extended commands. These are the commands which are unique to my MUOOP. Examples may include commands to interact with specific objects in my MUOOP, which may not be included in other MUOOPs.  This will be equivalent to BFlat's online help system.
• The player scripting guide, for people who want to write scripts in the MUOOP environment and need to know how to access objects/properties/methods etc. This may  be dependent on the language you choose to script in, so there may be different versions of this.
• The VB documentation, for people who want to tinker. This will be as complete a documentation as I can manage on the VB engine. It will, hopefully, document each procedure in the code, and allow programmers to follow what I have written, and expand on it where they want.

All/any of these that have actually reached the release phase will be available both from here and from SourceForge, under the GNU Documentation license.  

How can I help the MUOOP project?

I am not, at present, asking for any assistance. I hope to get the VB engine up and running soon. Once the system is up and running I will be asking for builders, admin, players, suggestions, etc.  So please check back to find out what is going on.

Is there a mailing list I can join?

I'm hoping to set up a mailing list via SourceForge, to allow people to keep up with what's happening with MUOOP. When I have done, I'll let you know how to join it.

I anticipate setting up a number of lists and/or web fora (the plural of forum, for those who can't speak latin) when the system goes live, to include bug reports, wish lists, tech queries, etc.  Check back when the system goes live (as shown in the SourceForge list) to join/read them.