For people and teams developing mods and games with Valve's Source engine.
Next-gen games are coming. As gamers, they mean glorious high-definition graphics. But as modders, they mean enormous increases to workload and time. In this feature ModDB explores how these problems can be avoided while keeping the bar firmly raised.
Posted by Varsity on Dec 1st, 2005
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!
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."
"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.
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:
And the order in which I would implement them is:
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.
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.
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.