In the industry, people with various skills and talents all work together on a team. They are most often specialised in their field.

However, this is unpractical for a hobbyist team. All people in such a team need some skill in various fields and people have to wear many hats. Which skills are crucial for an average hobbyist team (without taking any game specific details into account)? Detail some tasks that people with such a skill would be required to do. What other skills are usefull but not necessary? Are there any skills that can more easily be combined (for example, the game designer can more easily do the marketing then an artist?).

A good answer to this question can be used to complete a team, based on missing skillsets or available time of current teammembers, or just to get more insight of the dynamics of a hobbyist team.

  • \$\begingroup\$ Although downvoted, I would like to thank everyone who answered so far. Some good and useful considerations were made! \$\endgroup\$
    – Nef
    Aug 17, 2010 at 13:43

5 Answers 5


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.

  • \$\begingroup\$ Thanks, it's a good overview and I liked the part on reliability. The bottom line can be that anyone might need to fulfill a certain task at one point or another. \$\endgroup\$
    – Nef
    Aug 17, 2010 at 13:44
  • \$\begingroup\$ "Also, art is definitely a large marketing point of most games, since good visuals will pull a." Did you fall asleep? :-D \$\endgroup\$
    – Ricket
    Aug 17, 2010 at 15:25
  • \$\begingroup\$ Whoops. Yes. I apologize, I was falling asleep. D: \$\endgroup\$
    – Overkill
    Aug 17, 2010 at 17:56
  • \$\begingroup\$ Excellent post :) Glad to say after 13 years I can competently cover all those roles. \$\endgroup\$
    – Rushyo
    Aug 25, 2010 at 10:49

All non development tasks can be done by anyone. The team must be capable of completing the development. Marketing, licensing and company directing legal stuff are all easy to pick up. A lot easier than games development itself. It all takes time though, so try to pick someone who's going to be done with their part of the development early to take on these roles, and maybe someone who doesn't come in till later to take on the role of company direction.

Hobbyists need resources as much as professionals. However, hobbyists don't need to maintain old code. This is a crucial difference between industry and indie. The difference manifests itself in skills required, but only slightly.

As a hobbyist, you'll likely need to pick up a graphics package as a programmer, and figure out how to create audio too. There's no pain like not having an asset to get something tested. In addition to the digital asset creation skills you must have, you also need to acquire the sense of when to give up. If something is proving to take longer than expected, as a hobbyist, you need to find something else to do to keep rolling. Small teams means there's less chance that all your requirements are covered, and that'll mean last minute research and development before the game can come together. Heed the advice of those who have gone before regarding what not to do and how to do stuff without doing it right. There's time to be wasted doing things right when you could just get them done. Not sloppy coding or bad art, but test driven development way of thinking, do only what you need to do to get it performing as expected.

There is no need to draw a grand backdrop if you're only going to see it through a dirty window, no need to code a physics model if a free one will suffice. We in the industry know that it's fun to do these things, but any company that has pandered to its staff and let them have their head came crying to the banker when the money ran out.


I can write about how I work since what I do could be described as a hobbyist gamedev. We loosely have a 4 person team: programmer, business guy, graphics artists and music guy. The graphics and music guys are contracted do for specific work and are paid per hour/job.

The design for the games comes from the business guys (which happens to also be a programmer who has made multiple games previously) mainly, but with a lot of input from the programmer.

The programmer does the actual programming with the business guy helping with the testing. Once the game is ready, the business guys take responsibility for pushing it on to vendors, try to get deals with distributor/carriers. When new platforms are made available, the programmer ensures that it will run properly and make modifications as necessary. Of course, there is bug fixing as well.

We work in the mobile space, so it is not clear if the concept would work on the PC/Console due to the size of the games produced. We are on track to get 3-4 games out per year. Finally, the programmer and business guy split the revenues.


This question is a bit vague, so I can just give you some similarly vague answers.

a) Many hats. There's no way that you'll have clearly separated roles. Some roles might be easy to assign to one and only one team member. Others will have to be shared. In our team of five (we're not hobbyists but a similarly small team) we've never managed to clearly assign roles because we're still too small for that.

b) It all comes down to personal preference. If you're a game designer and more of the social kind of guy you might enjoy marketing. Maybe your game designer loves Twitter. Then he/she should definitely take over that PR aspect. Maybe she's good in English - she should write the PR texts then. Finding motivation for some tasks can get very hard in a hobbyist team. If you like what you do you'll be more easily motivated.

c) Stay agile. Even if you find the perfect team, there are a number of roles you'll only need at certain phases of a project, e.g. a graphics artist and an audio designer. You can hire those or ask a friend to do it, but you can similarly find someone in your team who's into audio and have him mix your soundtrack and switch back to whatever he did before, afterwards.

d) Persistent communication rules. Use something like basecamp and version control for everything. This way, people can easily reconnect to threads that were dismissed months ago, and keep their information up to date. Also, you can backtrace decisions and have everything documented. This is especially important if you work in a distributed team.

e) Every project needs a different team. Since you don't tell what game you're working on I can't get very specific. But given a little bit of planning and design you'll most likely end up with a list of project roles you're going to need. Additionally you'll need someone to act as the sysadmin (e.g. for servers), research and maintain the asset pipeline and tools, do the PR and maybe budgeting.

PS: I prefer to wear "many hats", as opposed to "many heads" ;-)


The ability to learn things well on a deadline, the ability to maintain a clear vision of what the end is going to be, the ability to go without sleep and work in a closet, and the ability to celebrate victories and accept defeats as a team, with no single person being blamed.


Not the answer you're looking for? Browse other questions tagged .