Original post by Limdallion See, that's the thing. I don't think this is a niche game or some wild ...
add franchise potential to the list of reasons why this game is a good idea.
I hear ya, really, I do.
It's one of the most strange feelings having something like this in hand, looking at the market, and having a publisher just flat out tell you they don't see any potential in a Nintedo DS game.
I can quote "By the time you're going to release the game, the PSP would have taken over." There's a tiny bit of truth to that, but it's not really a reason to not want to publish the game.
Nintendo is well on their way to selling over 12m units world wide by next year (having already sold 6m in less than a year). Sony by the same time wants to have sold 14m units. The Sony track record has shown their sales have always fallen short of their projections (the psp being no exception).
Even so, a mediocre NDS game will claim about 1% of the market, a good title as much as 5%. at 29.95 thats between 1.7m and 8m in gross gain. (based on 6m units, double that if the game comes out next year, which is what the plan is.) It boggles my mind, really.
I agree that the PSP might take over the market. But no matter how much it sells, it isn't going to rip the NDS out of the hands of people that already own NDS. NDS already sold 6 million and that is a large enough customer base to sell games to. Even if the PSP sells 100 million there will still be that 6 million that would want to buy this game.
The fact that there are so few good games for the NDS and the NDS is failing is all the MORE reason why your game would sell. It has very little competition. People are so starving for a good NDS game that they are buying up these cruddy other games for it that have awful reviews. Put a great game out there like this one and literally everyone who owns a NDS will buy it. That is 6 million people. No matter what the PSP does, that's 6 million.
I have only read the posts of this thread. The PDF has been open for about 15 mn, and it will still wait for my eyes to lurk on it. But no doubt the mentionned ideas are great.
I just wanted to asked something : how would your concept match with a webcam ? Imagine the webcam as a tool, capturing some move (following the hand/finger). In some way, it can replace any 'touch me' screen. That way, you would be limited to the DS market.
IMHO, the webcam is a tool that's been far too much neglected untill now. I don't think it can replace a mouse/keyboard/gamepad ( ...huh...maybe it could :) ) but it's definitely a good way to add a new dimension to gaming.
Please, understand that I'm no fan of what's been done this far with the EyeToy. So I do not refer to any already published game. I just happen to have been playing with a webcam at work for 2 weeks, in order to prototype some application that would replace the 40 years old mouse. And I kinda did it - though I'm still a noob.
Original post by Ishraam I have only read the posts of this thread. The PDF has been open for about 15 mn, and it will still wait for my eyes to lurk on it. But no doubt the mentionned ideas are great. ...
Well anyway, why to not do it with a webcam?
Actually I had thought of the Eyetoy as a possibility. For tracking a single point in space rather than the outline of a body I was thinking I could also build a light pen with a frosted bulb cover. With this the player could use the device like a magic wand.
It's still not out of the question, but developers and publishers shy away from adding 'gadgets' to a package more than an original IP.
The game was designed for a handheld because of the lower cost of development. The eyetoy would be on a full ps2 console, so the art, programming, and content would have to be expanded to match other games of a similar look. The larger scope would be an order of magnitude more expensive, thus even less likely to be picked up by a publisher.
Ya know, this could be done on the PSP using the that little round controller. Sure, it's not the same as on the Nintendo, but I think you could still create a good experience allowing you to market the game for both systems.
I've skimmed over your design documents today, alexokita, and it looks very nice! But I've just got one question which I'm not really sure about...
Is this really what a design document is like? I've had a bit of commercial game experience, but my background training is more in the field of software engineering. My understanding of a game design document is that it was more analgous to what I'd call the "software requirement speification"; a completely detailed document outlining exactly what everything does. So you'd have, say, one chapter that completely describes what the user interace is, and another chapter outlining the gameplay to the nth detail. There would be appendices full of tables of spell statistics and monster details etc.
Your document reads much more like a tender proposal, the sort of thing that you'd give to a publisher in order to convince them to give you the funding to make your game. In that respect, it's a really top notch tender proposal (really, it is, first rate!). But it doesn't really go into the detail I'd expect in a full design document. Plus it's also way too pretty (the few design documents I've read are wieldy, ugly dogeared tomes [smile]).
But it's a great idea, although I'm sure I've seen that spell dynamic been used in the Harry Potter games as well as Black and White. And I'm sure that the 'drawing glyphs for magic' gameplay dynamic will be picked up by someone developing for the Nintendo DS sooner or later. But your approach and presentation really is well done, and would definitely be sellable.
For the tables charts and other game guts, i'd say that would be more of a technical design document. Something that the programmers or rather, lead programmer would be involved with. ( I have no programming help to speak of, so I cant get around to a doc like this. )
A "design doc" really varies from company to company. At the more grass roots level a design doc will read more like a 3-ring binder full of "wish list" items and "wouldn't it be cool if..." statements, or worse case; a screen play with bad dialog and cut scene descriptions. That's the kind of nonsence I've tried to get away from.
A more organized crew will see a design doc that is usually a giant word document complete with maps for every level and at least placeholder art for every object character and monster in the game.
These are usually completed with a small crew which consists (usually) of a producer, a game designer, an art director, maybe an artist or two, and a lead programmer. Being that I'm just an artist, I have much left to do. Level layouts, monsters, items, spells, a ton of actual game bits, you name it, I need to do it.
After that is done then the programmer will talk with his crew and start writing a doc that consists of tasks, goals, risks, and methods in software to accomplish what needs to happen in the game. That's a tech doc, I've seen these, they have lots of examples from other games to use for reference, lots of tables and charts with big equations for things like skill levels and monster hit points.
Stuff like "What we want our particle system to do, and what the artists need to make that happen." or "This is the database that makes up all the monsters, and this is how the game designers will make changes to their stats."
These are cool, but only interesting to other programmers and maybe the designers, and the rare artist who is curious about what happens on the otherside of the cube walls.
Sure, if I had some additional help that sort of stuff would have gotten filled in much faster, but I have to pay bills, so most of my time has been taken up with freelance contract work.
>shrug< what can ya do...
Something I've also learned that if the "game X" has a boring 3-ring binder game design, then "game X's" development team will not read it. Hard to believe, but It happens all the time.
The artists look to their art director and just build from the concept art they are given. The programmers will look to their lead programmer, and will code a system that fits the specs.
Then, amazingly, a game will be completed with most of the production crew having never read their own design doc. Hard to believe, but its true. I've seen it personally and I've herd the stories. oh boy, have I herd the stories.
Anyway, I am in the middle of some rewriting of the design. I'm hoping to have an update before the end of the month. It's more of just a lot of typo fixes and some clarification of ideas. A lot of sentences, after re reading a few times, make no sence at all. (sorry about that... my bad, I'll try to do more writing while im still conscious.)
Original post by alexokita For the tables charts and other game guts, i'd say that would be more of a technical design document. Something that the programmers or rather, lead programmer would be involved with. ( I have no programming help to speak of, so I cant get around to a doc like this. )
Ah, okay. However, I'd consider the technical design document to be the "software architecture design document" from my engineering background. I'd think that things like the tables and charts would be in the design document proper. The basic rule of thumb in software engineering is that if anything at all does not depend on the choices made in coding and implementation, it goes in the design document (or software requirements design). So "we will use this graphics algorithm" would not go in the design, but "monster X has 100 HP" would.
However, as you said, that leads into this point...
Quote:
Something I've also learned that if the "game X" has a boring 3-ring binder game design, then "game X's" development team will not read it. Hard to believe, but It happens all the time.
The artists look to their art director and just build from the concept art they are given. The programmers will look to their lead programmer, and will code a system that fits the specs.
Then, amazingly, a game will be completed with most of the production crew having never read their own design doc. Hard to believe, but its true. I've seen it personally and I've herd the stories. oh boy, have I herd the stories.
... which is what happened to me! [grin]
Seriously, when I joined this project midway through, I asked to see the design document, and found a copy at the bottom of a filing cabinet, months out of date. Consequently, I just ignored it and just asked other people what the design was meant to be (and got different answers depending on who I asked). Not good for maintaining a consistent game!
Which is why I think your design document is a great game tender or sales document, even if you are selling it to your own team. Ultimately, that's of more use than the huge out-of-date tomes of tables that the technical design documents tend to me.
By the way, what software did you use to create this? I'm no graphic artist, but the document looks like a professial game manual standard, and I was wondering how easy it would be to emulate. Being from a research background, I write all my lengthy documents in LaTeX.
I love the design document. I love the game idea. You are a very creative individual. If this game ever sees the light of production, I would very seriously consider purchasing a DS just for it. Its definitely a unique, fantastic concept. I've only read about 5 pages or so of the DD, and although Im unsure about several pieces (the collectable card game, actually, is the only one off the top of my head that I can think of), but the basic system (using drawn symbols for attacks/spells) is fantastic. I seriously think its a great step-up from similar elements that Ive seen in previous games - e.g. Sabin's Blitz techniques, or the common special-attack moves from fighting games like Soul Caliber and the Street Fighter II series.
For whatever obsessive-compulsive reason, I like to offer ideas whenever I make a post. People probably don't like it, but I can't help doing so. So here's a couple ideas.. if you don't like them, ignore them.
- I noticed a couple of spelling errors. Im not sure if there's a way to spell-check the pdf, but it might be worthwhile to look into (p 24, 1st full paragraph, 2nd sentence 'onteractive')
- The example on p. 9 referencing fig. 2 is confusing when describing connecting nodes. It makes sense when being viewed with fig. 2, but if for any reason fig. 2 is unavailable (if the document is ported to a .txt file, for instance), I would have had no clue what sort of drawing the second example was talking about. 3 of those 'n' symbols didn't make any sense, without realizing that, in fact, there were 3 separate 'strokes' being performed.
- Will there be any kind of 'training ground' where the instructors would rate how well the player was able to draw the symbols, and offer suggestions?
- Since I haven't read the entire DD cover-to-cover, Im not certain that this is already implemented, but will spell-order in combos affect the resulting combo? I'll read through this later today, so if its already been implemented, please ignore this comment.
