Managing a Mod Project - by always_black

Posted in _blackbox by Administrator on the October 6th, 2004

In March 04, for reasons I still don’t fully comprehend, I was invited by a net friend to go all the way to Melbourne (Australia) and speak to a seminar about the mod I worked on.

The seminar was part of an independent game developers conference called Free Play, in turn part of the wider Melbourne arts festival called Next Wave. When I heard the offer I started all the metal processes to dismiss the idea as too expensive/too far/too wild and then suddenly overode that and decided to quit playing safe for once in my life. In an explosion of recklessness and disposable income I bought a plane ticket and went and had an adventure. This isn’t the story of that adventure.

I keep meaning to write all that up in some kind of travelogue but every time I sit down to record it, it still seems too big and I can’t find the words.

I was a little bit unsure of what the seminar was supposed to be, other than the title, “Managing a Mod Project”. It still seems a bit presumptious of me to take that mantle on, as mentioned elsewhere on this site my ‘management’ role of the single mod I’ve worked on consisted of overseeing the last deperate attempts to finish the first part of the first episode of The Cassandra Project. On the other hand when it comes to cataloguing mistakes to be learned from, I decided I probably had enough experience to do that well enough. And as I said, I was due an adventure.

I did know that I might be doing it panel-style but that was still unconfirmed when the date rolled around to get on the plane. To be on the safe side I wrote some notes and made up some slides as if I was going to give the entire 20 minute presentation by myself.

In reality it turned out very differently. I was near-paralysed with nerves about public speaking exacerbated by the kind of jetlag that you can only get by travelling as far as you can without leaving earth orbit. My co-speaker, none other than Damian Scott, one of the original Team Fortress team, came to my rescue by being a university lecturer who, as he put it, talked shit for a living. He carried my ass all the way through the entire experience for which I’ll be eternally grateful, even though it turned out to be not nearly as terrifying as I imagined.

So the presentation never got presented and I found it sulking on my hard drive the other day. I’ve tidied it up a bit to be more suited to reading straight and edited out some of the more inane margin notes.

Slide 1 – The Cassandra Project

The mod I have worked on is called The Cassandra Project, which is a mod for Deus Ex by Ion Storm.

It’s an episodic, single-player story set in a much closer future than the original Deus Ex and up to now we’ve released one episode.

I’ll explain a bit about the mod in a sec, but first of all, I want to introduce the core members of the Cassandra team, mainly because at the moment I wish any one of them were up here instead of me, but also because whatever The Cassandra Project became is down to the hard effort, late nights, sweat and various other bodily fluids of these people.

Slide 2 - Kieron Gillen aka BremXJones

Kieron Gillen, he’s to blame.

Kieron is the award-winning ex-deputy editor of PC Gamer UK, now working as freelancer also expanding his music journalism and writing scripts for comic books.

The Cassandra Project was Kieron’s idea and he wrote the 30,000 words of dialogue that make up the script for the first episode. That’s not including the text for the books and other incidentals.

But he did more than just write the dialogue. He created this world that the characters that appear in the Cassandra Project inhabit.

He also assembled the rest of us and worked on the conceptual and organisational side of things, but the actual in-game machinations were more the domain of…

Slide 3 - Colin Cobb aka ColCob

Col was a student of architecture, head mapper and lead design. Having an architect as your level designer is a double-edged sword. On the one hand you’re getting levels that are rationalised by a guy who knows what he’s doing.

On the other hand only an architect could spot some of the things that Col condemned as faults, I mean, I have no idea when a particular support is obviously the wrong thickness for the material it’s supposed to be made of but Col could and got really irate about such things.

Eventually something terrible happened. He and his wife had a healthy baby son.

Actually that wasn’t so terrible. But it meant that Col couldn’t spend the time on Cassandra that he had previously.

Management of the project defaulted to me, mainly because I was louder than any of the others.

Slide 4 - Tim Fletcher aka Dungard

Tim was the Cassandra Project’s only coder. A man of infinite patience and pretty much managed to beat the scripting into everything we asked for as well as contributing greatly to the design of the mod itself. Wherever we modified the original games mechanics it was usually Tim’s idea to start with, based on what he thought he could do with the code.

He’s now enjoying highly warranted success with his Neverwinter Nights module, Maugeter.

Slide 5 - Matthew Carter aka FiveEight

Matt Carter was Cassandra’s modeller, now doing a bit for the Nightblade guys, I think. A staunch perfectionist and always his own biggest critic I think FiveEight was the least flaky of all of us, always did what he was supposed to, always did it when he said he would. When you recruit a team that’s the kind of guy you’re looking for.

Slide 6 - The Rest

These are the names of the other people who helped us out during the three years or so it took to make Cass Episode 1. Some of them were artists and levelmakers, others were things like music and voice talent, but all of them came and went, drifting through.

For some of them, they had a limited role to play anyway. We didn’t voice all of the lines so the voice actors just had to do their little bits and that was that, for example. Some of the others were supposed to have a more extended role but just didn’t deliver for one reason or another.

The worst thing you’ll face if you have to manage a mod project are those people that don’t have the guts to admit either to you or to themselves even that they’re just not interested any more.

Situations like that can leave you waiting weeks, months even for media that just isn’t coming. And you can’t assign that work to anyone else because then you’ll have to call the original team member a liar.

So that is and was the team the made the Cassandra Project. This is the only mod team I’ve had any experience with, so any advice I can give you on how to manage a mod team is based only on the lessons I learned in those special circumstances.

Slide 7 - Managing a Mod Project

So, we get to the point, managing a mod project. Now this is supposed to be a discussion session so I haven’t gone into as much depth here as I could’ve done. Instead I’ve summarised a few things that I wish I’d known before I got involved with the Cassandra Project.

Slide 8 - Make a Plan, Be Specific, Stick to The Plan

Take your ideas and start to figure out how you intend to make them into a reality. Sounds obvious, but it’s easy to get romanced by the creativity of the idea and push the practicalities to one side.

Pinpoint every model that will have to be made, every sound effect you think you’re going to need, if you intend on adding a new conversation system to the Source engine, figure out exactly what might be involved.

Once you’ve drawn up your plan, swear a blood oath to yourself that you’ll stick to it, no matter what. You won’t stick to it, of course, but it’s the frame of mind you have to establish.

If you deviate from the plan it becomes a concession, one you might be able to think of a way of avoiding, rather than the normal way you run things.

It’s easy to fall in love with an idea and let it run away with you. One of the biggest problems we had with the first episode of Cassandra is that we let new ideas excite us without realistically considering the impact they were going to have on our stretched out resources.

Be realistic.

Slide 9 - Do it Yourself

I’m not kidding. If you can find a way to make your mod a solo-effort then it’s probably a good idea. Trying to recruit a team of people and then trying to keep those people recruited can be a real headache that can rapidly suck the fun out what you’re trying to achieve.

If you don’t have the skills you think you’ll need, then consider learning them rather than recruiting someone else to do it.

Even if you do end up with a team the ability to multi-task and fill in gaps on demand is invaluable. And more team members doesn’t necessarily mean that the work will get done faster.

And recruiting is hard if you have no credibility to make your project look attractive. A bit of a reputation can go a long way in bringing in serious volunteers, so it may be worth your while creating a few levels by yourself first.

Slide 10 - Find Team Members You Can Afford

If you really feel that you can’t possibly manage to make your mod by yourself, you are going to have to start looking for a team.

It might seem a bit odd to think of ‘affording’ staff in the context of a mod project. After all, everyone is supposed to donate their time free of charge, right, that’s the nature of the game.

The thing is that no-one worked on the Cassandra Project for free, everyone expected some form of payout, whether that was in an increase in reputation, the realisation of their ideas, or even just an equal share in the work, for example the initial plan for Cassandra called for very little in the way of new meshes, but FiveEight obviously wanted to play as big a part in the making of the mod as anyone and wanted to stretch his modelling skills, so more custom meshes got added to the list.

Something like that is going to present a real quandry to you. On the one hand you might need the modeller and his skills to meet your plan but to pay for that you’re going to have to give in a little to his own wants, which in turn is going to have a knock-on effect on your development time.

The more people you recruit the more likely it is that the payout they are looking for is going to cost or change your project. So bear that in mind when you do start looking for people, be prepared to compromise and understand what that compromise will mean to the end result.

Slide 11 - Assess, Evaluate, Be Ruthless

Remember the plan? We didn’t. In fact, I have to hold my hands up here, because I was as guilty as anyone, OK maybe more so, of adding new things and trying to implement new ideas as we went along. We got stuck in a loop of creating content and coming up with more and more ideas and every time we ran into a problem we couldn’t solve we always seemed to think of something else to make to cover it up.

What we should have done is stuck to the plan. And while we were working we should have been assessing that work against the plan, evaluating it.

We should have been ruthless. Only at the end, when we were very, very tired of the whole thing, did we eventually say things like:

“That’s taking too long” or “That isn’t worth the effort it’s costing.”

By that time people had a lot of emotional investment in stuff that got canned and I’ll admit that some people got upset about it. It’s going to happen, but it’ll be worse if you don’t keep assessing and evaluating your progress from day one.

Nipping creeping features early is less painful than throwing stuff out at the end when you realise it’ll never work despite the months of effort you’ve put into it.

Slide 12 - Set a Date

This is critical.

The Cassandra Project always had a very bohemian attitude towards productivity. We didn’t set any targets or deadlines, we thought that since we weren’t getting paid then we’d spare ourselves the discipline. After all we were supposed to be doing it for fun, yeah?

In the last few months we realised that unless you actually say when it’s going to be finished then you can just keep on working and working and it’ll never be as complete as you’d like it to be. There will always be another texture to tidy up or another decoration to add.

So set a date. Not just for the completion of the end result but set little minor dates too. Maybe nothing so grand as a ‘milestone’, but just agree amongst yourselves that a particular model will be finished by a week on Thursday, for example.

You don’t have to get all grumpy if it isn’t actually finished by the date you set, God knows we missed every single one. But what it does do it put the idea of ‘finishing’ in your mind instead of leaving it open-ended. Instead of sitting down to watch the TV, it’ll nag you at the back of your mind that you are supposed to be working on a certain element.

Slide 13 - Don’t forget to enjoy it.

I’ve said some pretty negative things so far, a lot of criticisms of the way things turned out with Cassandra and you might think that I had a pretty rotten time of it.

That’s not true, working on Cassandra was one of the best things I’ve ever decided to do. The end result in the shape of the first episode is pretty short and it’s barely more than an extended briefing sequence really, but when I play through it and see how it took shape and remember all the little battles we fought together, the ones we won and the ones we had to concede and just the sheer cameraderie of it all… I’d do it all again in a heartbeat.

Well, maybe after a bit more of a rest.

The End

Comments on the blackbored