Live port dev vs. live/builder port dichotomy?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
Traithe



Joined: 13 May 2005
Posts: 50

PostPosted: Sun Jun 05, 2005 11:25 pm    Post subject: Live port dev vs. live/builder port dichotomy? Reply with quote

Currently setting up the foundation for our builders/content creators over on Etherea, and I'm debating the pros and cons of either setting up a system to allow all development work (sans programming, obviously) to take place on the live player port, vs. having a separate "builder port" like we do on SoI and then swapping over the changes to the live port once they're ready.

I'd be interested to hear from people who use the former model on their MUDs - experiences, what worked, what didn't, etc. Or anyone, really, with thoughts on the subject.

I'm thinking that with properly-designed builder security levels - e.g. restricting low-level builder avatars to specific non-live-linked zones only, limited resource quotas, etc. - live-port development should be not only a feasible model but a marked improvement from the sometimes discouraging isolation of a restricted builder port.

Of course, there could also be a 'privacy' flag added that would mimic the silence of said isoport in case the builder feels more productive when it's quiet - but, anyway...

Thoughts? Thanks in advance.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Molly O'Hara



Joined: 11 May 2005
Posts: 99
Location: Sweden

PostPosted: Mon Jun 06, 2005 8:51 am    Post subject: Reply with quote

I would definitely advocate the separate Building Port, for several very good reasons:

1. Trust and security issues.
While there are some colleagues that I trust completely in my own mud, and allow to build - or rather edit typos - in the Game port, I shudder at the thought of letting any newbie builder work in there. New builders generally go through a 'powertripping' phase where they create overpowered items, houses for themselves, quest designed so that only they and the close friends they tell about it can get the choice items, and other types of lame cheat attempts.

Also you need quite powerful commands when building, like stat, load, list, where... A certain amount of the new builders would abuse those imm commands to get advantages in the game. Sure, you could log them, but someone still has to check the logs. Like that rather funny message in stock Circle goes; 'You cannot trust a mort, hehe!'

And if you restrict the building capacity to already established Builders that you know and trust, you will miss out on all the potential talent in the playerbase. Because some of the newbie Builders, once they've matured beyond the initial Twink Builder stage, will make you some awesome areas...

2. Crashes and memory problems.
We have over 200 zones in our Build Port. Only about 1-2 percent of those will ever be finished. Several of them generate constant syserrs about bad doors, bad resets, bad scripts. Some of the bad scripts cause crashes. Some of them even cause the mud not to boot up properly.
Why on earth would you subject the Game Port to all this unnecessary spam if there is an alternative?

3. Distractions
To me the Buildport is a working place. There is very little channel spam, basically players go there to work on their zone and to the game port to play, chat, goof around and generally have fun. There are just too many distractions in the Game Port for anyone to concentrate on their task. Unless of course your Mud will be one of those with no global channels whatsoever. In that case it might be different.

Sure, the Build port can feel a bit lonely at times. But that is really one of its advantages too. If people like company in between their creativity spouts, they can always have an extra window open for the Game port and idle in that in between. I remember when I first start building how I used to reward myself after each finished room by going to the gameport and bash some mobs. Theyd respawn while I made the next room... Oh, the good old irresponsible days, hehe...

4. Time perspective
Building is slow and tedious work. On discussion boards I constantly see Administrators complaining about lazy or improductive Builders and asking for advice how they can motivate them to produce faster, presumably to deserve their imm level. I have even seen extremely silly suggestions, like for instance demanding a specified amount of work per week. But Builders are different, and have different methods and working habits. And a zone produced fast or under time pressure usually is a sloppily built zone.

With a Build Port you can allow them to take as much time as they need. So what if some of them take years to finish their zone? With a Build Port it doesn't matter.

---
And on a side note, I'd prefer all coding to take place in a separate Port too. New code quite frequently causes crashes or at least has bugs. Unless your coders are some superhumans that never make any mistakes f course. Ours aren't...
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Author Message
Alister



Joined: 13 May 2005
Posts: 62
Location: Alberta, Canada

PostPosted: Mon Jun 06, 2005 10:18 am    Post subject: Reply with quote

A long time ago on a mud I did admin work on, building was conducted on the live player port. However, for reasons Molly pointed out (1 and 2), we eventually switched to having a separate building port. Of course, this brought around problems of its own. The relative lack of people on the building port was discouraging for some builders, and productivity dropped off sharply for some people. In the worst cases, some builders just simply stopped building entirely. Some builders (like myself... on the odd times I build) prefer to build during the times we feel like socializing; this, of course, is very hard when the builder's port and playing port are separate.

The only real con I see to having a separate builder's port is the isolation it leaves builders with. Assuming this is the only serious problem to having a separate builder's port, maybe there's a solution that can address it, as well as the problems Molly pointed out for having builders work on the playing port:

Have communication possible across all ports. Given that we already see something like this with the IMC, this should be doable.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Mon Jun 06, 2005 10:35 am    Post subject: Reply with quote

Some mud architectures are designed specifically with secure online programming and building as a requirement; some with just secure online building as a requirement. I don't think it is something you can successfully do as a late requirement or afterthought.

The question here isn't a design question, but a design consequence question.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Mon Jun 06, 2005 1:34 pm    Post subject: Reply with quote

We do all online building on the live port. We don't have any known ways builders can cause crashes; they find new ones periodically and we fix them. We have pretty good crash recovery, so usually players only lose a minute or two of play in a crash. Builders can turn off most sources of distraction (except other immortals).

As far as the trust issues, we just deal with it - people cheat, we stop them, it's not so bad. We give them the building commands gradually: first the stuff to build and examine rooms (which gives minimal cheating capability), then when they have finished the rooms for a new area we give them the commands do the mobs (at which point they get access to our scripting language), and not until we really trust them do we let them do items - at first someone else will make items based on their requests. We log everything everybody does, and let the builders know it, so it's easy enough to catch cheating.

All of the building capability was pasted on to a stock diku which originally had no online creation. It never occurred to us to make a separate server or port for building, so we just tried to make it work on the same port. I haven't regretted it.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Molly O'Hara



Joined: 11 May 2005
Posts: 99
Location: Sweden

PostPosted: Mon Jun 06, 2005 1:49 pm    Post subject: Reply with quote

Quote:
We give them the building commands gradually: first the stuff to build and examine rooms (which gives minimal cheating capability), then when they have finished the rooms for a new area we give them the commands do the mobs (at which point they get access to our scripting language), and not until we really trust them do we let them do items


As a new builder I'd really hate to work with restricted commands, because that makes it hard to work efficiently. To make a good zone, you need to have rooms, objects mobs and scripts intertwined and interacting. As an experienced builder it is easier to handle, because by then you know what to do and usually work your way through a zone very methodically. But new builders need to experiment a bit, to see what flags and levels and addaffects really do to a mob/object. I'd rather have those experiments going on somewhere else than the game port.

And just out of curiosity: At what point do you decide that you trust someone, and on what facts do you base that decision? The really bad eggs would be cunning enough not to get caught in the initial stages, they'd save their antics for later.

But maybe that's just me getting cynical... Guess I have seen too many bad eggs over the years... Razz
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Author Message
Teelf



Joined: 12 May 2005
Posts: 21
Location: Seattle, WA

PostPosted: Mon Jun 06, 2005 3:14 pm    Post subject: Reply with quote

I am all for building via RPC that effects the 'live' port. This is the setup we used that The Seventh Sun when I worked there and it worked very well. When builders were creating a new area, it was built in the middle of nowhere until it was deemed ready and which point it would be linked in with the main MUD.

There are some issues to consider if you want to have a builders port that swaps over to the live port. If you want to allow players to have a lasting affect on thier environment (i.e. changing room properties, or even things like NPC memory) then you will run into merging issues. What if a player casts a spell that turns a room from a forest into a swamp? What then happens when you switch the builder port over? Merging things suck in general. Don't do a builder port.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Mon Jun 06, 2005 3:47 pm    Post subject: Reply with quote

Quote:
As a new builder I'd really hate to work with restricted commands, because that makes it hard to work efficiently. To make a good zone, you need to have rooms, objects mobs and scripts intertwined and interacting. As an experienced builder it is easier to handle, because by then you know what to do and usually work your way through a zone very methodically.

This is true, but they manage. The intent is that they plan it out on paper including mobs and items before they build it.

Quote:
But new builders need to experiment a bit, to see what flags and levels and addaffects really do to a mob/object. I'd rather have those experiments going on somewhere else than the game port.

I don't really see any harm in them doing this on the game port. Our online building is pretty stable - they aren't likely to crash us no matter what they do - and everything they create gets an "unapproved" tag on it until someone higher up approves it. This tag means among other things that mobs won't repop, they aren't worth any exp, I think that you can't rent with items, etc.

Quote:
And just out of curiosity: At what point do you decide that you trust someone, and on what facts do you base that decision? The really bad eggs would be cunning enough not to get caught in the initial stages, they'd save their antics for later.

I think it's just not that big a deal that someone gets caught cheating and then we get rid of them. Probably half of our content was created by people who were eventually thrown out for cheating. It doesn't mean it's bad content, much of it is very nice. We have good logs and good search tools so we can usually undo the effects of their cheating without too much effort.

To answer your original question, if someone builds a lot of stuff and doesn't cheat, (or only cheats once, gets chewed out, and then stops), then we decide we trust them. We're often wrong; but it never has done us any real harm. In fact, once in the early days of the mud someone stole our source code (as has happened several more times since then) and that's the only reason we're still running, because I got sick of the player griping and shut down the original mud for good. At that point someone else started up the stolen copy, our pbase went there, and after about seven or eight years I came back and started working on that copy.
Back to top
View user's profile Send private message Visit poster's website
Author Message
RuinsOfFeyrin



Joined: 20 May 2005
Posts: 4
Location: Chicago!

PostPosted: Mon Jun 06, 2005 10:17 pm    Post subject: Reply with quote

So it seems to me, the only advatage people find on having building on the live port instead of a builder port is the interaction with players. The advantage of having it done is that the live port is safe from errors, and crashes, and abuse bys taff in general.

So to me, the answer seems obvious. Why not implement some sort of cross server communications? This way peopel on the two ports could still talk and chat it up and be social, but the live port would maintain its stability and security.
Back to top
View user's profile Send private message Visit poster's website AIM Address
Author Message
Traithe



Joined: 13 May 2005
Posts: 50

PostPosted: Mon Jun 06, 2005 10:35 pm    Post subject: Reply with quote

Some interesting points; I suspect I should clarify the reason I ask, based on what I've read so far.

On my current project, having started with Yui's Aetas C++, we use a postgresql database to store all our data, including the worldfile. Thus, any additional port, without a great deal of retooling and a problematic swapover implementation, will draw from and modify the same data set - defeating the purpose of having a builder's port in the first place, and creating all sorts of sync issues. (Object IDs being the most problematic.)

Now, the vast majority of the issues raised against building on the live port can be resolved pretty easily, I think, since I'm basically starting from scratch on our building implementation. Staff security levels can be implemented that address troublemakers and/or incompetents, our script engine can be improved so that it poses little or no risk of crashing the game server itself in the event of a malformed script, and an implementation can be made that will allow builders working on the live port voluntary isolation in case they feel a need for peace and quiet.

I thought the point brought up about dynamic worlds and the issues of swapping stale datasets was particularly interesting, as I'd never even considered it before.

At this point it's starting to seem to me like designing a stable build environment with all the appropriate safeguards into the live port will be much less difficult than addressing the database sync issues of setting up two ports, and given the ideally dynamic nature of our game it might even be the better alternative.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Mon Jun 06, 2005 10:52 pm    Post subject: Reply with quote

RuinsOfFeyrin wrote:
So it seems to me, the only advatage people find on having building on the live port instead of a builder port is the interaction with players.


No there's the required migration, the downtime, the cost of two processes and similar memory requirements for both.

RuinsOfFeyrin wrote:
The advantage of having it done is that the live port is safe from errors, and crashes, and abuse bys taff in general.


If one's building or script code is crashing the mud, I'd sure hate to see the game code.

Ah but Kjartan has apparently added a single flag and has a somewhat different experience. Imagine if one actually added a role-based security system instead of level-based one. Imagine if one had object ownership. Imagine if one weren't running an Dikumud and didn't have a piss poor security model.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Traithe



Joined: 13 May 2005
Posts: 50

PostPosted: Mon Jun 06, 2005 10:53 pm    Post subject: Reply with quote

Tyche wrote:
Imagine if one actually added a role-based security system instead of level-based one. Imagine if one had object ownership. Imagine if one weren't running an Dikumud and didn't have a piss poor security model.


Any chance you could give a quick rundown of the models you've seen used successfully?

What I'm currently looking at is dividing all imm commands into groups, i.e. building, scripting, security, enforcement, information, movement, etc., and then allowing imms with access to management commands to grant access to individual groups (or even individual commands) on other staff members as they're needed.

I'm also thinking about using levels, but they'll only be used to determine relative privileges - e.g. when you're trying to use an enforcement command on another staff member, overwrite their world changes, etc. - likely won't have anything to do with command access itself.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kyuss



Joined: 13 May 2005
Posts: 37
Location: Southern Hellinois

PostPosted: Tue Jun 07, 2005 12:52 am    Post subject: Reply with quote

Actualy the unapproved flag was added a long time before KJ came back
to S3.

Ive debated adding the unapproved flag myself for a long time, I how ever
dont feel like taking the time to approve every room and mob. Smile
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Author Message
Sandi



Joined: 13 May 2005
Posts: 94
Location: Boston

PostPosted: Tue Jun 07, 2005 12:52 am    Post subject: Reply with quote

I agree with Molly regarding a dikubase.

But, I really like being in the game.

In other worlds, I've created tool objects containing all the commands needed to do a job. Then, a toolbox was locked and uselocked to each working player. Required tools were added to the player's toolbox through parenting. Extra commands needed could be added by me with a simple copy & paste. As the player didn't own the box, they could only use the commands written on it, not modify it in any way. Temporary commands would be issued as a separate tool object; this made them easy to purge with a timer. Note that these toolboxes worked equally well for staffers and advanced players (who sometimes can be the more useful).
Back to top
View user's profile Send private message Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Tue Jun 07, 2005 8:25 pm    Post subject: Reply with quote

Role-based security is giving access based on what tasks the user is allowed. It also interfaces with objects. Objects being task oriented and providing methods (commands) for appropriate functions of the task. A user placed in the builder group gets the object which contains the builders interface, a user given a programmers objects gets the appropriate object with programming commands, an administrator would get an appropriate object with admin commands, a player/user would also be assigned one, etc. The granularity of this can be furthered by providing more objects, or in some cases by putting users in a table that contains groups and by delegation assigning the groups the actual objects. Usually these objects are part of the parsing chain (or rather it's their absence that's preventative at that level).

Many LP mudlibs and ColdC use stack-based security, where at any point in the execution the current, caller, sender, and user objects are available for examination. Also many mudlibs add ownership attributes to objects, either allocating a single system or production id to live objects or using multiple system ids to various subsystem objects. Builders/programmers/users would have any objects they create stamped with their id as the owner.

Logic is setup in the core mudlib to check the ownership to prevent live objects from responding to messages from these unauthorized objects. Some mudlibs have publish/unpublish commands that are used to transfer ownership of objects to the id that would make them live objects. In some mudlibs the original owner id is kept for other purposes.

Additionally some mudlibs make use of access flags like create, read, write, delete, spawn that are placed on objects that determine whether they can be inherited, cloned, examined, updated, deleted, etc. Often attribute and method access is split allowing a user to examine and change attributes, but not code, or vice versa.

Security models in mudlibs are not well documented and described and the best source is typically the source code in the particular library which will give you an appreciation for the finer differences.

This is an excellent paper extending and building on the MOO security model (postscript file)

And there's this page Agora::CapabilityBasedSecurity with a handful of links.


Last edited by Tyche on Tue Jun 07, 2005 11:01 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign