   Designing to the Cognitive Ability of the Player
  I'm in the preliminary planning stage for the development of a demo which I'll use to seek funding for my game. The demo requires a number of aspects, one of which is a programming-type module, instructing objects in the game to perform some actions.  My question is, if my target audience is 15-20 years of age, what level of cognitive ability can I expect from a game player at this age who has no "programming" ability?  Would they be able to understand conditional logic and events which trigger alternate paths of execution?The next question is, would the same group understand component design involving hundreds components?  Assuming the UI method for the organization of the components is well thought out, would this age group get overwhelmed by the number of components involved?  Is there any kind of upper limit where their is just too many components and therefore, too complicated to manage and play?The last question is more of a psychological question, from a 15 year old perspective.  While most games provide you the "technology tree" and you simply apply resources to achieve the new discovery, in this game the player is actually performing the research.  At what point should I expect a player to get bored or frustrated with the research/experimentation work that the game would demand that they perform?  What I was thinking was setting the game difficulty to "hard" in each of the modules within the game.  If they get into a module area that is too hard, they can relax the difficulty; or increase it if it is too easy.  Comments?Thanks.   
  You might look at The Incredible Machine as an example of a system designed for non-programmers which acts somewhat like programming and can get quite complex.  Also the tech tree of a game like Starcraft/Warcraft, I would say that's at the highest level of complexity most teenagers and adults can manage.   ;  Don't think of it as "can a random person do this".Think of it as "can I teach a random person to do this".If the game, step-by-step and in a fun way, teaches you how to do these complex tasks, people will be able to learn it.;  What about the number of components involved.  Could I have hundreds?  thousands?  Or is a few hundred (200-400) sort of a good working limit?   ;  40 tops. I wouldn't play a game that requires more time to read the manual (API reference?) than is actually spend playing it. I'm guessing I'm not the only one...   ;  Do you have a target market? Region, level of previous game playing, theme interests?   ;  Actually, there is probably 20-30 components to start with, but the player designs additional (and more elaborate) components as the game progresses ... to some upper maximum of a several hundred.  Players can manage the number by retiring old designs.   ;  A game you may want to check out is Armadillo Run. It starts with 10 introduction levels, teaching you a new item every level. A good way to explain items, I think your idea could use such an introduction type pretty well.If you create clearly distinct function blocks (audio box, fire igniter) as output blocks, and have the players trick wires between them and input blocks (buttons, whatever), and show bright sparks following these wires, to indicate activation signals, then I think you can cover a wide group. Sort of those system boards students get to play with during physics courses.As for the number of objects, that's something you have to play with. Ask some people for feedback, let them playtest your demo before you put it out. 100 sounds pretty much, but if the UI allows easy handling of them (for example, the clustering of such items to 'boards', and the connection of boards as meta-blocks) then players might be able to handle much more. That's a tweaking thing I think. In Armadillo Run, you can (and sometimes need to) use many objects, because they are all very simple and it's the cooperation between them that makes the structures work. Your demo sounds like it'll use more complex and unique objects, so perhaps there isn't a need for so much, at least not too soon.   