Forming a PBBG development group

Forming a PBBG development group

Have you ever tried to create a PBBG by yourself? I have. I haven't completed it yet and I have been working on the code and design for almost a year now. It's a ridiculous amount of work for one person to attempt to plow through when you are creating all your code from scratch.

Well your next step would logically be to build a team of designers and developers to work with you. If you're like me and don't know anyone else that has the know-how to help, you are out of luck. Well, not entirely...

There is always the Internet. But it seems every time I mention on a forums, or a blog, or in chat that I would like to form a group of developers to work together over the net, every shies away. Why do people in our community believe this to be such a difficult thing? Do the nay-sayers not know of open-source where developers and designers from all over the world work together online building applications?

It can be done. Only if everyone is whiling to agree to a set of terms better the project starts. So what I'm going to do is outline the steps I believe needed to successfully build a PBBG when the workplace is entirely online.

  1. Choose a project leader. The project leader will often time be the person brining the group together. If anyone in the project has a problem with the leader either resolve it before the project starts or kick them from the team. The project leader will need to have the final say if it comes done to it and actually have everyone listen. This isn't to say that the project leader makes all the decisions, but if there is a choice between to call it gangs or groups or alliance, or if a split arises in the team about a design or coding problem the leader's decision will put the subject to rest so the group can continue working.

  2. Design before Code. This is a simple rule that could (more than likely will) save the group hours and anger. Complete the game's design COMPLETELY before coding anything. For anyone that has designed a game before, a little change could costs a developer hours of code. This could cause much anger and resentment within the group so don't let any of your coders do anything before the game is designed.

  3. Size. Now before you go recruiting 25 people to design/develop a project stop and think. Can we organize that many people efficiently? Can everyone step you and do equal shares of work? Do we all have the same goal? Now that last one is very important. The larger the group the more likely you are to have people that don't agree with the vision of the project and just leave in the midst or cause an uproar. So I suggest trying to keep the group size at about 5 members. This number is easily manageable, especially if they all agree, or even mostly agree with the design and coding structure.

  4. Online Gathering. You want it to be easy for your members to easily share documents between each other so you'll want to set up a meeting place. I personally suggest Google for everything. Google groups, documents and calender would work wonders for organizing the whole group. And since most people already have google accounts its should be no problem.

  5. Coding structure. Before anyone starts coding you will want to set up a structure that is easy to maintain. I suggest creating a relational map to show variables and what pages are sharing variables. If it seems to difficult to plan out all the variables before starting, just have everyone declare their variables at the top of each page. This way you can go in and easily re-assign their values.

  6. Money. This is a VERY touchy subject with many people. A lot of developers create games for this sole reason. I personally create to see people love my creations, but that's not the point. The point this when the game is finish it will need a server and unless one of the members is willing to host it you are going to need to buy one. Now, the entire group can chip in or one person can be responsible. But the page would also produce money. And this is also a problem. So this is the way I would approach this. If the entire group chipped in equally and did relatively equal work them the profits should be split up equally. If one person is maintaining server costs, then that person should easily receive 70% of the profits. They took a risk none of the other members were willing. As for payment to member, I would limit it to every two months. Keep the money in an account and make all transactions from that account available to the team. And after server costs are deducted, split the profit. I would keep a $100 extra for the server just in case.

  7. Maintaining. If everyone agrees to help maintain the game great. But if not, payment will become an issue again. What I would do is this: If a person decided they couldn't maintain the game anymore they would receive their share of the profits for 6 months. After that they are no longer part of the team and no longer will receive any profits.

As you can see, this could be done. It may not be as easy as working with people in the same room as you or just a block or two away, but it's doable with a good crew and a firm understanding amongst the members of what needs to be done.

The trickiest part if the money. Everyone gets uppity when it comes to making cash. So make sure you have everyone in agreement before you launch the game and who 'owns' the code. Most likely it would be the project manager.

I hope this has given you some insight into organizing your teams, online or in meatspace. It can be difficult to have people maintain a scheulde when everyone is working for free, but if you can bring a group of people together that really want to make a game, you can do it.


PS: I would like to attempt to form a group to develop a game. I do game design and develop using PHP/MySQL. If you are interested, email me at bardic(dot)knowledge(at)gmail(dot)com

More about



Show all Browse discussions

Start a discussion