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

[EricTCartman (阿ㄆㄧㄚˇ)]

※ 引述《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.cc), 來自: 36.231.107.108 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1618720051.A.92B.html
推 xxxrecoil: 企劃還有一堆分類咧
→ xxxrecoil: 數值企劃 戰鬥企劃 等等
→ xxxrecoil: 還有的企劃還要包GUI設計
→ xxxrecoil: 我認為企劃最重要的能力是溝通
→ xxxrecoil: 你要如何描述你腦袋的東西給美術、程式聽的懂
推 xsubarux: 感謝分享
→ xxxrecoil: 簡單明瞭的闡述你的核心玩法，通常你企劃寫一堆，結果
→ xxxrecoil: 根本就只看標題就走神了
→ xxxrecoil: 簡單來說，遊戲腦跟做遊戲的腦袋是不一樣的
推 nihilistrue: 推第一句
推 kaj1983: 工程師最討厭就是寫規格書，通常都丟給文筆好的去搞
推 arrenwu: 問題是proposal也只有強的工程師能寫啊 ==
→ arrenwu: 其他人頂多是看了之後給你修改意見而已
→ chung2007: Pm:可以幫我設計大概手掌大小的東西嗎,工程師：男生的
→ chung2007: 手掌？女生的手掌？小孩子的手掌？老人的手掌？pm:我
→ chung2007: 的手掌？工程師：拿尺囉給我
推 cactus44: 企劃最重要的是共通能力和耐心+1
推 egg781: 我要的是這種感覺
推 WhoChaos: 其實樓上舉的例子
→ WhoChaos: 工程師可以自己察知目標客群再取個尺寸
→ WhoChaos: 但文化上工程師習慣把自己當成建設或除錯的無決策工具
→ WhoChaos: 所以現實狀況確實跟樓上說的差不多
我覺得把自己職能應該要做好的工作好好做好，而不是丟給別人還要別人但書


阿，對了，有些工程師是真的沒有決策權，只能"建議"而已
※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:15:04
推 edwin96017: 推 同樣合體有87種方法，然後還要看遊戲引擎跑不跑的
→ edwin96017: 動 會不會跟其他系統衝突
推 WhoChaos: 那我只能為你感到可惜 並非很好的工作環境
每家公司確實不同，但我不知道你有沒有遇過這樣的情境

設計師寫了一份不清楚的規格，然後就像你講的 工程師可以自己察知目標客群的使用習
慣，然後跟設計師解釋以後也做了，但做出來設計師卻認為不是他預期的樣子

這種問題有兩種狀況：
1. 設計師與工程師溝通有誤，或兩人想像的結果不同
2. 設計師不知道或根本不在乎也沒在聽

今天東西要改，難道是設計師動手花時間去改嗎？如果可以，那應該是不用聘工程師了

世界上確實不存在100%有效的溝通，但有些自己職責範圍內的工作做好，就能省下別人
很多時間。
※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:28:27
→ WhoChaos: 這我認同呀 任何工作領域都有這個狀況
→ WhoChaos: 只是在這裡爭論大概也不會發揮你想要的影響力
→ WhoChaos: 但能讓你心情好一點的話倒是很好
推 as4565971: 看看版上那位辭職做遊戲的
推 chuckni: 溝通超重要偏偏超難，以前有跟老闆溝通到心態炸裂的經驗
→ chuckni: 過
針對溝通，其實業界有提出用DSL改善溝通的方法(不是UML)
雖然方法多得是，但肯學肯用的人倒不多就是了

※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:41:10
推 chister: 推
推 Golu: 企劃實行可行性還跟團隊規模、產品規模/類型、開發工具、設
→ Golu: 計工具、專案排程等許多跟可能跟企劃本身看起來沒關係的要素
→ Golu: 相互牽連，更不用說還有所謂的因為規格設計造成的技術債這種
→ Golu: 外面看不到的潛在問題
→ Golu: 甚至這些都還是"理性"上的產物，人為"感性"產生的氛圍還要踩
→ Golu: 下去了才知道這泥潭有多深
→ Golu: 此外，溝通工具、管理工具、管理策略等項目的自身疊代也能有
→ Golu: 效提升項目的處理效率，但很多時候管理層只是使用了工具或者
→ Golu: 策略後，就認為會自己調整變好不加以客製化以適合組織或者調
→ Golu: 整組織的縱向與橫向訊息擴散的手段與強度，這樣也是徒勞
推 siyaoran: 企劃的溝通能力就是需要有程式美術音樂的基礎 學習專門
→ siyaoran: 領域用的專門用語
→ siyaoran: 外行人之所以自稱自己是外行人 就是連花時間在這些專門
→ siyaoran: 上都做不到 更何況日本也有企劃專門在教這些基礎