"The little time spent from my life on these ideas is so small that I don't really loose much from taking the chance."
Then do you think you have any chance at all above the person who IS devoting a large part of his life into turning his game into a playable pitch, and still has almost negligible odds of succeeding?
Proposing a Game Idea to a Company
Quote: Original post by Professor420
"The little time spent from my life on these ideas is so small that I don't really loose much from taking the chance."
Then do you think you have any chance at all above the person who IS devoting a large part of his life into turning his game into a playable pitch, and still has almost negligible odds of succeeding?
I think you misunderstand me. Let's say it takes ~4 years to design and produce a game, give or take a few years.. Those ~4 years are so small in the grand scheme of things as its hardly worth it to NOT take a chance... You say someone is devoting a large part of their life into making a game into a playable pitch.. What are you considering a large part of someones life? 20 years, 30 years? That seems like an AWEFULLY LONG TIME to just create a playable pitch.. Maybe I'm all wrong about the gamming industry, but I'd be hard pressed to belive someone is going to spend the majority of their life on one game pitch, considering the average person lives ~80 years, they'd have to spend over ~40 years on one pitch.. In my eyes, that's nutty :)
Edit: I kinda put a 'b' where a 'p' should be in one select word.. I think you can figure it out :)
Frankly, MMORPGs are NEVER going to be accepted by a mainstream company's submission department (should they have one) and will NEVER be given the time they need to be evaluated.
By nature of the complexity of the beast, an MMO's design spec (which has to approach a range of issues a LAN / single machine game doesn't) is often a long-winded, laborious affair of many interlinked documents. There are something like 600-700 pages (A4 / letter) of rough notes for Bloodspear and Primogen. These don't shrink when turned into a presentable formatted (and cross-referenced, and indexed) document - as a case in point the 'Terrain and Artefacts' document went from 3 pages of coffee-stained, scribbled notes and diagrams to a (actually fairly concise) 20 page technical document (no diagrams) (that is now being used by the code team). MMO design as I've seen it working (in my one professional experience with it) and indeed as I work with it is a somewhat sketchy affair until almost the last minute when the 'best working' design is codified and used as a base for further discussions. Trying to cover every angle with a rigidly codified document from the start doesn't happen - there are simply too many factors to consider in a reasonable time frame. A rough plan is laid out, and the bones of the system are added to. This is kind of like building a set of abstract base classes that interact, before working on concrete implementations. Occasionally something interface-breaking turns up, and causes a hassle, but with good forethought, a reasonably robust development sequence can begin. For design docs, I usually operate a 3 step principle: 1- Concept (beermats, post-it notes and cigaratte cartons), 2- Function Design Doc (FDD) (what it should do - don't even mention how - indexed, cross referenced, formatted word doc), 3- Technical Design Doc (the programmer's handbook on how it works). Each major system in the game, or each major feature gets its own document. 'Umbrella' documents that give overviews of several related features are occasionally created if they would help in grasping the concepts involved.
From my point of view (wanting to make a profitable studio out of basically nothing), thinking ahead and creating a reusable technology base has been paramount - 'how it works' (and to some extent why with a little bit of statistical analysis) was the most important task in concept documents, moving on to optimisation for a distributed, online environment (minimising math and physics simulation where possible etc. etc. etc) for the technical design docs. I don't generally define classes or do UML modelling at the design doc level, unless there is a clear and present need to do so (such as it being a standard interface to another portion of the codebase).
I'm interested in hearing more about your design though - I'm looking for another product that can be developed with the tech my team and I are developing that would be worth investing in.
By nature of the complexity of the beast, an MMO's design spec (which has to approach a range of issues a LAN / single machine game doesn't) is often a long-winded, laborious affair of many interlinked documents. There are something like 600-700 pages (A4 / letter) of rough notes for Bloodspear and Primogen. These don't shrink when turned into a presentable formatted (and cross-referenced, and indexed) document - as a case in point the 'Terrain and Artefacts' document went from 3 pages of coffee-stained, scribbled notes and diagrams to a (actually fairly concise) 20 page technical document (no diagrams) (that is now being used by the code team). MMO design as I've seen it working (in my one professional experience with it) and indeed as I work with it is a somewhat sketchy affair until almost the last minute when the 'best working' design is codified and used as a base for further discussions. Trying to cover every angle with a rigidly codified document from the start doesn't happen - there are simply too many factors to consider in a reasonable time frame. A rough plan is laid out, and the bones of the system are added to. This is kind of like building a set of abstract base classes that interact, before working on concrete implementations. Occasionally something interface-breaking turns up, and causes a hassle, but with good forethought, a reasonably robust development sequence can begin. For design docs, I usually operate a 3 step principle: 1- Concept (beermats, post-it notes and cigaratte cartons), 2- Function Design Doc (FDD) (what it should do - don't even mention how - indexed, cross referenced, formatted word doc), 3- Technical Design Doc (the programmer's handbook on how it works). Each major system in the game, or each major feature gets its own document. 'Umbrella' documents that give overviews of several related features are occasionally created if they would help in grasping the concepts involved.
From my point of view (wanting to make a profitable studio out of basically nothing), thinking ahead and creating a reusable technology base has been paramount - 'how it works' (and to some extent why with a little bit of statistical analysis) was the most important task in concept documents, moving on to optimisation for a distributed, online environment (minimising math and physics simulation where possible etc. etc. etc) for the technical design docs. I don't generally define classes or do UML modelling at the design doc level, unless there is a clear and present need to do so (such as it being a standard interface to another portion of the codebase).
I'm interested in hearing more about your design though - I'm looking for another product that can be developed with the tech my team and I are developing that would be worth investing in.
Winterdyne Solutions Ltd is recruiting - this thread for details!
At any point in time a game company has 10x more ideas than it has manpower to develop them. That is IF they're in the fortunate situation of being able to create original IP, instead of making the latest Spongebob Squarepants licensed title.
Most developers are like you; always playing games, looking at games, working out how you make a better game. They're also evangelizing it to each other and the boss, getting feedback and improving the design.
The company would rather develop their own idea (both because it makes the dev-team very happy to see their brainchild created, and because they can own the IP on it) than take some off-the-shelf design. And that's assuming the off-the-shelf design had credability, which yours don't.
So.. by all means, go ahead and send out your 'idea'. Most companies will send it back unopened (we get too many of these things, and there's always the odd nut-job who'll come back 12 months later suing people because 'that MMOG looks just like the one I sent in earlier'). In the cases where people mistakenly opens the envelope, they'll most likely bin it the moment they see it. There ARE people a company would accept a design document from, but you ain't one of them (Miyamato or Will Wright springs to mind). We once had a grown man submitting his 'game design' drawn using crayons on used photocopying paper, so I suppose your's won't be the worst, at least.
So..If you want your game made, you have two paths open to your.
You can do it yourself. Downscale to a normal RPG (you are right, MMOGs are almost impossible to do with a small team, unless you're going the Puzzle Pirates / Tale in the Desert route). If you're a combat heavy RPG, maybe look at a small 8 player coop game (like Diablo or Arena.Net). Use that design doc to recruit a team at Help Wanted, build the core tech, and you may have a small, complete title in 2-3 years.
You can try to get a position in a game development company that does your kind of games. You can work like mad, testing out ideas, getting feedback, and (once you got a bit of credability), pushing your game ideas to the rest of the team. While I doubt you'll ever get your full magnus opus done, you would perhaps see many of your (good) ideas implemented in the game.
So... as you've ignored Tom's advice, Obscure's advice, etc, you'll probably ignore this. Just don't use crayons :)
Good luck.
Allan
Most developers are like you; always playing games, looking at games, working out how you make a better game. They're also evangelizing it to each other and the boss, getting feedback and improving the design.
The company would rather develop their own idea (both because it makes the dev-team very happy to see their brainchild created, and because they can own the IP on it) than take some off-the-shelf design. And that's assuming the off-the-shelf design had credability, which yours don't.
So.. by all means, go ahead and send out your 'idea'. Most companies will send it back unopened (we get too many of these things, and there's always the odd nut-job who'll come back 12 months later suing people because 'that MMOG looks just like the one I sent in earlier'). In the cases where people mistakenly opens the envelope, they'll most likely bin it the moment they see it. There ARE people a company would accept a design document from, but you ain't one of them (Miyamato or Will Wright springs to mind). We once had a grown man submitting his 'game design' drawn using crayons on used photocopying paper, so I suppose your's won't be the worst, at least.
So..If you want your game made, you have two paths open to your.
You can do it yourself. Downscale to a normal RPG (you are right, MMOGs are almost impossible to do with a small team, unless you're going the Puzzle Pirates / Tale in the Desert route). If you're a combat heavy RPG, maybe look at a small 8 player coop game (like Diablo or Arena.Net). Use that design doc to recruit a team at Help Wanted, build the core tech, and you may have a small, complete title in 2-3 years.
You can try to get a position in a game development company that does your kind of games. You can work like mad, testing out ideas, getting feedback, and (once you got a bit of credability), pushing your game ideas to the rest of the team. While I doubt you'll ever get your full magnus opus done, you would perhaps see many of your (good) ideas implemented in the game.
So... as you've ignored Tom's advice, Obscure's advice, etc, you'll probably ignore this. Just don't use crayons :)
Good luck.
Allan
------------------------------ BOOMZAPTry our latest game, Jewels of Cleopatra
First off, I thank everyone for replying.. :)
To __ODIN__: I apologize if it seems like I was ignoring the advice given. I'm not ignoring it, but its all obsticles I totally understand. I know that my chances that a company will even accept my idea, let alone look at it, are 1 in a million. But with that said, putting in the effort can't hurt.. I only loose time. And, when/if I get in the field, or am able to produce the game myself, I already have the base design specs ready.. Sure, I'd have to build on them alot more, but the base of it will be completed, which will ultimatly save me time in the long run :)
To _winterdyne_: I am almost complete with my pitch docs. JUST the docs tho, I enlisted the help of a friend of mine from FFXI (He does 3D arts) to help me create a little demo presentation of my ideas. I am trying to keep my "pitch doc" small and concise. It's currently 6 pages, and I'm trying to keep it under 10 (minus pictures/diagrams). My reason behind this is, I want to sell the main points in a clean/easy to read fashion. If I bog them down with information up front, they might feel overwhlemed and just move on.
Once these docs are done, and being mailed out I am going to start on my design docs.. These, like you said, will reach a couple hundred pages of the nit and gritty information. I am actually looking forward to creating my design specs. To see my ideas on paper is a sense of accomplishment (in a weird kinda way xD). If you were serious about wanting to hear my idea, send me a PM here and I'll give you my email or any other form of contact information you might want. I'd be happy to show you my docs/explain my ideas to ya :)
To __ODIN__: I apologize if it seems like I was ignoring the advice given. I'm not ignoring it, but its all obsticles I totally understand. I know that my chances that a company will even accept my idea, let alone look at it, are 1 in a million. But with that said, putting in the effort can't hurt.. I only loose time. And, when/if I get in the field, or am able to produce the game myself, I already have the base design specs ready.. Sure, I'd have to build on them alot more, but the base of it will be completed, which will ultimatly save me time in the long run :)
To _winterdyne_: I am almost complete with my pitch docs. JUST the docs tho, I enlisted the help of a friend of mine from FFXI (He does 3D arts) to help me create a little demo presentation of my ideas. I am trying to keep my "pitch doc" small and concise. It's currently 6 pages, and I'm trying to keep it under 10 (minus pictures/diagrams). My reason behind this is, I want to sell the main points in a clean/easy to read fashion. If I bog them down with information up front, they might feel overwhlemed and just move on.
Once these docs are done, and being mailed out I am going to start on my design docs.. These, like you said, will reach a couple hundred pages of the nit and gritty information. I am actually looking forward to creating my design specs. To see my ideas on paper is a sense of accomplishment (in a weird kinda way xD). If you were serious about wanting to hear my idea, send me a PM here and I'll give you my email or any other form of contact information you might want. I'd be happy to show you my docs/explain my ideas to ya :)
jlach said:
>putting in the effort can't hurt.. I only loose time.
Not only can't it hurt, it can help. And you do not "loose" [sic] anything, unless you don't really want to become a game designer.
>And, when/if I get in the field, or am able to produce the game myself, I already have the base design specs ready.. Sure, I'd have to build on them alot more, but the base of it will be completed, which will ultimatly save me time in the long run :)
So your plan is to only get one original idea for a game in your entire life, then, huh? Too bad.
>I am trying to keep my "pitch doc" small and concise. It's currently 6 pages, and I'm trying to keep it under 10 (minus pictures/diagrams).
That's the right idea, but you also need to add a few pages about the awesome development team you've got. FAQ 35.
>Once these docs are done, and being mailed out
To whom? FAQ 21.
>To see my ideas on paper is a sense of accomplishment (in a weird kinda way xD).
What's so weird about it? I don't think you really have the design spirit, if you think that'd be weird.
>putting in the effort can't hurt.. I only loose time.
Not only can't it hurt, it can help. And you do not "loose" [sic] anything, unless you don't really want to become a game designer.
>And, when/if I get in the field, or am able to produce the game myself, I already have the base design specs ready.. Sure, I'd have to build on them alot more, but the base of it will be completed, which will ultimatly save me time in the long run :)
So your plan is to only get one original idea for a game in your entire life, then, huh? Too bad.
>I am trying to keep my "pitch doc" small and concise. It's currently 6 pages, and I'm trying to keep it under 10 (minus pictures/diagrams).
That's the right idea, but you also need to add a few pages about the awesome development team you've got. FAQ 35.
>Once these docs are done, and being mailed out
To whom? FAQ 21.
>To see my ideas on paper is a sense of accomplishment (in a weird kinda way xD).
What's so weird about it? I don't think you really have the design spirit, if you think that'd be weird.
-- Tom Sloper -- sloperama.com
Also: Developers tell aspiring game makers the ugly truth.
Quote: “Don’t come to the traditional game companies and try to sell [them] an idea,” said Gordon Walton, co-studio director at BioWare Austin. “It won’t happen. Every company I worked for had a backlog of ideas that was too deep to work through.”
Instead, Mr. Walton said aspiring developers would greatly increase their chances of success if they could show actual implementations of their ideas.
“Publishers… are saying they won’t sign anything until they see a working prototype,” said Michael Scandizzo, president of Castaway Entertainment, a small company staffed with numerous former employees of Blizzard Entertainment, producer of the blockbuster multiplayer game World of Warcraft.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Unless you were making a joke, I'd just like to point out that its Massively Multiplayer Online Role Playing Game, not roll. Or you could have been making a joke about D&D.
"Fruny" wrote:
>Developers tell aspiring game makers the ugly truth.
FYI (whoever any of us are), The truth is NOT "ugly." The truth is... just… um… the, you know, "TRUTH."
>Developers tell aspiring game makers the ugly truth.
FYI (whoever any of us are), The truth is NOT "ugly." The truth is... just… um… the, you know, "TRUTH."
-- Tom Sloper -- sloperama.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement