The Guide to a Successful Playerworld

[Projectshifter]

Anymore it seems like the dev worlds are becoming more and more of a joke, and out of the hundreds of planned playerworlds, the list of playerworlds with a chance of even making it to the hosted tab is virtually non-existant. The problem isn't with the lack of enthusiasm, skill or even time for the most part, it's about a lack of management and organization. So I have decided to write this brief little guide to help those thinking about investing their time (and money) into making a playerworld.


1. The Planning
The single most important part of getting a playerworld up is to start it off right. It's like a house, if you mess up the foundation, it's hard to have a nice finished project. The best way to plan out your playworld is basically to write an outline. Basically you want to start out with a rough concept (I., II.,...) and be general and get out all of the concepts. Everything from an idea of how the overworld should be to plot to player interaction and NPCs to basic gameplay. It's important to start off with rough concepts and then get pretty extensive on how things should be.

It's okay and probably a good idea to leave certain things a little vague. For example NPCs. At this stage you don't really need to know if houses are going to be scripted or built out of tiles, or if movement will be default or rescripted. You want to give your staff members a chance to express creativity and make things that are interesting and unique, but at the same time give certain guides to ensure that everything fits together and doesn't look hack-and-slash. It's good to get input and not just have one person sit down and plan out the entire server. The ideas of one person might make a server that is appealing to a lot of people, but diversity is never a bad thing.


2. The Overworld/Map
A common problem with "upcoming" playerworlds these days is the matter of the overworld. Hiring someone who has "already built an overworld" is not a good idea. I repeat, if you're a playerworld manager and you do this, please open up your C: drive (because I'm sure you must use Windows), and delete all the files you can find. Make a game out of it.

But seriously, the overworld is important, but more important than just hiring a few LATs and having them go to town is drawing out a basic map and plotting out areas for towns, quests, and other areas. A big downfall of many playerworlds is that the levels are disorganized and random. A lot of times the level generator is used and there is a huge overworld with little or no ideas behind it, and things are just kind of filled in after the fact. Depending on the theme and concepts behind the playerworld it, an overworld should fit the concept and tie in with much of the game.

Having all of the towns, and if possible much of the houses (and their purpose) on the "map" is useful and help keeps things organized. It is perfectly acceptable to have several overworlds. Take Graal Kingdoms for example. There are several different islands and areas, but they're not all on one large map. This not only keeps lag down a bit but also keeps things a bit more organized and allows each island to have their own theme seperate from the other main islands. No one likes to have too much open space, but at the same time having everything tight and compact is a bad idea.


3. Items and the Economy
If you think about any Graal server that has ever been in existence, most of the game revolves around making money or trying to get certain or better items. With this in mind, it's important to put a lot of thought into this portion in particular. Making items that have both advantages and disadvantages is something you should definately consider. GK doesn't have one sword that is more powerful than all of the others. There is certainly a hierarchy of what is better than certain others, but you can improve your weapons and some do fire damage, while others do ice damage or poison, giving the game a good bit of diversity.

When it comes to designing this part of your server it doesn't help to have a scripter handy. Having a mudlib-like system (or basically a system that reads items from text files that are easily created rather than hard-coded in as a weapon) allows for more variation and makes it much easier to create items. Doing this also means that non-coders are able to help out with the development of items which also leaves coders more free-time to devote to other areas. It isn't necessary to have every single item/weapon planned out, but there should be a general idea of what types of items you are intending on using, and does not hurt to have at least a few examples in place. One thing I would like to stress, you do NOT need to have guns. In fact, a good way to lose the interest of a coder is to ask them to make guns, it might be the most annoying request ever. Make something unique, creativity is key to getting and keeping players.

I don't have many suggestions for the economy, that's where you're going to have to come up with some ideas. There are a lot of different economies that have been thrown around on different servers, choose wisely, and choose something that works in with the rest of the game. UN once setup a job for making coffee, yet it really had nothing to do with any part of the game and was perhaps the most random thing they could have done. If it doesn't fit into the rest of the gameplay, the players aren't going to be keen on doing it. The game shouldn't necessarily revolve around working but it should be something that doesn't boil down to purely button mashing and is going to lose the interest of the players in the long run.


4. Staff Selection and Management
If you've actually followed the other steps, you basically have a "map" of what your playerworld is going to be. If you look in the real-world at jobs, a boss hands down what is needed to be accomplished. Very rarely will you be handed a project and told to just get it done with no limitations or guidelines in place. Having your server's outline is going to ensure that the staff have a concept of what needs to be done, how it needs to be done, and an idea of what the end result should look like. Giving staff the ability to use their discretion is a good thing, but each developmental department should have a manager or administrator (a supervisor) to oversee and make sure that nothign strays too far from the plan as to not become disconjoined from the rest of the playerworld.

Try-outs are not a bad thing, and probably should be encouraged. Rarely is hiring your friends a good practice. Often times you'll probably find that the people who tell you that they're the best and you're stupid if you don't hire them, are full of themselves and have no idea what they're talking about. Be wary of those individuals who just like having RC to play around and really don't have any developmental skills. Hiring FAQs/ETs/GPs etc is completely pointless (perhaps ever), but definately during the dev stages.

Giving out rights is a big deal. Only give out what rights are absolutely needed. Someone who is designing levels does not need access to the NPC Server, but at the same time someone who is designing levels may not need access to all of the levels. Do not hire the supervisors/admins first. It's good practice to wait a week or two before deciding who is capable of being a good leader over a section, otherwise you'll end up having an incompetent person in charge of parts and you'll find out that it does a lot of harm in the long run.

Setting deadlines is not a bad thing to do, but be realistic. Developing a playerworld takes time, but it is also true that staff that are unmotivated are most likely not going to work. Positive reinforcement sounds like something from Kindergarten, but saying thanks and letting your staff know that you do appreciate their work (remember, they're most likely volunteers and really don't owe you anything) can work wonders.


6. Everything Else
Hopefully by having it all planned out you can get things going on different sections simultaneously. Having at least one town, even if it's purely built for the purpose of testing things, can really help out the scripters. Realize the limits of your scripters, and every now and then it isn't a bad idea to ask a GST member or an experienced scripter to come by and check over some things and make sure that it's headed in the right direction. I've checked far too many servers that started off their NC on the wrong foot and the end result was a disaster. It's better to scrap everything and start over from scratch in the beginning than have to go through and redo everything when you're in the farther stages of development.

After some key gameplay elements are setup, you should try and get a few people to come through and test out some ideas and get some reactions to see what some of the players think. No one wants to hear that their work isn't any good, but it's much better to hear it from a few players during testing stages than from the playerworld inspectors.



I think that about brings this to a close. I'm hoping that maybe a few people who are serious about developing a playerworld will read through this and hopefully be able to benefit from it. Having an organized playerworld will help not only a server keep track of progress and have an idea where things are headed, but also makes developers more willing to help out and instill confidence that your project has actual potential and isn't some backyard project thrown around.