Documentation

Jun 6, 2013 at 11:43 PM
There is a bit of a derth of documentation on this project. I have the sourcefiles downloaded, and I am playing around with it, but some of the options are a little vague.

For example, is save frequency in ms, s, min, hours, days, months, years, decades, eons?

Also, need to be able to change the server owner instead of pulling it from the machine login to allow building on a development host if desired.

After the initial test:

Pros:
VERY easy set-up
Easy to configure
Had a server with a few rooms up and running within just a few minutes.

Cons:
Lack of basic default functionality. i.e. Help/Movement Commands/etc(No, I don't think you should burden the core with too many commands, but those are fairly standard to the genre).

Suggestions for future implementations:
Communications channels defined in the editor. Something along the lines of:
Channel Name:
Distance: Private(Same Room), Private(Any room), Public(Same Room), Public(Zone), Public Region, Public(All)
Permissions: Player/Imm/Wiz/Builder etc(Maybe prefill list from config file)


Drop down for default color selection of different room aspects. Example:
Room Name: <name> : (Dropdown): <color>
Room Desc:<message> : (Dropdown): <color>
Room Exits: (Dropdown)<color>

Ability to use MCP/MXP

Built in (but separate) web server. Part of the package but not dependent on the mud being up and running.
Coordinator
Jun 7, 2013 at 3:09 AM
Greetings,

Thanks for the comments, we appreciate your feedback!

As the engine is in Alpha, it is far from being completed. Some of the things, such as the auto-save feature, have visible properties, but have no implementation. So there are several areas of the engine that just have not been wrote yet. Looking back, it was a bad design decision to expose those properties publicly when we released it.

If you would like to change the server owner, that can be done fairly easily. You can change the following line in Engine.Networking.Server.cs (Line 81)

From this
        /// <summary>
        /// Gets the owner of the server.
        /// </summary>
        [DisplayName("Server Owner")]
        public string ServerOwner { get; private set; }
To this
        /// <summary>
        /// Gets the owner of the server.
        /// </summary>
        [DisplayName("Server Owner")]
        public string ServerOwner { get; set; }
That will allow you to change the ServerOwner property within your own custom Game class that inherits from MudDesigner.Engine.Core.Game like this
    public class MyGame : MudDesigner.Engine.Core.Game
    {
        public int MinimumPlayerAge { get; set; }

        public override bool Initialize(IServer startedServer)
        {
            Server.ServerOwner = "My Name Here";
            Name = "Mud Designer Default Game";
            Description = "This is the default game setup that comes shipped with the Mud Designer Game Engine!";
            HideRoomNames = true;
            MinimumPlayerAge = 0;
            Version = "Alpha 2.0";
            Website = "http://MudDesigner.Codeplex.com \n http://AllocateThis.com";

            World = new MudDesigner.Scripts.Default.Environment.DefaultWorld();

            bool result = base.Initialize(startedServer);

            if (!result)
                return result;

            //Let the parent Game setup the last of things.

            //Finally, since base.Initialize() initializes the World, we set ours up afterwards.
            World = new MudDesigner.Scripts.Default.Environment.DefaultWorld();

            return true;
        }
    }
As for some default commands such as movement, help and etc, they are available already within the Scripts project. If you downloaded the source, Visual Studio should automatically copy the scripts from the Scripts project into the Engine projects /bin folder. If you downloaded the binary, then the scripts are already included with the engine executable and provide movement.

I'm glad the engine is easy for you to setup, that was one of our primary design goals.

Thanks for the suggestions, the chat channels is something we have not yet started on, so we'll definitely take your suggestions into consideration while we have the ability to create it without any re-writing. The Permissions is simi-available for use already using the Engine.Mobs.CharacterRoles enum. The enum is not built into any of the Types yet, but it provides you with something you can use in the mean time (or replace if you wish) with your custom Mob, Object and Environment sub-classes.

As for the built-in web server that can be running independently from the mud, what would be the purpose of that and what or how would you use it? This isn't something we had thought of, so I'd like to hear why you would need it. Always good to get input for future improvements!

Thanks for the feedback,

Johnathon Scionwest
Coordinator
Jun 7, 2013 at 3:11 AM
I had forgot to mention our documentation, which is fairly lacking. Thanks for at least trying to read through it, I will put more effort into bringing it up to par. Documentation is not our strong suit, but I will work on it for the community.

If you feel up to you, feel free to request to join the team as an editor to help out!

Thanks,

Johnathon
Jun 7, 2013 at 4:28 AM
Johnathan,

Wow, wasn't really expecting a reply. I never know when these projects are still active or not. Thanks for getting back to me so quick. That is a BIG incentive to actually consider this tool as a primary candidate for my project. I realize that the project is in early alpha, and that there are going to be things that are simply not done yet. The point of the OP was to give you the first impressions of 'What would trip up a new user and cause them to use a different engine'. Familiarity breeds contempt, and the designer of a project is often so familiar with the ins and outs of their software that they can no longer reliably see the issues that would trip new users. On to the issues:

(Note: I realize that this is probably more information than you want or are practically ready to deal with at the moment. I just want to get it logged so that I don't forget because I am an incredibly busy and incredibly scatterbrained person most of the time. )

Movement - I found out about the 'walk <dir>' command after I had posted the original topic. I think what through me is that you broke convention in a pretty major way with that. Personally, IMHO, if you are going to add that type of functionality <walk/jog/crawl/sprint/etc> <dir>, then it should default to <dir> == walk <dir>. Just my $.02, though. In general, I am kind of against breaking basic conventions without a damn good reason to because it limits the accessibility of the Engine to new players/devs. Better to have the potential there, with it defaulting behind the scenes to something they are familiar with when possible.

Server Owner - You have the drop down in the editor, it needs to be editable from there, removed from the editor, or else displayed in such a way as to make it obvious that it should not be edited from there, perhaps with a tool tip pointing to where it can be edited. i.e. (mouse over event) "You can change this in the following line of Engine.Networking.Server.cs (Line 81)". As is, it is misleading.



Server Segregation - The segregation of the web server and mud server is actually something that bugged me about coffeeMud(A full feature rich Java based engine actively being developed. I highly suggest you check it out if you haven't already.) The problem was that if I brought down the mud, it brought down the webserver as well. So, for instance, say you are going to do planned maintenance, and you will have to bring the game offline, you would crash your website too which is likely going to be your primary conduit for information to your players. So you lose the ability to post news up like "Performing maintenance until 3pm CST" so that your players know what is going on.

There is no reason that they can not share resources, however. I think having the web server automatically grab data from the active game library is a wonderful idea, so long as the actual processes are not linked so that shutting one down requires shutting the other down. For example, your web server might grab some basic info, like help files, a list of Realms>Zones (not rooms, at least not for the public face of it), and whatever other information that might be useful to players.

Prompt - The prompt should also default to a standard, such as '>'. Not sure how much that would muck up your engine as is, but there is a valid reason for it. In general, a MU* is going to follow one of two principal concepts, roleplaying or combat, or a combination of the two in some way shape or form. In RP mode, the 'Command' actually serves to remind the user they are in a game. Strange, I know, but true none the less. In a Combat based mud, most players/devs are going to want to fill that space with things like <hp/HP mp/MP> etc. I also noticed that in your command definitions you were using 'commandSay' and the like. I do not know yet if that is tied to your prompt, or just a convention you are using. Some clarification on that would be good.

In-Game Help - Again, realizing that you are in alpha, this can be excused somewhat, but I think that needs to be tackled sooner rather than later. Nothing is more disorienting than to type help and get "Not done yet", particularly when there is a lack of out of game documentation. If you want help writing the docs, I am willing to help, but in return I will probably plague you with questions :P

MCP/MXP - I noticed this was skipped earlier, but there was a major reason for bringing this up. The use of these technologies should ideally be integrated in the beginning, not tacked on later. Of the two, MCP is less of a priorty because it will not effect the design as much, and can probably be moved to somewhere further down the development list. MXP, on the other hand, is directly related to how your engine stores and outputs data to the player, so should definitely be a major consideration in early development. Considering that it is a mud 'standard' for newer muds, uses XML(which in and of itself has huge advantages), is supported by a wide number of popular clients, and provides a developer friendly method of controlling output to the clients, IMHO no newer engine should NOT have this in it's arsenal. MXP Specification, IRE MXP Implementation

Engine Architecture - I am having a little trouble following your engine architecture here, particularly in regards to your MOB specification. I am not a programming guru, so I will try to explain as best I can. The old methodology, was to have single class with all of the attributes/behaviors for each type of mob. While ok at the time, OOP was much more convenient. With OOP, the architecture became MOB>(NPC or Player)>Class), with the classes inheriting behaviors and such. It was good, but it can be better.

Recently, I had the opportunity to work with HeroEngine for a 3D MMO project. The system they use blows the old OOP paradigm out of the water, even though it is technically still OOP. In their architecture, you use 'glomming' to define things. Glomming is a process by which an additional Class is added to a Node at run-time. This then gives that node access to, and values for, all of the Fields associated with that Class, as well as the Class methods of the new class. So, for example:

The server instantiates a MOB node, then gloms on the Player class, which only establish the critical mechanical differences between player and non-player, then, as the player makes changes, new bits and pieces are glommed on to that node so that the final result is a conglomeration of all classes glommed on to a give node. This allows for maximum re-usability of code while dramatically reducing the complexity of any given program.

The reason I bring this up is because it seems to fall in line with your stated goals for this engine. If you are wanting people to be able to make whatever kind of game they want, this will allow you to create some default templates without having to create a huge mess of code that is hard to unravel. For example:

Base node: Server
Optional Glommed Classes: Classes, Races, Levels, TickCombat, TurnCombat, Permadeath, GhostState, etc, etc, etc,

As part of your game set up, you choose the options you want, and those options are then added to the server node when the server is initialized, but they are NOT part of the actual server code. Each one is a standalone plugin style option that the end user is free to use or ignore as they choose. This will help make the builds MUCH more stable over the long run. It may not be something you are interested in, and it may be something that takes too much work to implement. I don't know where you are at really because I have not seen the code base, just the windows pre-compiled version.

Let me know if you want help with the documentation.

Regards,
Tony
Jun 7, 2013 at 7:52 AM
Additional Links - I reread my reply and realized that my description of glomming was poor, so I am adding links to the HEWIKI that describes their implementation in detail. Not saying you should follow it explicitly, but they are a AAA engine and are worthy of consideration when it comes to design choices.

Nodes and Classes
Glom a Class to a Node
Jun 7, 2013 at 1:16 PM
The screen dump I mentioned in the forums.


Developer
Jun 8, 2013 at 4:12 AM
I just wanted to let you know that Johnathon and myself have read your response and plan a follow up, but since this is touches on multiple aspects of the engine we will give you a formal [LONG] reply on this.
Jun 8, 2013 at 6:15 AM
No worries. I'm patient(and busy at the moment), so take your time. I did notice after I sent that message that 11 direction support was planned, so the only question really is about optional exits in the GUI interface.


Jun 9, 2013 at 3:34 AM
Damn, I was just getting ready to write another long piece on something, only to realize after I was about 1000 words into it that none of it might be relevant. So, before I go into any more big hoorah over anything else, let me ask this:

What is the relationship between the scripts and the editor? I.E. If I go into the scripts and change the default architecture of the Environmental scripts, how bad is that going to screw up the editor?


Jun 9, 2013 at 4:03 AM
Edited Jun 9, 2013 at 4:35 AM
Also, now that I can dig into the code more, I see you are using C#/.Net's delegates, which are essentially what glomming was all about. I will dig more into it and see what I find there.

If you are using delegates, why create default directions at all? Treat rooms as containers and just use a generic moveObject(From ID, To ID) which could be used for inventory management as well. The same could apply to Realms/Zones as well. I could think of some VERY cool functionality that could be incorporated with that:

*especially for players that like to make maps, like being able to return a nested heirarchy of location. Player is in The Realm of Ur>Zone of Ugh>Room of Arrggghhh. (Which could also be used to return the location of objects within bags, within bags.)
*Or being able to implement some pretty efficient pathfinding using something akin to Navmeshes, where each zone, and realm were 'meshes'. You could do a top down search on the first pass, to get a list of which realms/zones the player/mob was going to have to pass through, then a localized search for each zone. The nice thing being that you could distribute the searches over time so as not to bog down the server.
*Combining that with a lock/flag system so that each container is locked to particular mobs. Great if you want to allow mobs to move from room to room, zone to zone, or even wonder the realms, but don't want to micro manage it.
*It would also reduce the amount of code needed, as any object that was a container could pull from the same core group of methods. I mean, from an abstract stand point, what is the difference code wise between moving a player between two container rooms and moving an object from a player container to a backpack container?
Coordinator
Jun 9, 2013 at 4:04 AM
That's a difficult question to answer in layman's terms, so I'll give it a shot.

The editor does not rely on any Room scripts at all. Instead, it rely's on the Type IRoom (found under Engine.Environment.IRoom.cs). When you change the Room script within the editor settings, the engine will always create Rooms using your script. The editor simply asks the Engine to provide it a copy of the Room currently being used via the script engine. All of the rooms created do not have to inherit from BaseRoom (as the scripts do), but they MUST implement the IRoom interface. The following line of code is used in the Room editor to get the currently used Room script from the engine.
IRoom room = (IRoom)ScriptFactory.GetScript(EngineSettings.Default.RoomScript, null);
As you can see, the editor just interprets your scripts as the internal interface IRoom. The internal engine room code (and due to inheritance, the external example scripts), have a contract with the IRoom interface. Because they have a contract with IRoom, they are required to implement all of it's properties and methods. So in short, as long as your custom class inherits from BaseRoom or any of the scripts, you will not break anything because the editor will see it as IRoom. If you want to go and re-write everything, you can do so, provide you satisfy the contract requirements with IRoom. I know the documentation is lacking, but this isn't something that would really be documented extensively, as this is a C# language feature and not really an engine feature. This allows for the editor to operator with Rooms, regardless of what kind. We did this so that you could have hundreds of custom Room classes, for different reasons, and use them through-out your game. The default Room is used for the editor, but in the future we were planning on allowing you to set the room script on a Room basis and not just a global setting.

Just make sure you inherit from BaseRoom like such
using MudDesigner.Engine.Environment;

namespace MudDesigner.Scripts.Default.Environment
{
    class DefaultRoom : BaseRoom
    {
        public DefaultRoom() : base()
        {
            
        }
        public DefaultRoom(string name, IZone zone) : base(name, zone)
        {
        }
    }
}
In order to see what methods are supported, take a look at BaseRoom. You should avoid editing BaseRoom, as that's the point with the scripts. Allow you to change the behavior without editing engine code, which would make updating the engine on your server harder in the future for you. Again, overriding methods are not a Mud Designer feature but a C# language feature, so documentation on this is not going to be extensive either when we actually get the documentation done on it. In the event you don't know how to override a method, you can look at Engine.Environments.IRoom and find the method you want to implement in your custom class. So for example, if you need to override the AddItem method, you would do so like this in your custom class.
        public override void AddItem(Engine.Objects.IItem item)
        {
            base.AddItem(item);
        }
The "Base.AddItem(item);" line lets your script call the internal engine AddItem method and perform what ever the engine wants to do, then all of your code follows afterwards. If you don't want the engine to do it's default actions, then just delete that line and continue with your own stuff. The full script file would look like this.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

using MudDesigner.Engine.Environment;

namespace MudDesigner.Scripts.Default.Environment
{
    class DefaultRoom : BaseRoom
    {
        public DefaultRoom() : base()
        {
            
        }
        public DefaultRoom(string name, IZone zone) : base(name, zone)
        {
        }

        public override void AddItem(Engine.Objects.IItem item)
        {
            base.AddItem(item);
        }
    }
}
So just to reiterate, you can change the way the Environmental scripts (Scripts/Environment folder, not Engine/Environment in the source) behave however you want. The engine will simply pass your modifications off to the editor. The editor will continue to work as intended. You can add custom properties and those properties will be editable (to an extent) within the editor as well.

Hope that helps.
Coordinator
Jun 9, 2013 at 4:09 AM
RAVaught wrote:
Also, now that I can dig into the code more, I see you are using C#/.Net's delegates, which are essentially what glomming was all about. I will dig more into it and see what I find there.
From what I understood of glooming, we are essentially doing that but with the built-in language features of .NET and Interfaces. You can create a class that implements Factions, Races, Genders etc by attaching interfaces to your class. We have not broken it down to a minute level, but we are essentially doing the same thing with interfaces.
Coordinator
Jun 9, 2013 at 4:12 AM
Edited Jun 9, 2013 at 4:13 AM
Scionwest wrote:
RAVaught wrote:
Also, now that I can dig into the code more, I see you are using C#/.Net's delegates, which are essentially what glomming was all about. I will dig more into it and see what I find there.
From what I understood of glooming, we are essentially doing that but with the built-in language features of .NET and Interfaces. You can create a class that implements Factions, Races, Genders etc by attaching interfaces to your class. We have not broken it down to a minute level, but we are essentially doing the same thing with interfaces.
The only difference between glooming and interfaces is that glooming attaches functioning code to the object for use during runtime. This is not something we are not really looking at doing at the moment, as the engine is being developed for heavy script usage without an IDE if needed. Doing a lot of runtime attaching and detaching of objects to other objects would make debugging errors extremely difficult without access to the source or setting up visual studio to monitor and track the objects during runtime. That's what I observed from my 10,000' overview of the way the feature worked anyway.
Coordinator
Jun 9, 2013 at 4:27 AM
Edited Jun 9, 2013 at 4:28 AM
Ok, let's try to dissect this :)

RAVaught wrote:
Movement - I found out about the 'walk <dir>' command after I had posted the original topic. I think what through me is that you broke convention in a pretty major way with that. Personally, IMHO, if you are going to add that type of functionality <walk/jog/crawl/sprint/etc> <dir>, then it should default to <dir> == walk <dir>. Just my $.02, though. In general, I am kind of against breaking basic conventions without a damn good reason to because it limits the accessibility of the Engine to new players/devs. Better to have the potential there, with it defaulting behind the scenes to something they are familiar with when possible.
I don't understand what you mean by convention? Are you referring to typing "walk west" instead of simply "west"? If that is the case, we used the walk command to test setting up a command script system that could support arguments. Since items and other things that would use arguments are a little further down the development roadmap, I choose to go this route with movement so I can prepare the engine to support commands with arguments. You can very easily write your own custom command script to use "west" or "east" if you choose. The engine is designed to support custom commands wrote using scripts. Check out the Scripts/Default/Commands/WalkCommand.cs script for an example. Again, we might change the default behavior in the future, but this was simply a choice made to help test sending multiple words into the command engine during development.

If you are referring to the fact that the command script is not hard-coded internally, we choose to move 99% of all commands externally into scripts to help Mud Developers who just download the binary, learn how to code their own scripts using ours as examples.

RAVaught wrote:
Server Owner - You have the drop down in the editor, it needs to be editable from there, removed from the editor, or else displayed in such a way as to make it obvious that it should not be edited from there, perhaps with a tool tip pointing to where it can be edited. i.e. (mouse over event) "You can change this in the following line of Engine.Networking.Server.cs (Line 81)". As is, it is misleading.
Yeah I see what you mean. The server properties was a back burner item for us while we worked on getting the editor and engine working properly and tried to get a release pushed out. Changing the server owner from being read-only is a simple fix and I will probably try and push a new update out here shortly with that corrected.

RAVaught wrote:
Server Segregation - The segregation of the web server and mud server is actually something that bugged me about coffeeMud(A full feature rich Java based engine actively being developed. I highly suggest you check it out if you haven't already.) The problem was that if I brought down the mud, it brought down the webserver as well. So, for instance, say you are going to do planned maintenance, and you will have to bring the game offline, you would crash your website too which is likely going to be your primary conduit for information to your players. So you lose the ability to post news up like "Performing maintenance until 3pm CST" so that your players know what is going on.
There is no reason that they can not share resources, however. I think having the web server automatically grab data from the active game library is a wonderful idea, so long as the actual processes are not linked so that shutting one down requires shutting the other down. For example, your web server might grab some basic info, like help files, a list of Realms>Zones (not rooms, at least not for the public face of it), and whatever other information that might be useful to players.
This is on our development roadmap. darxval and I had planned on doing it this way from the beginning, the web server side of it just hasn't been worked on yet.

RAVaught wrote:
Prompt - The prompt should also default to a standard, such as '>'. Not sure how much that would muck up your engine as is, but there is a valid reason for it. In general, a MU* is going to follow one of two principal concepts, roleplaying or combat, or a combination of the two in some way shape or form. In RP mode, the 'Command' actually serves to remind the user they are in a game. Strange, I know, but true none the less. In a Combat based mud, most players/devs are going to want to fill that space with things like <hp/HP mp/MP> etc. I also noticed that in your command definitions you were using 'commandSay' and the like. I do not know yet if that is tied to your prompt, or just a convention you are using. Some clarification on that would be good.
This has been noted, thanks.

RAVaught wrote:
In-Game Help - Again, realizing that you are in alpha, this can be excused somewhat, but I think that needs to be tackled sooner rather than later. Nothing is more disorienting than to type help and get "Not done yet", particularly when there is a lack of out of game documentation. If you want help writing the docs, I am willing to help, but in return I will probably plague you with questions :P
This hasn't been worked on yet because we have not ironed out a concrete path for us to take on this. We are working on a manor that will make this very extensible, allowing custom scripts to easily add help "modules" or what-have-you to their classes, without needing to add dozens of lines of code to their script. Our answer to a solid help system is still baking at the moment.

RAVaught wrote:
MCP/MXP - I noticed this was skipped earlier, but there was a major reason for bringing this up. The use of these technologies should ideally be integrated in the beginning, not tacked on later. Of the two, MCP is less of a priorty because it will not effect the design as much, and can probably be moved to somewhere further down the development list. MXP, on the other hand, is directly related to how your engine stores and outputs data to the player, so should definitely be a major consideration in early development. Considering that it is a mud 'standard' for newer muds, uses XML(which in and of itself has huge advantages), is supported by a wide number of popular clients, and provides a developer friendly method of controlling output to the clients, IMHO no newer engine should NOT have this in it's arsenal. MXP Specification, IRE MXP Implementation
I've never heard of MCP/MXP, so we will take a look at this.

Hope this answers your questions, feel free to comment away :)

Johnathon
Jun 9, 2013 at 5:18 AM
With the Walk command, you pretty much nailed it down. I would just need to remove the command and implement some default movement commands, or create some aliases for the cardinal directions i.e. North, N = walk north. However, even that could be improved upon some. I will think about it some more.

Server Owner Drop Down/ Webserver /Prompt- check. Wasn't so much worried about it being implemented right away as much as looking ahead and avoiding any unnecessary rewrites :P

Help - XML.. easy to write, easy to parse, completely customizable, very easy to port to a dbase whenever your engine gets to that point as well.

Thanks, that does answer a lot of my questions. Maybe for practice I will see if I can hack together a good walking script for 11 directions plus custom exits.

Tony
Jun 9, 2013 at 5:21 AM
Oh, also is it worth looking into making room creation commands available from the prompt in-game instead of through the editor, or would that be something that would be better left till later?
Jun 9, 2013 at 5:55 AM
Observer Pattern - Glom Equivalent
Coordinator
Jun 9, 2013 at 6:43 AM
RAVaught wrote:
Oh, also is it worth looking into making room creation commands available from the prompt in-game instead of through the editor, or would that be something that would be better left till later?
It's something that can easily be implemented with Scripts and was at one point in the 1.x alpha releases. Did you know that you can edit the game, rooms included from the editor while the server runs and you are connected? This lets you edit the game in real-time and see the results instantly. World creation commands is something we would like to re-add, they're just very time consuming to put together.
Jun 9, 2013 at 7:28 AM
Yup, I know it can be done in the editor while the server is live, but here is the kick. If you are designing a Mud, one of the most important tools is to be able to visualize what is going on in your world when there is none of the normal text present yet. I could draw it out on paper, but that is practically useless when testing for broken/incorrect links. I use mappers(such as the auto-mapper in Zmud) when I am building so that I can kind of layout my world space(using the drag-able exit lengths and scale-aable room sizes). Unless you implement a mapping feature that is similar(hopefully better) than Cmuds, it is really more convenient to do it all from the command line because I don't have to keep switching back and forth.

Back when I tested out CoffeeMud, I played around with it's web-based mapper and was not terribly impressed. It was better than nothing, but it really gave you no sense of scale or positioning for designing your room connections, which had a tendency to make new builders create more rooms/links than were necessary for a build.

Again, a lot of the things I am asking about will fall into the realm of design tools and functionality. I don't expect most of them to be implemented yet.