[NotL337]

I have a bit of a dilemma.

I plan to code, build, and design my entire world mostly by myself. I intend to code the features, write roughly 10,000 rooms that'll be open once the MUD starts, and of course do all of the history/races/etc. by myself.

As far as the sheer volume of the work goes, I'm 100% certain that I can do it. I'm going to be taking a few years to get it done, of course, but I'm more than capable of handling the workload.

But my real question is: Should I?

My reasons for doing it are that I know I can depend on myself, I want the world to have a good, continuous feel to it (which is easier if you have one writer), and I already have the world outlined quite clearly in my brain and just need to get it all down on paper.


But would not enough cooks spoil the soup?

I'm not worried about getting lazy or hurried--that's not how I work. If I sense I'm cutting corners in my writing, I've always made it a habit to move to something else till I can come back and do a proper job. But I suppose my real worry is that I might have trouble getting people to join on if the MUD's just starting up, but it's already highly designed.

[KaVir]

Originally Posted by (NotL337 @ Nov. 05 2006,10:37) But my real question is: Should I?

To be honest, that's a question that only you can answer.

Is it possible? Yes. Is it a lot of work? Yes. Is it worth it? That depends entirely on you.

[Brody]

It's a good question and an important question.

I'd argue that it can't really be a one-man job. First of all, it automatically sets you up for a long development process - a few years, as you noted. Keep in mind that after those few years have passed, it remains to be seen whether you'll still have the same enthusiasm for working on the project. And after you've finished primary development, it'll be time to market and promote your game. Will you still have the energy needed to put behind that effort?

I understand wanting to protect your creative endeavor to some degree, but from my own experience I found it was better to bring in other people to work with me on code, building and thematic development. First of all, if you have multiple people working on things, you speed up development. Second, you give yourself a measuring stick for progress and might be encouraged to keep up with each other. Third, you share in the growing enthusiasm of watching the project evolve. And, fourth, when you're ready to open the doors, you've already got a small army of people to greet newbies and help the place look alive.

Don't doom yourself or your project by taking on too much on your own.

[Fern]

While it may be heaps of fun to do everything at once (and for awhile you may be able to do so), developing a team and sharing the burden can also help ensure that you don't get caught with a pair of blinders around your eyes. Over the years I have found that our team does a vastly better job of protecting and nurturing the world vision than one person could ever hope to do. We need the counterbalance, the input, the devil's advocacy - a well crafted team gives you these and much more.

[Lanthum]

I agree with what both Fern and Brody wrote. But I wish it was as easy to build a team as you guys make it seem.

I know personally on my project - it has proven impossible to build a team so far. I've tried several times bringing people on board - both coders and content developers - but none of them have stayed. They all seem to get to busy, or want to start their own MUD. *sniffs his armpits* and *checks his breath* I guess it could be me too

While it would be preferable to build a team to do the work, I personally would not wait on finding other people to start. At least this way you are making some progress.

[Fern]

Who said it was easy building a crack team? It's one of the most difficult tasks I've taken on in my life, and I'm including the 20 ++ years spent running my own on-ground business. The task is daunting, and finding those perfect people is not something that happens overnight - but once you do find those people who mesh with you and merge into a team, they're priceless.

[Brody]

I don't see anything wrong with starting on your own. However, my caution is against *planning* to do *everything*, from start to finish, on your own. When I first worked on OtherSpace in 1998, I focused on theme development on my own. I then got together with more technically minded people who could help 1) host the game on a server and 2) code the bells and whistles to accessorize the game.

After that, it was a matter of growing a playerbase and then adding more staffers to help flesh out theme and promote the game.

There's plenty that you can do in the way of advance work before opening the doors to new players. It helps a lot if you're jumping into the project with like-minded compatriots, though. (Not the fair-weather friends who vanish to do their own projects and leave you hanging, of course, but people really dedicated to helping bring your vision to life.) It has to be something you really believe in, and that belief has to be something contagious when you try to get other people involved.

[Valg]

After a while, I think trying to run an entire game from scratch is only useful if the creation of the game is an intellectual exercise or training for yourself. If your goal is to make a game that other people will play, it's simply bad management.

Put another way, if I wanted to make a company that sells widgets, there are tons of things I'd want to do myself at first (design the product, keep the books, negotiate with lenders and major buyers, etc.). However, people would think I'm nuts if I insisted on also driving the trucks, sweeping the floors, running all the machines, etc.

Even one or two trusted volunteers would make a huge difference in your project. Now, locating those volunteers can be a challenge, but you have to view that investment of time and energy as no different from the investment of time and energy it would take to do the work of several people yourself.

You want creative control of your areas and storyline? Get a volunteer who will check them for errors, and make suggestions for changes and improvements. Want to design your own combat system? Get someone else who can help you playtest it and try to locate degenerate strategies and bugs. None of that requires signing over your vision to anyone else, but it will save you hours and hours of slog. Eventually, you'll also have the core of a senior staff when you're closer to thinking about beta-testing or going live.

This is crucial. We have the luxury of recruiting 100% of our staff (typically 25+ active members) from long-term players of our game, so we always get people who know the story, know our tastes, have some roleplay chops, and have a schedule compatible with making an impact. You won't. Identifying a couple 'right-hand men' early on will save you a lot of pain down the road.

[KaVir]

Originally Posted by (Valg @ Nov. 09 2006,4:41) After a while, I think trying to run an entire game from scratch is only useful if the creation of the game is an intellectual exercise or training for yourself.

He's not talking about running it, but rather creating it.  Of course it could also be argued that a well-designed game pretty much runs itself...

Originally Posted by You want creative control of your areas and storyline?  Get a volunteer who will check them for errors, and make suggestions for changes and improvements.  Want to design your own combat system?  Get someone else who can help you playtest it and try to locate degenerate strategies and bugs.

You don't need staff to do that, just some players.  The players are, after all, the people who see those areas and use the combat system each and every day.

[the_logos]

Originally Posted by (KaVir @ Nov. 09 2006,11:09) Of course it could also be argued that a well-designed game pretty much runs itself...

That could be argued I suppose, but every popular text or graphical MUD I'm aware of does not "run itself" because they're more than just products: They're ongoing services and they require significant ongoing effort to keep the product/service fresh and running smoothly for the players.

To the OP: I'm with everyone else. Get yourself some help!

--matt

[Gromble]

I'm about to start year four in the development of a "from scratch" server (which I do as a hobby), and I'm still adding infrastructure.

I'll echo what others have said, that it takes a tremendous committment and your enthusiasm will wax and wane over the course of the project.  I did a burst of work this past weekend after several months of inactivity, and the satisfying results have motivated me to do more this weekend.

Maybe the question to ask is how soon do you want to have something to go public with?  In my case, I have no deadline I'm trying to meet so I have no reason to add more people and distribute the workload.

-Gromble

BTW, I love hearing about nifty innovations other developers have come up with in their own servers so please share them.  For my own server, some examples (which are not original) are...

- A parser stack that allows me to push and pop parsers depending on what the user is doing.
- Instanced quest zones, where every party gets their own copy to play in without interference from other parties.
- All content is stored and retrieved in XML format, and validated via schemas (Apache Xerces).
- Command permission groups rather than a level based command hierarchy.
- Event driven scripting (Lua).

[Valg]

- Instanced quest zones, where every party gets their own copy to play in without interference from other parties.

It's always fun to see contrasts between games. I know this is a popular design, yet we're always making things thinking "Is there a way to let other players have a chance at lying to, stealing from, and/or killing you here?"

[KaVir]

Originally Posted by (the_logos @ Nov. 09 2006,5:49) Originally Posted by (KaVir @ Nov. 09 2006,11:09) Of course it could also be argued that a well-designed game pretty much runs itself... That could be argued I suppose, but every popular text or graphical MUD I'm aware of does not "run itself" because they're more than just products: They're ongoing services and they require significant ongoing effort to keep the product/service fresh and running smoothly for the players.

They require significant ongoing development work to avoid stagnation, but that is a separate issue from what I was talking about.

By "pretty much runs itself" I'm talking specifically about a mud that requires little in the way of an administrative presence within the mud - the players don't depend on admin-run quests, events or storylines in order to be able to play the game and enjoy themselves. The players have their own tools for dealing with griefers and spammers. Undesirable activies are blocked by the code rather than enforced by people. Players can quickly and easily find the answers to most questions they might have via intuitive in-game documentation. And so on.

When a game pretty much runs itself, it gives the admin more time to spend on other things...like development.

[KaVir]

Originally Posted by (Gromble @ Nov. 09 2006,6:06) - Instanced quest zones, where every party gets their own copy to play in without interference from other parties.

Actually, I use the same sort of system to give each player their own 'home plane' - their own private world that they can terraform to their liking. It's a good way to avoid having loads of idlers hanging out in the central village, and it gives the players a private place to invite their friends.

[Gromble]

Originally Posted by (KaVir @ Nov. 09 2006) Actually, I use the same sort of system to give each player their own 'home plane' - their own private world that they can terraform to their liking.  It's a good way to avoid having loads of idlers hanging out in the central village, and it gives the players a private place to invite their friends.

Interesting.  Is this "home plane" essentially a builder sandbox that they can populate with mobs, items, etc, or is it just terrain?

[the_logos]

Originally Posted by (KaVir @ Nov. 09 2006,1:51) By "pretty much runs itself" I'm talking specifically about a mud that requires little in the way of an administrative presence within the mud - the players don't depend on admin-run quests, events or storylines in order to be able to play the game and enjoy themselves. The players have their own tools for dealing with griefers and spammers. Undesirable activies are blocked by the code rather than enforced by people. Players can quickly and easily find the answers to most questions they might have via intuitive in-game documentation. And so on.

Sure, if you have only a few players or you don't care about the player experience, that's possible.

With a lot of players that you're trying to keep happy, on the other hand, support services are simply a fact of life. What you describe is a pipe-dream.

--matt

[Gromble]

Originally Posted by (the_logos @ Nov. 09 2006,3:34) Sure, if you have only a few players or you don't care about the player experience, that's possible. With a lot of players that you're trying to keep happy, on the other hand, support services are simply a fact of life. What you describe is a pipe-dream.

I think what you're not so delicately trying to say is that with a large number of active players comes a large number of diverse needs and expectations, and that human intervention (i.e., customer service) is necessary to address them.

-Gromble

[KaVir]

Originally Posted by (Gromble @ Nov. 09 2006,9:16) Originally Posted by (KaVir @ Nov. 09 2006) Actually, I use the same sort of system to give each player their own 'home plane' - their own private world that they can terraform to their liking.  It's a good way to avoid having loads of idlers hanging out in the central village, and it gives the players a private place to invite their friends. Interesting.  Is this "home plane" essentially a builder sandbox that they can populate with mobs, items, etc, or is it just terrain?

It's really just terrain for now, although players sometimes carry back small mobs from the main world (perhaps to train their pets against). At some point I'll extend it to include other building features.