PTT推薦

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

看板C_Chat標題Re: [討論] 現實中有能讓外行人提遊戲企劃的管道嗎作者
EricTCartman
(阿ㄆㄧㄚˇ)
時間推噓15 推:15 噓:0 →:31

※ 引述《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溝通超重要偏偏超難,以前有跟老闆溝通到心態炸裂的經驗

chuckni04/18 13:34

針對溝通,其實業界有提出用DSL改善溝通的方法(不是UML) 雖然方法多得是,但肯學肯用的人倒不多就是了

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

chister04/18 13:54

Golu04/18 14:31企劃實行可行性還跟團隊規模、產品規模/類型、開發工具、設

Golu04/18 14:32計工具、專案排程等許多跟可能跟企劃本身看起來沒關係的要素

Golu04/18 14:33相互牽連,更不用說還有所謂的因為規格設計造成的技術債這種

Golu04/18 14:33外面看不到的潛在問題

Golu04/18 14:35甚至這些都還是"理性"上的產物,人為"感性"產生的氛圍還要踩

Golu04/18 14:35下去了才知道這泥潭有多深

Golu04/18 14:48此外,溝通工具、管理工具、管理策略等項目的自身疊代也能有

Golu04/18 14:49效提升項目的處理效率,但很多時候管理層只是使用了工具或者

Golu04/18 14:50策略後,就認為會自己調整變好不加以客製化以適合組織或者調

Golu04/18 14:50整組織的縱向與橫向訊息擴散的手段與強度,這樣也是徒勞

siyaoran04/19 10:08企劃的溝通能力就是需要有程式美術音樂的基礎 學習專門

siyaoran04/19 10:08領域用的專門用語

siyaoran04/19 10:09外行人之所以自稱自己是外行人 就是連花時間在這些專門

siyaoran04/19 10:09上都做不到 更何況日本也有企劃專門在教這些基礎