hi. im starting to write a new game design document and i have good new ideas. but now i think maybe there will be many poblems because i dont know the limitations. for example we dont know the limitations of hardware and devices and platform we want to work on. or we want to work on new engine like ue4 and we havent worked on it before or maybe all these things supports our gameplay but after spending a lot of time we find that we cant do this or it takes a lot of time to make it without buggs and fun. what should my vision be to write the documatation. as i know in most of the studios writers and designers dont have much technical information. what should i do? write the documetation and the team works and learns on it untill its possible or even if it takes lots of time or ....? thank you for helping

1. Decide the technology and platforms ahead of time. This should be simple enough. Talk it over with the team if necessary.

2. When looking at the capabilities of the platforms, look at other games on it. You won't see Halo 4 run on a tablet necessarily, but you will see Sonic 4 run on it.

3. No matter the amount of research, accept that things will go wrong. But hopefully your team and you will be able to work through the problems.

Note: I don't work in the industry. I just went to game college for awhile and am trying to use reason.

what you mean "accept that things will go wrong"? you mean most of the time even for proffessional big teams when they start a new gameplay they will have a lot of "test and fail as we say" and it cost a lot of time for all of them? as you know indie teams dont have much time like naughty dog spent 3.5 years on the last of us and i dont know how long of it was writing and pre productions. as i understand you mean only limitation is device.

what you mean "accept that things will go wrong"? you mean most of the time even for proffessional big teams when they start a new gameplay they will have a lot of "test and fail as we say" and it cost a lot of time for all of them?

Yes, I mean that. But I'm also of the mind that problems tend to happen when someone who has less technical knowledge than most team members take the lead. And I suppose that accidentally bleeded over into my post.

I've worked for people freelance who knew less than me, and I did the job to the key, but there was still complete failure. The problem was, the person making the design document and giving the orders knew less than I did, and that led to the failure of their product.

That's why I and a college graduate always talk about how we will never work for someone with less knowledge than us in the lead, without the right amount of pay. Sorry if this sounds pessimistic.

Not to mention, it sounds like your team doesn't know what they're doing, which adds to the problems.

Sorry if any of this sounds overly pessimistic, I'm just going blankly by what your opening post says.

I'm not sure of your setting, but if possible, it sounds like you maybe need to work based on experimentation mainly, rather than a cut and dry document. Have the most experienced member such as the Lead Programmer take lead of the technical stuff as it comes up.

My advice is a bit wishy-washy since the answer to everything can be "it depends", but I thought I remembered reading that a lot of experimentation went into the original Halo. There was probably a design document, but it seems like this was a game made through experimentation and testing as well.