[魯蛇] 企劃提出的構想常常被程式打槍？

看板GameDesign作者 (笨嘎嘎)時間10年前 (2014/03/10 13:24), 編輯推噓20(20推 0噓 78→)
留言98則, 22人參與, 最新討論串1/2 (看更多)
如果不是此板討論的方向，麻煩版主請刪文，謝謝^^ 本人是在假日沒事自己寫小遊戲的程式魯蛇， 沒遊戲公司上班過^^ 最近在「www.你的新資.com」裡的「火版」看到某三間遊戲公司的文， 當然裡面不少情緒性的字眼與八卦，這些不是我想討論的範圍， 裡面有兩句話這樣寫的， 「好的企劃又怎樣，程式一句不行、不能、不想、以前就是這樣了直接打槍。 製作人一句要、不要、不然你想怎樣完全沒有要溝通的意思。」 就一個程式的角度來看，有點感觸， 不管是不是在遊戲公司上班，身為程式都會遇到這幾個為難之處。 01. 好的企劃又怎樣，程式一句不行、不能、不想、以前就是這樣了直接打槍。 也在「www.你的新資.com」裡的「火版」看到， 某企劃：「程式放大絕：『這不在規劃之內。』」，來打槍企劃的構想。 以我的角度來看，我會覺得沒有什麼是程式寫不出來的， 僅只在於「規畫階段」與「找對人」， 一旦到了正在CODING階段，或者上線階段，很難再改了。 個人常遇到的就是，需求有了，寫出來了，一切如同機械錶一樣的完美運作， 然後就會有新的需求進來，當然，上頭會希望你在「原本的架構上面新增功能」， 這時就陷入了地獄的無限迴圈， 新需求>改程式>新需求>改程式>…，程式不穩定，BUG一堆。 實務上「需求一直在變化」， 有些需求只要改個兩行程式碼就可以實現， 有些需求是要耗費長時間才有可能實現， 有些需求甚至要將架構整個重新設計才有可能實現， 更不用想說有些需求是要打掉重練才有可能實現… 身為一個程式，我知道需求會變， 我不會說「計畫趕不上變化」，而是要「變化也是在計畫之內」， 對於老鳥，上頭的需求+基本上都會預先想出可能會改變的地方，然後再寫， 對於菜鳥，上頭有什麼需求就寫，不會預想有其他變化，直接寫。 但是，再怎麼老的鳥也是會有改不出來的東西… 不是老鳥能力不足，而是在「現在的架構」寫不出來。 順帶一提，我也看過程式跟企劃嗆聲過： 「這個功能就是寫不出來，如果你可以你來寫，我的薪水讓你領。」 通常都是在系統上線了，然後又要求加某些做不出來的功能時， 才會聽到這句話… 另外，說不想作的那個程式有點威猛～ 02. 製作人一句要、不要、不然你想怎樣完全沒有要溝通的意思。 其實這也很為難， 我本身遇到的例子來講， 上頭直接說「別家有這樣的功能，我們也要有。」 或者「別家沒有這樣的功能，我們就不要畫蛇添足。」 為什麼？因為客戶的使用習慣，或者上頭想打保守牌。 就一個很現實的層面來講， 上頭放絕：「今天沒有那個功能，客戶就不會買單，公司就沒收入。」 如果是在規劃階段，程式一定沒問題。 如果是改舊的系統，程式一定都會叫，因為有時真的很難改。 就上頭的角度來看： 「我不管你怎麼做，就是一定要出來，不然沒收入。」 就下面的角度來看： 「在舊系統底下就改不出來，或會造成其他不可預計的錯誤，或不良好的使用者環境。」 不過，在實務上來講，幾乎都改的出來，只要不太誇張的需求。 有些是直接改舊系統， 或者不是改舊系統，而是寫新的輔助系統， 但通常會有一些問題，如：更改所需時間過長、BUG、速度變慢、改太大使用者混淆…等。 常常上頭有了突發奇想說要加某些功能， 評估後可行，但是所需時間太長，然後上頭就說不要… 或者改完後，客戶覺得難用，又改回之前的… =======我是分隔線======= 有個舊文章：[請益] 遊戲企劃數值 題目如下： 玩家的血量都是 200， 戰士攻擊力 50 ，攻擊距離為 1 ，攻擊速度為 4。 弓箭手攻擊 x ，攻擊距離為 4 ，攻擊速度為 1。 戰士受到攻擊時有50%的機率會加速， 縮短與弓箭手1/3的距離，請問弓箭手的攻擊力要多少， 兩個職業才會平衡？ 很認真的看過之後發現不少人的答案都不同， 我的算法跟想法如下，麻煩請各位驗證我的想法是否正確^^ 文長，請注意。 個人題目解釋： 1. 弓箭手與戰士同時攻擊 2. 攻擊回合>移動回合>攻擊回合>移動回合>… 3. 傷害per回合 = (攻擊力*攻擊速度)per回合 首先計算， 1. 以期望值來說：攻擊X次後，戰士才打得到弓箭手 每次受到攻擊，50%的機率縮短與弓箭手1/3的距離 => 以期望值來看，每次受到攻擊縮短與弓箭手1/6的距離 => 以期望值來看，每次受到攻擊剩下與弓箭手5/6的距離 => 問題：求 4*((5/6)^X)<1 ，問X最小需要多少？ => 解答：X=8 => 以期望值來看，攻擊8次後，戰士才進入到攻擊距離 => 所以第9次攻擊時，戰士才可以攻擊到弓箭手 2. 戰士要攻擊Y次才可以解決掉弓箭手？ 50*4*Y=200 => Y=1 3. 綜合1與2，經過9次攻擊，戰士才可以解決掉弓箭手， 為了平衡，在第9次攻擊時，戰士與弓箭手同時生命值為0， 那弓箭手的攻擊力=Z？ 9*Z=200 => Z=200/9 => 弓箭手攻擊力為200/9(對一半) 4. 以下驗證 第0回合： 戰 __ __ __ 弓 0 1 2 3 4 ====================== 第1回合：攻擊 戰 __ __ __ 弓 0 1 2 3 4 弓箭手攻擊次數：1次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*1 戰士給予弓箭手總傷害：(50*4)*0 第1回合：移動 戰 __ __ __ 弓 0 1 2 3 4 剩下距離距離=> 4*((5/6)^1) = 10/3 = 3又1/3 > 1 戰 __ __ __ 弓 0 1 2 3 3又1/3 ====================== 第2回合：攻擊 戰 __ __ __ 弓 0 1 2 3 3又1/3 弓箭手攻擊次數：2次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*2 戰士給予弓箭手總傷害：(50*4)*0 第2回合：移動 戰 __ __ __ 弓 0 1 2 3 3又1/3 剩下距離距離=> 4*((5/6)^2) = 25/9 = 2又7/9 > 1 戰 __ __ 弓 0 1 2 2又7/9 ====================== 第3回合：攻擊 戰 __ __ 弓 0 1 2 2又7/9 弓箭手攻擊次數：3次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*3 戰士給予弓箭手總傷害：(50*4)*0 第3回合：移動 戰 __ __ 弓 0 1 2 2又7/9 剩下距離距離=> 4*((5/6)^3) = 125/54 = 2又17/54 > 1 戰 __ __ 弓 0 1 2 2又17/54 ====================== 第4回合：攻擊 戰 __ __ 弓 0 1 2 2又17/54 弓箭手攻擊次數：4次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*4 戰士給予弓箭手總傷害：(50*4)*0 第4回合：移動 戰 __ __ 弓 0 1 2 2又17/54 剩下距離距離=> 4*((5/6)^4) = 625/324 = 1又301/324 > 1 戰 __ 弓 0 1 1又301/324 ====================== 第5回合：攻擊 戰 __ 弓 0 1 1又301/324 弓箭手攻擊次數：5次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*5 戰士給予弓箭手總傷害：(50*4)*0 第5回合：移動 戰 __ 弓 0 1 1又301/324 剩下距離距離=> 4*((5/6)^5) = 3125/1944 = 1又1181/1944 > 1 戰 __ 弓 0 1 1又1181/1944 ====================== 第6回合：攻擊 戰 __ 弓 0 1 1又1181/1944 弓箭手攻擊次數：6次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*6 戰士給予弓箭手總傷害：(50*4)*0 第6回合：移動 戰 __ 弓 0 1 1又1181/1944 剩下距離距離=> 4*((5/6)^6) = 15625/11664 = 1又3961/11664 > 1 戰 __ 弓 0 1 1又3961/11664 ====================== 第7回合：攻擊 戰 __ 弓 0 1 1又3961/11664 弓箭手攻擊次數：7次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*7 戰士給予弓箭手總傷害：(50*4)*0 第7回合：移動 戰 __ 弓 0 1 1又3961/11664 剩下距離距離=> 4*((5/6)^7) = 78125/69984 = 1又18141/69984 > 1 戰 __ 弓 0 1 1又18141/69984 ====================== 第8回合：攻擊 戰 __ 弓 0 1 1又18141/69984 弓箭手攻擊次數：8次 戰士攻擊次數：0次，不在攻擊距離內 弓箭手給予戰士總傷害：(Z*1)*8 戰士給予弓箭手總傷害：(50*4)*0 第8回合：移動 戰 __ 弓 0 1 1又18141/69984 剩下距離距離=> 4*((5/6)^8) = 390625/419904 < 1 戰 弓 0 390625/419904 ====================== 第9回合：攻擊 戰 弓 0 390625/419904 弓箭手攻擊次數：9次 戰士攻擊次數：1次 弓箭手給予戰士總傷害：(Z*1)*9 戰士給予弓箭手總傷害：(50*4)*1 = 200 => 弓箭手死亡 平衡：弓箭手死亡同時，戰士也同時死亡 => (Z*1)*9 = 200 => Z = 200/9 = 22又2/9 (對一半的解答) 回頭看題目 「請問弓箭手的攻擊力要多少，兩個職業才會平衡？」 由上面驗證推導出公式： 8Z < 200 && 9Z >= 200 => Z < 200/8 && Z >= 200/9 => 200/9 <= Z <200/8 => 22又2/9 <= Z <25 (解答) 如果弓箭手攻擊力為整數， 解答為 23 與 24 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 60.249.117.38 ※ 編輯: StupidGaGa 來自: 60.249.117.38 (03/10 13:32) ※ 編輯: StupidGaGa 來自: 60.249.117.38 (03/10 13:34) ※ 編輯: StupidGaGa 來自: 60.249.117.38 (03/10 13:41)
推
03/10 14:32, , 1F
www.22k.com
03/10 14:32, 1F
→
03/10 14:45, , 2F
不是www.22K.com，是我寫的太隱含了嗎？
03/10 14:45, 2F
→
03/10 17:23, , 3F
其實很常見的是 還沒有prototype以前這理論聽起來完美
03/10 17:23, 3F
→
03/10 17:23, , 4F
有了prototype以後發現這理論根本東落西落
03/10 17:23, 4F
→
03/10 17:23, , 5F
這時候倒霉的通常是程式 :D
03/10 17:23, 5F
→
03/10 18:25, , 6F
其實想轉遊戲業，雖然程式走到哪都會遇到一樣鳥事
03/10 18:25, 6F
→
03/10 18:26, , 7F
但是看到薪資後，恩～現在的公司根本天堂>///<
03/10 18:26, 7F
→
03/10 18:28, , 8F
企劃還是要會點基礎程式，不然某些需求會讓程式很無奈
03/10 18:28, 8F
推
03/10 20:19, , 9F
沒有什麼是程式寫不出來的 <<完全不認同
03/10 20:19, 9F
→
03/10 20:58, , 10F
樓上+1 而且程式有強者 也有魯蛇如我 價錢不同這樣XD
03/10 20:58, 10F
推
03/10 21:18, , 11F
那可以寫一個能繞過密碼解壓縮檔的程式嗎
03/10 21:18, 11F
推
03/10 21:23, , 12F
我是程式，企劃要功能我會開時間給他，要不要做他會決定(死
03/10 21:23, 12F
推
03/11 00:16, , 13F
理論上所有東西程式都做得到(包括破解密碼) 只是時間
03/11 00:16, 13F
→
03/11 00:16, , 14F
和薪水問題XD
03/11 00:16, 14F
→
03/11 00:33, , 15F
包括理論上不可行的東西嗎XD
03/11 00:33, 15F
推
03/11 01:03, , 16F
推真的不是什麼都做得出來..可能最近很少沒聽到太誇張的需
03/11 01:03, 16F
→
03/11 01:04, , 17F
求0.0 我家企劃都好棒
03/11 01:04, 17F
推
03/11 01:08, , 18F
經驗上太誇張的需求通常不是來自企畫 而是來自運營/老闆/外
03/11 01:08, 18F
→
03/11 01:08, , 19F
部各方不知名大大的意見之類的
03/11 01:08, 19F
→
03/11 01:09, , 20F
或者: 企劃被洗掉一批人 新來的想說應該要做成這樣
03/11 01:09, 20F
→
03/11 01:09, , 21F
殊不知如果要這樣做的話 要把已經蓋好的三層樓拆了之類的
03/11 01:09, 21F
推
03/11 08:30, , 22F
你遇過要壓你時間又不講道理只開需求的企劃嗎?
03/11 08:30, 22F
→
03/11 08:31, , 23F
我相信好的企劃一定是可以接納程式的建言的
03/11 08:31, 23F
→
03/11 08:31, , 24F
但是有些企劃/業務..他們會用他們認知的方法去寫程式
03/11 08:31, 24F
→
03/11 08:31, , 25F
"阿這個東西不是拉一拉就好了..."
03/11 08:31, 25F
→
03/11 08:32, , 26F
"這個計算法有很難嗎..你就拿什麼什麼去算嘛"
03/11 08:32, 26F
→
03/11 08:33, , 27F
'這個做不出來'.."老闆說要"..'沒辦法'.."老闆說要"
03/11 08:33, 27F
→
03/11 08:33, , 28F
沒有構想不出來的需求...只有不足的時間跟理論~~
03/11 08:33, 28F
※ 編輯: StupidGaGa 來自: 36.233.102.232 (03/11 08:52)
→
03/11 08:53, , 29F
通常我們家企劃開了需求出來，程式都會估時間給他
03/11 08:53, 29F
→
03/11 08:54, , 30F
太誇張或做不出來的也會跟契話講說為什麼會做不出來
03/11 08:54, 30F
→
03/11 08:57, , 31F
不過通常關係到公司生存的需求都是要硬著頭皮去做～
03/11 08:57, 31F
→
03/11 09:02, , 32F
基本上我們家企劃與程式人都很好^^
03/11 09:02, 32F
→
03/11 09:03, , 33F
多溝通的話其實可以少掉很多心結跟不愉快之類的
03/11 09:03, 33F
推
03/11 10:08, , 34F
他們開需求，我開時間，他們要壓...那就請他們多拜拜保佑
03/11 10:08, 34F
→
03/11 10:08, , 35F
真的生的出來~_~
03/11 10:08, 35F
推
03/11 10:45, , 36F
沒有什麼是程式寫不出來的 <- halting problem表示：
03/11 10:45, 36F
→
03/11 11:19, , 37F
如果溝通就能解決問題 那這世上哪會發生戰爭
03/11 11:19, 37F
→
03/11 11:28, , 38F
所以有溝通技巧課啊
03/11 11:28, 38F
還有 22 則推文
→
03/11 18:02, , 61F
真的就是沒救 連帶拖垮整個團隊
03/11 18:02, 61F
→
03/12 10:16, , 62F
@chenglap 還有一種實力不是專業是手段...XD
03/12 10:16, 62F
推
03/12 15:14, , 63F
有一些相對於實力的力，可概稱為虛力。
03/12 15:14, 63F
→
03/12 17:04, , 64F
還有一種力，叫做原力！？
03/12 17:04, 64F
→
03/12 17:05, , 65F
願原力與你同在。（May the force be with you.)
03/12 17:05, 65F
→
03/12 17:06, , 66F
另外，我下面的算法到底有沒有錯誤？還是有其他想法？
03/12 17:06, 66F
→
03/12 19:06, , 67F
抱歉我沒看...
03/12 19:06, 67F
推
03/12 21:17, , 68F
沒看+1
03/12 21:17, 68F
推
03/12 23:40, , 69F
其實還沒丟到老闆桌上以前，都是可以談的。企劃丟什麼
03/12 23:40, 69F
→
03/12 23:41, , 70F
天馬行空的東西，跟程式聊聊其實多少會知道哪些對哪些錯
03/12 23:41, 70F
→
03/12 23:41, , 71F
就怕那種先丟到老闆桌上以後再來跟程式談的.....
03/12 23:41, 71F
→
03/12 23:41, , 72F
其實我說句不客氣的老實話，會做遊戲的程式只有兩種
03/12 23:41, 72F
→
03/12 23:42, , 73F
要不就是想洗經驗，要不就是真的超有愛。
03/12 23:42, 73F
→
03/12 23:43, , 74F
這兩種，都是應該要好好談的，而不是去讓老闆壓RD
03/12 23:43, 74F
→
03/12 23:43, , 75F
(遊戲程式只有兩種這句話指的是台灣遊戲界)
03/12 23:43, 75F
→
03/13 17:26, , 76F
2種都是瘋子 想壓瘋子要有必死的決心！（重點錯
03/13 17:26, 76F
推
03/15 01:03, , 77F
一天到晚提意見要改 你去叫蓋房子的蓋好說要重蓋看看
03/15 01:03, 77F
推
03/15 01:06, , 78F
台灣要人改都想要今天提明天馬上要 誰鳥你啊...
03/15 01:06, 78F
推
03/15 06:10, , 79F
學數學的路過，你算的不對
03/15 06:10, 79F
→
03/15 06:11, , 80F
你用期望值的時候，固定了每次的移動為1/3單位
03/15 06:11, 80F
→
03/15 06:11, , 81F
跟原本的兩者間1/3的距離有出入
03/15 06:11, 81F
→
03/15 06:12, , 82F
就算是固定為1/3單位好了
03/15 06:12, 82F
→
03/15 06:12, , 83F
平衡應該是兩者獲勝的機率相同
03/15 06:12, 83F
→
03/15 06:13, , 84F
應該要算累積機率，而不是期望值
03/15 06:13, 84F
→
03/15 06:14, , 85F
BTW,我用了固定為1/3單位下去計算,結果漂亮的有點恐怖
03/15 06:14, 85F
→
03/15 06:16, , 86F
阿我笨了,結果是二項式定理,漂亮是必然的
03/15 06:16, 86F
推
03/15 06:27, , 87F
去爬了原文,如果原PO對平衡的理解也是前人那套
03/15 06:27, 87F
→
03/15 06:28, , 88F
那就又是另一個故事了
03/15 06:28, 88F
→
03/15 06:28, , 89F
但是一來我不認同,二來我想睡覺,所以先這樣吧
03/15 06:28, 89F
→
03/15 06:30, , 90F
附上我算的固定移動,獲勝機率相同http://ppt.cc/-dI4
03/15 06:30, 90F
→
03/15 06:34, , 91F
然後睡覺之前最後一瞥發現我忘了攻速問題
03/15 06:34, 91F
→
03/15 06:35, , 92F
所以會修正成200/18=11.111111111
03/15 06:35, 92F
→
03/15 06:36, , 93F
至於前面因為都是弓箭手單方面射所以沒差
03/15 06:36, 93F
→
03/15 06:37, , 94F
最後會影響的就剩攻擊模式還有回合的問題了
03/15 06:37, 94F
結果一推人的算法都不一樣，哈哈哈 到底有沒有正解阿~"~
→
03/15 09:09, , 95F
弓手可以往後跑不給戰士殺.
03/15 09:09, 95F
推
03/15 09:34, , 96F
弓手可以射到最後一格再往後跑, 等戰士不追了回頭射死他
03/15 09:34, 96F
→
03/16 06:23, , 97F
如果考慮到弓手往後移的情況 那戰士"突擊"之類的中距離技能是
03/16 06:23, 97F
→
03/16 06:23, , 98F
否也該考慮進來 這樣整個影響的點究竟會是這些技能還是數值?XD
03/16 06:23, 98F
※ 編輯: StupidGaGa 來自: 60.249.117.38 (03/19 14:11)
‣ 更多 StupidGaGa 的文章
文章代碼(AID): #1J7KoHap (GameDesign)
‣ 更多 StupidGaGa 的文章
文章代碼(AID): #1J7KoHap (GameDesign)