Hello again, my name is Matthew Dryden - I'm the team lead for Modular Combat. I'm here to talk to you today about how we develop our mod - and how a mod generally developed.
This is going to be a rather long block of text - butif you're interested in reading a layman's version of how a mod is developed, please read on.
The Revision Structure
When an artists starts to create a work of art, it usually begins with a sketch or a quick outline of what the final product is going to look like - such is the same for modding (which some can call an art - a statement I don't entirely disagree with).
When Andy and I started developing Modular Combat, I already had an idea of what the final version of the mod was going to look like (and we are progressing nicely towards that vision), and through a series of conversations through Steam, we decided to purchase some development space (a small package that only cost us $5.00 monthly) and start development.
LIke the design of gameplay goes through a series of revision and refinement, the technical side of modding works this way as well. We started by adding a completely unchanged version of the "Source SDK - Orange Box" code.
This is where it starts getting interesting. We had a full version of the code that was ready and playable - but it was just normal gameplay (with the acception of OB-style graphics). By the time we were ready to start developing the mod, we already had 3 revisions to the original code.
What does revision mean?
A revision means basically a change - a single or a few multiple changes. This is how we develop Modular Combat. We start by making a few small changes and then testing them, and then another few, then testing them. While it seems like it might be a tedious process - it's really not at all.
When you have 2 or more people working on the same with the same goals in mind, this revision process can actually move very quickly. As of this writing, we have made 407 revisions to the original source code (all of which have been logged and kept in our history). All of these changes made Modular Combat what it is today.
How do you coordinate all of these changes?
If you're anything like me, you're probably wondering how we coordinate all of these changes. Well, we used a milestone and ticketing system.
Modular Combat considers each milestone a release. A milestone is a hub (think parent category) for all of our tickets relating to a single release. Milestones keep track of the percentage complete based on how many tickets we log against it versus how many were closed.
We log tickets for many different things, but these are the four different category: task, enchancement, quality, and defect.
We consider a task as something new that needs to be added to the mod. This could be anything ranging from a new module to a whole new gamemode.
An enhancement is a change to an existing feature - an addition or improvement to anything. This category is often used to rebalacing modules or adding additional information to our hud elements.
Quality is new category we've added so that our Quality Assurance team leads can have tickets assigned to them for testing purposes. Quite often we add a feature that needs testing to make sure it functions correctly, and sometimes we will forget to do it. With this new category, we just log a ticket and assign it to a QA Lead.
The defect category is most often used during playtesting and most used by our QA Leads. They start writing down bugs and slight defects for tickets which they later log. These tickets are often then handed back to the dev team in order to fix the mod.
So who coordinates all of these tickets?
As team lead of Modular Combat, it's part of my job to make sure that the workload is evenly distributed between my teammates and that tickets are being logged, assigned, and completed in a timely manner. This is part of what makes Modular Combat move.
We also give priority to tickets ranging from blocker and critical to trivial, as seen here in this picture:
You will also noice that there are three different people working on different parts of the mod. We all view this screen almost on a daily basis - so we always know who is working on what and what is the most important tickets.
What you've seen here is the tail-end of our rather large-scale development cycle over the last month or so - so we've already taken care of the most important details.
One of the biggest struggles of any mod is coodination. With a revision and ticketing system like how we have, it's easy to see who is working on what and it's extremely easy to see how much work is getting done - by all the dev team.
One of the interesting things about our system is the order in which things get done. We will often jump back and forth between tickets and finish things in a skewed order. While it may sometimes seem like chaos, there is a definite order to how things get done.
A Real Life Example
You may be wondering how this relates to Modular Combat. Well, I'm about to give you our whole changelog in it's entirely - but in a format that you don't normally see - the revison format.
This means that as you read along, you will notice that we sometimes added features in and then remove them at a later point, or we ended up changing the functionality and adding to it over time.
Here is the full changelist for just 75 different revisions to Modular Combat - starting June 2, 2009 all the way up to July 11, 2009. (just over a month of development). Since we compile this list in reverse order, I would suggest reading it from the bottom up.
Conclusion
Thank you for reading this rather long-winded look into a small part of how we develop Modular Combat. I appreciate your time and be sure to check out version 1.75 of Modular Combat when we release it!
Follow us on:
(Special thanks to the Overgrowth team and Iiro Jäppinen for providing these nice icons!)
Great way of doing things! I'll be taking a lesson or three from this.