06 Jul, 2011, Oliver wrote in the 1st comment:
Votes: 0
For all of you who have released games and can provide your advice, I've a question.

I am deliberating when, exactly, in the cycle of my building schedule I will open the game for Beta testing. I have mostly worked out two plans of action, but currently I'm not sure exactly which one will be better. There are sure to be pitfalls of both that I can't anticipate, which is why I come to you guys.

So. Option one: build several small, core areas of the game that fulfill all the basic requirements of players; as players begin to file in and the playerbase expands, release new areas on a regular (fairly frequent, hopefully) schedule.

Option two: wait until most, or all, of the game is built before opening for Beta. Let the players file in, explore the whole world.

The benefits of the former, as far as I can tell, will be that I can begin testing sooner; this means that I'll have more time to balance the code, balance the existing areas, et cetera. It also means that as new areas are released, I will have ample time to tweak the things that go wrong. The drawbacks lie in the fact that there will be less of a world for players to use, and while it doesn't mean that I would have to limit the starting areas to a VERY small selection, there still will be less.

The benefits of the latter are obvious: the players will have an entire world to explore and use. The main drawback I forsee is that I would have a far more difficult time balancing the game (re: objects, mobiles, etc.) with a whole bunch of things interacting. With the former approach, I could address balance with each area release.

So! If anyone has advice, speculation, or anything of the sort, I'd be glad to take your words into consideration.
06 Jul, 2011, Ssolvarain wrote in the 2nd comment:
Votes: 0
Just a bit of advice on the whole "world not yet built and I want balance"….

Auto-set equipment and mobiles is a great way to establish consistent balance throughout your game. From there, you can decide on some kind of system for how you want to go ahead with further enhancements (like additional damage roll, or what have you). Also paves the way for the balance to continue throughout the game's history as other builders come and go. The tendency is to make items more powerful than the others so that your area gets more exposure… which can lead to some pretty funked up gear.

As far as when to go beta… Maybe work up to X level areas before opening to testers. Ever try building a whole mud by yourself? It can get pretty damn boring <.<
06 Jul, 2011, Scandum wrote in the 3rd comment:
Votes: 0
In my opinion it depends on how active you are. If you update almost every day you can start beta right away, if updates are monthly you should wait till the game is as good as finished.
06 Jul, 2011, Oliver wrote in the 4th comment:
Votes: 0
Ssolvarain said:
Just a bit of advice on the whole "world not yet built and I want balance"….


You can counteract power creep with strict guidelines and simple vetting. I probably won't have equipment stats generated automatically, if that's what you're referring to.

Quote
As far as when to go beta… Maybe work up to X level areas before opening to testers. Ever try building a whole mud by yourself? It can get pretty damn boring <.<


I understand this. My question is what value of X seems to work the best in practice, though.


Quote
In my opinion it depends on how active you are. If you update almost every day you can start beta right away, if updates are monthly you should wait till the game is as good as finished.


Fair enough. I'm referring mostly to the release schedule of areas, though; actual code updates are another can of worms alltogether (although I plan on probably keeping to a bi-weekly release schedule for the actual codebase, once Beta opens).
06 Jul, 2011, Ssolvarain wrote in the 5th comment:
Votes: 0
Oliver said:
My question is what value of X seems to work the best in practice, though.


No, your question was which of two options you should choose. I suggested a compromise.

It's a pretty simple fact that building enough areas on your own to fully flesh out a game is going to take a large amount of time. So, you might as well build as much as you can possibly tolerate, then take a break and let players in to break stuff.

Unless, of course, you're some kind of superhuman who never gets burnt out.
07 Jul, 2011, Famine wrote in the 6th comment:
Votes: 0
As someone who works in the gaming industry and has released a few MUD's, I can share some past experiences.

When you're talking about beta, you want to establish different types of betas. The most common two is open and closed. The most general understanding is one that's invite only and one that's open to the public. When you're in your closed phases, it's generally the idea that you are releasing content as you progress through the different beta phases. Some like to label phases based on the content players are testing, others just keep it simple with one big beta. Then when you head towards a more open public beta, most like to aim for more complete games or products. That's because it's the first impression to anyone on top of your general testing needs.

If it was me, I would slice my beta into a series of open beta phases if my game was not widely known or anticipated by many. That way each phase can have a purpose and those testers feedback can compile nicely into each phase as opposed to one big beta where feedback is coming from all different directions (or areas in your case). Then you can say this beta is for X area (or areas). Then you release the next set, close the recent beta phase and do another round on those areas. It helps keep your testers focused one, or a set of predefined areas of the game as like I said, everything at once.

On that note, that doesn't mean you can't do everything at once. It just means you open pieces at a time.


Cheers!
07 Jul, 2011, Oliver wrote in the 7th comment:
Votes: 0
Famine said:
If it was me, I would slice my beta into a series of open beta phases if my game was not widely known or anticipated by many. That way each phase can have a purpose and those testers feedback can compile nicely into each phase as opposed to one big beta where feedback is coming from all different directions (or areas in your case). Then you can say this beta is for X area (or areas). Then you release the next set, close the recent beta phase and do another round on those areas. It helps keep your testers focused one, or a set of predefined areas of the game as like I said, everything at once.

On that note, that doesn't mean you can't do everything at once. It just means you open pieces at a time.

Cheers!


Good advice. I'll definitely take into consideration several different beta phases, as I guess that hadn't really occurred to me (although I know that's how it is frequently done). I don't really anticipate my game to be opening for testing with a large amount of hype, no; not because I expect my game to be lacking in features or quality, but more because I don't intend to put a large amount of effort into advertising until it's a more completed project.

Thanks for the input!
07 Jul, 2011, melopene wrote in the 8th comment:
Votes: 0
My general experience tells me that you should have your core areas completed, your code as stable as you can make it on your own, and open for testing. Testing brings players, and those who decide your game is worth sticking around often become builders, or eventually find another home on your staff.

My game is still a month or two from ready for general consumption, but I'm very pleased that I opened it up for testing, posted a listing, etc., as it's yielded me some fantastic people who are really dedicated to contributing.
07 Jul, 2011, quixadhal wrote in the 9th comment:
Votes: 0
There isn't a good answer to the number of areas you want before you declare yourself "ready for players". If your game is a simple hack-and-slash MUD where the areas are mostly there for flavor and the central goal of the game is to kill stuff and level, then you're in a very different place than a game that focuses on exploration, or a game that focuses on puzzles solving.

In the case of a game where exploring is a primary goal, you may need a large volume of rooms to allow people to freely wander and immerse themselves in the game. If you're doing more of a puzzle-solving game, you may never have a huge number of rooms, but your areas might be very dense and pack a lot of activity into a small area.

I've found most hack-and-slash players don't care much, as they only want to kill stuff to get rewards and reach the level cap. You could put them in a single room with a trapdoor in the ceiling, through which mobs of increasing difficulty fall, and they'd be happy, as long as there's a vendor standing there to buy their loot, and train them in their new level's powers.

I would probably have the core systems of the game working and bug free (as much as possible) before you open the doors for testing. You may find you have to redesign some systems as players show you things you didn't anticipate in design, but you want that to be able to seperate design flaws from bugs where possible.
07 Jul, 2011, KaVir wrote in the 10th comment:
Votes: 0
Famine said:
When you're talking about beta, you want to establish different types of betas. The most common two is open and closed. The most general understanding is one that's invite only and one that's open to the public. When you're in your closed phases, it's generally the idea that you are releasing content as you progress through the different beta phases. Some like to label phases based on the content players are testing, others just keep it simple with one big beta. Then when you head towards a more open public beta, most like to aim for more complete games or products. That's because it's the first impression to anyone on top of your general testing needs.

This is also the approach I used. Closed beta allowed me to do some controlled testing of the core mechanics, and perhaps more importantly, the feedback from players gave me a big motivational push. Prior to that I'd been working on the mud for 11 months with no external feedback, and it was often a struggle to remain interested in the project - but the players helped rekindle that interest.

The problem with my closed beta was that the game had little to do other than the core mechanics. There was just a vast plain that stretched endlessly in every direction, and 3 different mobs that would spawn randomly as you moved around, their strength based on how far from the centre of the plain they appeared. Although I continued expanding the mud, it wasn't fast enough to retain the beta testers' interest, and they drifted away over the next few months.

After about nine months of closed beta I'd got most of the basics working, but didn't have any active testers. So I disabled all the unfinished stuff (notably classes and advancement), renamed the mud, and opened it as a pure PK game. This was effectively an "open beta" of the newbie phase of the final product, and it worked out pretty well - it was a very simple game, but a fully playable one, and quite a lot of people came and tested it. I spent a couple of years polishing it before changing the name back, unlocking the other features, and moving into the next stage of open beta.

To the OP: I would definitely go for a closed beta first. Invite a few people to test things and give feedback. If you go straight to open beta, and the mud sucks, many players will check it out and leave - and won't give you a second chance later on, even after you've finalised and polished the features.
07 Jul, 2011, Oliver wrote in the 11th comment:
Votes: 0
Quixadhal said:
There isn't a good answer to the number of areas you want before you declare yourself "ready for players". If your game is. . .


Theme-wise, it is a roleplay-enforced game. Codewise, I intend to make the mechanics as finely balanced as any game where PK or PVE is the central focus. The core function of the game, I suppose, will need areas for both roleplay and a fair amount of PVE opportunity before players can test the game in truth.

Thanks to KaVir and Melopene for the input; you guys have reassured me. I'm glad that I could get some advice from people who have been through the trials and tribulations already.
07 Jul, 2011, plamzi wrote in the 12th comment:
Votes: 0
My 2c:

* Begin BETA when you feel like you'll go mad with loneliness.

* Never end BETA. Just tell your players that BETA is over at some point when you think they'll buy it.
07 Jul, 2011, Rarva.Riendf wrote in the 13th comment:
Votes: 0
plamzi said:
* Never end BETA. Just tell your players that BETA is over at some point when you think they'll buy it.


Exactly something not moving is dead anyway, we all are 'new shiny thing' junkies.
07 Jul, 2011, Runter wrote in the 14th comment:
Votes: 0
It's indicative of a poor features integration process when alpha, beta, and live distinctions are meaningless.

The purpose of a beta is to test content properly in a sandbox before players not willing to put up with the nonsense give you a shot. You don't want to poison the well for those players, and they don't want you to either. Don't call something a beta that isn't. If you want to open a game for players and have an excuse for why stuff is still buggy, just tell them you don't understand a production cycle and they'll probably be understanding. This is the mudding community, after all.
07 Jul, 2011, Oliver wrote in the 15th comment:
Votes: 0
Runter said:
It's indicative of a poor features integration process when alpha, beta, and live distinctions are meaningless.

The purpose of a beta is to test content properly in a sandbox before players not willing to put up with the nonsense give you a shot. You don't want to poison the well for those players, and they don't want you to either. Don't call something a beta that isn't. If you want to open a game for players and have an excuse for why stuff is still buggy, just tell them you don't understand a production cycle and they'll probably be understanding. This is the mudding community, after all.


I'm familiar with the development cycle. I don't think anyone in the thread was talking about buginess. My original question was in regards to the amount of content that I should shoot for before beginning testing of the game's meta balance by opening to players– though yes, I would imagine that bugs will surface in beta (catching the unanticipated bugs is part of that phase).
07 Jul, 2011, Runter wrote in the 16th comment:
Votes: 0
Oliver said:
Runter said:
It's indicative of a poor features integration process when alpha, beta, and live distinctions are meaningless.

The purpose of a beta is to test content properly in a sandbox before players not willing to put up with the nonsense give you a shot. You don't want to poison the well for those players, and they don't want you to either. Don't call something a beta that isn't. If you want to open a game for players and have an excuse for why stuff is still buggy, just tell them you don't understand a production cycle and they'll probably be understanding. This is the mudding community, after all.


I'm familiar with the development cycle. I don't think anyone in the thread was talking about buginess. My original question was in regards to the amount of content that I should shoot for before beginning testing of the game's meta balance by opening to players– though yes, I would imagine that bugs will surface in beta (catching the unanticipated bugs is part of that phase).


The the answer should be obvious. The amount of content you still need to test. Beta != strip tease. It has a purpose.
08 Jul, 2011, Oliver wrote in the 17th comment:
Votes: 0
Runter said:
Oliver said:
Runter said:
It's indicative of a poor features integration process when alpha, beta, and live distinctions are meaningless.

The purpose of a beta is to test content properly in a sandbox before players not willing to put up with the nonsense give you a shot. You don't want to poison the well for those players, and they don't want you to either. Don't call something a beta that isn't. If you want to open a game for players and have an excuse for why stuff is still buggy, just tell them you don't understand a production cycle and they'll probably be understanding. This is the mudding community, after all.


I'm familiar with the development cycle. I don't think anyone in the thread was talking about buginess. My original question was in regards to the amount of content that I should shoot for before beginning testing of the game's meta balance by opening to players– though yes, I would imagine that bugs will surface in beta (catching the unanticipated bugs is part of that phase).


The the answer should be obvious. The amount of content you still need to test. Beta != strip tease. It has a purpose.


The reply to which should, also, be obvious: I never said anything about holding out on players. The point isn't how much I deem worthy for the players to experience; the question was whether other developers have found it more effective to beta test with a small amount of core areas built, or whether they have found it more effective to build their entire world prior to beta.

Not really looking to bicker. I got my advice. Thanks to those of you who gave it.
08 Jul, 2011, Runter wrote in the 18th comment:
Votes: 0
And what advice was it that you think was good here?
08 Jul, 2011, Famine wrote in the 19th comment:
Votes: 0
Runter said:
The the answer should be obvious. The amount of content you still need to test. Beta != strip tease. It has a purpose.


That's not really what he is asking I believe. It's more about how much content is needed for a beta to actually consider a beta. Sure, you can go fly off your seat here and say, "the amount that needs testing!" But, that does not help him in understanding how much is needed to keep those testers there testing, and when to say, "OK, they've tested enough content."

This IS the MUD community, and beta testers are not a dime-a-dozen. If you go through your beta phases with a small amount of content through each phase, it could lead testers to become bored because of the downtime. That's the last thing you want, especially if you're a new game where you don't have a large following of players at all. So, I could see why someone would ask how much content should be needed for a beta before entering a beta as opposed to just giving vague answers.

But that's me! :devil:
18 Sep, 2012, dnicolai wrote in the 20th comment:
Votes: 0
For the OP, here is my suggestion:

Build a single string of zones that will take your players from 1-50, including one zone that will teach brand new players how to MUD (that can be easily skipped). Once you have that first string of zones in place you can bring players around to have them try out the zones and see what they do and don't like.

What I would like to suggest on top of that is that after you get that first one in, build another string of quests that's based on an entirely separate alignment. 9/10 of us will make our quests focus on the good guys, but lots of players don't want to be the good guy, they want to be the villain of your game, so give them a way to express themselves other than running to the forest and slaughtering bunnies (btw, don't have quests where you slaughter bunnies). Once those two quest strings are in place, start making branches on them so that players can go from 1-50 in a totally unique way each time.

As for a beta/alpha/live timeline… those don't work so well in MUDs, your game is either advertised for players or it's not. Players will give you a great sense of what needs to be tweaked, but even games like RoD are still getting bug reports every day, so you are never really done fixing the code.
0.0/20