Found you programming literate types insanely helpful with the last question I had about, you know, programming, so I figured I'd seek out your assistance again.

My intent is to take the entertainment and experience of a game like Fallout and provide it on a much smaller, and obviously cheaper, scale. Consequently I'm aiming to have as little of a programming burden as possible so as to keep the team small and production fast. The aim is to be able to produce the game with only myself and a programmer, as sound will be restricted to effects and I am capable of both writing and art. As follows are the major elements of the game:

-stationary background: camera may move a little but not much. Enter and leave rooms by clicking on the exit. If enemies present battle begins and continues until all enemies are dead, cannot solve puzzles while fighting.

-stationary enemies: stand still (possibly varying levels of cover), muzzle flash (or similar graphic) indicates attacks, each enemy attacks with a set pattern.

-field stat checks: exploration/puzzle solving, so not utilized during combat. Very basic (example: strenght stat to move an obstruction, intelligence to fix a machine, etc., no more than basic math, and there won't be many stats, though I may combine different stats on certain checks)

-information checks: your character only knows what has been told or what he/she understands. This includes your mini-map, which will only be unlocked (and not necessarily all of it) if you gather the information in town. This also overlaps with stat checks in general as your character will not be able to identify the short-cut allowing devices if incapable of recognizing them to begin with.

-combat stats: what I'm most concerned with as I don't know how much the math will burden the system. My initial idea was to keep enemies as static as possible, no % chance of hitting, just damage per second applied to the player while the enemy is still alive, possibly mitigated by an endurance stat. I do want some sort of gun skill to affect the player's ability to handle the gun (reload time, sway while aiming, etc) but am willing to simplify or drop these if it requires too much calculation.

You gather information/supplies in town, leave for the dungeon by clicking on the exit which brings you to the dungeon (no travel). Click to enter the dungeon, clear the room if enemies present, then have to find your way through the different options that will be made available and attempt to find the big prize, with most rooms containing either enemies, some element/piece of a puzzle, or both.

So I have three questions:

1) what's the general plausibility of this game being completed with a small team in under 6 months (at least a first level to kick it off)?

2) what level experience of a programmer should I be looking for?

3) if these don't cut enough programming to be possible as stated above, any advice on how to alter them so as to cut the burden?

Any guidance or advice is greatly appreciated.

What is the level of graphical fidelity that you expect to have in game? You should focus on something graphically simple.

Whether or not it can be done within 6 months depends on the people involved, and their abilities, but as a programmer, I think it's something that I could craft with relative ease (it just sounds like a relatively straightforward RPG engine).

Although, I generally wouldn't want to work on anything that tries to emulate a AAA title. When someone describes their game idea in that way - like <popular thing> but with <gimmick> - it tends to fail.

Graphics will be very low. As high as I can get them, of course, but it's at the bottom in terms of importance. As you said, Goran, I'm aiming for a very straightforward RPG. As simple and easy to play as possible while still maintaining the general experience of exploring a dungeon or vault.

Apparently I didn't explain myself well enough as I was only listing a few features I was designing into it to drop the need for heavy programming. Further I'm asking for programming expertise, not business or law. Neither am I looking to copy Fallout, but was using it as a reference for the general experience I'm aiming for.

Guess I can't explain the concept without going into full detail, which is way too long for me to expect anybody to read. Thanks for the help either way.

1) what's the general plausibility of this game being completed with a small team in under 6 months (at least a first level to kick it off)?
2) what level experience of a programmer should I be looking for?
3) if these don't cut enough programming to be possible as stated above, any advice on how to alter them so as to cut the burden?

... I'm asking for programming expertise, not business or law.

I'm not a programmer. I'm a producer. Your questions 1 and 2 look like producer questions (not programmer questions) to me. Based on the wording of your questions, these are definitely project management questions, and definitely need to be here in this forum.

My answers:

1. It depends on the experience level of the people, and the thoroughness of the design (the plan), and the competency of the person who's managing the project. I could probably get it done in 6 months (a very small scale, single-level demo), if I had the budget. But I'm not producing it -- you are. Since you had to ask: "hard to say."

2. The more experienced, the better your chances of a quality job.

3. Not sure I understand the question. Cutting features is the usual way to cut a schedule. Fewer features causes less programming. Less programming means less time. Less time means less money.

I see where you're coming from in regards to the business/law vs programming and I definitely worded this post poorly. Amazingly you've still all managed to answer the gist of my concerns. Was largely just trying to see if there were any aspects to programming that I'm not considering as I'm working largely in the dark here and didn't want to sound like a total idiot when bringing in a programmer.

So sorry about the crap post, but thanks for all the help despite it.