The Modular Release Model tutorial

---

Table of Contents

1. Introduction
   1. The state of modding today
   2. The modular release model
2. Example Mod: Counter-Strike
   1. First release
   2. Two months, four updates
   3. Retrospective
3. Example Mod: Pirates, Vikings and Knights II
   1. If at first you don't succeed...
   2. Who says sequels are never as good?
4. Think small
   1. Facing facts
   2. Downscaling
5. Example Mod: Prototyping a deathmatch racer
   1. The premise
   2. Identifying your core gameplay
   3. Simplifying art assets
   4. Simplifying player code
   5. Simplifying level design
   6. Simplified gameplay
   7. Identifying problematic areas of the core gameplay
6. Modular releases for Single-Player
   1. Episodic gaming
   2. Anchoring gameplay features to release modules
   3. Weapon-enemy relationships: Quake
7. Conclusion
   1. What the modular release model can do for you
   2. About the Author
   3. Extra Reading

Introduction

The state of modding today

In a recent poll on the Mod DB, the majority of voters agreed "developing a game is more difficult than it looks" when citing their opinion on why most mods fail to release. As game engines get more intricate, industry dev teams are growing in size to accommodate the customer's thirst for accurate game physics, tantalisingly realistic vistas and much bigger worlds. The industry does this predominantly on a 'bug-free full release' model. Meanwhile, modders are getting conflicting messages about what development model they should be adopting to keep their heads above water in a sea of competition, and amidst the climbing expectations of an impatient playerbase.

Take the following for example. On the one hand Valve Software's modding mantra advises: "release early and often". On the other hand, these very same successful mods are the ones being bought out by the industry. Modding is the most viable platform for getting a job in the games industry, and the most successful mods get the biggest coverage. So there is this desire for a mod to be successful, which a lot of shortcut developers (and players) translate into "make it look and feel like a game that would sell" (or a mod that stands a chance of being bought out).

I do believe that releasing early and often is correct in principle, but it is too generic a statement to be effective if taken at face value. Releasing early has proved itself to be a death blow for many mods because of poor reception. Gamers have so much choice for online amusement they will not be going back to a buggy, laggy or boring mod if it failed to captivate them the first time round. So we have a bit of a dilemma. Release early and often, but woe betide anyone who screws it up first time round, the players won't like it.

modular (adjective) - Designed with standardized units or dimensions, as for easy assembly and repair or flexible arrangement and use

This is where a modular release model comes into play. The modular release model is a bit more realistic in that it accepts people don't want to play buggy games first time round, it accepts that people who aren't paid to stay together generally won't do if it isn't in their interests, and it accepts that most mods are way too ambitious with what they aim to achieve. The idea is to get to a first release as quickly as possible, but also have a plan of action for future releases that will keep people interested and give your team a focal point of development.

A modular release model is simply one that takes your key features and places them into the public domain in playable form with the minimum amount of time spent in development. I'll go into more detail on this in the coming sections, but first let's look at an example of the kind of effective development model that the modular release principle is based on.

Example Mod: Counter-Strike

From humble beginnings to a gaming legacy

The truth of the matter is most mods try to do too many things. Counter-Strike is a great example of a mod that didn't do this and was a success because of it. It's an even better example because the version of CS people play today has almost identical gameplay to the version people first played eight years ago. The fundamentals have not changed a bit, and that's why CS is proof that the 'release early and often' does work given the right circumstances.

Modders look at Counter-Strike now and have it in their head that they will make something just as great for their first release. The problem here is they are usually not thinking about what makes CS great, they're thinking about the frills that make it better than it was. We should also note that CS wasn't massive on it's first release. I'd like to think I've always been on the modding pulse, but the truth is I -along with the majority of gamers at the time- didn't hear about Counter-Strike until over a year after its initial release.

Counter-Strike started out very small both in terms of content and in terms of widespread appeal. In it's first public version on 19th June 1999, CS Beta 1.0 had the following:

» weapons: usp, glock, shotgun, m4a1, mp5 navy, TMP, awp, G3/SG-1 & FN M249 PARA
» hostage rescue scenario
» custom maps: cs_siege, cs_mansion, cs_wpndepot, cs_prison

That's 9 weapons, 4 maps and 1 game mode. The most important thing here is the "1 game mode". Counter-Strike could have released with only 5 weapons and 2 maps and it still would have caused a stir. The point is they got the simple mechanics of the hostage recue scenario working, made some weapons to play it with and some levels to play it in. This is all any mod needs for a first release: an original game mode, the tools to play it with, and an environment to play it in. Any mod that can do that has had a successful release and anyone who says otherwise is either foolish or ignorant. Yeah, that's right: a FOOL or an IGNORAMUS!

It's the part after release that further determines a mod's success. What is often ignored is that while CS Beta 1.0 brought a fun and original game concept, it also came with a lot of design flaws and bugs. There was no clock to tell you how long you had to rescue a hostage, the server code was unstable, you could rush the opposite team before they had a chance to buy their guns, the deathmatch-style jumping was at odds with the 'realistic shooter' name tag. Looking over the changelogs for the first two months you'll notice how much was done to improve it.

BETA 1.1
[6.27.99]
» greatly improved server stability, crashes should be eliminated
» primary servers will now work with CS
» fixed the ammo and armour reset bugs
» balanced the economic system a bit
» added new firing mode for the glock18
» enabled 'mp_friendlyfire' command for server admins
» fixed map rotation
» adds two new maps: cs_assault & cs_desert
» cs_siege fixes
» cs_wpndepot fixes

BETA 1.2
[7.20.99]
» 5 second "molasses period" at the start of all rounds to dissuade rushing tactics
» kick option added
» Refined the prices for some of the gunS
» made the kevlar MUCH more effective (it now covers people's arms)
» made jumping and shooting MUCH more inaccurate for all the guns
» added a $16,000 salary cap
» tweaked the bonus money awards.
» tweaked the flashbangs effectiveness

BETA 2.0
[8.13.99]
NEW Features :
» Three new guns added : {Sig SG-552 Commando , AK-47 , Desert Eagle}
» Added silencers to the USP .45 Tactical and the Colt M4A1
» Added a round timer which shows how much time is left in the round
» Added team scores which shows how many rounds a team has won
» Added Night Vision Goggles
» Added new entity for mappers to use (info_hostage_rescue)
» Optimized all the models for lower r_speeds!
» Ability to assign keys to all of the commands from the controls menu
(courtesy of cannelbrae of Gunman project)

BETA 2.1
[8.17.99]
» added new vesion of cs_assault (compatible w/ hlserver.exe)
» added scientist model for hlserver.exe
» added assault's proper sky
» fixed telefragging (cs_alley will no longer telefrag)
» fixed dropweapon
» fixed those spurious 'player joined' messages
» changed Ak-47 price

Apart from showing that releasing early and often is a good way to succeed, my main point here is that Counter-Strike wasn't perfect on its first release: it had only one simple game mode, some poorly balanced maps (many of which were axed in subsequent versions) and some unbalanced weapons (which have been fixed after many, many versions of testing).

The important thing here, though, is that the core gameplay seen today in Counter-Strike: Source hasn't much changed from Beta 1.0 in 1999. This is where I'm really trying to go with this tutorial: mods need to focus on their core gameplay and build upon it in subsequent releases with gameplay tweaks, bug fixes, and improved and additional assets and levels.

I know what you're thinking, though: that was then and CS was made in the 'golden age of modding' where players were so much more accepting of unrefined gameplay, where ideas and techniques were shared from one team to the next completely altruistically, and where money and portfolio building were the last things on a modder's agenda. Next, then, let's look at an example of how this format can be made to work in today's climate.

Example Mod: Pirates, Vikings and Knights II

Seasoned veterans of the modding high seas

My second example is PVK II, a mod with a fairly ambitious end goal, but with the experience to know how to get there. As you may have guessed from the name, this is the second outing for the PVK crew with their first being a fairly underappreciated mod on the Half-Life engine. This time on Source their experience is showing in how they are approaching their releases.

Their end goal has been announced as:

• 3 teams
• 5 unique classes per team
• 2-3 weapons per class
• 4 different attacks per melee weapon
• 4 different blocking moves per melee weapon
• 9 map-specific game modes
• 9+ levels supporting 3 teams each

This is a lot for any team to take on, but sensibly they have focused on releasing the core portions and building upon this iteratively. Their first release had only 1 class per team and showcased several game types and their hand-to-hand combat system (including blocking). It doesn't sound like much, but it was enough to get everyone talking about it and, more importantly, playing it. PVK II Beta 1 probably had 2-3 months of high popularity before most people lost interest and the numbers dwindled slightly, with ex-players usually citing 'lack of depth' among their main reasons. Still, at the time of writing they are the fifth most popular mod for Half-Life 2, and that's no mean feat.

Their modular release format has served them well. From the initial player feedback they were able to look at their combat model and refine it to include better hit detection and directional blocking, as well as receiving a lot of valuable map feedback. Since the combat system is mapped onto all of the classes they only needed a bare minimum of class types to test it with on initial release. They sensibly identified their hand-to-hand combat system as one of their more unique features and concentrated having that tested on a large scale through their first release. In their next release they will be adding one class per team to the equation (bringing it to 2 out of the eventual 5), and also some new maps to try out.

So modular development does work. The next sections detail what you can do to gear your mod and your team towards a modular release pattern.

Think small

If you think the sky's the limit, you've got your head in the clouds

Reach for the sky in modding and you'll most likely have the carpet pulled from beneath your feet. On a typical item asset like a weapon or tool you could have in excess of 20 separate tasks spread across 3-5 individuals before it reaches a state of completion. This is further complicated by the fact these individuals may not be able to communicate with eachother directly for 80% of the time due to the hours they are available and which side of the world they wake and sleep on. This is one of the disadvantages of not having an office where the team can work together in person. One of the advantages modding does have, though, is that you can improve upon something post-release at minimal cost.

This advantage should be used to keep that initial release as uncomplex as possible. If you can leave out a weapon without compromising the core gameplay, do so. If two maps showcase the same game mode, choose one for release and concentrate on getting it balanced and tested. As long as adding something in at a later stage doesn't pose any major problems (e.g. having to re-design or re-code an entire feature), you're probably better adding it to a second release 'wish list'.

Guess what? This means you don't need to recruit a team of amazing artists! As long as people can make a pistol look like a pistol and a health pickup look like a health pickup, you'll be headed in the right direction. By the time your mod releases you'll have a proof of concept to help convince better artists to join your team, and with any luck you'll have convinced players that value gameplay over looks.

I can tell you from experience that having to cut gameplay features from an overambitious design just to make a release possible really is a gut-wrenching feeling. Protect yourself and your team from having to do this by thinking small from the outset.

Example Mod: Prototyping a deathmatch racer

Not a real mod, just one I made up for the sake of an example

Let's imagine you are making a racing mod where players ride various creatures. Your unique feature for your mod is that the riders can knock eachother off of their steeds to damage their opponants' chances of victory. Your end goal is to have 8-10 tracks, 8 unique rider-and-creature pairings, unique qualities and abilities for each pairing and interactive scenery that can be used to temporarily and dynamically transform the racetracks.

It is a lofty end goal and it would be impossible to do everything for a first release. Instead, for a first release you should be looking at focusing on your core gameplay. Your core gameplay is that you ride a steed around a track to victory, you can attack to knock other players off their steeds, and you must get back on to continue racing and complete the race. You also have other core gameplay like unique abilities for each rider and interactable racetrack set pieces, but these are not essential to the mod working. These are the walls, you need to build the foundations first and make sure they're stable.

To begin with, you will simply want to focus on getting a race mode with multiple player-controlled racers, a lap counter and a functioning victory condition (all using placeholder assets). But for a first release you will want to focus on the basic mechanics of the unique feature your mod concept has to offer. This first release will be your first development 'module', and to keep it simple and achievable it would contain the following:

• 1-2 simple and short tracks
• 1 rider-creature pairing with 1 attack ability and 1 defence ability, with a different colour skin for each player
• a simple race mode with victory conditions

Simplifying art assets
Here you are saving a lot of time by just adding a colour shade to each player to tell them apart instead of designing, modeling, texturing, animating, sound designing and programming each new player type. By even adding one other type of steed and rider you're doubling the amount of work required in this department for your first release. You're also losing focus on your goal for a first release, which is to get a working, playable game mode. Having two types of racer won't make your game work any better, and if it has a major bug that spoils some of the fun your extra artwork won't stop it having frustrating gameplay.

Simplifying player code
You don't need to have 8 different attack styles to prove the game can be fun. In this concept the main enjoyment factor comes from players being able to duel eachother while racing and knock their opponants off to stop them from winning. Player customisation is a supporting extra that will make the game more fun, but because there is a lot of balancing involved to make sure one player isn't better than the other, it is too time-costly for a first release. The attack itself should be something simple like a fireball. Later on you can think about how to design in more powerful and original weapons, but the basic requirement is that there is 'an attack'.

Simplifying level design
By keeping the tracks simple you won't have to redesign them massively if you need to change how the core gameplay functions based on player feedback. When the core gameplay is in place and you are happy with it you can add further character and complexity to the levels to further improve the gameplay. Level design should be considered as an extension and enrichment of the core gameplay. Until the main game mechanics are in place, tested and working, it is unwise to expend time and resources on the maps. The absolute last thing you want is to have to ditch a map because it just doesn't work with a new design or, worse still, to feel the need to make concessions in your game design just so it will fit the flagship levels in your mod.

Simplified gameplay
A lot of this adds up to simplified gameplay. The major benefit of keeping your gameplay simple to begin with is that you may come up with an amazing way to make the game more original than you originally intended. For example, post-release you may decide that the attacks don't have to be complex, you could add more complexity and originality to how they are performed. Since you haven't over-complicated your first release, you have plenty of room to manouvre and reassess your design. When I explained this example game concept to a friend over a pint in the local pub he came up with the sort of improvement that would undoubtedly make a massively popular game. I would say what, but we're holding onto it for now in case we're ever in a position to make it happen! The point is if your first version is fairly simple there could be dozens of great ideas coming from the community and from within the team that could really help make your game stand out.

It may sound like a pretty barebones release and something not a lot of people could get excited about, but at this stage you're looking for feedback on the main ideas on show in this initial release. You can choose to make this a public release or you could choose to just release this to a playtester group; time and circumstance will help decide which is the best option for your mod and your team. At this stage you're prototyping an idea, and if you get a positive response from the people who play this, then you know you're headed in the right direction.

Identifying problematic areas of the core gameplay
When you start focusing on these bare essentials, you'll soon begin to identify problematic areas of the design that really need to be thought through and prototyped. In this example, how do you handle players re-mounting their steeds once they have been knocked off? There are several issues that need to be dealt with: How do you ensure that the racer can reach their steed quickly once knocked off? Do you automate this area and re-spot the player on their steed, or do you make it in itself an aspect of gameplay where the player has to call their steed back and manually mount it? If you think the re-mount system is going to be a major gameplay area, it becomes part of the core gameplay and it makes sense to prototype it early. If not, you can really simplify this down to some automatic respawn code without any art necessary.

The advantage to having an automatic respawn system is that it requires less art assets, and it requires less testing to make it intuitive for new players. But beware! The disadvantage is that the code has to be bulletproof, since the player will have no control over choosing at which point on the track they wish to rejoin the race. Here, you'd need to make sure than when a player respawns they respawn back on the track and not within another object or player. This means you first have to set up something in the code that differentiates between track and non-track areas that can be used to seek out the nearest possible location for a respawn (this could be a set of linked point-entities that are positioned manually along the centre of the track, or a special material property that can be toggled on/off in the level editor or script files for track textures). Next, this would then be partnered with some anti-collision code that checks the suitability of a possible respawn spot and prevents players from getting stuck in other players/objects or from unforeseen scenarios that break the code and crash the game.

When you consider how much can go wrong with one simple-sounding feature, it makes a whole lotta sense to keep your first release feature list to the bare essentials so your development is focused and fruit-bearing from the outset. Sure, even if you went for a full feature-complete release model you would still find out about this early on. But by focusing on this early, you will ensure that you don't have to ditch custom art and supporting code that has been based on an assumption of how the core gameplay will work. Instead, all of your 'expensive' art (i.e. non-placeholder/programmer art) will be bespoke-made to fit a real, working gameplay model.

Modular releases for Single-Player

Making an episodic release pattern work for your SP mod

We've talked a lot about multiplayer total conversions, but what about the single-player experience? Single-player games are usually experienced only once and there is little room for improvement post-release. So how can you plan a smaller release for a single-player concept?

Episodic gaming
One of the buzzwords of the past few years has been 'episodic' gaming. The buzz seems to have died down now, and from a commercial standpoint it seems to have had mixed results. Valve have brought out their episodic editions for Half-Life 2 at a much slower rate than predicted, and Ritual's SiN: Episodes series, originally announced as a total of 9 episodes at 6 month intervals, never got past the first chapter. Admittedly this failure was largely due to the company being bought out and key members leaving, but 'episodic' has yet to prove itself on a wider scale. Luckily in the world of modding we don't have to worry about buyouts (most of the time), so we have much more freedom to make the episodic system work.

There are some key points to remember about single-player episodic content. Like the multiplayer modular release model already discussed, there is a big emphasis on structuring your development and design around your release model. This isn't too complicated, though, you just need to look at how most single-player games introduce you to the gameplay. Typically a game will begin with a single weapon or item and some basic enemies or tasks to overcome. This is merely to introduce you to the core gameplay, the movement controls, any special functions, the environment, and allow the story's 'exposition' to unfold (i.e. explaining who you are, where you are, who they are, where you've been and where you're going).

This introductory sequence, usually lasting 1-3 levels, is perfect for a modular release format, as it will enable you to get finished or prototype versions of your key characters modelled and in-game, your story and art style introduced, your control scheme worked out, your HUD working, and perhaps a neat unique or original feature worked in too. There are ways to make this tutorial experience more interesting, though.

Anchoring gameplay features to release modules
Another thing to think about is using characters and plot pieces to expand your mod episodically. You could plan your story so a major event or a significant character is introduced in every release. Don't forget that in something like a shooter or even an RPG, your attack styles are almost characters in themselves. Learning a new ability or acquiring a new item usually introduces a new style of gameplay, and can be used to keep future episodes fresh and entertaining.

Weapon-enemy relationships: Quake
Now this doesn't mean your first release should begin with the weakest and most boring weapons or abilities. Quake's first episode (which was used as the free shareware trial version at the time), featured the grenade launcher very early on in the game. A weapon like a grenade launcher is perfect for the beginning sequence of a game because it feels like a force to be reckoned with when in fact it does have many limitations. A GL has a very limited range, does not fire in a perfect straight line and does not perform well against airborne enemies.

Brilliantly, in Quake, the gameplay of the GL was taken to a secondary level by interweaving it with the Zombie enemy class. Zombies in Quake could only be completely disposed of by use of explosives; if you shot them with a shotgun they would go down, but seconds later they would be back on their feet again chucking bits of brain at you. The solution to this was the grenade launcher (and later on, the rocket launcher). Quake introduced the GL and the Zombies together, cementing their relationship from the very first encounter. The GL was placed in a pit full of Zombies, so after fighting off a seemingly endless throng of indestructible foes the player was rewarded not only with a new weapon, but the satisfaction of gibbing the undead horde that had been such a nuisance up until now into a shower of fleshy globules!

Quake is a lesson in how some creative thinking can make a weapon more than 'just another gun', and actually give it a unique role in the game. This is the sort of approach that can turn a first release from a tutorial demo into a satisfying gameplay experience.

Conclusion

A modular release format has many plus points. Below is a list of things it can do for you:

Sense of completion and achievement for dev team
Every time a team member completes a piece of work there is a sense of personal achievement. One of the keys to successful modding is to set your team achievable common goals that they can work towards in unison. There is one feeling greater than personal achievement, and that's the sense of having worked together in a close-knit group to achieve something bigger than you could ever manage under your own steam. Conversely, when you work on something for years on end with nothing to show to the public it has a habit of frequently bringing the morale of the entire team down.

Self-preservation
Not all of your members will want to work on a mod for more than 18 months. One of the realities we need to face when we put together modding teams is that modding is a reliable route into the games industry. The longer people work on a mod, the more skilled they become and the more chance of them making a career of it. If you keep your release schedules short you give your team members opportunities to leave at the end of a development cycle, you can protect yourself against losing core members at a crucial moment.

Simplified task-management for the project lead
By scaling down a first release, the project lead will have less things to think about (or be distracted by). It will also be easier to keep a track of the mod's overall progress towards it's first major milestone. This means it should be easier to compile a definitive list of tasks for each member to work through autonomously.

Lock down design and features
It is very important to be wary of 'feature-creep' during your mod's development (i.e. when your development schedule is extended indefinitely to make room for endless additional features that will improve the gameplay). These ideas may be good, but the project lead needs to put a cap on these extraneous details and keep them for future releases or there will be no first release. The modular release model is all about getting the fundamental basics right first time and having a solid foundation to build on in future releases.

Focus all members on a similar goal, instead of disjointed tasks
One of the bigger problems of having a more ambitious goal for your first release is that at any one time two members could be working on two completely unrelated tasks. It's important to keep everyone in the team on the same page and for everyone to know what they and the team are aiming for. This will also help streamline internal development: if the programmer knows that a modeler is due to finish a piece and the animator has already finished all his pieces, the programmer knows to set some time aside for getting the model in-game with the necessary animation code, ready for the animator to start as soon as possible. A LOT of time is wasted when team members are waiting on eachother for their next task.

Solid future plans
When a mod tries to do everything at once it can often fail on many levels. When a player experiences a mod that does little well there is no incentive to return. If your mod can get a main feature to play solidly and lay the groundwork for the mod's gameplay, there is a reason for people to keep an eye on the mod. By the time you release you will be able to give some information on future plans for the mod. Wouldn't you prefer the common perception of your mod to be of one that has excelled in a particular area and has demonstrated the know-how to achieve what it claims it aims to do next? If your mod can do this you will retain a much higher proportion of your fanbase versus the mod who failed to ignite and whose next release is almost 100% bug fixes which it may not even get right.

---

About the Author:
LinkedIn Profile

Extra Reading:
Planet Half-Life's Mistakes Mod Teams Make
Valve Software's Mod Release Guide
Valve Software's Tips for a Solid Team