Re: [討論] 現實中有能讓外行人提遊戲企劃的管道嗎

EricTCartman 發表於 2021/4/18 下午12:27:29

看板C_Chat標題Re: [討論] 現實中有能讓外行人提遊戲企劃的管道嗎作者

EricTCartman

(阿ㄆㄧㄚˇ)時間Apr 18 12:27:29 2021推噓15 推:15 噓:0 →:31

PTT評價

※ 引述《xsubarux (爆漿小雷包)》之銘言：
: 有沒有那種純粹提出企劃想法
: 再由公司判斷是否能實現的管道啊？

有，就是你自己當老闆，出一張嘴就好

: 我相信一定有一堆人有著很不錯的創意
: 礙於能力、經費、時間等因素無法實現

真的夠屌，有些遊戲公司內部也會提供管道，或者你有做出成績老闆就會相信你

: 還是說只能期望自己認識天才畫家、天才程式設計師、天才作曲家才能實現？

我覺得你這觀念很奇怪，為什麼不是自己成為天才設計師而是靠別人

不過大部分的鄉民講的話都差不多，大概有心的人也沒辦法獲得什麼有價值的提示

不過底下有人說得真好，企劃本身就是工程性質的，工程不是說你一定要會寫程式

而是要有一顆工程的心，例如有人企劃寫：

「遊戲中的怪物可以合體，變得更強大！」

這種描述，應該只會出現在GCD(game concept document)，通常是提案或市場面的

決策，GDD的寫法可能會像是：

「清除地圖上目標怪物相鄰的怪物，依照公式A計算修改目標怪物的數值，技能則參
照附錄N的M表格規則將被清除怪物的合體技能加入目標怪物的技能表中」

有些甚至會直接寫pseudocode或乾脆把excel表格的公式寫出來

不幸的是，不只遊戲業，就連軟體業不少人都不懂得怎麼寫規格、設計書，都要大家

通靈，或者是用歌謠把他真正的設計含意口耳相傳出來，讓現代社會文明直接倒退到

部落文明去

GDD要怎麼寫，網路上很多資料，從最基礎的遊戲設計理論到產業等級的

Level Up!: The Guide to Great Video Game Design

The Art of Game Design

Theory of Fun for Game Design

如果遊戲不是動作遊戲或需要時間反應的，倒不如直接做成桌遊，畢竟說到遊戲規則

書就不能不提TRPG，去看看DnD、CoC這些用人腦run的遊戲引擎是怎麼用白話文寫的

不過用瀑布式跟快速迭代式，企劃書的定位跟細節需求都會有所不同，數值企劃反而

比較吃重就是了。反正快速迭代式都要求你要做原型了，Unity太難，不如去學個

Game Maker吧，很多很屌的獨立遊戲也是用Game Maker做出來的

在有些遊戲公司企劃甚至要懂 BM(business model)

※ PTT 留言評論

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.107.108 (臺灣)

※ PTT 網址

推

xxxrecoil04/18 12:31企劃還有一堆分類咧

→

xxxrecoil04/18 12:31數值企劃戰鬥企劃等等

→

xxxrecoil04/18 12:31還有的企劃還要包GUI設計

→

xxxrecoil04/18 12:32我認為企劃最重要的能力是溝通

→

xxxrecoil04/18 12:32你要如何描述你腦袋的東西給美術、程式聽的懂

推

xsubarux04/18 12:34感謝分享

→

xxxrecoil04/18 12:35簡單明瞭的闡述你的核心玩法，通常你企劃寫一堆，結果

→

xxxrecoil04/18 12:35根本就只看標題就走神了

→

xxxrecoil04/18 12:40簡單來說，遊戲腦跟做遊戲的腦袋是不一樣的

推

nihilistrue04/18 12:40推第一句

推

kaj198304/18 12:41工程師最討厭就是寫規格書，通常都丟給文筆好的去搞

推

arrenwu04/18 12:44問題是proposal也只有強的工程師能寫啊 ==

→

arrenwu04/18 12:44其他人頂多是看了之後給你修改意見而已

→

chung200704/18 12:56Pm:可以幫我設計大概手掌大小的東西嗎,工程師：男生的

→

chung200704/18 12:56手掌？女生的手掌？小孩子的手掌？老人的手掌？pm:我

→

chung200704/18 12:56的手掌？工程師：拿尺囉給我

推

cactus4404/18 13:01企劃最重要的是共通能力和耐心+1

推

egg78104/18 13:02我要的是這種感覺

推

WhoChaos04/18 13:10其實樓上舉的例子

→

WhoChaos04/18 13:10工程師可以自己察知目標客群再取個尺寸

→

WhoChaos04/18 13:10但文化上工程師習慣把自己當成建設或除錯的無決策工具

→

WhoChaos04/18 13:10所以現實狀況確實跟樓上說的差不多

我覺得把自己職能應該要做好的工作好好做好，而不是丟給別人還要別人但書阿，對了，有些工程師是真的沒有決策權，只能"建議"而已

※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:15:04

推

edwin9601704/18 13:14推同樣合體有87種方法，然後還要看遊戲引擎跑不跑的

→

edwin9601704/18 13:14動會不會跟其他系統衝突

推

WhoChaos04/18 13:20那我只能為你感到可惜並非很好的工作環境

每家公司確實不同，但我不知道你有沒有遇過這樣的情境設計師寫了一份不清楚的規格，然後就像你講的工程師可以自己察知目標客群的使用習慣，然後跟設計師解釋以後也做了，但做出來設計師卻認為不是他預期的樣子這種問題有兩種狀況： 1. 設計師與工程師溝通有誤，或兩人想像的結果不同 2. 設計師不知道或根本不在乎也沒在聽今天東西要改，難道是設計師動手花時間去改嗎？如果可以，那應該是不用聘工程師了世界上確實不存在100%有效的溝通，但有些自己職責範圍內的工作做好，就能省下別人很多時間。

※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:28:27

→

WhoChaos04/18 13:34這我認同呀任何工作領域都有這個狀況

→

WhoChaos04/18 13:34只是在這裡爭論大概也不會發揮你想要的影響力

→

WhoChaos04/18 13:34但能讓你心情好一點的話倒是很好

推

as456597104/18 13:34看看版上那位辭職做遊戲的

推

chuckni04/18 13:34溝通超重要偏偏超難，以前有跟老闆溝通到心態炸裂的經驗

→