The mechanics that support the game play should only be as complicated as the game play requires; this is especially true if the supporting mechanics are visible to the player.

Simpler design lends to being intuitive for players to learn, which is a very desirable trait for your game to have.

complex mechanics are not what makes a game fun...game play is.

Agreed, great example and good use of available input.

In novel-writer land a poll equivalent to the top question is a pretty common topic. The responses seem to be about 40 : 60 (people who plan before writing : people who start writing and do any planning during writing or revising)

I feel like the poll didn't allow be to answer one of the questions accurately:

What is prototyping to you?

The actual nature of the prototype depends on the subject. Typically, the first prototype will be completely minimalistic - the lowest-fidelity representation of the system which still allows it to be experimented with in a way which will transfer meaningfully to the final system.

If I have an idea for a control scheme, weapon/skill, AI behavior or something of that nature, the minimal prototype may be something interactive created with a scripting language. I will no doubt be using terrible placeholder art - stick figures, stolen sprites (non-animated) or boxy models.

An idea for a graphical effect may be testable in Photoshop. I've tested ideas for shader-based effects using a scripting language like Python. The prototype may not even run in real time, but it allows me to gauge the results and play around with ideas more easily and in a more productive environment.

On the other hand, it may be possible to effectively play around with the idea using a few improvised props (bits of paper, game pieces etc). Turn-based battle system? Play with a friend on paper.

In fact some systems are very nebulous, and a typical interactive prototype may not make much sense. A skill or development system, for example, generally works in terms of abstract inputs - the player kills an enemy of level X, the player spends Y points on a stat, the player casts a spell Z times etc. To build a representative prototype of this might require you to implement shallow versions of all sorts of related systems such as combat, movement, casting and so on, simply to provide input to the system you are actually trying to experiment with. Suppose you want to estimate the rate of player growth or damage against enemies of various levels resulting from a particular character development system you have in mind - does it make sense to spend hours artificially grinding away in an interactive prototype? At this point you're probably better off using a spreadsheet! (After all, that is how the most obsessive players will be calculating their optimal builds anyway...). Of course, this is still a system you'll want to playtest, tweak and balance once the related systems (combat, casting etc) are actually implemented and you can put it in its proper context.

Finally, prototyping a game may not be the same thing as prototyping a single system or mechanic. Generally, my actual approach to beginning design / development of game is more like the following:

• Have an idea. Make notes. Over a short period of time, I will begin to develop a broad vision of what the game will consist of. Keep a notebook and continue to make notes of new ideas in off-time throughout the following steps
• Prototype the core mechanics. Often this consists of basic control / combat, implemented with placeholder art in Python. Play around with it. If it's engaging, consider going further with the idea. I believe that the very act of interacting with a game or controlling your character should be satisfying
• Create a "playground" area. Usually hacked together with what I expect to be the final development language. For a side-scrolling platformer, first create a character floating in thin air. Then add basic movement. Then perhaps a floor. Then a box to climb on to. Then walls. Then maybe a simple enemy, etc, etc... Basically, populate this test area with new game entities as you create them, to provide an accessible way to play with them
• More brainstorming of specific mechanics / abilities. As I now have my playground area, I can often prototype these ideas with minimal effort
• Think more seriously about the world, the mood of the game, its setting, the people / factions involved, what messages I want to get across etc. I've usually had some sort of vision for this in my mind since the beginning of the process, but now begin to build it around the gameplay in a meaningful way. New factions may give me ideas for new game mechanics, and vice versa
• Clean up the code. Some sort of save/load is usually implemented at this point, which allows the playground world to become one of several test worlds or mockups of planned scenarios

For example in my current game (a space shooter), I decided that I wanted some kind of robot faction. Thinking about this led me to the idea of networked swarms of ships. I knew about flocking/swarming AI, so tried that out in my playground area, using a spreadsheet to help me come up with reasonable initial parameters for the algorithm. It looked pretty cool, but then I considered the possibility of the robots spontaneously splitting/joining/reassembling with nearby teammates in flight. This turned out to be very interesting when prototyped, and actually added some more strategy to the combat. This splitting/merging mechanic was born out of a combination of thinking about the lore (how such a robotic race might work using self-assembling nano-robots) and playing with the earlier prototype of basic flocking behavior.

In my humble opinion, "design vs development" is quite a false dichotomy. The actual process is more like this...

Step 1 - Ideas Generation

This is the "fun'' part of making games. Often mistaken for "design" (Tom Sloper Lesson 14). I dream of different game ideas, stories and mechanics. I used to write a lot of details out on paper but don't do it anymore because I keep having to make major changes or drop nonviable ideas.

Step 2 - Prototype

This is one of the "hard" parts. I pick an idea from step 1 and test/prototype to see if it is viable or works like I imagined. I had to go back to step 1 several times when my idea turned out to be not viable or not what I expected (which is why I stopped wasting too much time writing extensive details in step 1 without testing). The prototypes/tests are never "playable demos". They are often not playable implementations for my own use only.

Step 3 - Develop

Step 2 tests which ideas are viable and which technologies (programming languages, engines etc) to use. Once that is done, its time to actually make the game. This is another one of the "hard" parts.

Sometimes I have to do "heavy" development. E.g. I recently had to write a node.js web server from scratch for my multiplayer game. But this is always done with the design of the game in mind. There is no "generic" web server or engine that programmers churn out from a fixed blue print. The design is deeply intertwined with the programming. After that, I switch to developing the client-side or "front-end" while at the same time, adding complementary features to the server-side or "back-end". Once again, the game's design is so deeply intertwined with this process: I have to test what works and what is doable, then edit my game's mechanics and story accordingly.

Conclusion

Each of the 3 steps both requires "design" and is influence by "design". I am not sure if it is possible to separate "design" out into a standalone activity.

I try to spend as little time in design-mode as possible.

That's not to say that I don't like design or engage in it, but I definitely focus on development, and I go through a ton of iterations of whatever game I'm making. I'd rather not spend too much time thinking about how to implement a mechanic or an idea that I ultimately can't find a good place for, and thus wind up crowbar-ing it into my design (which so rarely makes for a good gaming experience); and so I prototype almost constantly. As I figure out which mechanics work with each other and fit the overall feel of my game, I implement them.

I should note that I've learned not to get attached to any of my ideas--I've thus far tossed out (or put on-the-back-burner) more mechanics than I've implemented (and been satisfied with).

When I think about a game concept I get vast ideas because of my study in game reviews, playing games, observing some techniques and even reading stories. But when we make a very creative and vast concept there comes the limitation of coading.

So just thinking most crative things and idea leads to waste of time because finally you have to design your game under the limits of codes.

Hope designers will agree on this point.

I think that every Design begins with a better video-demo ,
which will show the Idea and Vision of the Chess Field.

As of right now to think about KickStater.com :
who have Amazon account - USA and UK (I with UA)

Assassin Creed because the team of about 700 people,
so Space is better, because that requires less people in development,
but Need more Intelligence and AI for NPC too .

Twin Shadow Interface

">

Cancel Button of 3D Voice

@Morphia: I honestly didn't fully understand what you said but I did my best to dissect and reply to it.

I think that every Design begins with a better video-demo ,
which will show the Idea and Vision of the Chess Field.

Again, I disagree with this approach due to my fundamental approach to design/development. I know I am among the minority who believe in a design heavy/design oriented foundation.

I do NOT feel a proper design begins with a "video-demo". I begin with sketch and written prototypes which won't go post that until I feel I have enough down to get ready to develop the mechanics and features. I'm usually very thorough and detailed which works just fine fire me.

Idea and Vision of the Chess Field.

I'm assuming you're equating a design/project to chess. Meaning a video demo is a good way of showing the scope and range of your design/project. I agree, it is just not for me and doesn't work out with my way of processing things mentally or physically.

As of right now to think about KickStater.com :
who have Amazon account - USA and UK (I with UA)

I'm not entirely sure what you meant to say by this.

- You're with Ubisoft North America?
-AC3 has a "video-demo" on kickstarter?

That's great, I'd be honored/amazed to work for such a well established company. I hope the project goes well?

Cool, I've been meaning to give kickstarter a visit. I may have a reason to, now that I'm curious about the way ubisoft may have laid or their proposal.

Assassin Creed because the team of about 700 people,
so Space is better, because that requires less people in development,
but Need more Intelligence and AI for NPC too .

Space as in the larger team quantity works out best considering what they are undertaking?

More specifically:

Assassin Creed because the team of about 700 people

I disagree once again. There is an article on UE4 in GameInformer (Start Your Engines: Introducing Unreal Engine 4) which states my opinion on why bigger teams in the industry are a waste.

It leads back to my comments on efficiency:

[rollup='My stand']wodinoneeye, on 21 Jan 2013 - 10:31, said:

The nature of your 'idea' will significantly effect any answer you can get. It is a paradigm shift that noone in the industry will seriously consider

...or that many within the industry will commonly apply in practice. Even if the shift were to begin occuring, it won't be largely supported/practiced by many in the western culture (for atleast another decade as you said).

?§•??§?

This is (in my opinion) because physical examples are collectively malleable and have assessable traits which can be agreed on across the board. That allows for things like realistic deadlines, budget constraints and tools/technological capabilities/ceilings to be calculated.

Our (as in you and I),proposed means of operation implore thoughts in place of physical examples. Ideas/thoughts have all the capabilities of physical examples and more due to being infinitely malleable/nebulous by nature. This poses infinite problems as well as infinite possibilities which is a playground few would dare tread on.

?§•??§?

Two things have to occur for this to become plausible in a professional setting. Again, this is all opinion:

This ties into part of the point that Kylotan was making when he said:

Kylotan, on 21 Jan 2013 - 11:28, said:
All you are really saying is that game designers have not learned how to be very good at their job yet. This is because we don't really understand games very well. If people truly understood games fully, it would be possible to produce a precise design that a programmer could turn into a completely functional and playable game.

As a side note, Kylotan, I loved what you said here (mainly how you said it):

Kylotan, on 21 Jan 2013 - 11:28, said:
the point was that anybody who is truly involved in the design process is also truly involved in the implementation process.

One of these things that would have to occur would be advances in communication and iteration techniques/skills across the board for all disciplines.
______
That means more diverse education within each member off a team. Everyone would need to have a decent grasp of everyone elses discipline while having a strong sense off their own, allowing them to realistically process as well as pass on ideas. If each member can atleast grasp a sense of what the ramifications of their own work can cause a coworker, things become more harmonious by principle. They can both minimize conflict as well as constructively contribute through suggestions or streamlining of the others work.

The second would be a stronger sense of poise and discipline to allow the "treading on an infinite playground" to be plausible.
______
If every single member of the group is equally dedicated to maintaining a certain level of poise and discipline, never letting it falter below that level,certain things become less of an issue. If this level of focus were carried out in all their actions, priorities become simple to meet, giving more time to delve into extra content or focus on quality. There wouldn't be any restrictive time constraints or fear of not reaching deadlines. This fear and pressure alters behaviors and forces certain common results which tend to weaken the quality of projects. A deadline wouldn't need to be established/required in this sort of environment because the time frame will realistically present itself (and be accepted or dismissed) if everyone is working at peak performance.

As a side note, peak performance does NOT mean worked to point of high end negative (there are forms of positive) stress. Peak performance is when your resolve/poise is in harmony with your surroundings/environment.

The other thing that would be less of a worry is budget constraints. I'm not saying a budget isn't required, that's ludicrous. What I'm saying is that if money wasn't the primary focus, people wouldn't be as greedy. AltarOfScience commented/contributed handsomely to this point:

AltarofScience, on 21 Jan 2013 - 14:50, said:
Well one major problem is how little entertainment success has to do with the product itself. So much of it is tied up in name recognition, popularity, marketing, and other such nonsense.

You really only need a baseline quality in a product and then its all about perception and marketing.

This means a budget can be managed more conservatively without the need to compromise quality or over indulge in salaries. In a sense you wouldn't feel the budget cap nor would you be stressing over the minimum required assets to see a project through if the product came first and potential gross/marketing/popularity came last (not second). <~~~ Ahh, if only people were that unanimously passionate, uninhibited, motivated, dedicated and inspired by their work. We would have such a rise in quality (of product, work ethics, happiness?) and progress within the industry.

?§•??§?

They are obviously farfetched ideals/principles to implement in western culture, but not entirely unrealistic in my opinion. I know that my reason for having these standards as a person aren't normal or common. Alot of it is derived from about two decades of traditional martial arts training. Basically, I don't expect everyone to become Vulcans, able to mind meld in order to share ideas exactly as they envision them. I also don't expect everyone to adopt a monks sensibility and work ethics. Its a nice thought though lol

Adding these principles to practice would effectively cause a sense of infinite potential in my opinion. But I'm a pragmatic realist (for the most part I like to dream too!) and the world isnt perfect. There will always be limitations. Allowing ideas to be more affluent within a proffesional environment and loosening the safe:risk ratio won't cause this fact to magically ceast to exist.

Another part which sparked something within me was:

wodinoneeye, on 21 Jan 2013 - 10:31, said:
DO you know it will work ? Thats sometimes the hardest of all -- to realize an idea just wont work (or rather work in the right way so players would actually want to play it).
---
Ideas ARE a dime a dozen, but demonstratable ideas cost alot more...

..and as convenient as interactive/demonstrable ideas are, they can simply be unrealistic/implausible/unfeasible/impractical to develop JUST as a demonstration tool.

?§•??§?

This is what I was trying to put into words when I was originally flamed and accused of "too much dreaming and not enough doing".

My stand was (and probably still is) mistaken for a lack of willingness to flesh out a prototype. The fact is that I an not willing to flesh out a prototype specifically for the sake of demonstration.

It can be argued that a prototype specifically for demonstration, would be work done towards your project (as experience if nothing else) and can ultimately be used within the final product. But as you so elegantly put it, demonstration of the material kind are expensive and time consuming. So much so, that the scope/scale of something as I wish to develop, would not allow it and could quite possibly rendering it pointless. The amount of time and effort I'd spend even producing a prototype could easily cause an overlap of technology, cultural relevance, fall steeply under the trend curve as well as be out developed by up and coming concepts.[/rollup]

because that requires less people in development,

but Need more Intelligence and AI for NPC too .

What requires less people in development?

I can see how a dedicated team for AI would benefit a project (if you can afford that kinda stuff, which I'm sure if anyone could, it'd be Ubisoft lol). However, I still don't think it justifies a team of such magnitude.

SinisterPride :

I think you are trying to gradually understand me!
Vision of Gameplay as the ChessBoard: it is soonely the word-revolver.
I know people who from UbiSoft , but I did not say that I work in UbiSoft.
That is, you did not watch the video - you, like most of the other all the same, or more then one computer bots (programs), because of your text is not true. And I said that we needed to account for AmazonPayments for Kickstater.com, well, where does UbiSoft - unless you understanding, I would say that I am Freelancer - Independent Manager (yes GameDevIndustry modern companies - just a "modern trash"). In translation: better to act. Will Write one hundred thousand Theme than those in the text and a Zero Result in the End. In EpiEnd none GameProduct and none Money : eating text or other it ?!

What was done on GameDev.net or GameDev.ru : nothing .. tell me again of Orientation of this Forums .