MMORPG Contest End - Fractured Universe

Fractured Universe - City

Hello everyone! A quick introduction: I am Nathan, also known as PyroGuNx. I do game design / business & marketing stuff (as it becomes necessary) for Fractured Universe.

The MyDreamRPG contest came to a close yesterday. This, however, has not been any reason for those of us on the Fractured Universe team to slow its development. While the contest has come to a close, we still have been ruthlessly plugging away developing, adding quests, and moving the game forward.

Originally, I debated whether or not I wanted to post anything about FU. Tony (SgtFlame) and Allyn (MrBloodworth) pretty much covered a lot of what might be said. While I personally could say a lot, most of it would be pertaining to design philosophy, concepts, or business which of course makes sense since that's what i'm on the team for. But I feel it might not be as appealing as other topics. After much deliberation, though, I found two things I felt really aided our success that I wanted to comment on.

The first is a comment on Tony's post mortem post. He made the comment that one thing he wouldn't have done was start alpha testing as early as he did. While I generally agree with him, I personally think it was for the best as it brings in real feedback. Ideally, we would have started alpha testing about a month from now, maybe two at most. However, due to the time constraints, we wanted trusted people on and testing it now. It has really worked out for the best, and in my opinion, is a solid development philosophy. Get your target players (trusted, of course) testing as early as possible, even before you're actually ready to test. It allows for you to take many of the concepts you have and receive real feedback. Why take the time developing guesses so far along when you can find out the answers at the beginning. It also allows for the appropriate trimming of gameplay which is the most important thing, irregardless of the number of features a game has.

Now, I have seen (and been with) teams that don't like this philosophy simply because they don't want to have a huge list of bugs early on and they're afraid of frightening players off. Certainly a merited concern... but those are bugs you need to be squashing anyways, and just because it's on a list doesn't mean you have to fix it now. So long as frequent updates are occurring, players are going to be aware that what they're playing is a work in progress that, best of all, they're a part of. If you picked them right, they'll understand it's not final and that you're actively working on it... which leads me to my next comment.

Regular, small updates. This is something I have seen other teams use with great success and that our team has thus far been using with great success. Frequent, small updates. They're fantastic. They help keep the motivation flowing both within the team and within its community. People see development actively occurring, even if it is small, and it gives a sense of achievement. Not only that, it also helps bug fixing! But the bigger point here beyond regularity is size. By avoiding doing massive updates, it seems to me that feature creep can be more easily avoided, and that updates or bugs won't be put off. In addition, it allows for newly implemented ideas to be quickly elaborated on, shrunk, or potential downfalls or necessary improvements with them noticed.

With large updates, however, it's easy to get caught up in the "oh, we can't release until we get X finished." or "we can't release this yet, it still has Y bug." and inevitably your progress is slowed, if not halted for a time. I also I think this will cause the motivation within the team to be lowered for a number of reasons, and the community I know will be less motivated, or anxious at the least, which is just an additional strain on the team.

I'm not saying that those two methods should be a staple (although I certainly wish they were present in each project i've worked on) to any good team, nor am I saying that this is the only way to develop. But I am saying i've seen these things as primary factors of success (speaking purely beyond our project at this point, as it could only really be considered a moderately short term success right now) to many projects, especially when the majority of the team is made up of volunteers, and perhaps that is the key. What do you all think?

In ending, the contest, though challenging and time consuming has been a blast. Our team of about 5 core guys (including myself) has been an awesome bunch to work with. I don't know about others, but I know that I am impressed with what we have put forth, even if all of us on the FU team would have liked to have had more. Best of all, whether we win the contest or not, we have the foundation and team to put out an indie MMORPG that will, if we have any say in it (which fortunately enough, we do!), will stretch the limits.