Hola Mi Gente!.
Since its not really an ad or anything its more of a question about that section i thought id add it here in Community i was pondering design philosophy but figured thats more for game mechanics then a general question. not sure if this will even get any hits but heh everything is worth a shot am i right?
Anyways my question to the general community is:
When should you begin hunting for a team and why at certain points rather then at other points.
And DISCUSS! :D
~Midgets
ID:181377
 Sep 6 2010, 9:51 pm
|
|
I'd actually argue against quite such a document myself, in favour of a page or two that specifies the game's unique and killer feature, the main reason someone would play the game.
The reason I make this recommendation is that the unique / killer feature(s) is the bit you need to get correct and everyone in a team must be clear on, the rest of the game would fall around that feature and seek to support it. Amon R actually showed me such a design document recently for review, and out of the 50 or so pages it was, it turns out I only needed to review the first two, specifically just look at a picture on page 1 and read a bit of page 2. The other 48 pages provided information to guide a potential technical design, but I'd have probably made 3/4 of the pages partially or completely redundant before having a game to release, as the functions they described didn't "need" be be carried out in that way necessarily, or in fact needed to be carried out at all in some cases. You are looking for artistic / technical staff, most probably because you cannot do these roles yourself to an acceptable level. A detailed "no stone unturned" design document will have you doing design in those technical areas, usually risking imposing a solution which actually isn't in the game's interest. But you can't appreciate that yourself while doing the design, because you don't have the artistic / technical heritage to remind you why X didn't work so well last time, and why the users didn't like it, or simply you can't think of a better solution. Then finally and perhaps most simply, a lot of that design is actually probably not important. A shop mechanism in an RPG for example is a feature you'd want, but (usually) doesn't involve itself heavily in the core gameplay. You can design this later, once you have core gameplay to make it against and ensure it supports that gameplay. Progressive disclosure works with technical people as well as end-users. I'm not providing a contractual estimate of how long the game will take to make, I don't need every inch of the game specified up-front. It forms an unwieldy document with a lot of noise, making the job of seeing the killer features that need executing best more difficult than it should be. Mock-ups I would say play more of a role in selling the game's concept to potential programmers than a design document, which is ordinarily executed like a wish-list of disparate features on BYOND. Games are visual, and processes in games can be presented visually to provide an explanation that personally I find superior to what a designer attempts to write in a document. Clear communication of the core idea is key. Which I think myself and Schnitz can agree on. | |
Stephen001 wrote:
(...) in favour of a page or two that specifies the game's unique and killer feature Then again, a good design document has a summary, containing and highlighting important details like the unique selling proposition. Which is kind of exactly what you're describing. Stephen001 wrote: (...)Then finally and perhaps most simply, a lot of that design is actually probably not important. I would somewhat disagree with you on that point. When you can afford to pay others, sure, that's valid. But soon as the joy of creating a game you like yourself becomes part of the compensation (which is the case in most every classified ad on BYOND), different ideas of realising a feature can become breaking points on developing teams. The simple way of interacting with a shop keeper in your example could deter people. Some might insist that it happens in a HMTL pop-up, where another person wants this as HUD on the map and a third embedded as child on the interface, featuring grids. When the team had time to discus these points upfront, there is less trouble later on during development. As for the difficulty of translating design to programming and validating the features, I'd say that this is the programmers job and shouldn't really be the main concern of the developer. I'd be astonished if an author would be required to have solid knowledge on special effects as well, when it comes to writing a storybook for a movie ;) I do see the point where a base knowledge on the possibilities and limitations of the core engine is useful for design though. I think that the original poster has these set. Stephen001 wrote: Clear communication of the core idea is key. Which I think myself and Schnitz can agree on. Definitely. | |
Snagler and Stephen both have good points about design documents, although I think a design doc is really just one way of articulating a clear goal. If the project is any good, it has to have a goal--not a nebluous one like "to be the best ____ game on BYOND!" but a concrete one. If I wanted to make a top-notch fan game to stand out among others for instance, I'd probably be looking at what other games were doing well or not, both within and outside of the set of games just for that particular interest. Then I'd get a rough mental picture of the style of gameplay I wanted, and work from there.
Incursion was actually born more out of a proof of concept than anything else, but when I decided to make it a game I wanted something that would incorporate resource production like Lords of Conquest, rather than straight-up dice rolling like Risk. The result (at the time) was far more Risk-like, but it still had plenty of unique features to make it stand out. In particular, Incursion has a special mechanic that cards can be played in or out of turn, and are simply more powerful when played in turn (either because their effects last longer or the player has more options while it's still their turn). It also does not limit the number of redeployments you can make at the end of your turn; it only limits how far any single unit or resource can travel. These things contributed to giving the game its own personality. When most people post in CA to recruit, they have no clear goal. Indeed, most don't even have a defined role for themselves. Many of the posters there have a poorly-defined grand idea, but they themselves will contribute nothing but the idea--no programming, no artwork, no anything. They might do some story work, but that's trivial; it's also counterproductive, because if you can't put a goal into words you can't write for crap either. So if you're going to recruit for your project, you need two things especially: 1) A clear, well-stated goal or design document that lays out the way this game will stand out, what essence will give it its unique flavor. 2) A job for yourself that isn't pointless. You need to contribute more than ideas, story, or supervision. If you're a lousy programmer, artist, or sound effects guy then learn to be good, or at least competent, at one of those things first. For my part, I've often found that my goals tend to be pretty vague until I've reached some critical point in a project, and then its true style becomes clear to me. Most of the posters in CA haven't pushed their idea past conception yet, and they aren't ready to recruit. Once the game starts taking on more of a basic shape, even though the artwork may be lousy stand-ins and the gameplay may be rough, it may have enough of a unique feel at that point to finally warrant bringing contributors on board. And at that point, not only has the author proven they can contribute something themselves but they can probably describe what makes that project special. (That's a programmer-centered view of course; if you came at it as an artist, I'd recommend taking all your great icons and building a set of still images that can convey the kind of gameplay you want.) Lummox JR | |
This is a very interesting topic, and one that I have been wondering about for quite sometime. I have been looking for help on a project that I have been very dedicated to and working on for... years. I am by no means a programmer. The little programming I do know how to do is very basic from what I learned from the DM guide and the various projects I have worked on. But I am (In my opinion) an excellent mapper, and I am pretty good when it comes to icons (Not amazing, but decent enough).However, when I begin to set up my ad for help with programming, I find that I always get stuck on how exactly I should go about it.
Perhaps, since you all seem to be experienced in this, you can give me tips on how to improve my ad so that I may be able to find more help or the help that I ma looking for. (Generally so far, I have not been able to find the help that I need.) And maybe hopefully this will help others who have the same issue I have. Everyone always says that you should just go to the BYOND forums and there is help. But it seems to b harder and harder to find the right help. OR help that is experienced enough to do the job. This is my post! I am also having trouble making a design document. I don't know enough about programming, to really get into technical detail about what I would like added to the game and how It should be added. I can see how it would work in my head. I can explain it in a very simplified way, but I cant do it in a specific way that would make for a good design document. Perhaps someone could help me with that as well? Edit: By the way, if you require any more information or need some way to contact me personally to go over how I can improve this, please feel free to ask, I am more than happy to give my contact information, or additional details about the project. (I'd really love to see this project lift off and become finished so any help is appreciated.) | |
HuntsMagic wrote:
I am also having trouble making a design document. I don't know enough about programming, to really get into technical detail about what I would like added to the game and how It should be added. As I mentioned, I do not think that this is actually what the design document should be like. The programmer should translate English (or whatever human language you're using) to the programming language of your choice and evaluate if something is possible or not. If it's not, the programmer might suggest alternative concepts that resemble the original idea, but would be easy to implement. HuntsMagic wrote: I can explain it in a very simplified way That should be fine, as long as you're not talking about 'we'll have a battle system'-sort of simple. HuntsMagic wrote: Perhaps someone could help me with that as well? I think that you might want to try Chatters. As long as you can stand some rough jokes and some harsh feedback, you can actually get some constructive criticism and decent ideas from this resource (depending on the time/people on-line). Optionally, without being anywhere close to decent, I'd sure give it a look if you contact me on the pager and can link me to a resource like a BYOND forum or Google Docs that doesn't require any other software than the browser to interpret (I'm not going to install Word or the like, sorry). | |
The additional benefit is that there is structure and everybody knows exactly what they're getting into before touching the project, thus avoiding discussions and drama later on.
If you're going to tackle additional aspects of the game development part, such as programming, art, hosting, or promotion, then a little mock-up would seem to work wonders as well.
The better your concept and your abilities in showcasing the project, the higher the quality of those willing to work with you. That is, not to mention monetary resources benefiting the task as well ;)