Post tutorial Report content RSS feed The Modular Release Model

"Release early and often" - we've heard it before but why does it so often fail? Why do players try an early release mod and never come back? This tutorial aims to address the difficulties associated with releasing early and outline a development strategy to protect your mod from failure.

Posted by on - Intermediate Management

The Modular Release Model

A tutorial on game design and mod management

by Stephen 'Crispy' Etheridge

crispy[dot]pie[at]gmail[dot]com


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

Comments  (0 - 50 of 51)
Aeneas2020
Aeneas2020

nice, maybe i should show this to some of my friends and they'd share my view on this subject :)...great work

Reply Good karma Bad karma+1 vote
BuZZeR
BuZZeR

Cool stuff, I really enjoyed it!
I think the episodic testing for a big SP mods is really working. But I would like to notice one thing - some story details will be spoiled, that's why episode testing should be private.

Reply Good karma Bad karma+1 vote
naveh3
naveh3

a very smart and refreshing article, can take alot of it.

thanks alot and good work!

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

Added a section on 'Weapon-enemy relationships' to the 'Modular releases for Single-Player' chapter.

Reply Good karma+1 vote
Qu1f
Qu1f

Im using that racing dm game. Only joking.

This has been a very usful article you have written, many will learn :).

Reply Good karma Bad karma+1 vote
konradbeerbaum
konradbeerbaum

You left out probably the biggest success for episodic gaming, the Sam & Max series. That is probably the best example of a company properly executing a business plan based on that model.

Other than that, great article. Modular releases seem like the best compromise between the various development models, and the one most fitting for mod development. Heck even the name matches!

Reply Good karma Bad karma+2 votes
StoneyDumples
StoneyDumples

TellTale Games has pulled off the Sam & Max series quite well. They are now appplying the same episodic model to their game Strongbad's Cool Game For Attractive People. It's worked very well for them.

Reply Good karma Bad karma+1 vote
leilei
leilei

Yay for Quake kudos! About time that game is recognized for its brilliance, on a pro-Source site of all things

Reply Good karma Bad karma+1 vote
Halloween4
Halloween4

Another reason why mods don't get released is that modders get sick of hearing the same question over & over again, i.e 'can you give us a release date'.

I've now got a stock reply, which is, 'some time before I die, I hope'.

Don't get me wrong, I do appreciate people taking an interest in my mod, & understand them getting impatient to play it, but the same people have to also understand that making a mod is not a five minute job & some Total Conversion mods take 2,3 or sometimes 4 years to produce, & hearing this same old question again & again can make modders feel pressurised into getting their work done quicker, which often leads to premature releases of half baked mods that are full of bugs that gamers soon complain about, little relising that they are probably to blame for the mod being release in such an buggy state in the first place.

Also:
This same question can make modders feel pressurised to the point of giving up on their mods all together, & many have in the past, & I should know, as I was nearly one of them untill I started not to pay attention & work at a pace that suites me.

Reply Good karma Bad karma+2 votes
Crispy Author
Crispy

A mod is your creation, not theirs. Yes, there is pressure to release from followers, but if you break your mod into more managable modules the fans will be playing the mod sooner and won't have anything to complain about. The trick about deciding what to put in a module is to make sure it demonstrates your core gameplay and that it is simple enough that you can fix bugs very quickly after (and preferably before) release.

This is slightly off-topic, but one thing I have found works with the fans is to have an open-house development style, where you try to explain exactly which parts of the game you're working on at regular intervals. This educates the player so he or she has a better understanding of why it's taking so long. Once fans realise how much work goes into a mod they'll begin to understand how things can take a long time, and you'll get a little sympathy for your efforts.

Reply Good karma+2 votes
Halloween4
Halloween4

I've seen other modders release their mods a bit at a time like this but personally don't like the idea.

Well I suppose releasing a mod in this manner wouldn't make much difference if you were making DMW or DEATHMATCH maps for a game, but I think that this kind of media release can spoil a mod that has got a strong story base, & players can also get annoyed with only being able to play such a mod up to a certain point in the story, especially if the mod maker decides to no longer continue the mod in question. Just think of how many unfinished mods litter the web, it's a sobering thought, & after all you wouldn't keep on going back into a games store to buy your game a bit at a time so that you could finish it would you, as this would be rather complete madness, to say the least ( the very least).

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

1. This isn't about media releases, this is about playable releases.
2. Mods are not games. They are free entertainment.
3. If you've spent 6 months watching a mod, wouldn't you prefer an unfinished mod with a playable section than an unfinished mod that you could never play?
4. The point of this release model is that mods are more likely to release, and mods that release are less likely to die.

"you wouldn't keep on going back into a games store to buy your game a bit at a time so that you could finish it would you, as this would be rather complete madness, to say the least ( the very least)." - MINERVA mod released 4 separate single-player chapters over 3 releases over 2 years, and although each one on it's own was only 30-40 minutes play, it was still thoroughly enjoyable.

Reply Good karma+2 votes
stenchy
stenchy

Although I agree with most everything in this article, it is a lot tougher to maintain an modular/episodic release for a SP total conversion. Aside from the issues Halloween4 raised, you not only have to make new content assets but gameplay scripting, voiceovers that all factor into the continuing narrative.

Minerva had an (arguably) easier time of it because it uses HL2 content.

Reply Good karma Bad karma+1 vote
Halloween4
Halloween4

(1). I do know what this is about.

(2). This comment is just crazy, mods are still games weither they are free or not, unless they are just weapon mods or something like that, that dosen't change the story.

(3). I get fed up with playing parts of mods, never to see the end of the story, as it's a bit like getting into a movie, then never being able to see the end. so no is the answer to this question.

(4). I don't agree as I've seen tons of releases like this, only for the mod never to be heard of again, the truth of the matter is that it's realy down to individuals commitment & determination to their mods that secure a release or not, nothing else.

(5). I certainly wouldn't want to go & buy a game in the store, get it home & start playing it, only to find that the game was short of the ending, with a message saying part 2 comming soon, so why would I expect the same thing form a mod.
Also, there's something that I've notice over the years concerning partial mod releases, & that's it's often a indication that the modders are getting tired of working on the mods, i.e I might as well release the work that I've done upto now as I don't know weither I'm going to continue or not, but they don't say that of course, but 9 times out of 10 you never hear of any progress on the mod again.

Reply Good karma Bad karma+1 vote
mikejkelley
mikejkelley

Yeah, it def depends on the type of mod your making. Modular is better suited for DM, but then again you could adapt it to all sorts to. A story based game could be released incrementally in "chapters" for example.

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

Updated:
- Expanded 'Think Small' section with a personal tip from experience
- Expanded 'Conclusion' section with an explanation of the benefits of locking down your design for a first release
- Minor fixes

Reply Good karma+1 vote
Dragonlord
Dragonlord

Good article. Still the players changed a lot in the last couple of years. While releasing an unpolished proof of concept worked back then ( best example The Ship for HL ) you have a hard time nowadays. People expect finished mods and the bickering going on if you fail to do so is tremendous. Not that I'm in favor of such a stupid behavior but this all has to be watched in front of what happens today. Granted many projects aim very high so I am for a proof of concept release especially to get feedback from players if what you came up with in terms of gameplay really works out the way you planed. Many things look nice on paper but no more once implemented.

Reply Good karma Bad karma+1 vote
Varsity
Varsity

Choosing your game wisely is another part of simplifying the development process. How much better would Empires be today if the same amount of development effort had gone into UT2004 instead of Source?

(The Empires team probably went with Source for its vast playerbase, but my point still stands.)

Reply Good karma Bad karma+2 votes
Wills
Wills

I an 100% on board with the release early and often process. I'm one of the developers for Jailbreak: Source (www.jailbreaksource.com), we started developing the mod 9 months ago, with just two of us, and are about to release our fourth version, still keeping to a small development team (4 now).

Each version we've released, we've doubled our player base, and assembled a community of amazingly friendly and helpful people.

The first version we released consisted of two maps, and the core gameplay. The second, four maps, tweaked core-gameplay, and two new weapons. The third, highly tweaked gameplay and a few new features. The fourth will have all new weapons (17 in total), four new maps, a new game mode, and LOADS of new features.

We really hope that the trend continues this time round, and again we double our player base.

Reply Good karma Bad karma+1 vote
Aeneas2020
Aeneas2020

It does depend a lot on what community you are releasing for however. Source based games tend to be accepted in this manner readily by their community. Some UE2.0 mods seem to as well but when you start developing for more specific games like max payne etc the communities that will be playing your mod seem to be a lot more picky about whats in and where the future is going to be.

Reply Good karma Bad karma+1 vote
smurfbizkit
smurfbizkit

Great article.

However, I can't help but love the irony of seeing an article written about "release early and often" by a guy from the Nuclear Dawn team.

This a sort of "lessons learned from ND" thing?

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

Naturally this tutorial is based on personal experience, either from mods I've been involved with or from mods I've seen come and go in the past.

Nuclear Dawn started off with an overambitious design of epic proportions. I intend to do a retrospective article on Nuclear Dawn for a more detailed 'lessons learnt' perspective, but it would be premature to publish this piece while the mod is still being worked on.

Reply Good karma+2 votes
STPDeveloping
STPDeveloping

Total Conversions are indeed a lot harder. Most people tend to expect something better from a "game", every time a new episode/sequel is released. Total conversions, if done correctly, can make the impression that they're an actual new game.

Reply Good karma Bad karma+1 vote
revility
revility

Our team uses the modular format. We get the main features in there and then release the rest of the content in chunks depending on feedback. I also look at this as the sandbox method because your creating a majority of the assets and features from the start. From there its just picking out your toys, polishing them, and adding more when needed.

Thanks to this method, we've done 1 quake4 mod, and have 2 doom3 mods coming out in the next 4 months. Thats three mini mods done in the course of 2 1/2 years and a total of 20+ levels combined.

Its also easier to keep help interested when the original scale of the mod isn't as large. Modders do it for free and thus can get bored easy or walk away if things get too rough. Keeping your release in smaller chunks and taking it from there helps keep the good help around. Shooting for a 3-5 levels for an sp game is far more achievable than a 20+ level build from the start.

Reply Good karma Bad karma+1 vote
Deathy
Deathy

Very nice article... *thumbsup*

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

I would appreciate if whoever edited my article would send suggestions to me via email or via comment below. I will acknowledge contributions from others (and I will also check them for typos before they go in).

For this person's information I do intend to link to the advice given by Valve, but I actually wanted to find a valid link to Erik Johnson's advice that was given on ModHQ, which is far more detailed and in-depth (but now has an invalid link).

Reply Good karma+1 vote
OOmiz
OOmiz

Excellent article. Probably the best I've read on moddb in a very long time. Really interesting.

As Konradbeerbaum already stated: Sam & Max really has showed that episodic gaming with regular releases can work on a professional scale.

Reply Good karma Bad karma+2 votes
Lucífer
Lucífer

mod teams sometimes are pressured into releasing mods because of a few people wanting a beta asap.
and when they dont get updates they claim a mod dead before the team does, making the team want to release their mod to keep people interested in it.

The Mod Team I can look up to ever is the Empires mod team.
They made their buggy beta release of V1 a long while ago, people didn't like it but they have carried on going, something to admire and look at their mod now!. :D

Reply Good karma Bad karma+1 vote
RammJaeger
RammJaeger

An article with the Mantra "Release often, release early" should be entitled "How to kill your mod and ensure it never makes it anywhere". Seriously, releasing your mod "early" is the quickest way to kill it. The main reason that mods that release early and then quickly die is because teams release a mod that is too buggy, and the bugginess turns poeple off and they never try it again. In other words, you only get 1 chance to make a first impression. Blow that, and your mod is finished.

When we developed Red Orchestra the mod version, we took a different approach. We worked on the mod until we felt it was highly polished, and relatively bug free. The part I will agree with is release often. By that I mean update your mod often. Fans love updates to mods, and getting new content. The days of CS are long gone though, that was a different time. If CS came out today it wouldn't even make a dent in the mod scene. People expect a LOT more from a mod than they did back then. That doesn't mean you have to release a lot of content the first time around. But it does mean you should release at least a few maps, and make sure that it is REALLY polished before you let it out the door.

Reply Good karma Bad karma+2 votes
Varsity
Varsity

The entire point of this article is to suggest a modular development process, hence its title. There's no need for a quick release to be buggy if only a handful of key changes are introduced by it.

If you try to do everything at once then obviously it'll never work.

Reply Good karma Bad karma+1 vote
InterfaceLeader
InterfaceLeader

Great article -- agree with it. As long as the intial release has enough in it to make it interesting, early and often is the best way to maintain interest.

Reply Good karma Bad karma+1 vote
Squeebo
Squeebo

Good stuff! I just know that some people wouldn't play a game that had a good core gameplay if it was really ugly and lacked some cool extra features. Quite a few people, I bet. And PVK2 had good art in it's first release, I suppose... But it was good.

Reply Good karma Bad karma+1 vote
Varsity
Varsity

Got some more extra reading:

Developer.valvesoftware.com

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

Probably applies more to Wraiyth's post-mortem article, but I'll add it anyway.

Reply Good karma+1 vote
Nuka5
Nuka5

This is a great article, and very true. A good example of a mod that released far too early was "Empires" for HL2. Laggy gameplay, terrible player models, more glitches, crashes and bugs than every windows release ever made put together (you could escape the map by rubbing the wall, fit three nukes and six railguns on a tank that's only supposed to have one of each, and even build tanks that GAVE you money for making them if you knew how)

thank goodness the team didn't give up, because the latest release (2.0) is awesome. no bugs, just fun. What i'm trying to say is: if your first release IS absolutely aweful, do not give up. keep working on it and you'll get to a bugless fun game to play at the end.

Reply Good karma Bad karma+2 votes
Crispy Author
Crispy

This is also very true. Perseverence can overcome most difficulties.

Reply Good karma+2 votes
2d-chris
2d-chris

A good read Crispy!

Reply Good karma Bad karma+1 vote
BrotherLaz
BrotherLaz

Releasing early will leave a lasting negative impression if your release has significant problems - regardless of you fixing them in the very next patch. This includes beta releases.

You would be surprised how many people don't bother to give mods a second chance, even years later. Some people are still angry with me because my mod did not have very important feature XYZ (in 2006, and it has been implemented 10 patches ago).

Thankfully Diablo 2 is a fairly timeless engine and old wounds heal in time, but a mod project for a recent engine that needs to succeed immediately or face extinction could get buried if something like this happens.

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

I think I need to write a chapter on what exact qualities your first release should be aiming for (e.g. a few basic, core features that are playtested to be relatively bug-free).

Reply Good karma+1 vote
Crispy Author
Crispy

Also, part of the early-release process is giving indications on what your future aims are. E.g. "Here is our first release, it focuses on one of our core features, 'X'. In our next major release we plan to incorporate features 'Y' and 'Z', now that the groundwork is in place."

Reply Good karma+2 votes
masterofnone
masterofnone

I'd like to testify to modular releases. It is something we decided upon a couple of years ago as The Fourth Age: Total War development team and has enabled us to get out a polished and playable product (currently the only Rome Total War Mod in the Top 100 at Moddb) which has been downloaded over 100,000 times. If it were not for this approach we would still be trying to get the "whole thing" to work to this day I am sure. I wish more mods would follow the advice in this article.

Reply Good karma Bad karma+2 votes
Crispy Author
Crispy

Updated:
- Completely reformatted tutorial into separate pages for improved reading
- Added table of contents (shamelessly copied from Koroshiya_Ichi's tutorial)
- Minor fixes

Reply Good karma+1 vote
Forceflow
Forceflow

Crisp knows what he's talking about. Great read, great write.

Reply Good karma Bad karma+2 votes
Crispy Author
Crispy

Updated:
- Added 'Identifying problematic areas in the core gameplay' section to 'Example Mod: Prototyping a deathmatch racer' page.
- Minor fixes

Reply Good karma+1 vote
Lumpengnom
Lumpengnom

Excellent article. I esspecially like the part about focusing on getting core gameplay to work and concentrating on additional art assets later on.

Reply Good karma Bad karma+1 vote
Crispy Author
Crispy

Updated:
- Re-did all the broken pagebreak/header formatting from Intense's recent WYSIWYG editor re-vamp.

Reply Good karma+2 votes
raxiv
raxiv

Remember that there is one game which succeeded with episodic gaming. Sam and Max anyone?

Reply Good karma Bad karma+1 vote
julz127
julz127

Haven t read it all, but thanks for taking the time to write this.

Reply Good karma Bad karma+2 votes
Soulseker
Soulseker

I would like to work as a proffesional playtester too :P

Probably one of the best jobs in the game industry :D

Reply Good karma Bad karma+1 vote
joey95
joey95

ok

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Tutorial
Browse
Tutorials
Share
Related Groups
Nuclear Dawn developers
Nuclear Dawn developers Fans & Clans with 5 members