是設計遊戲還是隨便拼湊一個內容?

作者:Lewis Pulsipher

這是有關遊戲設計的一個重要主題:你是否在設計一款遊戲還是隻是隨便拼湊了一個內容?創造性是遊戲設計的組成部分,但是它只佔整體遊戲設計的10%。剩下的幾乎都是關於工程:你需要明確問題和適當的解決方法,執行解決方法,測試這些解決方法的結果等等。科學方法是包含於測試中,工程則是包含於解決方法中。有時候纔會出現靈感與創造性。

不要猜測

遊戲設計絕對,或者不應該是關於反覆試錯。我正在使用年輕時非常流行的一種方法:猜測什麼是可行的然後觀察結果。將這種方法稱爲“猜測與覈查”,因爲現在似乎存在有關這種形式的科學方法,即試錯法。但事實上,這就是猜測。而遊戲設計並不是關於遊戲猜測(儘管在其它創造性或工程行動中,你有時候也能夠幸運地猜對某事)。

讓我們使用一個來自入門編程班的例子進行說明。我曾因爲一位大學老師生病了而代替他去爲新手們上了一堂編程課。在計算機領域,雖然很少人會成爲程序員,但是所有人都需要學習一些編程知識。因爲班上的學生已經有正在編程的簡單內容,所以我只需要在課堂上到處走走提供適當幫助便可。

我們都知道編程是非常有邏輯性的,所以並不能遵循K12的教育方式。當編程不能有效進行時我們能給予的最恰當的迴應便是明確編程流,找出哪裏出了問題,改變程序,並測試解決方法。在遊戲設計中也是如此。我們創建原型的主要目的便是識別問題並測試解決方法。這包含了一些直覺性,而解決方法也包含一定的創造力,但從更大程度來看還是關於邏輯。

而除了嘗試去識別爲什麼程序不能有效運行外學生們還能做些什麼呢?他們只能進行猜測,並根據自己的猜測去改變編程,然後再次運行去查看結果。如果這種方法不可行,他們便會猜測其它方法。他們會使用傳統的試錯法,進行猜測然後覈查,當然他們最終會因爲結果不可行而受挫。所以比起猜測我希望告訴他們去明確編程的邏輯性與流。

遊戲設計亦是如此。有些人並不像我所說的這樣設計遊戲,但其實這纔是最有效的方式。當然不同人會有不同的設計方法。即比起邏輯有些遊戲設計是源自設計師的直覺。但這也仍然是關於假設與測試:如果你正有條理地使用自己的腦細胞在設計某些內容,我便希望你不只是完全依靠於自己的靈感。

靈感是不可靠的

靈感是非常不可靠的。“當靈感到來時我們會覺得它非常美妙,但作家自己卻需要爲沒有靈感的其它時候買單,等待靈感的時間總是非常漫長。”靈感既會到來也會離開。如果你能夠更多地將遊戲完善看成一個工程問題,你的效能便會更大地獲得提高。

有些人可能會認爲比起工藝,遊戲更像是藝術,如果你也抱有這種想法,你便會想依賴於靈感與直接去設計遊戲。所以我們會說你不是在設計遊戲,而是在創造遊戲—-儘管當你擁有一個可遊戲原型時遊戲就會變成一件工藝。如果你做得不錯的話可遊戲原型真的會很有效。你並不能朝牆上扔遊戲設計去看看它是否具有粘性,這便是試錯法會使用的方法。但事實上這卻是一種非常糟糕的解決問題的方法。

爲什麼人們要這麼設計?

當我在創造本文的視頻版本時我並未意識到猜測與覈查方法如此普及。不幸的是遊戲玩法的改變導致更多人去使用試錯法。

當我還是孩子時(即50多年前),我會去尋找那些需要通過思考才能獲得成功的遊戲,那也不是什麼抽象遊戲。最經典的便是象棋和西洋棋,不過它們都過於抽象了。我需要的是一些更現實的內容。最終Avalon Hill的戰鬥遊戲彌補了我的需求,還有之後的《外交》。

隨着電子遊戲的出現,比起腦力工作,遊戲更多地傾向於運動技能。不管你有多聰明,如果你不能擁有快速的反應能力和靈活的手眼配合,你便不能有效操控一款電子遊戲。

此外,電子遊戲更傾向於單人玩家益智遊戲,即通常只存在一個正確的解決方法。所以很少會有關於人類對手的替代品。

當你在玩一款敵對策略遊戲時(通常都是桌面遊戲),你不能只是猜測該做什麼。而現在我們擁有許多單人玩家與合作型電子遊戲,即玩家可以按照自己的意願去扭轉敗局。許多玩家會嘗試各種不同的方法去找出最有效的方法,然後使用該方法去迎接下一個挑戰。他們只需要通過猜測與覈查便可。但這卻是非常荒謬的!相反地,有些遊戲是伴隨着在線幫助功能。如果某些內容不能有效運行,玩家將尋找最佳方法去“戰勝”它,然後繼續遊戲。但這類心理是與你在設計一款遊戲時的心理相反的。

此外,隨着90年代末歐洲風格遊戲的出現,我們開始進入平行競爭的時代,即玩家將嘗試着去解決同樣的謎題。儘管存在許多不同的解決方法,它們也仍然都是一些正確的解決方法。許多桌面遊戲變成了謎題解決遊戲。玩家將學習如何尋找解決方法,因爲他們不需要再擔心對手了。

在設計遊戲的時候,你最好添加一個“保存遊戲”的選擇。因爲你可以嘗試你所設計的解決方法,而如果你發現它並不可行,你也可以回去使用之前的老方法。但這將耗費你許多時間。也許你擁有很多時間去猜測改變,但我卻沒有,那些爲了生計而設計遊戲的開發者也沒有這樣的時間。

同時你必須清楚總是存在最佳方法(遊戲邦注:在益智遊戲中便是如此)與需要在不確定的選擇中做出決定是截然不同的,就像在經典的戰爭遊戲中那樣。比起解決謎題,遊戲設計更多的是關於解決問題。在這裏很少存在總是對的解決方法。

關於如何遊戲的改變的結果便是,許多想要成爲遊戲設計師的人學到了設計遊戲的錯誤方法和錯誤技能。當然並不是所有人都是如此玩遊戲,但的確大多數玩家是這麼做的。

用球擊牆的方法

我已經看過有關用球擊牆的方法。最近桌面遊戲設計新人所創造的包含紙牌和分數的簡單多人遊戲(30分鐘)便讓一些新玩家進行測試。這款遊戲在Kickstarter上獲得了成功,但顯然它還未真正完成。遊戲中的大多數紙牌都是手寫的。設計師並未在遊戲中添加規則。我問他爲什麼呢?他的回答是,自己以6或7種不同方式去玩遊戲,並且通過不斷修改去滿足支持者們,所以他才未添加任何規則。

也就是我們所看到的是一款在Kickstarter獲得成功但卻擁有未經測試的手寫規則的遊戲。而當他說自己正在嘗試一個特殊規則時,我的反應則是當剩下的遊戲還不穩定時你又怎麼去嘗試做出改變呢?你只是嘗試着去改變衆多遊戲方式中的一種而已。當你開始測試遊戲時,你所測試的是整款遊戲而不只是你想要測試的那一部分。如果其餘內容仍將繼續發生改變,你又該如何去評估一個改變所造成的影響呢?

我的下一個問題是,你是如何記錄遊戲測試結果的?他回答道,他通常是記在筆記本上,但同時他也有檯筆記本電腦並會在被淘汰出局時在上面做記錄。可以指出的是這是一款包含玩家淘汰的遊戲,這是現在很少遊戲會使用的機制,特別是在一款30分鐘遊戲中,這同時也是一款計分遊戲,但是他去並未使用任何計分設備,所以所有人都只能在自己的智能手機上計分。

雖然我說過像玩家淘汰等顯著問題,但除此之外還有另一個問題。這是一款關於直接攻擊其他玩家的紙牌遊戲。遊戲並不會限制你該攻擊誰,如果對於玩家能夠攻擊哪些類別的對手的限制越少,玩家在任何時候能夠發動最強攻擊的對象將會是特定玩家而不是任意其他玩家。遊戲中主要有5或6個玩家。當我在做其他事時我便不會去留意遊戲。之後當我詢問是否有可能攻擊其中的leader時,我所獲得的答案則是可以。看來這是一款關於攻擊leader的遊戲。我不知道設計師是否會認可我的這一形容。隨後人們便可以提出有關攻擊leader的解決方法,而其中的攻擊周邊玩家的方法將破壞這款最初在Kickstarter獲得成功的遊戲。

需要注意的是,爲什麼攻擊leader是不可行的呢?因爲這將消除遊戲的策略型決策制定,玩家將只是去攻擊leader。這會導致玩家在結束前都不希望自己成爲leader。實際上考慮到遊戲屬性,這裏並不包含決策制定。玩家可以選擇自己最強大的攻擊去影響其他玩家。我並不是在反對那些簡單,甚至可以說是膚淺的遊戲,它們同樣也可以提供給玩家多樣的選擇以及像傳統桌面遊戲那樣的“兩難局面”。但這款遊戲卻並非如此。

該設計師繼續嘗試了各種方法去看看什麼方法最有效。對於我來說這便是一種試錯法。這也說明了Kickstarter比起真正的遊戲更加看重理念和目的。

“科學方法”/工程

現在讓我們簡單說說如何進行這部分的設計,即不只是嘗試這樣或那樣的方法,也不是進行各種試錯。我使用了詳細的圖解。這是一個工程設計過程。這同時也像項目管理,因爲在項目管理中每一次你所做的事都與你之前做的有所不同。我便打算在這裏討論這一較簡單的項目管理。

Plan-Monitor-Control-Replan cycle(from gamasutra)

Plan-Monitor-Control-Replan cycle(from gamasutra)

計劃是關於創造一款遊戲直至擁有一個可遊戲的原型。

執行是關於嘗試這個原型,首先一個人,然後讓其他人進行嘗試。

當別人在玩遊戲時,你應該觀察他們是否按照你的想法在玩遊戲,是否按照你的計劃在玩遊戲。

當你發現玩家並未按照你的計劃在玩遊戲時,你便會做一些事去糾正它們的做法,這便是控制。

成功調整後你將進行重新計劃,即你將修改你的原型。然後你將回到執行階段並再次嘗試原型,你將不斷在這個週期中循環着,直至最終創造出一款更出色的遊戲。

我並不喜歡“迭代”這一詞。沒錯,這的確是一個迭代過程,而雖然迭代這詞經常出現在電子遊戲中,但是它卻只包含你所做的所有事情的一半內容。你是在進行修改與測試,而不只是反覆遊戲。這裏也包含了科學方法。科學方法包含了通過觀察與試驗獲得的種種數據以及對於假設的構想與測試。

而遊戲設計不只是如此。與科學家不同的是,大多數情況下游戲設計師需要依賴於相對較少的測試。(遊戲邦注:如今在電子遊戲中我們可以看到一些“開放beta”測試,發行後的測試以及分析統計方法。)與科學家不同的是你將在設計中做出改變,並通過試驗去觀察結果。幸運的是這是一種可用性測試而非科學測試,而可用性測試通常都不需要大量嘗試。我建議你能看看Nielsen Norman Group網站並瀏覽他們的文章。他們經常會談論有關網頁設計可用性,並且他們所說的的內容都能夠有效作用於重視用戶界面的遊戲設計,特別是電子遊戲設計重。我們的桌面遊戲便擁有用戶界面,但這些內容卻在很早前便已經定下來了並且不會輕易做出改變。

類比

作爲一個缺乏想象力的人,我通常不會冒險進行類比,但在此我還是想嘗試看看。關於工程與試錯法的問題可以與人們如何學習軟件或家用電器或電子進行比較。而與大多數人不同的是我會去閱讀各種手冊。而令人驚訝的是基於這種方式你可以有效學到多少東西。但似乎大多數人都是淺嘗即止。

基於工程風的遊戲設計就像閱讀指南那樣,而試錯法則像埋頭去嘗試某些方法。與大多數希望別人來教自己的人不同,爲了能夠了解一款桌面遊戲我會嘗試着去閱讀規則。或許這可能會花費更長時間,但比起別人來教授,當我親自閱讀規則時我能夠更透徹地去了解一款遊戲。

我曾在Udemy.com上的“學習遊戲設計”課程中討論過測試和修改的過程,那裏也有關於遊戲測試的課程。而本文的要點是希望你能夠遵循一個以解決你所明確的問題爲重點的過程。你同時也必須清楚什麼問題可能會出現,如紙牌遊戲中的攻擊leader,這也是我爲什麼要製作這麼多視頻去教授人們有關任何可能出現的問題的原因。

方法總是很重要,但除非你別無選擇了,否則不要輕易去嘗試試錯法。直覺或靈感總是能夠賦予你更多優勢,但這並非我想要教授給那些有抱負的遊戲設計師的內容。如果你認爲遊戲設計便是關於靈感,你便大錯特錯。你必須基於始終如一的基礎去致力於某項工作,而不是寄託於那些隨機跳出來的靈感。

作爲一名老師,我希望人們能夠清楚,“靈感”,“直覺”,特別是試錯法並不是一種真正有效的好方法。

本文爲遊戲邦/gamerboom.com編譯,拒絕任何不保留版權的轉發,如需轉載請聯繫:遊戲邦

Are you designing a game, or throwing one together?: You can’t design a game as though you were playing a video game

by Lewis Pulsipher

This is a vital topic in game design: are you designing a game or you throwing one together? Yes, creativity is part of game design, but it only amounts to about 10% of the whole. The rest is more or less engineering: you identify problems and propose solutions, implement the solutions, test the results of those solutions, and so on. Scientific method is involved in your testing, and engineering is involved in your solutions. Occasionally inspiration and creativity are involved.

Just Say No to Guessing

What game design definitely is not, or at least should not be, is trial and error. I’m using the meaning that was prevalent when I was young: guessing what might work, and then checking to see if it does. I now call it “guess and check”, because there seems to be a notion today that trial and error is a form of scientific method. No, it’s guessing. Game design is not a guessing game (though as in all other creative or engineering endeavors, sometimes you get a lucky guess).

Let me use an example from a beginning programming class to illustrate. While I was a college teacher I substituted for a teacher who was ill, in a programming class for beginners. Many the people were not going to become programmers, but everybody was required to learn some programming, which made good sense in a computer department. The students in the class already had a program to work on, a simple one, so I walked around trying to help in general, as their programs didn’t work.

This is not surprising. Programming is very logical, and people often are not taught logical methods in K12. The proper response when the program isn’t working is to figure out the program flow, identify where it went wrong, change the program, and test the solution. It works the same way in game design. Much of the purpose of playing a prototype is to identify problems and test solutions. This includes some intuition, and the solution might involve some creativity, but mostly it is logic.

But what did the students do rather than try to figure out why it wasn’t working? They just guessed, changed the program in accordance with their guesses, and compiled/ran it again to see what happened. If that didn’t work, they guessed something else. They were using traditional trial and error, guess and check, and they were frustrated, of course, because it wasn’t working. I tried to show them how to figure out the logic and flow of the program rather than just guess.

Game design ought to be the same way; some people won’t do it that way but I think it’s the most efficient way, and it’s the way that I like to teach people. Certainly different people have different design methods. Some design more from the gut than from logic. But it still involves hypotheses and tests: if you’re actually designing something you are primarily using your brain in an organized way, I hope, and not just relying on inspiration.

Inspiration? Not Reliable

Inspiration is not very reliable. “Inspiration is wonderful when it happens, but the writer must develop an approach for the rest of the time . . . the wait is too long.” (Leonard Bernstein, the composer and conductor – and writer.) Inspiration comes and goes. The more you treat the modifications of your game as an engineering problem, the more efficient you’re going to be.

Some people may think of a game as art, rather than craft, and the more that you think of it as art, the more you might be inclined to rely on inspiration and intuition. So we might say that you’re not designing a game, you’re creating a game, though it’s mostly craft once you have a playable prototype. A playable prototype is going to change a lot if you’re doing a good job. Game design is not throwing things against the wall to see if they stick, which is what trial and error and error amounts to. It’s “try this and see what happens. Then let’s try that and see what happens.” Some things might happen better than others, but it’s a terrible way to solve a problem.

Why Do People Design This Way?

When I did the video version of this piece, I had not realized why this guess-and-check method might be common. Unfortunately, changes in game playing have led to much greater use of trial-and-error (guess-and-check) than in the past, and to puzzle-solving rather than problem-solving.

When I was a kid (more than 50 years ago) I searched for games that required you to think to succeed, but which were not abstract. The classic games such as chess and checkers were just too abstract, I wanted something that represented, modeled, some (possibly fictional) reality. Avalon Hill’s wargames finally filled the bill for me, followed by Diplomacy (for more than two players).

With the advent of video games, gaming became a matter of athletic skills more than brainwork. No matter how well you could think, if you didn’t have the reflexes and hand-eye coordination needed, you’d not be good at most video games. Video games were athleticware, not brainware.

Moreover, video games tended to be single-player puzzles, where there was an always-correct solution, owing to the inadequacy of the computer opponent. There was no substitute for human opposition.

When you play an opposed game of strategy, a game you can lose – which is usually a tabletop game – you cannot afford to simply guess at what to do. That’s the road to Loserville. But now we have so many single-player and co-op video games, games where you can save the game at will. Many players try lots of different choices to see what works best, saving each one, and then use the best to move on to the next challenge. They don’t have to figure out anything, they can just guess-and-check. In the extreme I know of someone who, finding a chest with random contents, will open it, save it, open it again, save it, and so forth, dozens of times, in order to get the best result. Ridiculous! Alternatively, some play games with online help open. If something isn’t working well, the player will look up the best way to “beat” it, and continue. But it’s these kinds of mentality that are the opposite of what you should be doing when you design a game. These mentalities amount to “throwing things against the wall to see what sticks.”

Further, with the advent of Eurostyle games in the latter 90s, we entered the era of parallel competitions (which I called “contests” in my book Game Design), players all trying to solve the same puzzle. Even though there were usually several different solutions (“paths to victory”), they were still always-correct solutions. Many tabletop gamers became puzzle-solvers. People learned to look for the solutions, because they didn’t need to worry about the opposition. Some games coming out of the Euro style transcended this, but most have not.

In designing a game, you do have, in effect, a “Save Game” option. Because you can try a solution you’ve devised, and if you decide it doesn’t work, you can go back to the old way of doing it. But this takes a lot of time (one playtest often isn’t enough to determine the success of a modification). Maybe you have lots of time to waste guessing at changes, but I certainly don’t, nor does anyone who wants to design for a living.

Furthermore, knowing that there’s always a best move (as it true of puzzles) is quite different than having to decide among uncertain alternatives, as in a typical wargame. Game design is problem-solving far more than puzzle-solving. There is rarely an always-correct solution in game design.

As a result of these changes in how games are played, many people who want to become game designers have learned the wrong ways of doing things, learned the wrong set of skills, to design games! Obviously, not everyone plays games this way (I don’t, even when I play a video game), but the majority of gamers do.

Illustration of Throwing Against the Wall

I’ve seen the throw-against-the-wall method dramatically illustrated. Recently a beginning tabletop designer had his simple, multiplayer, 30 minute game, which involved cards and scoring only, playtested by players new to the game. The game had already been successfully Kickstarted but clearly it was far from done. Most of the cards were handwritten (not even computer-generated) for example. He also made the error of playing the game without having any rules with him (to test the rules as well). I asked why? His response was, he played it six or seven different ways, and was also changing it to satisfy backers as well, so he didn’t bring the rules!

So here we had a game that was already Kickstarted and the rules writing wasn’t being tested. When he said he was trying out a particular rule change my reaction was, how can you try a change when the rest of the game isn’t stable? You’re only trying to change one of those half-dozen ways to play. When you playtest, you playtest the whole game, not just the part that you’re experimenting with. If the rest of it keeps changing, how can you evaluate the effect of one change?

My next question was, how are you recording the results of the playtest? He said he usually had a notebook, but not today, but he did have a laptop and he took notes after he was eliminated. (Yes, he played in the playtest, worse, without rules at hand. Bad Idea.) I can point out here that it was a game with player elimination, which is not desirable nowadays, even in a 30 minute game, and it was a scoring game yet he hadn’t bothered to bring the scoring devices, so everyone scored on their smart phones. This is just sloppy. You’ve got to test the actual game, not substitutes!

I’ve talked about some of the obvious flaws like player elimination, but there was another one. It was a card game of direct attack on other players. There was no overall constraint on whom you could attack; the lesser constraint involved categories of who you could attack that is, your strongest attack in your hand at any given time could only be aimed at some of the players rather than any of them, depending on their characteristics. They had about five or six players in this game. I didn’t watch the game much as I was doing other things. I asked afterward if there was a strong tendency to attack the leader, and the answer from the players was, yes. The game suffered from leader-bashing. I’m not sure the designer actually recognized the term when I used it, and only had a glimmering of why it was undesirable. People then started to suggest solutions to the leader-bashing, but the first, only allowing attack on adjacent players, would have pretty drastically changed a game that’s already Kickstarted! (I’m often critical of Kickstarted games because of the nature of the audience, but I’m really offended by the idea of Kickstarting a game that is so far from complete.)

As an aside, why is leader bashing undesirable? It takes the strategic decision-making out of the game, you just attack the leader. It makes people want to sandbag (if they can), they don’t want to be the leader until the very end. In fact, given the nature of the game, there was virtually no decision-making involved. You picked your strongest attack that could affect someone in or near the lead, and that was it. I’m not opposed to simple, even shallow, games, but they should still give players viable choices, the “horns of a dilemma” of traditional board games. This one didn’t.

To continue with this egregious example, what we have in this designer is a case of somebody throwing things against the wall to see what will stick. He tried to playtest the game in various ways to see what seemed to work better. It seems to me to be trial and error in the undesirable sense. It also helps show that Kickstarter is often about ideas and intentions rather about an actual game. He had a little bit of the art for the actual game for a small number of the cards and that looked quite good, and probably helped the Kickstarter a lot.

“Scientific Method”/Engineering

So let me talk briefly about the proper way to go about this part of design, not just trying this and that, not throwing things against the wall. I use a fairly detailed diagram and a simpler version. This is an engineering design process. It’s also something like project management, because each time in project management you’re doing something that’s rather different than what you’ve done before. I’ll discuss this simpler project management diagram here.

The Plan is about you creating the game to the point where you have a playable prototype.

Execute is playing a prototype, first of all solo, then other people.

While a game is being played, you Monitor whether it’s doing what it’s supposed to do, whether it’s going according to your plan, the vision you had in your head.

Control is when you monitor something that isn’t going to plan, you do something to fix it, to make it work the way you want to.

Successful changes go into the Replan, where you modify your prototype. Then you go back to Execute and you play it again, and you keep going round and round on that, gradually making your game better.

I despise the word “iterate”. Yes, this is an iterative (repetitive) process, but the word iterate, which is often used in video games, must be one of the ugliest words in the world, yet only covers half of what you’re doing. You are modifying and testing, not just playing again and again. The scientific method is involved. To be termed scientific, a method of inquiry must be based on gathering observable, empirical and measurable evidence subject to specific principles of reasoning. A scientific method consists of the collection of data through observation and experimentation and the formulation and testing of hypotheses. (Wikipedia)

Game design is lot more than that, though. Unlike scientists, in most cases you have to rely on relatively few tests. (Nowadays in video games we see “open beta” testing, and testing after release, in order to increase the sample size and use statistical methods of analysis.) Unlike the scientist you’re making changes in the design, an actual product, as well as experimenting to see what happens. Fortunately, this is usability testing, not scientific testing, and usability testing does not require a large number of trials. I strongly recommend that you check out the Nielsen Norman Group’s website at alertbox.com, and read their articles. They are talking about web design usability, but most of what they say applies to game design, especially video game design where user interface is very important. We have user interfaces in tabletop games, but they have over many centuries settled down and don’t change rapidly.

An Analogy

Being a literal-minded person, I don’t venture into analogies much, but I’ll try one here. This question of engineering versus trial and error (guess and check) is comparable to how people learn software or home appliances or electronics. Unlike most people I read the manual. It’s amazing how much you can learn that way and it’s far more efficient. But what most people do is a just dive in and try things, or they simply remain ignorant. I read the manual and find out all you can do (if it’s a good manual) that most people who just dive in and try things are not going to figure out.

The engineering style of game design is like reading the manual, the trial and error style is like diving in and trying things. It’s much less efficient, but it is easier, just like not reading the manual is easier, and we can apply this to games. I would rather read the rules to a tabletop game in order to learn it, unlike most people who would rather be taught. It may take longer, but I miss less when I read the rules and understand the game better when I read the rules, if they’re good set of rules, than when somebody teaches me.

I’ve discussed the whole cycle of testing and modification in my “Learning Game Design” course on Udemy.com, and there’s also a course just about Playtesting. The major point to make here is that you follow a process that relies on solving problems you’ve identified. You also have to know what kinds of problems might occur, like leader bashing in a card game, and that’s why I make so many of my videos to educate people about those possible problems.

Method is important, and trial and error (guess and check) is poison unless you have no choice but to use it. If you rely heavily on intuition or inspiration, more power to you, but that’s not something that I want to teach aspiring game designers. If you think it’s all about inspiration, I think you’re dead wrong, any more than getting ideas is all about inspiration. You have to work at something to do it well on a consistent basis. You can’t hope to be bailed out by random flashes of brilliance.

As a teacher I want people to understand a good, efficient method: “inspiration,” “intuition,” and especially trial and error (guess and check) are not good, efficient methods.

Design a game, don’t guess at it!(source:gamasutra