{ause f eath}

*** Is Kind Of Like 7-11, We May Not Always Be Doing Business, But We Are Always Open.***
HomeFAQSearchRegisterMemberlistUsergroupsLog in


 Organization Issues in the Development Team

Go down 
's Flank Artist

Number of posts : 226
Age : 36
Location : Yonkers, NY.
GAMING RIG AND OS : x86_64 AMD Athlon(tm) 64 Processor 3700+ AuthenticAMD GNU/Linux 2.6.24-gentoo-r4
Registration date : 2007-03-12

Organization Issues in the Development Team Empty
PostSubject: Organization Issues in the Development Team   Organization Issues in the Development Team EmptyWed Feb 25, 2009 4:25 pm

First, let me make it abundantly clear that the only insights I have into the drama amongst the TCEDEV members is from what has been posted to the TCEDEV forum ( http://www.xfire.com/clans/tcecomunityteam/forums/ ). I now have to find multiple places to post this to reach all those concerned.

Ever since it became apparent that we will not receive the source code of the TC:E modification, that TC:E is truly dead, the development effort we have begun has taken on a new role. It is no longer about revitalizing a dying game, but about remaking a dead one. This means that all of our decisions have to be made based on what is best for the project due to our limited resources.

Since there are so few of us who have applicable skills, we have to put our personal differences aside. Anyone who has a skill is welcome to contribute. There is no reason for people who don't like each other to interact. I will elaborate on this below.

There has been a glaring oversight since the onset of this effort that must be addressed. The decision process for this group has been completely unacceptable. This has gone by largely unchecked due to the effort being in its infancy, so such topics have yet to be discussed. It is now time to do so.

Part of this problem stems from the hierarchy in place. I don't know what criteria "diamondback rattlesnake" used to appoint the administrators, or why they took such appointment to mean they had complete say over decisions. I took the positions to be preliminary, intended as an attempt to get the ball rolling, and to be dealt with later with more scrutiny: regardless of us getting to continue the mod or having to start a new project.

I feel that those who considered themselves to be in charge have not conducted themselves appropriately for such authoritative positions. This is mostly due to decisions being made without everyone's consent (everyone active). This runs the gamut of decisions about everything from who is (supposedly) in charge, to the name of the project, to the exclusion of members. If you take the decision of the engine as an example, there was much deliberation amongst many of the team members before it was agreed upon, and the final decision was made at a meeting. This is how everything should be handled.

Ideally, decisions would be made (finalized) during a meeting with every active and contributing member present. In a best case scenario, we would have appointees to act as secretary for keeping minutes, and a moderator to ensure people don't dominate the conversations. It is unreasonable to expect this approach to be achieved any time soon, but it should be an administrative goal.

This seems to suggest that a democratic structure would be the best choice. Unfortunately, the democratic approach is not perfect. A majority rules system can be slow, resulting in stalled progress and indecisiveness. A possibility is for one person to have the final say to ensure progress is made, but that has obvious drawbacks. A mix of the two could also work.

The solution to the clashing-ego problem mentioned at the beginning is to establish divisions and appoint section heads. This way people only have to deal with their section head. Division leaders would be the only ones required to attend meetings, so that tasks can be delegated, and those personalities that don't work well together won't clash. Of course, everyone would be welcomed at meetings, but it must be understood that meetings are for discussing the project, not sorting out personal grievances. This also lends itself to resolving the majority rules versus tyrant problem. The division heads would finalize decisions based on a majority rules vote amongst themselves with an impeachment/election system in place. This is rather cumbersome, though, and probably unnecessary at this stage.

One possible division division (haha) would be as follows:

  • Management
  • Programming
  • Art
  • Music & Miscellaneous
  • Support & Quality Assurance

To further mix the concepts. The division heads would make up the basic committee structure, but there still could be a a person to have the final say: a head-leader. This person would most likely be the same person who heads the Management division.

There is one basic common requirement of all division-heads: no preexisting personal issues may exist between the head and members in their division.

If the "head-leader" approach is opted for, it is important that they be someone who has no previous problems with anyone. At the very least, the head-leader can not have any problems with other division heads, as problems with other members can be avoided given the meeting structure.

It, for example, obviously doesn't matter if the Programming-Head has a problem with someone in the Music & Miscellaneous division (presuming it isn't the division head!), since there doesn't have to be any interaction between them, but it would be problematic if someone new to programming was having fixes ignored because the head didn't like the person.

Instead of having the head-leader double as the Management division head, it might make more sense to have the five divisions above, and a sixth person to act as the head-leader: the person who has the final say.

These are all examples of how to deal with the "final say" decision problem, but I think we would be very foolish not to establish the division hierarchy above as a base to build upon.

In an effort to make things go a bit smoother, in the hopes that everyone will appreciate the importance of everyone else's role, I am going to strongly recommend some reading material:

  • Game Architecture and Design: A New Edition by Andrew Rollings & Dave Morris (ISBN: 0-7357-1363-4)
  • Anything of interest to you at GameDev.net, at a later date I will pick out a few articles in particular I feel we could all benefit from (if they're still online)
  • http://www.wired.com/science/discoveries/news/2006/02/70179 -- The Secret Cause of Flame Wars. Honestly, after having been on IRC for several years, I thought everyone knew this.

The game architecture book is, by far, the most important. I'm not asking you to buy it, but it will be invaluable for anyone sincerely interested in game development. Look for it at your local library, and if they don't have it ask them to order it: libraries do that, take advantage.

The book is split into three parts: 1) Game Design (conception, core design, game play, balancing, look and feel, etc), 2) Team Building (team management methods, roles and divisions, milestones and deadlines, etc), 3) Game Architecture (development methods, initial design, building blocks, etc). The suggested division structure, above, was taken from Part 2, Chapter 10: Roles and Divisions.

Remember, this is about what's best for the development of the new project.

P.S. my apologies to CoD for having to post this here.

{} G
Back to top Go down
View user profile
Organization Issues in the Development Team
Back to top 
Page 1 of 1
 Similar topics
» Your favorite basketball team
» New Skill (Double team)
» What basketball team do you like?
» Tourney #31 ****"Tag Team" Sign-ups closed****
» Team Chloe Thread (Official)

Permissions in this forum:You cannot reply to topics in this forum
{ause f eath} :: Pick Your Poison :: General Discussion-
Jump to: