Parallelizing Mason Developement

by Bryce Harrington


Mason development has been going very well recently and is accelerating. The idea I'm proposing is to enhance this by dividing up into some sub-groups to focus intently on particular aspects of development. Here is a preliminary list of sub-teams:

Mason Media Team

Create art and music and determine what else is required. Establish specific standards that will be followed for this particular game. Use Request Tracker and Eidetic to keep track of what needs doing and who is doing what. Make use of the media repository to store and organize the products. This team will be in charge of determining what media to make, how to make it, and ensuring that it can easily be used in the game, and reused for other games.

Mason Entity Design and Development Team

Design the entity hierarchy, determine the properties and parameters entity archetypes will have, and start creating archetypes in Eidetic. When it is possible to do entity dev work in STAGE. This team has the full responsibility of determining exactly what archetypes to make, how to make them, and how to render them in a way that can be used by STAGE. It needs to be attentive to game balance.

Mason Rules Implementation Team

Expound on and clarify the rules specified by the Mason concept document, and implement them as RIM's in STAGE. This team will have end-to-end responsibility of the rules from concept to implementation, and avoiding introduction of loopholes and exploits, as well as providing tutorials and training guides to give others who wish to develop RIMs.

Mason Integration Team

This is the group that puts everything together. It has a key role in this whole endeavor. This team needs to be handy with doing "fill in coding" - adding required features to other software products without interrupting or subverting their development. It has the duty and authority to determine what goes into Mason and what comes out. They will be creating the packages, making sure all the components compile and function properly on all supported systems. They can reject media that or RIM's that aren't good enough, and have a responsibility for conducting testing and ensuring the quality of their output. They are also responsible for documenting how to use everything, and will likely be generating or augmenting user docs for many other products, so we've got a strong need for technical documentation type folks on this team. Testing - especially automated technical/regression/compilation and performance testing - is vital, and folks interested in this are urged to join this team. We'll call the coordinator of this team the "Lead Programmer", and his assistant the "Tin Programmer".

Mason Play Team

One thing I think we learned with Acorn is that having the software is not enough. We need to use it, and we need to encourage others to use it. That's the domain of this team. We might think of it as "play testing with emphasis on play". They have the end to end responsibility of establishing and building up a user base - including helping and teaching newbies, doing public marketing, organzing play sessions, introducing plots and stories into the game where possible and desired, and of course providing feedback (and encouragement) to the other teams to continue enhancing the game.


We will of course need people who can focus just on one of these areas, whom we can view as dedicated teammates. Likewise we'll need some generalists who can interlink the teams by popping around from one to the other; this is vital to maintain overall project cohesion and also to ensure communication flows smoothly around the team. This is kind of a loose hybrid hierarchical/anarchical organization, which I think is exactly what we need.

So, with that in mind, I think we should select coordinators for each team, and allow people to sign up for particular work areas, but at the same time have a "pool" group that are allowed and encouraged to "float". :-)

For coordinators, I think we should try to use folks who have experience here at WF, whereever possible. For instance, I think Alistair is the guy we need for the integration team. Zzorn has done a great job getting Mason to where it is now, almost singlehandedly at times, and I think we need to keep him doing what he's been doing, and call him the Game Architect. For other positions, I'd like to hear who's interested and who's available and can dedicate plenty of time to doing it. I think the most sensible way to pick the coordinators is to just get started and then see who starts smelling like a good coordinator. ;-)

Note that there are a lot of products which are going to be feeding in here - such as clients, editors, servers, etc. While obviously it is important that these continue development for mason's success, we will continue to view them as independent and separate efforts in their own right. WorldForge's tradition has always been to avoid coupling development too tightly, in order to let us benefit from competition and having plenty of alternatives. We will use the best tools for the job. This means, if one client doesn't seem to be developing fast enough or in the right directions for Mason, we can use a different one that is making an effort to support us. Client interfaces are going to be pretty driven and challenged by mason's requirements, so we really need to open competition as widely as possible here. It also means that we recognize that Mason isn't the only game that these other products (clients, web tools, servers, libraries, etc.) are supporting, and so we need to also try to accomodate and work within their constraints as much as is feasible.

I'd lastly like to mention that the two most important things each and every person here needs to give attention to doing as we go are fleshing out task lists and documenting the agreements we come to. If we don't do the former, we'll have a hard time figuring out where we need to go, and if we don't do the latter then it'll be impossible for others to see where we've come. If we are all good about doing both, and can all do it together in an organized and consistent manner, our progress can be swift and sure.

Reference: Parallelizing Mason Development"