Need help convincing a design guy to tune down the scope of his project.

Here's my advice-take it or leave it.

Try to get your 'idea guy' to break the 'big picture' down into smaller phases, or deliverables as they're called in the software biz. For example, if your guy wants Natural Selection, a simple breakdown could look like this:

Phase 1) Development of Marine weapons
Phase 2) Development of Alien models and functionality
Phase 3) Development of Commander functionality

You would probably want to take this even farther than my example, breaking down each phase to smaller levels.

Now you, as the code grunt, give a ball-park estimate of how much time each phase would take you to code. You and your team pick and choose what items to implement, buying them with the available time you have left before the deadline (always add in a significant ScottyFactorTM for unexpected delays). Perhaps in doing this, you can get to a compromise point where some of the 'big picture' is realized, but you don't have to give yourself a 45 caliber ear ring to do it.

Besides, this approach helps you break down seemingly humongous tasks into more managable pieces. If you design your phases well, you can even use them as beta release points.

Big picture is made up of small pictures. I tend to concentrate on smaller chunks and then build from there, that way I get a product out there quicker, or something I/public can test and use quicker.

Mods that have a production line similiar along to these lines will eventually dissolve with the resolve of not even making anything in the end.

In addition to breaking down your big picture into smaller tasks, I'd have a series of release dates that would consist of an alpha version of some chunk of what you're doing. This could be a weapon pack of all the weapons in the game (or all the weapons for one team) released as a mutator, or it could be a series of mutators that showcase various ideas that will be in the final version.

For instance, if you're going to have some RPG elements (experience improvements or whatnot), make a mutator that is 90% what you'd need in the final project. That way you can sit down and say, "This is what I have so far, assuming the same rate of development, I'll be done by about this date." If it happens to be past the enddate for the contest, tough for your teammate. You aren't saying, "It can't be done so I'm not going to try," which will make him mad, but you aren't making any promises about completing the mod in time.

I'd agree that the scope seems pretty unrealistic, especially considering the size of the team and the scope of the project.

That doesn't mean that a cut-back version wouldn't be workable, though. Maybe if you focused on one of the hybridizations you were talking about, and see where you are (time-wise) when you finish. Maybe work on the RTS part first, creating a base-building system. I wouldn't go so far as Natural Selection, though. I'd do something more in the vein of Battlezone with click-and-drop buildings rather than NS's overhead view.

If you're at February with half an RTS game built, then say, "Oh Well" and keep building. The likelihood of winning is pretty slim, especially considering that you're inexperienced and you're sort-of doing a port of a Half-Life mod.

Having previous programming experience helps you to get into UnrealScript, but what you actually need to be a good UnrealScript programmer is loads and loads of UnrealScript coding experience. That, in turn, you can only get by coding a lot in UnrealScript. UnrealScript language syntax is for the most parts close enough to other languages to be simple for anyone with programming experience; effectively using UnrealScript's features and the class API of the game is where the challenge is.

I suppose it's possible to pull this through in the given time frame, but then again it's just as possible that it won't work out. I know too little of your capabilities or your designer's ideas to say anything more definite. Prepare to spend a lot of time running into dead ends. Don't put all your hopes on the contest, or you'll be devoid of any motivation should you not manage to make it for the contest deadline (or not on the level of quality you originally figured; it's always possible to churn out something subpar for a fixed deadline.)

On a personal note... if your lead designer's only area of expertise is being able to make good maps, I'm not sure why he/she is doing the "lead design" job of this mod. Having loads of ideas is a poor qualification for a lead designer if it is not backed up by a good feeling for how to go about implementing those ideas. Tell your lead designer that you, as the coder on the team, wish to work on the mod's design together with him/her on equal footing. (And always expect to change part of the specifications once you learn how to technically approach a certain part of them.)

My opinion:

Making big mods is a A LOT of work!!!
To make an average mod, i think it's best
to have 2-3 dedicated & experienced modders.
If you have too many ppl you might get into
too many disagreements (due to human nature),
and if you have too few there's too much to do.

When you have that big mod you need to split it into phases:
1) basic gamecode, weapons, maps
2) normal gamecode, player models, more maps
3) advanced extra super bug-free gamecode with 1000's of features,
and amazing looking pro maps

If you dont finish the 1. phase dont go to the second,
or else you might never finish anything.
There's a chance you might loose patience after phase 1, and never go to 2.
If you dont follow the rules above that means that you may never finish anything.

This is a good topic guys, can we not turn it into some grudge match?

A few more thoughts Nickel:

nickelplate said:

Now, I'm feeling like my friend is way overconfident in our abilities, considering this would be my very first mod project, and he's been doing some mapping for a long time, but never participated in a mod himself.

Click to expand...

That is a good feeling and one that's rarely wrong. More mod concepts have been killed because someone wanted to do something ubersupercool as the first thing out of the gate. Start small, but do it in a way that anything you learn might be carried over. Make a sandbox project, like one player model, one weapon model, one map, one unique gametype. Once your designer realizes that the "real" project will be 100x more work than that, he might change his scope.

He is in charge of writing a design doc but hasn't sent anything yet, everything is pretty much in his head for now.

Click to expand...

Don't let him get away with that. Writing things down is essential for a team.

We had a meeting last week, and he said something in the lines of "codinging a character/multiclass system would be relatively simple", which made me wonder if he even had an idea of what he was talking about.

Click to expand...

The only people who can answer how simple something is to code is coders, and you can only trust them half the time.

Is it exaggerating to say that a team shouldn't attempt such a mod as a first project, most of the team members or potential members being new to the modding scene? Have you encountered similar problems? How did you deal with them? Was it inappropriate to start this thread here?

Click to expand...

Other than what's already been said, I would say this: you can either have a mod that has everything in it that the team wants and a schedule to try and release it or you can have a deadline.

In other words, you can say "I want A,B,C, & D in this mod and I hope to have it done by March"

Or you can say "We have to be done by March and I'm only certain we can make A & B by that time"

RegularX said:

This is a good topic guys, can we not turn it into some grudge match?

Click to expand...

I second that.

[edit]
The grudge match has been split off into this thread.

Most of this has already been stated. Humor me.

Past experience has shown me that the programmer should NEVER be the one to design a mod. Sure, he can code it, but if you want the mode to be simple and make some sense, get a creative guy to do it.

Mod mod concepts, as has been somewhat mentioned, die for two reasons:
1) The "scope of work" is ludicrous. "I want to create a mod that has 67 weapons, 18 different game modes and 107 maps. Who's with me?"

The SOW can be arguably ludicrous, but you have to do it piece by piece. Sure, the whole SOW might take you three years to complete, but if you do it in phases and release some content in the meantime it isn't as bad.

2) The "lead" doesn't generate any actual content. "I got this great idea for a mod and need a team to do it. All I need is a mapper, modeler, texture artist, programmer, sound engineer, hairdresser and liontamer to work on it..."

The "lead designer" doesn't have to be able to actually do every aspect, but he has to be able to at least understand it and, IF NECESSARY, do things that others can't. I'm primarily a code, but if need be I can find my way around UnrealEd or 3DSMax. Sure, it might take me a lifetime to create a decent looking cube, but at least I understand the concepts.


There are two levels of a design document:
1) The "conceptual design". What you want to do, but without specifics.

2) The "technical specifications", or how things are going to be done. This may not have to be a document per se, but it has to be in the mind of the programmers. They are ultimately the ones that decide whether something's feasible or not and can determine how long it will take - because of that, coders have almost absolute veto power over any element in the design, but should be open to compromise in that the design might have to be changed slightly rather than eliminated altogether.


If you're creating a mod for the first time, start small. You can have a huge design document, but don't expect to complete it all in one shot. Set yourself up some "milestones": for instance, if you plan five game modes, work on one first. When some simple functionality is available (one game mode, a few models, one map), you can make the decision to either release as "Beta" or continue development. Trying to do the entire design document all at once leads to chaos because of the disorganization it brings and also causes the mod to take much longer to be playable.

Nighthawk[Opera] said:

Past experience has shown me that the programmer should NEVER be the one to design a mod. Sure, he can code it, but if you want the mode to be simple and make some sense, get a creative guy to do it.

Click to expand...

Many coders I know are creative guys; don't slam an entire group of people just because of your own past experience. (Pure code monkeys perhaps aren't, though.)

Good coders have a good feeling for user interaction and how to make things simple and easy to use. Inexperienced coders tend to quickly get into feature creep designing something because they don't know where to stop abstracting things.

I do agree to most of the rest of your posting though.

The most important thing is that you find an arrangement which you enjoy working in.

Actually, my experience in software development in general is that it's engineering reeling in creative ... not the other way around