A huge problem with byond is that everybody has different game creation ideals. How long should a game be kept away from the public, how big of a deal should launch be, how polished should everything be before its shown off.

The big advantage to open testing is transparency. The players can actually see how fast the game is progressing. This can be good and bad. When the development team takes a break or gets busy with real life the people may jump to conclusions that the game is "dying". Obviously to a game owner who is central to making the game and doesnt really depend on others, a game will not die unless the owner loses interest in it. So even though people may think the owner has lost interest in it, a month later it could get back on track. This is NOT true for games with multiple owners or a decentralized team. If the figureheads of the team start to lose interest or take breaks, then there is a good chance the game is actually dying. This is why i dont like decentralized game development cycles. Also when staff quit a game or are fired for inactivity, then often the code is leaked.. this has been a huge issue on byond.

Do you need multiple staff?
Answer: Yes, graphics and coding are talents from different sides of the brain, while I may feel comfortable iconing i by no means could have accomplished things like the hokage monument or the titlescreen on my own. So you dont absolutely need multiple staff, but in order to maximize a projects potential, graphics and coding need to be seperated.

Where do you create divisions?
Theres lots of aspects to game design that can not be effectively made independant. For instance, game design is not an independant quality from mapping. Mapping should not be outsourced as if it can be done by monkeys, mappers while there is no barrier to entry in terms of technical knowledge or artistic talent, there is in fact a requirement for that person to have a good grasp of gameplay design principles.

Who else needs gameplay design principles in a team? Is it the person doing graphics or coding? Definitely the coder. Coders can be hired to follow orders however, but i do not believe this is ever effective. The Coder needs to be a central part of the game design part of development. The reason for this is because coders who don't get creative input will quit on you, their job is boring and they will not be able to contribute nearly as much effort to a project in which they are not a part of the creative process.

The scenario that has worked for me has been this: The central person to a project needs to have exclusive control over the code and to prevent leaking and conflicts of gameplay ideals (if 2 coders have creative control then the game will not balance or satisfy either audience and those different gameplay ideals cater to different audiences and you never want to broaden your attempted audience too far or you'll lose your ability to satisfy any of them.)
The mappers if they are not also coders should be made map making kits to use, to accomplish this basically take your source code and take out all non turf and non essential mapping objects. Why take a chance with a position that has no barrier to entry in terms of skill except something as hard to determine as gameplay design? People who want to just be trolls and distribute source codes will only be repelled from your project if they are required to do actual work first. To repel them ensure that they show off existing work or have an established reputation as a good coder.

So division of staff:

1.Those concerned with Design principles:
Coders + Map makers

2.Those not concerned with Design principles:
Iconers, Sound effects makers(rare), GFX makers(larger scale like title pages, websites).

Why is this important? A project can have as many staff in the second category as it can attract without any risk to stagnating the development of the project. If you hire too many people who are in the first category then your game will quickly become impossible to progress.

I suggest you limit the first category to 1 person for the most efficient byond development. Mapping takes a lot of work but if you know how to code you can always cut corners with automated mapping routines (not overly used so far). However if you want to hire 1 mapper to help you, make sure you and him talk alot and that this person is quite good at understanding gameplay design. Ive had lots of success doing it myself, I dont think you need a very large scale map on a byond game, i think the flow is more important and that in order to maximize how much fun you have in a game its really important that you are kept fairly cozy with other players so to encourage interaction.

Now back to the idea of early public exposure. Its obviously not just advantageous as opposed to private development and ill go through those as well. Public exposure puts your game in an unpolished state in the publics eyes, some people are very quick to judge and those people will never give your project a second chance. That is why all development is always a mix of private and public exposure, but when i refer to public development I mean that there is a certain basic level of completion on the project, such that there is an active purpose to playing the game and that there is nothing in the game that would aggrivate players enough to swear off your game forever. What things will make people swear off your game forever?:
1) Playerwipes; never ever ever playerwipe unless you have to, never release the public alpha of your game if your going to be tweaking with how level ups are handled on a weekly basis. You should never release things to the general public unless your balance and leveling up systems are concrete enough such that playerwipes are only needed at minimum of 2 months. If you release an alpha and playerwipe bi-weekly then people will get pretty darn ticked at you. If you plan on doing this then make sure that the game is advertised as such and that players are aware of how uncertain the future of their character is.
2) Bugs: if there are bugs that selectively mess up players in any long term basis, then you need to fix those before you show the game off. Those may occur during development and that is not the end of the world. These bugs need to be fixed within a day of discovering them.

Anyway, anything thats described as Alpha should be offered a great deal of slack from the public. While i did not enjoy that type of understanding when GOA was released in Alpha, i would think that most projects would. Alpha is the first stage of a public release of a project.

Beta:
Ahh a frustrating topic indeed. The idea of beta is to release after the game is running smoothly and ready to be shown off to more of the general, less understanding public. GOA on the otherhand doesnt follow my rule of what i would consider an appropriate time to go Beta, this is due to a few factors which if you faced i would recomend following suit.
1) Inadvertent playerwipe, the host deleted all the saves, how can you satisfy the players and make a guarantee that you will make sure it doesnt happen again? Speed up release of the next major phase of the game. This is what happend to GOA, the beta was meant to happen after more stability was found but in order to appease people due to the fact that BETA would introduce new balance for more long term playing i rushed the release in order to avoid 2 playerwipes that break the 2 month rule.

2)An accelerated development cycle due to only 4 months of summer before i had to return to school in which i would be restricted in how much time i could spend.

The Beta should be meant for more long term character development in RPGS, people will want to play the game for months consecutively with the same character, so its very important that you take that into consideration for balance and player content distribution.

What is player content distribution? its basically the idea of you make X amount of things that players perceive as content, distributing X along each persons play experience effectively is what creates longevity for a project. That means you need to know how much your playerbase is going to play your game for and cater to them. If the people you bring in are short term play for 20 hours then quit people, then you better distribute content over that 20 hours. If your playerbase is more like GOA and the average player reaches levels that would indicate they play for over 100 hours then you need to keep that in mind and incur a system that gives content out over that time.

Hooking players:
Its not enough to distribute content evenly over an estimating play period, because people will decide to stay on a game and play the game for longer if they are thrilled with the first 10 hours of play. Its important to distribute content at an accelerated pace early on in order to convince people that they should invest more time in playing the game.

What is game content? in the anime guild it is anything that says "why should i keep playing". Many games accomplish this with Skills so balancing such that skill acquisition is distributed accordingly is important. Other things such as offering a ranking system (Naruto especially) or just any type of benchmark that unlocks the ability to do more in the game. In GOA that is accomplished by allowing people to do higher level Missions when accomplishing a higher rank. In your game even if you stray from ranks, you could still do a Level requirement or anything which opens up new aspects of the game that players will actually want to reach.

What of graphics then? well graphics determine to people the level of quality to expect from the game, these expectations are not satisfied with graphics of course, but are satisfied with overall experience. Good graphics are important then if you value large playerbases, if you value bringing in the average player. If your making a small scale roleplaying game in which you just want a few dedicated people then graphics actually are less important. People come for the presentation, they stay for the content.

Back to Private or invisible development:
I have a bone to pick with this concept, that bone is that over the last 4 years only a very very small percentile of these types of projects have actually made it to the public. The ones that did make it out turned out to be at the point in which the "public" games were released, in that while it took them forever to be released they were in fact just extremely slow at developing a game and had not really accomplished anything in that time period. The old original owners of DBO are my example,(DBO2 is a separate game with different code, Legendary Goku is a great and competent owner and iconer and his staff is very talented.)
DBOs hype started to emerge during Gekisens public development stint back in 03 or so. A screenshot or two would surface showing off very impressive ki beam attacks and overall graphics. They would intice people because they would appear to play significantly different. DBO spent years hyping its immenant release, players who heard the hype would spam Gekisen and talk about how the end was near because DBO would blow us out of the water. To put that in perspective, Gekisen stayed popular for around 3 years before i ended its development in favor of GOA. No Dragonball game EVER was released that was able to consolidate the playerbases of all the hundreds of dragonball games. Mine at the time being the NBotls of Zeta rips, that is it was more popular than Zeta and had a constant higher player count. The point is, the hype never materialized. DBO Classic would be released and would feature the X and Spike Npcs which indicated the game was originally in fact a Gekisen RIP, because Spike and X were GMs on my game and the npcs were made in their honor. DBO would eventually develope over the next few years as a public project, it would change owners around until eventually its quality would come to compare with Gekisen but only years after i had abandoned Gekisens development. Now im in the same scenario, Anime is ruled by games who made a public version available within 3 months of its announcement because these are games that have effective development policies. Games are made in private for a reason, either the owners are perfectionists and or the owners dont commit enough time to make the game playable anytime soon. Most of the time these games are simply slugs, taking forever to reach the public stage only to be at the quality that faster developed games were at when they debuted.

This is in reference to FOL, its just DBO all over again. The game has been in development longer than GOA and it has not made its development past base icons, basic turfs and an interface. (GOA has an interface btw downloadable for anybody who uses 4.0) Games like FOL are not likely to materialize, and if they do they are likely to take forever to be worth playing. This is a big point of this post. If a games development is healthy, expect to see it playable within a few months. Some people think its fair for a BYOND game to take years to release, youd be wrong. Theres no reason for it to take so long, BYOND graphics and mapping and games in general are of a MUCH smaller scale. Theres no reason except laziness and lack of knowledge to keep a game from being playable in a few months, and well polished within 6 months.

Goodluck on your projects guys, this is more directed to the people who play games and spend months waiting for games to be released that never do. Stop waiting, play games that are already out or make your own. Games that never become playable are hurting BYOND, it takes motivation from wouldbe developers who may want to make a Dragonball game of quality when they think the game they have in mind is already being developed, whether that be DBO or now FOL. If a game doesnt come out in a couple months for you to judge its basic gameplay principles, then stop waiting. Make your own, dont give these people so much credit!

Summary:
Make games public within 3 months of development, dont wait for games that take years to be shown off to the public. And dont take credit for a game you havnt even made yet.


Edit:
I am not taking credit for inventing the devlopment ideals that GOA follows, they are in fact very general and common sense and most serious game developers on BYOND already know them and could have made the same post. This post is more meant for the general public.