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.

Moving to the business forum.

While your description shows a few things that should happen, they do not define a full game.

The game is composed of thousands of little rules and procedures. Each operate within systems that are integrated together.

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?

1) Extremely low. For every game that gets finished there are perhaps hundreds or even thousands of people who make a list like that, and ask what it would take to make a game. As a percent you are looking at less than 1%. It is unlikely to happen.

2) Depends on the individuals. Depends on the quality you are looking for. Depends on the thousands of rules and procedures involved in the game that you haven't mentioned. Depends on the technologies they are planning on using. You will need more than just a programmer, you will probably need multiple programmers, multiple artists, a composer and sound provider, level designers, and QA folk.

3) Yes, gain experience. Go get one of the many rpg engines that already exist and learn what it takes to fill in the missing pieces.

My guess is that based on what you described, you would expect a level of quality for requiring a half million dollars or so in development costs just to get your first 'kick it off' version complete.

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.

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

I interpreted it as "I'm building a team of people. What competencies do I require, and can I reduce the requirements?" Generally the process of creating a team, identifying workers, and distributing their work are business concerns.

If all you are looking for is someone to mod RPGMaker that is one thing. If you are looking to extend a different engine it is a different task. If you are looking to build your own RPG from scratch that is something else altogether. Each requires a very different skill set.

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.

Thread is a bit old, but I wanted to point one thing out. You mention several times the desire to remove heavy programming and make the project as light on programming as possible. I assume this is with the intent of making things "easy" for whatever programmer you end up working with, in hopes of getting work done.

While that is a good idea when trying to do the programming yourself or use an existing framework, I don't think that is a valid concern when bringing in an experienced programmer to work on the project with you. Most programmers (especially those in games) do programming because it's what they enjoy. If we didn't like programming, we'd be doing something else. So reducing the amount of programming required is, to some degree, making the project more boring from our perspective. With less programming, you have less features, less options, less of a game to be proud of in the end. You don't want to cut down on programming effort for it's own sake. That's like asking an artist to help with a game that only needs drawings of stick figures in crayon. Where's the fun in drawing that?

Instead, have a clear idea of what game you want to make, and all of the necessary features and details. Think it through, don't be overly vague. If a programmer likes it, they'll do the necessary programming to make it happen. Stay focused on what's important, the end result.