Surviving Next-Gen Modding feature

Half-Life 2's game source code, from which all mods are made, is approximately ten thousand lines
longer than Half-Life 1's. Its textures are four times as large, its
models have thousands more polygons and its scripting is several times
more complex. Looking at the finished product it becomes very clear that
these increases are worthwhile, but what does it take to get to that
finished product? You would have to be actively ignoring the news not to
have not heard the concerns developers have been voicing over the extra
work, pressure and funds next generation game development needs: where
does all that leave us?
While mod teams don't usually have budgets to worry about, a rag-tag
team of modders working in their spare time will be and are hit far
harder by the increasing demands of content creation (modelling,
texturing, mapping, even sound to some extent) than any professional
developer. But fear not! There are solutions, and we will be covering
three of them in this article. One focused on mod management, one on
gameplay design, and one on content creation.
Armed with these, you should have everything you need to survive the
next generation. But the ideas are just that – ideas. They won't suit
everybody, so don't be afraid to come up with your own!

Management: Iterative Releases

When I read ModHQ's interview with Erik Johnson, one answer stuck in my mind and has remained there ever since:

"I think the real mistakes are happening on the
individual MOD teams themselves. They are becoming far too hesitant and
conservative in their approach to how they design, develop, and release
their games. If you go back and look at the first versions of
Counter-Strike, Team Fortress, or Day of Defeat, you'll see rough games
that focus around a single game play idea. The first version of Team
Fortress for Quake only had 5 classes, and wasn't even a team game. In
the first version of Counter-Strike, it was virtually impossible to tell
the CTs and the Ts apart. The goal of all MOD teams should be to go out
and learn from the community as to whether or not your game idea is a
good one or not, and plan on releasing as often as possible. Right now
it appears that too many MOD teams believe they have to build the next
huge hit with their first release, which is a plan that is pretty likely
to fail. [Successful mod teams] shipped as fast as they could and then
continued to ship and ship and ship. [They] measure their success after
each release and use what they learned to form the ideas for the next
one."

Popular mods are often the ones that released fast and often.

"Sometimes," Erik continues, "it feels like the MOD community is
becoming more and more like the 'professional' game community...MOD
teams that are approaching building games from that perspective are
throwing all of the advantages they have out the window, and are just
competing with every other game developer in the world". And do you know
what? He's right. Mod teams are throwing their advantages out of the
window with this megalithic approach. Not perhaps all of them as Erik
suggests, but certainly many of the important ones that can make or
break a project.
Take a look at the major mods for your favourite game. How many of
them released early builds with only the key gameplay elements that they
then consistently built on? Are those mods more popular than the ones
that waited for a complete release? Garry's Mod
began as nothing but a buggy and confusing ragdoll poser, but is now
immensely popular, feature-packed, easy to use and an established part
of Valve community culture. Version 9 (the mod's twenty-second release)
saw a first-day peak of well over 1500 simultaneous players and now chugs along at 500 or more each night; yet release of the highly anticipated Dystopia demo saw 1300 players, and the demo can today muster 160; an impressive but considerably smaller number.
Are these figures a reflection of Garry's Mod's quality? No, at least
not directly: Dystopia is very well-produced and a lot of fun, as is
Garry's Mod. It is a reflection of making nine releases when another mod
has made only one.
Nine releases is nine times to act on feedback, nine times to make
the news, nine times tempt new players with an installer, nine times to
fix your mistakes and nine times to add major new features. But above
all else, your mod is in the public domain nine times sooner.

Design: Rapid Prototyping

Think back to the very beginning of your mod's development. If you haven't ever made a mod, try to look wistful.
How long did it take you to get a working build with your gameplay
mechanics in place? A week? A month? Have you still not got them all
running? 'Rapid Prototyping' is the process of laying down the
fundamentals of your gameplay design in a few hours, perhaps even
minutes, ready for people to try out. The most basic gameplay elements
are banged out with no attention to presentation, feedback is taken,
another prototype is made, and the cycle repeats until you have all the
elements in place and are happy with them.
Perhaps the easiest way to understand Rapid Prototyping is with an example. Earlier this year game design site Lost Garden featured an essay where the site's writer, Danc, relates his experiences while prototyping The Secret Life of Aliens.
Give it a read, or at least scan the piece's structure. Each prototype
is made as quickly as possible, then it is playtested and the responses
noted down. The bad changes are improved or removed, and the good
changes are built on. Danc stopped after the fifth iteration for
brevity, but you will likely go on for far longer.
It's all very well for Danc and his friend coding away with their
industry-grade studio tools, but modders don't have access to that sort
of software, and compiling a modern mod project takes several hours. Add
in the time it takes to make useful changes to something tens of
thousands of lines long and it's not exactly what you might call rapid.
There are solutions, and the best for mod teams right now is Garry's Mod, which since version 9 includes LUA scripting
(modders for other engines are out of luck at the moment, I'm afraid).
LUA has a similar structure to full programming languages like C++, but
doesn't need to be compiled and, in Garry's implementation at least, can
be applied and re-applied to a running internet server without so much
as a restart.
In a perfect world the core gameplay elements would be laid down in
order of importance, one per revision, but the prototype must also be
efficient. Adding features that rely on anything but the simplest of
content is asking for trouble and at the very least a waste of time.
Build them into prototypes by all means, but don't try it with the rapid
ones! To demonstrate these guidelines, let's do a quick prototype plan
for Dystopia. Dystopia's core features, excluding those shared by all shooters, are:

• Class-based gameplay
• Alternate 'cyberspace' gameworld
• Interaction between players in the physical world and cyberspace
• Selectable implants that enhance or add abilities
• Objective-based gameplay

And the order in which I would implement them is:

1. Selectable implants
2. Classes
3. Objectives

Selectable implants are a key feature and should be implemented
first: if they aren't fun, there is little point in carrying on! Ideally
each of the planned implants should be added, but this is not possible
if we are aiming to be rapid. Adding a UI to choose whether to have
simple stat tweaks (faster, stronger, more accurate, etc.) is a simple
task that captures the principle behind the feature, exactly what Rapid
Prototyping is about.
Next up are classes and objectives, established shooter features that
are more likely to go well. Classes come before objectives because they
tie in with implants.
Notice how the other two features, interaction between players in the
physical world (or meatspace as it is known) and cyberspace and
cyberspace itself, have been left out. Both features are heavily
dependent on the map and can't realistically be implemented without a
large amount of effort and content creation – and thus time. The Rapid
Prototyping system has its limitations and it is important to recognise
them.
Update: You might also find this Gamasutra article interesting.

Content: Stylised Visuals

So you've got the first iterative release of your Rapidly Prototyped
design out, and the people who have taken the plunge like it. Now you've
got to build the content to go around the gameplay and make your mod
ready for the prime-time. This is where the next generation really hits
modders. How can we create new content that sits alongside any existing
resources we use, or in the case of TCs create content that lives up to
the original? You could re-use as much existing content as possible, or
settle for outdated-looking visuals. Both are perfectly reasonable, but
wouldn't make for an interesting article. I'm going to introduce a third
option that modders, of all people, use surprisingly rarely: non-photorealism.

Taking a brief tour of ModDB's image gallery,
I clicked on about fifteen random pages and of the screens with new
content, a total of one that wasn't trying to look realistic. You can form your own judgement here, but I'm sure you will come to the same conclusion I have. Even with one image, Rbotz
stands out a mile. It shows how you don't need the most spectacular
models or detailed textures to make something memorable and fun to look
at, but it also demonstrates how the approach can go wrong. The guns
held by the models are based on real-world weapons and look blocky and
ridiculous: if you are going for a visual style, whatever it is, make
sure you go all the way!
There are other pitfalls. The gaming masses typically respond poorly
to non-photorealism, particularly the more abstract forms. That might
not bother you, but then again you might be making a mass-appeal game
and can't afford to have that sort of reaction. Without the restraint
and focus realism usually provides you may also find you/your team are
producing fluff - and if you avoid all those, you could have chosen a
design that, bluntly, isn't any good.
But the payoff when it goes right is spectacular, and what's more
efficient. Your mod immediately stands out from the crowd, and you can
afford to make much, much more content than any attempt at realism would
allow; making your own visual style isn't easy, but it is hard in ways
that aren't quite so time consuming.
Of course, you might have the manpower and time to make realistic
content for next-gen games. And good for you! But the rest of us aren't
quite ready to set targets that high, perhaps today and probably
tomorrow, and abandoning photorealism is solution that has seen little
exploration.

Conclusion

With the increased complexity of next generation games, and to some
extent today's, adapting the way we work is vital if modding is to
remain an accessible hobby. Whether or not you agree with the ideas in
this feature, one thing is certain: there must be change. The way in
which we mod is the demise of many a team as it is, and this will only
get worse as time goes on. While there is no denying the value of
'professional' mods, nor the effort and dedication that goes into them,
it is the less ambitious projects that keep modding alive. Lose them,
and the system will soon close in