Am curious how to budget a team project

Business and Project Management Discussions
#1

How many people does it take to make an RPG? I’ve gone to meetups where there are all sorts of people trying to sell themselves, and some of the roles surprise me. Is there really a need for things like ‘level designers’? It seems to me a good artist and programmer pair can accomplish a lot. But if 3D is involved, maybe it takes a couple programmers because of the need to rig up the art to 3D models? (Having not done this, I may be assuming it is more mystical and difficult than it actually is, or I may be clueless about the complications. My experience is with sound and 2D.)

For the purposes of this discussion, lets assume the target is desktop/laptop computers, and the setting of basic D&D stuff, nothing particularly original. What would be a good lean team, assuming a decent script exists?

This is mostly for informational purposes–nothing concrete, yet.

#2

Have you played Wow? Skyrim? The levels are very huge and there is a lot of areas in the world… So you need a level designer… But if you don’t want to have huge levels a you can do it your self.And it is possible that you do it your self.
Ec9DqrtWcPc
I think he did it all by him self… I don’t know how to answer you question but all is possible. Maybe you will need an artist tome make art while you code, to speed up the process but you don’t really anyone. :wink:

#3

Sometimes artists have expertise in 2D or 3D art, which would be a concern for a team wanting to develop a top-quality 3D game. Also, designing levels can be quite intensive, and having a person or team dedicated to it can speed up the process.

#4

One.

But that’s not really what you’re asking. You’re really asking: How many people does it take to make a good RPG? You might also be asking: How many people does it take to make an RPG with great graphics? How many people does it take to make a multiplayer RPG? How many people does it take to make an RPG in a reasonable amount of time? How many people does it take to make an RPG that doesn’t have any bugs?

And the answer to those questions is: more than one.

From there, there really isn’t a single “this is how many people you need” answer. Every game is different, and every team is different. Maybe one person could pull off a hit (look at Notch or Orange Pixel), or maybe a team of two would be enough (look at Puppy Games).

The scale of everything (your team size, your budget, the time investment, etc) goes up along with your goals. So if you’re thinking about creating a simple one-player Pokemon-esque prototype, then sure, one person can probably pull that off- and in fact, adding more people would probably only complicate the process. But if you’re thinking of creating the next big MMORPG… that’s going to require a much larger team, budget, and time investment.

#5

Refining things here. (Thanks for thoughts and helping me think this through.)

Let’s say it’s a single-person game.

It occurs to me a first version could be something along the lines of “The Banner Saga” (on Steam) as an example of a form which is 2D with layers to give it some depth. Also “Banner Saga” has an alternation between script and puzzles/combat that potentially works for the target project.

I think the key is the script, which if it is strong and has a marketing plan, there will be a chance to raise money via a Kickstarter campaign. I was just trying to get a sense of the scale of the team size and budget.

But by staying 2D with layers, this starts to scale down to something I might be able to program myself, assuming I had a good artist & script. So, I guess that simplifies things. What do I require? (Only I can answer that!)

I should check the credits on Banner Saga to get a better sense of their team size.

#6

You’re still asking the wrong question, as throwing people at the problem (game) doesn’t always solve it faster or better it can just make the process more complicated. Define what you want (the game including, time frame and budget goals) and work backwards to the team size. If you already have a team in mind assess their skills and see if you need anyone to fill gaps.

#7

How many programmers does it take to screw in a lightbulb?

How many do you have?

#8

Exactly. The answer to this question depends entirely on the game, and entirely on the team.

You could be an amazing programmer with amazing design skills, and a single artist might understand exactly the “vision” you’re going for. Boom, you’ve got yourself a two-person team. On the other hand, maybe you’re an “okay” programmer, haven’t ever really designed anything (it’s harder than you might think), and an entire team of ten artists just aren’t really getting your vision. Fewer people aren’t always enough, more people aren’t always better. It depends entirely on the people in that team.

This is why I think that people who start thinking about “putting together a team” before they’ve built a prototype are looking at it backwards. Trying to form a team first is approaching it from the wrong angle. Build your prototype first. That’ll give you a better idea of where you need to focus your energy. From there you can maybe start thinking about adding people to the project.

#9

Thanks for inputs, all! Understood, about team building being very varied. I’m thinking, the equivalent of a prototype will come from a script being developed. I am going to advise the “client” that the first step is to take his “curricula” and work a significant segment of it into a form (kind of like a film script with visual information, and puzzles built in) where it is easy to visualize and the entire project becomes more real.

In addition, I could see where it might be necessary to build mockups, if a mechanic is at all unique. For some segments, for example, a simple variant on a “hidden object” puzzle (highly likely to be included), these might be easy enough to visualize.

I’m surprised that the differences in programming between something like “Banner Saga” (multi-layered 2D with set scenes, dialogue screens with choices, and intervening puzzles) is not considered enough information to give a range of estimates. Especially, when contrasted with trying to implement 3D which to me seems like it would automatically add significant complications and extra work.

I meet with the “client” (using the term loosely!) tonight for Pakistani food. Things are at a very exploratory stage.

Long ago, I worked as a team coordinator for a game company that employed about a dozen people. I think something like 8 or 9 games/apps made it to market. We had a couple programmers who primarily implemented our game-enabled FORTH onto various desktops, and others who worked primarily on the games. (Program once, implement on many!) We are talking about computers that boasted of having 64 KB of RAM, mind you! I made a game while I there, called “Laser Tanks.” The boss came up to me and handed me a roll of quarters, sent me to an arcade, and said, come up with a tank-themed game. But as a team coordinator, I occasionally had to put the game aside and work with the “core” team as they were getting frazzled. For example, I ended up being the main person who installed and got some software running that converted 8080 to Z-80 assembly language (despite having only a smattering of assembly language programming experience). I was also a main intermediary that helped coordinate common game features and sharable code in the team, and tracked time estimates and kind of helped people along.

This experience (which I viewed as overall positive despite the long hours) and an overly healthy “can do” optimism leads me to venture into projects that are sometimes over my head.

I like the video from GNecro1, in that one can see many important stages or components of the larger project dealt with in turn. Nice find.