When speaking at the hobbyist level, people wear many hats indeed. But the capabilities of each type of member really depends entirely on the individuals. At least, whenever I've looked in the past. I am not particularly successful, but this is what I've gathered.
Here's my 5-in-morning brain-dump on the topic, however. You need most of the following things (these roles might be combined into a few individuals. I've pluralized these, although you might only have one of each role between your team):
- Designers/idea people. A person who comes up with ideas and key concepts that comprise your game.
- Ideally, this should be everyone in the team, so all players in your team keep interested, and they should each have a say in what sort of game is made in their own way.
- Be careful. Make sure that people can agree to a general concept, and talk it out until the idea makes sense. Try to get every on board here, since a clear idea is tremendously important in making sure tasks go like planned.
- Artist.
- You can wait on this (placeholder art or programmer scribbles), but your ability to make certain kinds of progress can be severely hindered without the ability to create the intended visuals in-game. Especially if you require that sort of visual feedback to keep yourself motivated. Also, art is definitely a large marketing point of most games, and good visuals and eyecatching screenshots will pull in an audience.
- Musician/Audio Person
- This can also be waited on. Arguably audio can be less "important", as is evident by certain games completely foregoing sound, but it still has a huge impact on the feel of the game, especially the musical soundtrack. It is worth finding a capable musician.
- Programmers/Scripters
- Vital! The game's events and logic need to be programmed to an extremely large degree. Whether this is low-level system control, or a script written in a cookie cutter game maker tool, someone needs to program the scenarios. This tedium is real and necessary. Lack of programming skill bites you in butt, as you are constantly finding yourself limited in what you can do with the tools you can manage.
- At the same time, having bountiful programming skill can be a curse of its own. Suddenly there's a desire there to overcomplicate simple tasks and worse yet, they might waste time writing engines instead of writing games (speaking from my own pitfalls).
- Even tools like Construct technically have you "program". Whether you do it explicitly in a language or in some sort of tool that does it for you, you need to control the execution and flow of the game. This is a tedium to be expected of most if not all games.
- You need balance. Rushing out code ends up in bugs and a mess that cannot be maintained. On the other hand, slowly fleshing out engines and systems for stability are useful, but eventually you need to release something.
- Pre-existing tools are out there for a reason, but they have restrictions. You might be able to get a way without a "systems" programmer, but you might not. It entirely depends on the scale and type of the project. The closer it is to an existing system, the easier a time you'll have. But to make more "innovative" things, you may find yourself with cheesy workarounds and starting at least remotely from scratch.
- Mathematicians/Statisticians
- If your game needs math, or needs math and you don't realize it yet, you need someone knowledgeable (or at least know how to use the Internet) to consult about problems. Ranging from geometry and trigonometry, to data compression, to balancing damage distributions and levelling curves in RPGs, collision detection, etc. Depending on what you end up doing, math is required. Not always, but often. Keep it in mind when you run into a problem, don't just run away in panic.
- Writers
- Depending on the type of game, you may need a competent word-smith to captivate your audience. A person who's good with plot twists and clever prose, to use for scripted dialog, descriptive flavor text, introductions and whatever else you need.
- A writer for your design documents (if any) might also be nice. This style of writing should be much more explicit and technical as required to avoid ambiguities and problems. This all depends though. Not every team needs this, and you can sometimes dive right into the game-creation parts without writing a document or even a to-do list. Just keep it in mind. This person is likely a programmer.
Keep in mind that one team member in a hobbyist team will likely fill most of these roles.
As a personal rule, I find that I am typically the programmer, and I find assistance with artists and musicans. Occasionally, I'll call on a second or third programmer to help speed up the flow. The writing and design things are handled by every team member. Mathematical people are likely the programmer-types as well. But beware, not every programmer is tremendously good at math, some just know enough to get by. Overlap in design roles is especially critical, in my opinion, to keep everyone on board.
It's best to either not depend on people to do their part, or to only depend on reliable people (with whom you hold great confidence), since projects can fall apart due to one person not doing their part. As has happened so many times to me. This means that you might find yourself wanting to learn things on your own -- however, this leads to lots of time wasted learning skills you wouldn't need to learn if you were in a team (and now they can't be done in parallel). Be careful.
Your own experience is the only true guide for this sort of thing, and your first few encounters with hobbyist development will probably not yield anything (it's disappointing, but as far as I can tell, fact -- but never get discouraged, as you learn valuable lessons along the line).
Well hopefully somebody finds this interesting, I might end up disagreeing with myself later, since I was sort of trailing off midway through writing this, but I kept with it, even though it was 5am. Time for bed.
