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

看板C_Chat作者 (阿ㄆㄧㄚˇ)時間4年前 (2021/04/18 12:27), 4年前編輯推噓15(15推 0噓 31→)
留言46則, 15人參與, 4年前最新討論串2/14 (看更多)
※ 引述《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
推
04/18 12:31, 4年前 , 1F
企劃還有一堆分類咧
04/18 12:31, 1F
→
04/18 12:31, 4年前 , 2F
數值企劃 戰鬥企劃 等等
04/18 12:31, 2F
→
04/18 12:31, 4年前 , 3F
還有的企劃還要包GUI設計
04/18 12:31, 3F
→
04/18 12:32, 4年前 , 4F
我認為企劃最重要的能力是溝通
04/18 12:32, 4F
→
04/18 12:32, 4年前 , 5F
你要如何描述你腦袋的東西給美術、程式聽的懂
04/18 12:32, 5F
推
04/18 12:34, 4年前 , 6F
感謝分享
04/18 12:34, 6F
→
04/18 12:35, 4年前 , 7F
簡單明瞭的闡述你的核心玩法，通常你企劃寫一堆，結果
04/18 12:35, 7F
→
04/18 12:35, 4年前 , 8F
根本就只看標題就走神了
04/18 12:35, 8F
→
04/18 12:40, 4年前 , 9F
簡單來說，遊戲腦跟做遊戲的腦袋是不一樣的
04/18 12:40, 9F
推
04/18 12:40, 4年前 , 10F
推第一句
04/18 12:40, 10F
推
04/18 12:41, 4年前 , 11F
工程師最討厭就是寫規格書，通常都丟給文筆好的去搞
04/18 12:41, 11F
推
04/18 12:44, 4年前 , 12F
問題是proposal也只有強的工程師能寫啊 ==
04/18 12:44, 12F
→
04/18 12:44, 4年前 , 13F
其他人頂多是看了之後給你修改意見而已
04/18 12:44, 13F
→
04/18 12:56, 4年前 , 14F
Pm:可以幫我設計大概手掌大小的東西嗎,工程師：男生的
04/18 12:56, 14F
→
04/18 12:56, 4年前 , 15F
手掌？女生的手掌？小孩子的手掌？老人的手掌？pm:我
04/18 12:56, 15F
→
04/18 12:56, 4年前 , 16F
的手掌？工程師：拿尺囉給我
04/18 12:56, 16F
推
04/18 13:01, 4年前 , 17F
企劃最重要的是共通能力和耐心+1
04/18 13:01, 17F
推
04/18 13:02, 4年前 , 18F
我要的是這種感覺
04/18 13:02, 18F
推
04/18 13:10, 4年前 , 19F
其實樓上舉的例子
04/18 13:10, 19F
→
04/18 13:10, 4年前 , 20F
工程師可以自己察知目標客群再取個尺寸
04/18 13:10, 20F
→
04/18 13:10, 4年前 , 21F
但文化上工程師習慣把自己當成建設或除錯的無決策工具
04/18 13:10, 21F
→
04/18 13:10, 4年前 , 22F
所以現實狀況確實跟樓上說的差不多
04/18 13:10, 22F
我覺得把自己職能應該要做好的工作好好做好，而不是丟給別人還要別人但書 阿，對了，有些工程師是真的沒有決策權，只能"建議"而已 ※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:15:04
推
04/18 13:14, 4年前 , 23F
推 同樣合體有87種方法，然後還要看遊戲引擎跑不跑的
04/18 13:14, 23F
→
04/18 13:14, 4年前 , 24F
動 會不會跟其他系統衝突
04/18 13:14, 24F
推
04/18 13:20, 4年前 , 25F
那我只能為你感到可惜 並非很好的工作環境
04/18 13:20, 25F
每家公司確實不同，但我不知道你有沒有遇過這樣的情境 設計師寫了一份不清楚的規格，然後就像你講的 工程師可以自己察知目標客群的使用習 慣，然後跟設計師解釋以後也做了，但做出來設計師卻認為不是他預期的樣子 這種問題有兩種狀況： 1. 設計師與工程師溝通有誤，或兩人想像的結果不同 2. 設計師不知道或根本不在乎也沒在聽 今天東西要改，難道是設計師動手花時間去改嗎？如果可以，那應該是不用聘工程師了 世界上確實不存在100%有效的溝通，但有些自己職責範圍內的工作做好，就能省下別人 很多時間。 ※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:28:27
→
04/18 13:34, 4年前 , 26F
這我認同呀 任何工作領域都有這個狀況
04/18 13:34, 26F
→
04/18 13:34, 4年前 , 27F
只是在這裡爭論大概也不會發揮你想要的影響力
04/18 13:34, 27F
→
04/18 13:34, 4年前 , 28F
但能讓你心情好一點的話倒是很好
04/18 13:34, 28F
推
04/18 13:34, 4年前 , 29F
看看版上那位辭職做遊戲的
04/18 13:34, 29F
推
04/18 13:34, 4年前 , 30F
溝通超重要偏偏超難，以前有跟老闆溝通到心態炸裂的經驗
04/18 13:34, 30F
→
04/18 13:34, 4年前 , 31F
過
04/18 13:34, 31F
針對溝通，其實業界有提出用DSL改善溝通的方法(不是UML) 雖然方法多得是，但肯學肯用的人倒不多就是了 ※ 編輯: EricTCartman (36.231.107.108 臺灣), 04/18/2021 13:41:10
推
04/18 13:54, 4年前 , 32F
推
04/18 13:54, 32F
推
04/18 14:31, 4年前 , 33F
企劃實行可行性還跟團隊規模、產品規模/類型、開發工具、設
04/18 14:31, 33F
→
04/18 14:32, 4年前 , 34F
計工具、專案排程等許多跟可能跟企劃本身看起來沒關係的要素
04/18 14:32, 34F
→
04/18 14:33, 4年前 , 35F
相互牽連，更不用說還有所謂的因為規格設計造成的技術債這種
04/18 14:33, 35F
→
04/18 14:33, 4年前 , 36F
外面看不到的潛在問題
04/18 14:33, 36F
→
04/18 14:35, 4年前 , 37F
甚至這些都還是"理性"上的產物，人為"感性"產生的氛圍還要踩
04/18 14:35, 37F
→
04/18 14:35, 4年前 , 38F
下去了才知道這泥潭有多深
04/18 14:35, 38F
→
04/18 14:48, 4年前 , 39F
此外，溝通工具、管理工具、管理策略等項目的自身疊代也能有
04/18 14:48, 39F
→
04/18 14:49, 4年前 , 40F
效提升項目的處理效率，但很多時候管理層只是使用了工具或者
04/18 14:49, 40F
→
04/18 14:50, 4年前 , 41F
策略後，就認為會自己調整變好不加以客製化以適合組織或者調
04/18 14:50, 41F
→
04/18 14:50, 4年前 , 42F
整組織的縱向與橫向訊息擴散的手段與強度，這樣也是徒勞
04/18 14:50, 42F
推
04/19 10:08, 4年前 , 43F
企劃的溝通能力就是需要有程式美術音樂的基礎 學習專門
04/19 10:08, 43F
→
04/19 10:08, 4年前 , 44F
領域用的專門用語
04/19 10:08, 44F
→
04/19 10:09, 4年前 , 45F
外行人之所以自稱自己是外行人 就是連花時間在這些專門
04/19 10:09, 45F
→
04/19 10:09, 4年前 , 46F
上都做不到 更何況日本也有企劃專門在教這些基礎
04/19 10:09, 46F
‣ 更多 EricTCartman 的文章
文章代碼(AID): #1WUxKpah (C_Chat)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 14 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共14篇)
‣ 更多 EricTCartman 的文章
文章代碼(AID): #1WUxKpah (C_Chat)