Knowing the basics of coding will be a big help. Even if you aren't planning in doing any coding yourself, you'll be much more able to communicate your ideas to programmers in a meaningful way, and you'll have an easier time understanding the feedback you get from them. The same goes for art by the way - if you learn a little bit about it, you'll be better able to communicate with your artists. I can't do art at all really, but I've still taken the time to learn a bit about what they do and how they do it, so that when I need to make requests for art I can include the relevant information.

You shouldn't need UML (although extra knowledge is almost always helpful at some point). Trust your programmers on programatic flow, etc. What you want to do, is create a design document. This should explain, in as much detail as possible, how the gameplay works, how the screens are layed out, the storyline of the game, etc. Your workers will work from this. For some examples/articles on the subject, see the Design Documents section of GDNet's articles, here.

You need to hire good, skilled programmers and artists (and possibly someone for SFX/Music, although you can commission this person only when needed rather than having them on staff for the duration), who know what they're doing, and preferably have some experience. Ask for a portfolio when hiring. Artists should be able to provide you with some existing original artwork, of good quality. Good programmers will usually have some good tech demos or previous (possibly small-scale) projects to show you that they know thier stuff. With both artists and programmers, past experience is of course a plus. Also, make sure they have a reasonable personality - they will have to work with you and with each other closely, as a team, for the duration of the product.

Learn everything you can about the industry, and about how other companies do it (especially indie-teams, as you'll essentially be one).

That was all on the basis of you being willing to pay others to do most (close to all) of the work for you, if not, then discount it, but if so, I hope you find that helpful. Good luck. [smile]

Had to leave suddenly before, hence the additional post.

Just thought I'd make sure you're aware, that this will be a difficult, and time-consuming project. Even if almost all the work is being done by hired programmers and artists. You'll need to put in time to manage the team, you'll need to approve everything produced, you'll need to make decisions constantly (say if the programmers suddenly inform you your engine can't handle something - you have to decide wether to cut it, replace it, or whatever), and you'll have to keep the team motivated.

To that end, I'm going to link a few articles I recommend you read - you don't have to, but you'll probably learn some useful things from them, and perhaps be a little better prepared for the task you'll face with this:
- Game Development: Harder Than You Think (aimed mostly at programmers, but the points are still good)
- Psychological Hardships of Indie Game Design
- The Journey of Raymond Jacobs

In addition to those, sunandshadow had written some excellent design journals which are well worth checking out:
- Designing and Plex Levels
- The Plunge into Game Design
- Coming Up With A Concept
- Gameplay Genre Characteristics

The other two links I'm going to provide are interviews with succesful indie developers:
- Interview with Radu Privantu
- Interview with Raymond Jacobs
Also, a postmortem of Eternal Lands, created by Radu Privantu, which offers a good insite into developing a game:
- Eternal Lands Postmortem (there are 4 parts, which are all linked from this one)

Anyways, check out as many or as few of those links as you like, but I'd recommend reading through them, as they provide an excellent resource for getting an idea of what you'll be taking on, as well as including some good advice on how to handle it. Once again, I hope this is of some help to you, and good luck. [smile]

Thank you very much guys! Your advice has been very interesting and was exactly what I was looking for. Thanks again, and I am going to read those articles now, starting with the postmortem one.

This question might be a little late, but have you already taken care of the legal issues? Unless you are fully aware of the deep issues of trademark, copyright, and the game as an art form (or it is often used that way in court), you may run into major issues as you move down the road. If you're not interested in learning it yourself, you could hire someone, but finding someone in law who has a focus on the game industry and will stick with a smaller group... That may take some doing.

-Mennez

I'm going to second the idea of starting off as a hobby. Without money involved you can call it training.

Small teams require talented developers who have been doing this for a while. You may have trouble finding such talent with your lack of experience in the industry and obligation to your other business.

Developers want to know who you are, what you do, your policy, your role in the company, your ideas, your history, and so forth. Developers will not work for you no matter how much you pay if they do not like you or your company (Example Only: EA).

Unless you have multiple projects lined up to keep everyone busy, hire one pro and outsource the rest of the work. You don't want to pay a programmer or artist to learn new stuff or even worse game test.

Lastly, I want to say welcome! and good luck!

Quote:

Original post by Kazgoroth ...Masterpiece...

Wow, that was a geat post [smile]